IpManipulator
📖 معرفی کلی
| ویژگی | مقدار | توضیح |
|---|---|---|
| نوع نود | Tunnel (دوجهته) | ترافیک از هر دو جهت عبور میکند و کانکشن مفهومی ندارد. |
| لایه شبکه | لایه ۳ | کار با بستهها (Packet) بدون تغییر اندازهی آنها |
| موقعیت در زنجیر | وسط زنجیر | فقط در وسط زنجیر قابل استفاده است |
| وابستگی | نود قبل و بعد | برای دریافت/ارسال داده ضروری است |
این نود یکی از اصلیترین نودهای لایه ۳ واتروال است؛ معمولاً ترفندهایی که میخواهیم روی پکتها برای عبور از فیلترینگ اعمال کنیم را در این نود پیادهسازی میکنیم.
در نسخهٔ کنونی واتروال، این نود از ۳ ترفند پشتیبانی میکند که در ادامه به هر کدام میپردازیم.
عملکرد
ساختار کلی استفاده از این نود:
{
"name": "node_name",
"type": "IpManipulator",
"settings": {
// per trick settings
},
"next": "next_node_name"
}
ترفند شماره ۱: تغییر IP Payload Identifier
هر پکت لایهٔ IP (چه نسخه ۴ و چه نسخه ۶) یک payload حمل میکند که نوع آن با یک عدد به نام identifier مشخص میشود.
این عدد مشخص میکند که پکت، دادهٔ TCP، UDP، ICMP، IGMP و ... را حمل میکند.
لیست کامل این اعداد در لینک زیر موجود است:
📋 پروتکلهای IP
در این ترفند، پکتهایی که از سمت چپ به راست عبور میکنند بررسی میشوند؛ اگر پکت از نوع TCP بود (identifier = 6)، مقدار آن را به یک عدد دیگر تغییر میدهیم.
این کار زمانی مفید است که فایروال بین سرور ایران و خارج در پردازش انواع دیگر پروتکلها نقطهضعف داشته باشد یا آنها را نادیده بگیرد؛ در نتیجه میتوان از این رفتار بهره برد.
برای این کار، این تنظیم را ست کنید:
{
"protoswap-tcp": <number>
}
این نود هنگام برگشت پکت (مسیر راست به چپ) عمل معکوس را انجام میدهد؛ یعنی اگر identifier با آن عدد برابر بود، آن را به شمارهٔ ۶ (TCP) برمیگرداند.
این روش تونل در عمل خوب بوده و من بیش از ۲ ماه از آن استفاده کردهام و مشکلی نخوردهام (اگرچه توسط برخی دوستان مشکلاتی مانند فیلتر شدن یا «IranAccess» گزارش شده است).
به نظر میرسد این موارد میتواند به عوامل دیگری هم مرتبط باشد و نمیتوان همیشه مشکل را به تونل نسبت داد؛ چون اگر این روش قرار بود به طور کامل فیلتر شود، برای همه بهصورت یکسان اتفاق میافتاد، نه برای تعداد محدودی کاربر خاص.
همچنین دقت کنید عددی که انتخاب میکنید در احتمال فیلتر شدن مؤثر است. شخصاً دیدهام برخی اعداد بیمعنا باعث میشوند بین ۱ تا ۳ روز IP سرور خارج فیلتر شود، اما برخی اعداد منطقی تا این لحظه برای من بدون مشکل (فیلتر یا اکسس) بودهاند.
اگر بخواهید روشی مثل WireGuard (که UDP است) را تونل کنید و از این مزیت استفاده کنید، کافی است تنظیم زیر را اضافه کنید:
{
"protoswap-udp": <number>
}
میتوانید هر دو تنظیم را همزمان داشته باشید و هم TCP و هم UDP را تغییر دهید؛ اما دقت کنید:
- protoswap-udp
- protoswap-tcp
نباید با هم یکسان باشند! ⚠️
همچنین در سمت سرور خارج باید همین نود با همین تنظیمات فعال باشد تا آنجا پکتها به شکل صحیح برگردانده شوند.
ترفند شماره ۲: بازی با بیتهای پروتکل TCP
میتوانید با تغییر بیتهای TCP فایروال را در پردازش پکتها گیج کنید.
برای این کار به تنظیمات زیر دسترسی دارید. بهعنوان مثال:
"up-tcp-bit-ack": "packet->fin",
"up-tcp-bit-fin": "packet->ack",
"dw-tcp-bit-fin": "packet->ack",
"dw-tcp-bit-ack": "packet->fin"
📝 توضیحات:
به ابتدای تنظیمات دقت کنید:
- up: تنظیمات پکتهایی که از سمت چپ به راست این نود حرکت میکنند
- dw: تنظیمات پکتهایی که از سمت راست به چپ این نود حرکت میکنند
⚡ نکتهٔ مهم: اعمال تغییر بیتها بهصورت همزمان انجام میشود و خطبهخط نیست.
🔄 مثال:
- "up-tcp-bit-ack": "packet->fin" یعنی بیت ack مقدارش از بیت fin پکت اصلی خوانده شود.
- پکت اصلی تا پایان عملیات تغییر نمیکند؛ بنابراین در خط بعدی میتوانیم از مقدار ack پکت اصلی برای ساختن بیت fin پکت جدید استفاده کنیم.
در سمت سرور خارج باید بیتها را به حالت اول برگردانید و سپس پکت را به سیستمعامل تحویل دهید. در مثال ما این تنظیمات لازم است:
"up-tcp-bit-ack": "packet->fin",
"up-tcp-bit-fin": "packet->ack",
"dw-tcp-bit-fin": "packet->ack",
"dw-tcp-bit-ack": "packet->fin"
توضیحات تکمیلی:
میتوانید تمام بیتها را تغییر دهید؛ تنظیمات در اختیار شماست:
"up-tcp-bit-cwr": <string>,
"up-tcp-bit-ece": <string>,
"up-tcp-bit-urg": <string>,
"up-tcp-bit-ack": <string>,
"up-tcp-bit-psh": <string>,
"up-tcp-bit-rst": <string>,
"up-tcp-bit-syn": <string>,
"up-tcp-bit-fin": <string>,
"dw-tcp-bit-cwr": <string>,
"dw-tcp-bit-ece": <string>,
"dw-tcp-bit-urg": <string>,
"dw-tcp-bit-ack": <string>,
"dw-tcp-bit-psh": <string>,
"dw-tcp-bit-rst": <string>,
"dw-tcp-bit-syn": <string>,
"dw-tcp-bit-fin": <string>
و هر کدام را میتوانید به این شکلها ست کنید:
"off", "on", "packet->cwr", "packet->ece", "packet->urg", "packet->ack", "packet->psh", "packet->rst", "packet->syn", "packet->fin"
🧩 ترفند تکهتکه کردن پکتها (SNI Blender)
با همین نود IpManipulator میتوانید پکتهای TlsClientHello را به پکتهای لایهٔ IP تکهتکه کنید.
🎯 کاربردها
- 🔒 برای تونل زدن، دامنه را مخفی کنید
- ☁️ تونل به Cloudflare
- 🌐 در حالت «سرورلس»، سایتهای پشت CDN مثل یوتیوب را باز کنید
🔄 تفاوت با روشهای دیگر
این روش با fragmenting معرفیشده توسط gfw-knocker متفاوت است.
⚙️ نحوهٔ کار
- پکت ClientHello به پکتهای لایهٔ IP تکهتکه میشود
- سپس با ترتیب تصادفی ارسال میشود
- تعداد پکتها در تنظیمات قابل تغییر است (عدد ۴ معمولاً مناسب است)
📊 نتایج تست
- ❌ همراه اول: در برخی فایروالها این نوع پکت کلاً drop میشود
- ✅ ایرانسل: باعث باز شدن سایتهای فیلتر پشت CDN شد (یوتیوب و ...)
- 🖥️ تست روی ویندوز: چون نیازی به سرور نداشت
⚠️ هشدار: روی همهٔ شبکهها جواب نمیدهد، اما روشی جدید و قابل بررسی است.
🛠️ پیادهسازی
برای این ترفند، در سرور خارج واتروال کاری انجام نمیدهد. در سرور ایران، کانفیگ شما بهصورت عادی به پورت ۴۴۳ سرور خارج وصل میشود.
⚠️ نیاز: کانفیگی که دست کاربر است باید TLS داشته باشد. اگر ندارد، باید در واتروال به زنجیر نودهای TlsClient/TlsServer را اضافه کنید.
در کل سرور ایران باید به سرور خارج اتصال TLS برقرار کند تا این ترفند بتواند دامنه را تشخیص دهد و آن را تکهتکه کند.
اگر در خود Xray، TLS فعال باشد (یعنی کانفیگ کاربر هم TLS است) نیازی نیست واتروال در سرور خارج اجرا شود.
در غیر این صورت باید با واتروال یک TLS tunnel بسازید که در این حالت، در سرور خارج نیز برای نود TlsServer لازم است واتروال اجرا شود.
اگر قصد تونل به Cloudflare را دارید، واتروال فقط روی سرور ایران کافی است اجرا شود.
امیدوارم توضیحات این بخش واضح بوده باشد؛ درک کامل آن نیازمند آشنایی بیشتر با شبکه و TLS است.
میتوانید لینک این آموزش را به یک مدل هوش مصنوعی بدهید تا دربارهٔ بخشهای مختلف آن سؤال کنید و جزئیات بیشتری بگیرید.
برای فعالسازی این قابلیت، این مقادیر را تنظیم کنید:
"sni-blender": true,
"sni-blender-packets": 4
📝 نکته: در اینجا تنها کافی است IP سرور ایران و خارج را تنظیم کنید.
💻 استفاده در ویندوز
در حالت سرورلس نیز میتوانید همین کانفیگ را روی ویندوز اجرا کنید، اما باید:
- روتینگ ویندوز را تغییر دهید (دستور دارد)
- پکتهای دریافتی از IPهای مختلف را capture کنید
مرجع بهروز تنظیمات
در نسخه فعلی سورس، IpManipulator ترفندهای بیشتری از متن قدیمی بالا دارد. حداقل یک ترفند باید در settings فعال باشد؛ اگر هیچ گزینهای فعال نباشد، ساخت نود fail میشود.
Protocol swap
| گزینه | توضیح |
|---|---|
protoswap | alias برای protoswap-tcp |
protoswap-tcp | جایگزین کردن IP protocol number برای packetهای TCP |
protoswap-tcp-2 | عدد دوم اختیاری؛ TCPها بین دو عدد alternate میشوند |
protoswap-udp | جایگزین کردن IP protocol number برای UDP |
اگر packet برگشتی با عدد جایگزین match شود، نود آن را به TCP یا UDP عادی برمیگرداند و checksum recalculation را علامت میزند.
SNI blender
| گزینه | توضیح |
|---|---|
sni-blender | فعالسازی fragmentation و shuffle برای TLS ClientHello |
sni-blender-packets | تعداد fragmentها؛ مقدار معتبر فعلی 1 تا 16 |
این ترفند upstream-only است، فقط IPv4/TCP ClientHello را بررسی میکند، packetهای قبلا fragmented را skip میکند و SNI را rewrite نمیکند؛ فقط شکل IP fragmentation را عوض میکند.
Packet duplicate
| گزینه | توضیح |
|---|---|
packet-duplicate | هر packet نهایی را این تعداد بار duplicate میکند و سپس original را هم میفرستد |
این مرحله بعد از بقیه ترفندهای فعال اجرا میشود.
first-sni
| گزینه | پیشفرض | توضیح |
|---|---|---|
first-sni | - | ساخت یک کپی fake از ClientHello با این SNI و ارسال آن قبل از original |
first-sni-ttl | - | TTL برای packet fake |
first-sni-count | 1 | تعداد replayهای fake |
first-sni-replay-delay | 0 | فاصله replayهای fake |
first-sni-final-delay | 0 | فاصله آخرین fake تا original |
first-sni-random-tcp-sequence | false | random کردن TCP sequence در fake packet |
اگر ClientHello شامل TLS 1.3 PSK binder باشد و تغییر SNI نیاز به recompute binder داشته باشد، ترفند محافظهکارانه skip میشود.
smuggle-sni
| گزینه | پیشفرض | توضیح |
|---|---|---|
smuggle-sni | - | ساخت fake ClientHello با این SNI |
smuggle-sni-delay-ms | 0 | تاخیر ارسال fake روی مسیر normal |
real-sni-upstream-node | اجباری | شاخهای که real ClientHello فورا به آن فرستاده میشود |
real-sni-upstream-node باید یک branch جدا باشد، نه همان next معمولی.
overlap-sni
| گزینه | پیشفرض | توضیح |
|---|---|---|
overlap-sni | - | ساخت Chrome-like fake ClientHello و overlap کردن روی sequence range |
overlap-sni-delay-ms | 0 | تاخیر packetهای بعد از fake SYN |
overlap-sni-syn-ttl | - | TTL برای fake SYN |
crafted-server-hello-upstream-node | اجباری | branch جدا برای crafted server-side TLS packet |
smuggle-sni و overlap-sni همزمان قابل استفاده نیستند.
ech-sni-trick
| گزینه | پیشفرض | توضیح |
|---|---|---|
ech-sni-trick | - | فعالسازی ترفند ECH-aware؛ باید با TlsClient.settings.ech-sni-trick هماهنگ باشد |
data-shard-1-delay | 0 | تاخیر آزاد کردن original packetها بعد از ارسال fake inner ClientHello |
data-shard-2-delay | 0 | فعلا برای compatibility پذیرفته میشود ولی در پیادهسازی فعلی استفاده عملی ندارد |
این ترفند fake ClientHello را از داخل GREASE encrypted_client_hello payload پیدا میکند و آن byte range را به صورت out-of-order TCP segment میفرستد، سپس original bytes را بدون تغییر آزاد میکند.
ech-sni-trick، smuggle-sni، overlap-sni و synfin-sni در طراحی فعلی mutually exclusive هستند.
synfin-sni
| گزینه | پیشفرض | توضیح |
|---|---|---|
synfin-sni | - | ساخت fake ClientHello همراه با real-first chunk، close packet و fake SYN |
synfin-sni-additional-range-min | 0 | حداقل byte اضافه از real ClientHello در chunk اول |
synfin-sni-additional-range-max | 0 | حداکثر byte اضافه؛ هر flow یک مقدار random در بازه میگیرد |
synfin-sni-syn-ttl | - | TTL برای fake SYN |
synfin-sni-fin-ttl | - | TTL برای close packet |
synfin-sni-fake-ttl | - | TTL برای full crafted fake ClientHello |
synfin-sni-random-syn-checksum | false | random کردن checksumهای fake SYN |
synfin-sni-random-fin-checksum | false | random کردن checksumهای close packet |
synfin-sni-random-syn-sequence | false | random کردن sequence fake SYN |
synfin-sni-random-fin-sequence | false | random کردن sequence close packet |
synfin-sni-use-rst | false | استفاده از `RST |
اگر TTL را 0 بگذارید، واقعا TTL صفر ست میشود. اگر میخواهید TTL اصلی حفظ شود، کلید TTL را حذف کنید.
smuggle-fin
| گزینه | پیشفرض | توضیح |
|---|---|---|
smuggle-fin | false | ساخت FIN/ACK mirrored روی شاخه جدا |
fin-sni-delay-ms | 0 | تاخیر replay کردن queue بعد از echoed FIN/ACK |
real-fin-upstream-node | اجباری | branch جدا برای crafted mirrored FIN/ACK |
TCP bit rewrite
کلیدها با این prefixها ساخته میشوند:
up-tcp-bit-...
dw-tcp-bit-...
suffixهای پشتیبانیشده:
cwr, ece, urg, ack, psh, rst, syn, fin
نمونه:
{
"up-tcp-bit-ack": "packet->fin",
"up-tcp-bit-fin": "packet->ack",
"dw-tcp-bit-psh": "toggle"
}
کلیدهای رایج دیگر همین خانواده شامل up-tcp-bit-ack، up-tcp-bit-fin، dw-tcp-bit-psh و dw-tcp-bit-rst هستند؛ برای بقیه بیتها هم همان الگو با suffixهای جدول بالا استفاده میشود.
مقدارهای پشتیبانیشده:
off, on, toggle, flip, switch,
packet->cwr, packet->ece, packet->urg, packet->ack,
packet->psh, packet->rst, packet->syn, packet->fin
flip و switch alias برای toggle هستند.
| گزینه | توضیح |
|---|---|
bit-transport | اگر true باشد، جهت rewrite شده byte اصلی TCP flags را انتهای payload حمل میکند تا سمت دیگر بتواند restore کند |
Port ghost
| گزینه | توضیح |
|---|---|
source-port-ghost | original source port را انتهای payload میگذارد و source port زنده را به high port deterministic تغییر میدهد |
dest-port-ghost | original destination port را انتهای payload میگذارد و destination port زنده را تغییر میدهد |
اگر هر دو فعال باشند، اول source port و بعد destination port append میشود.
نکتههای مهم
- بیشتر ترفندهای SNI فقط upstream و فقط روی IPv4/TCP ClientHello کار میکنند.
- packetهای fragmented معمولا برای ترفندهایی که نیاز به TCP header کامل دارند skip میشوند.
- این نود pure packet tunnel است؛ آن را مثل stream tunnel معمولی با lifecycle اتصال استفاده نکنید.
- اگر چند branch helper مثل
real-sni-upstream-nodeیاcrafted-server-hello-upstream-nodeتعریف میکنید، آنها را ازnextاصلی جدا نگه دارید.