تانل‌ها

تانل یک سرور خارج را از طریق یک سرور واسط در شبکه‌ی محدود (سرور ایران) منتشر می‌کند. کلاینت‌ها به سرور ایران وصل می‌شوند و سرور خارج خودش به سرور ایران اتصال برقرار می‌کند، بنابراین سرور خارج به هیچ پورت ورودی باز نیاز ندارد.

نقشه‌ی زنده: هر تانل هر ۱۵ ثانیه تست می‌شود و نمودار ترافیک هر ثانیه به‌روز می‌شود.

flowchart LR
    Client(["Client"]) -->|"public port"| Relay["Iran server<br/>relay"]
    Foreign["Foreign server<br/>node or any server"] -->|"outbound connection<br/>chosen transport"| Relay
    Relay -.->|"forwarded ports"| Foreign

عامل تانل روی هر دو سرور به‌صورت سرویس مستقل اجرا می‌شود. پنل پیکربندی تانل را نگه می‌دارد و دستور نصب هر سمت را تولید می‌کند تا توکن و نقشه‌ی پورت‌ها دو بار تایپ نشوند؛ پس از نصب، پنل عامل را مدیریت نمی‌کند.

ایجاد تانل

تنظیم	کاربرد
نشانی و پورت سرور ایران	شنونده‌ی عمومی که کلاینت‌ها به آن وصل می‌شوند. پورت پیش‌فرض 8443 است.
سرور خارج	نودی که از قبل در پنل ثبت شده و نشانی آن استفاده می‌شود، یا هر سرور دیگری با نشانی آن.
ترنسپورت	روش اتصال سرور خارج به سرور ایران (جدول زیر).
SNI و دامنه	برای tls، wss و wssmux. برای دامنه می‌توان هنگام نصب گواهی Let’s Encrypt گرفت.
مسیر (Path)	برای ws، wss، wsmux و wssmux.
تعداد اتصال	تعداد اتصال‌های فیزیکی که سرور خارج باز نگه می‌دارد. پیش‌فرض 8 است.
پورت‌های فوروارد	نگاشت‌های نام‌دار پورت، هر کدام TCP یا UDP، از یک پورت سرور ایران به یک پورت سرور خارج.

برای هر تانل یک توکن به‌صورت خودکار ساخته می‌شود.

ترنسپورت‌ها

فرم چهار ترنسپورت پیشنهاد می‌دهد:

ترنسپورت	کاربرد
TCP چندگانه (tcpmux)	سریع‌ترین؛ سرور خارج مستقیم به سرور ایران وصل می‌شود.
TCP + Stealth (tcpstealth)	همان TCP چندگانه، با رمزنگاری کامل و پدینگ تصادفی؛ نه دست‌دادن متنی دارد نه اندازه‌ی بسته‌ی ثابت که DPI بشناسد. سرور ایران به هر اتصالی که تانل نباشد هیچ جوابی نمی‌دهد، پس پروب چیزی نمی‌فهمد.
WSS چندگانه (wssmux)	WebSocket روی TLS. مقاوم‌ترین در برابر فیلترینگ و تنها گزینه‌ای که از CDN عبور می‌کند.
UDP (KCP) (udp)	برای مسیرهایی که TCP در آن‌ها اختلال دارد.

تانل‌هایی که پیش‌تر با tcp، tls، ws، wss یا wsmux ساخته شده‌اند کار می‌کنند؛ هنگام ویرایش، ترنسپورتشان به‌صورت کارت «قدیمی» نمایش داده می‌شود.

عبور از CDN

با انتخاب WSS چندگانه، گزینه‌ی عبور از CDN باعث می‌شود سرور خارج به‌جای IP سرور ایران به یک دامنه‌ی CDN وصل شود؛ در نتیجه اگر IP سرور ایران فیلتر شود، تانل قطع نمی‌شود. در ایران ابر آروان پیشنهاد می‌شود؛ Cloudflare هم پشتیبانی می‌شود.

۱. تیک عبور از CDN را بزنید، ابر آروان یا Cloudflare را انتخاب کرده و دامنه‌ای را که به سرور ایران اشاره می‌کند وارد کنید.

۲. پنل SNI را همان دامنه قرار می‌دهد، یک مسیر WebSocket تصادفی می‌سازد و پورت را تنظیم می‌کند: در آروان پورت تانل همان پورت مبدأ است؛ Cloudflare فقط پورت‌های 443، 2053، 2083، 2087، 2096 و 8443 را عبور می‌دهد و با همان پورت به سرور ایران وصل می‌شود، پس پورت تانل همان پورت انتخابی خواهد بود.

۳. چک‌لیست زیر فرم را انجام دهید: رکورد A به سرور ایران با پروکسی CDN روشن، اتصال HTTPS به مبدأ روی پورت تانل (در Cloudflare حالت SSL روی Full) و روشن بودن WebSocket.

۴. تست اتصال یک مرحله‌ی مسیر CDN اضافه می‌کند: پنل یک درخواست واقعی WebSocket از طریق CDN به سرور ایران می‌فرستد و فقط با پاسخ 101 آن را سبز می‌کند.

ابر آروان ترافیک عبوری را محاسبه می‌کند، پس هرچه از تانل رد شود هزینه دارد.

کیفیت CDN

دکمه‌ی ⚡ کیفیت ابر آروان روی کارت تانل CDN سه تست واقعی را باز می‌کند. اگر سرور خارج نود پنل باشد تست‌ها روی همان سرور (ماشینی که واقعاً به CDN وصل می‌شود) اجرا می‌شوند، وگرنه روی سرور پنل؛ پنجره می‌گوید کدام.

• IP تمیز. حدود ۱۲۸ نشانی لبه از رنج‌های منتشرشده‌ی CDN، هر کدام با یک درخواست واقعی WebSocket تا سرور ایران تست می‌شوند؛ ده‌تای سریع‌تر سه بار دیگر تست شده و با زمان میانه، نوسان و تعداد موفقیت نمایش داده می‌شوند. سه‌تای بهتر خودکار انتخاب می‌شوند. لبه‌های ذخیره‌شده به‌صورت servers در کانفیگ سرور خارج قرار می‌گیرند: تانل اتصال‌هایش را بین آن‌ها پخش می‌کند و لبه‌ای را که جواب ندهد رد می‌کند.
• SNI جلو (Domain Fronting). سایت‌های شناخته‌شده‌ی ایرانی resolve می‌شوند تا معلوم شود کدام واقعاً روی همین CDN هستند؛ سپس هر کدام به‌عنوان نام TLS تست می‌شود در حالی که Host درخواست WebSocket دامنه‌ی شماست. فقط سایت‌هایی که واقعاً اتصال را تا سرور ایران رساندند پیشنهاد می‌شوند.
• تست سرعت واقعی. ۸ مگابایت از سرور ایران، از داخل CDN و با پروتکل خود تانل، با همان لبه و SNI ذخیره‌شده دانلود می‌شود و سرعت (Mbps) و پینگ گزارش می‌شود. قبل و بعد از هر تغییر اجرا کنید.

بعد از ذخیره، دستور نصب سمت خارج نمایش داده می‌شود؛ یک بار روی سرور خارج اجرایش کنید تا لبه‌ها و SNI جدید اعمال شوند. تست سرعت به نسخه‌ی جدید برنامه‌ی تانل روی سرور ایران هم نیاز دارد، پس دستور نصب سمت ایران را هم یک بار دوباره اجرا کنید.

با زدن تیک CDN، فرم تعداد اتصال را از ۸ به ۱۶ می‌برد، چون CDN سرعت هر اتصال را جداگانه محدود می‌کند.

رله‌ی پنهان (طعمه برای اسکن فعال)

رله‌ی WebSocket قبلاً به هر درخواستی که تانل نبود یک 404 خشک می‌داد. سروری که روی ۴۴۳ گواهی معتبر دارد و بعد فقط ۴۰۴ می‌دهد، خودش یک نشانه است: اسکن فعال — سیستمی که وصل می‌شود و جواب را نگاه می‌کند — آن آدرس را «سایت واقعی نیست» علامت می‌زند و آدرس می‌سوزد.

با روشن بودن رله‌ی پنهان (پیش‌فرض برای تانل‌های جدید ws/wss/wsmux/wssmux)، هر درخواستی که یک اتصال معتبر تانل نباشد — مرورگر، اسکنر، یا مسیر اشتباه — یک صفحه‌ی وب استاتیک معمولی با کد 200 می‌گیرد که با همان گواهی واقعی رله سرو می‌شود. اسکنر یک سایت عادی می‌بیند نه یک رله‌ی ساکت. کلاینت واقعی تانل (مسیر درست با آپگرید WebSocket) هیچ تأثیری نمی‌گیرد و مثل قبل وصل می‌شود.

• فقط روی transportهای مبتنی بر WebSocket اعمال می‌شود، چون فقط آن‌ها یک درخواست HTTP واقعی را که اسکنر می‌فرستد پاسخ می‌دهند. TCP + Stealth از قبل با سکوت جواب می‌دهد و دست‌نخورده می‌ماند.
• یک گزینه‌ی هر تانل است و فقط روی سمت ایران (سرور) اعمال می‌شود.
• تانل‌های موجود هیچ‌وقت تغییر نمی‌کنند: این گزینه برای تانل‌های قبلی پیش‌فرض خاموش است و فقط وقتی اثر می‌کند که تانل با آن ساخته شود یا دوباره نصب شود (دستور نصب سمت ایران را دوباره بزنید، یا 🔄 آپدیت تانل).

انتخاب ترنسپورت

پیش از ایجاد تانل، گزینه‌ی پیشنهاد بهترین ترنسپورت هر دو سرور را بررسی کرده، دسترس‌پذیری و تأخیر هر کدام را گزارش می‌کند و ترنسپورت‌ها را رتبه‌بندی می‌کند. این رتبه‌بندی بر پایه‌ی چیزی است که از بیرون شبکه‌ی محدود واقعاً قابل اندازه‌گیری است و نمی‌تواند رفتار فیلترینگ با هر ترنسپورت را پیش‌بینی کند؛ بنابراین ترنسپورت انتخابی را پس از نصب آزمایش کنید.

تست لینک

پیشنهاد بهترین ترنسپورت هر سرور را از بیرون بررسی می‌کند. برای اندازه‌گیری خود مسیری که تانل از آن رد می‌شود، تست لینک را بین دو سرور اجرا کنید: روی سرور ایران tifusi-tunnel linktest serve --port 8443 و بعد روی سرور خارج tifusi-tunnel linktest run --to <iran-ip> --port 8443. بسته‌های UDP زمان‌دار می‌فرستد و زمان handshake TCP را می‌گیرد، بعد پکت‌لاس UDP، زمان رفت‌وبرگشت (min/avg/p95/max) و jitter، تعداد handshakeهای موفق TCP و یک ترنسپورت پیشنهادی را چاپ می‌کند: روی مسیر تمیز tcpmux، و وقتی لاس یا jitter UDP بالاست یا handshake TCP شکست می‌خورد، udp (KCP با FEC). از پورتی استفاده کنید که روی سرور ایران باز است و در حال استفاده نیست.

نصب و آزمایش

۱. تانل را باز کرده و دستور نصب هر سمت را کپی کنید. این دستور هم مثل دستور نود، backend/tunnel_agent/install.sh را از تگ ریلیزِ هم‌نسخه با پنل می‌گیرد و فقط وقتی SHA-256 آن با چک‌سامِ ساخته‌شده در پنل یکی باشد اجرایش می‌کند.

۲. دستور سمت ایران را روی سرور ایران و دستور سمت خارج را روی سرور خارج اجرا کنید.

۳. گزینه‌ی تست اتصال را بزنید. پنل دسترسی به سرور ایران، سرور خارج و پورت عمومی تانل را بررسی کرده و وضعیت تانل را همراه با تأخیر و زمان بررسی، connected یا error ثبت می‌کند. تانل udp از بیرون قابل بررسی نیست؛ لاگ سرویس آن روی سرور ایران با journalctl -u tifusi خوانده می‌شود.

نصب و آپدیت با SSH

دکمه‌ی 🔑 نصب با SSH روی کارت تانل، نصب را برای هر سمت خودش انجام می‌دهد. این یک گزینه‌ی اضافه است؛ دستورهای یک‌خطی و دانلود بسته‌ی آفلاین مثل قبل کار می‌کنند.

1. آدرس SSH به‌طور پیش‌فرض همان آدرس خود تانل در آن سمت است (آدرس ایران، یا نود یا آدرس خارج)؛ فقط اگر SSH روی آدرس دیگری است عوضش کنید. رمز یا کلید خصوصی فقط برای اولین اتصال لازم است — پنل کلید خودش را (همان کلید نودها) نصب می‌کند و اتصال‌های بعدی چیزی لازم ندارند. هیچ رمزی ذخیره نمی‌شود و کلید سرور در اولین اتصال ثبت می‌شود.
2. حالت خودکار اگر سرور به گیت‌هاب دسترسی داشته باشد همان نصب آنلاین همیشگی را اجرا می‌کند، وگرنه بسته‌ی آفلاین همان سمت را با SFTP می‌فرستد و نصب می‌کند (اگر نصب آنلاین وسط کار خطا بدهد هم آفلاین امتحان می‌شود). آنلاین و آفلاین را می‌شود اجباری انتخاب کرد.
3. خروجی نصب زنده نمایش داده می‌شود؛ در صورت خطا آخرین خطوط لاگ سرویس تانل هم نشان داده می‌شود. هر نصب با تست سلامت تانل تمام می‌شود. بسته‌ی آفلاین برای نصب دوباره در روز قطعی روی سرور می‌ماند (0600).

دکمه‌ی 🔄 آپدیت تانل در همان شیت، سمتِ نصب‌شده را با برگشت خودکار به جدیدترین باینری می‌رساند: باینری جدید قبل از هر تغییری روی خود سرور با کانفیگ فعلی بررسی می‌شود، باینری قبلی با نام tifusi-tunnel.prev نگه داشته می‌شود و اگر سرویس بالا نماند یا لینک‌های فعال تانل ظرف ۴۵ ثانیه برنگردند، خودکار برمی‌گردد. کانفیگ هیچ‌وقت تغییر نمی‌کند. به‌روزرسانی امن را ببینید.

نصب و آپدیت با SSH فقط برای مالک پنل باز است.

زنجیره (مسیر چندمرحله‌ای)

زنجیره ترافیک را به‌جای یک رله از فهرست مرتبی از هاپ‌ها عبور می‌دهد: کاربر ← ورودی (ایران، عمومی) ← میانی ← … ← خروجی (سرور واقعی). کاملاً از همان تانل معکوس معمولی ساخته می‌شود و هیچ چیزِ برنامه‌ی تانل عوض نمی‌شود: N هاپ، N−۱ قطعه می‌سازد و هر قطعه یک تانل عادی با ترنسپورت خودش است — مثلاً TCP + Stealth داخل ایران و WSS Mux پشت CDN در خارج.

تانل‌ها ← 🔗 زنجیره‌ها را باز کن.

• هاپ‌ها. اولی ورودی است (آدرس عمومی که کاربر به آن وصل می‌شود)، آخری خروجی، و هرچه بینشان باشد میانی. هر هاپ جز خروجی، قطعه‌ی پایین‌دست خودش را نگه می‌دارد: ترنسپورت، پورت تانل، SNI/مسیر و تعداد کانکشن. هاپ بعدی به همان پورت وصل می‌شود، پس فقط ورودی و میانی‌ها پورت تانل ورودی لازم دارند، هرکدام روی پورت جدا.
• پورت‌های عبوری. کاربر روی یک پورت عمومی ورودی وصل می‌شود؛ خروجی به تارگت می‌رساند (پیش‌فرض 127.0.0.1). سرویس‌پورت پورت داخلی‌ای است که از هاپی به هاپ بعد حمل می‌شود.
• هاپ میانی دو سرویس اجرا می‌کند روی همان سرور — کلاینتِ قطعه‌ی بالا و سرورِ قطعه‌ی پایین — و ترافیک را روی 127.0.0.1 از یکی به دیگری می‌دهد، نه روی شبکه. پس پورت‌های عبوریِ میانی سوراخ فایروال نمی‌خواهند؛ فقط پورت تانل هر قطعه و پورت‌های عمومی ورودی باز می‌شوند.
• فقط پروتکل‌های اشتراک. زنجیره آنچه اشتراک می‌دهد را می‌برد (VLESS، VMess، Trojan، Shadowsocks، Hysteria2 روی TCP). IKEv2 و L2TP دستی روی گوشی تنظیم می‌شوند و از این مسیر نمی‌گذرند.

نصب و تست

هر هاپ جداگانه و با اعتبار SSH خودش نصب می‌شود، درست مثل هر سمت تانل (نصب و آپدیت با SSH): نصب این هاپ یک بار رمز آن سرور را می‌پرسد، کلید پنل را اضافه می‌کند، باینری تانل را با SFTP می‌فرستد و config هر سرویس (با مجوز ۰۶۰۰) و tifusi-<نام>.service را می‌نویسد. لاگ زنده نمایش داده می‌شود. تست زنجیره بعد پورت‌های عمومی ورودی را از پنل باز می‌کند — که فقط وقتی جواب می‌دهد که هر هاپ اتصال را تا خروجی رسانده باشد.

هر ۵ دقیقه پنل پورت تانل هر قطعه و پورت‌های TCP عمومی ورودی را هم می‌سنجد و نتیجه را روی زنجیره می‌نویسد و نام آنچه در دسترس نیست را می‌آورد. قطعه‌ها و پورت‌های UDP با اتصال TCP قابل بررسی نیستند و کنار گذاشته می‌شوند، پس زنجیره‌ی فقط-UDP «آماده‌ی نصب» می‌ماند و خراب علامت نمی‌خورد.

زنجیره‌ها فقط برای مالک پنل‌اند و یک زنجیره هیچ‌وقت تانل موجود را تغییر نمی‌دهد.

IP واقعی کاربر (PROXY protocol)

پشت تانل، همه‌ی اتصال‌ها از خود تانل به سرویس خارج می‌رسند؛ پس محدودیت دستگاهی که دستگاه‌ها را با نشانی از هم جدا می‌کند، همه‌ی گوشی‌های یک کاربر را یک دستگاه می‌بیند. با زدن تیک IP واقعی (PROXY) روی یک فوروارد TCP، سمت خارج هر اتصال را با یک هدر PROXY protocol v2 که نشانی و پورت واقعی کاربر را دارد به مقصد باز می‌کند.

مقصد باید منتظر این هدر باشد: در Xray مقدار "acceptProxyProtocol": true را در streamSettings.sockopt همان inbound (یا tcpSettings/wsSettings) بگذارید. سرویسی که منتظرش نباشد هدر را داده‌ی خراب می‌خواند و اتصال قطع می‌شود؛ پس برای تانل یک inbound جدا روی پورت دیگر بسازید و آن را روی inboundی که کاربران مستقیم هم به آن وصل می‌شوند روشن نکنید. فوروارد UDP این هدر را ندارد؛ محدودیت IKEv2 و L2TP بر اساس تعداد session هر کاربر است و به آن نیازی ندارد.

تست IP Spoofing

برخی انواع تانل به این وابسته‌اند که دیتاسنتر سرور ایران اجازه دهد بسته‌هایی با نشانی مبدأ جعلی از شبکه‌اش خارج شوند. کارت IP Spoofing در بخش انتخاب ترنسپورت دو دستور، یکی برای هر سرور، تولید می‌کند که پیش از ساخت چنین تانلی این موضوع را بررسی می‌کنند. تا زمانی که دستورها روی سرورها اجرا نشوند، هیچ کاری روی آن‌ها انجام نمی‌شود.

• پروتکل. بسته‌های تست می‌توانند با UDP، ICMP، ICMPv6 یا TCP فرستاده شوند. ممکن است دیتاسنتر یا فیلتر UDP جعلی را ببندد ولی پروتکل دیگری را رد کند؛ پس هر پروتکلی را که ممکن است استفاده کنید جدا تست کنید. همه به‌جز UDP روی سرور گیرنده هم دسترسی root لازم دارند.
• جهت. تانل در هر دو جهت مبدأ جعلی می‌گذارد، پس تست را در هر دو جهت اجرا کنید: ایران ← خارج و خارج ← ایران.
• پکت‌لاس هر مبدأ. گیرنده هر مبدأ جعلی‌ای را که رسیده همراه با تعداد بسته‌های رسیده نشان می‌دهد، مثلاً 5/5 packets loss 0%. با تنظیم حداکثر پکت‌لاس قابل قبول، مبدأیی که از آن بیشتر لاس داشته باشد با x علامت می‌خورد و قابل استفاده حساب نمی‌شود.

همین تست در خط فرمان tifusi-tunnel spooftest recv|send --proto udp|icmp|icmpv6|tcp است؛ recv --max-loss N --out file مبدأهای قابل استفاده را خط به خط در فایل می‌نویسد تا به‌عنوان لیست مبدأ جعلی سمت مقابل استفاده شوند.

تانل Spoof

تانل Spoof روی هر بسته یک نشانی مبدأ جعلی می‌گذارد تا از فیلتری که بر اساس نشانی مبدأ و مقصد لیست سفید دارد عبور کند. دیتاسنتر هر دو سرور باید اجازه‌ی خروج بسته‌ی جعلی را بدهد؛ اول با تست IP Spoofing بررسی کنید.

تنظیم	کاربرد
مبدأ جعلی	نشانی جعلی، یا لیست، رنج (a-b) یا CIDR که برای هر بسته چرخشی استفاده می‌شود.
حامل	بسته‌های جعلی روی سیم چه شکلی داشته باشند: UDP، ICMP (Echo Reply)، ICMPv6 (Echo Reply داخل IPv4، پروتکل ۵۸) یا TCP (سگمنت PSH|ACK). خودکار همه را امتحان می‌کند و روی یکی که کار کند می‌ماند.
حامل مسیر برگشت	اختیاری. حامل جهت خارج ← ایران وقتی باید با حامل بالا فرق داشته باشد؛ در این حالت حامل بالا فقط برای ایران ← خارج است. مثلاً رفت با TCP و برگشت با ICMPv6، چون فیلتر اغلب دو جهت را متفاوت برخورد می‌کند. پنل هر سمت را برعکس سمت دیگر تنظیم می‌کند. با خودکار در دسترس نیست.
استتار پیشرفته	TTL، DSCP و پورت مبدأ را تصادفی می‌کند و فقط بسته‌های همان مبدأ جعلی را می‌پذیرد.

وقتی ICMP بسته است، ICMPv6 ارزش امتحان دارد: فایروالی که IPv6 را می‌بندد اغلب با خود ICMPv6 کاری ندارد، و قانونی که برای ICMP نوشته شده روی آن اعمال نمی‌شود.

حامل‌های TCP، ICMP و ICMPv6 تا وقتی تانل روشن است قوانین iptables خودشان را اضافه می‌کنند و وقتی متوقف شود برشان می‌دارند. وگرنه فایروال سرور یک Echo Reply بدون درخواست، یا سگمنت TCP بدون دست‌دادن اولیه را INVALID حساب می‌کند و دور می‌ریزد (ufw به‌طور پیش‌فرض همین کار را می‌کند)؛ برای همین این بسته‌ها از ردیابی اتصال معاف و پذیرفته می‌شوند. حامل TCP پاسخ‌های RST کرنل به مبدأهای جعلی را هم دور می‌ریزد، فقط RSTهای خالی را، تا یک سرویس TCP واقعی روی همان پورت RSTهای خودش را نگه دارد.

تانل و IKEv2 یا L2TP

برای عبور IKEv2 یا L2TP بومی از تانل، پورت‌های UDP 500 و 4500 را از سرور ایران به سرور خارج فوروارد کنید، و برای کلاینت‌های L2TP بدون IPsec پورت UDP 1701 را هم اضافه کنید. هاستی که برای کاربران منتشر می‌شود باید به نشانی سرور ایران اشاره کند.

سرور ایران IKEv2 (UDP 500 و 4500) را به نشانی خود سرور خارج تحویل می‌دهد، نه 127.0.0.1؛ پس سمت خارج تانل (نود یا نشانی) باید مشخص باشد. اگر به loopback تحویل داده شود، سرور هر گوشی را 127.0.0.2 می‌بیند و هرگز نمی‌تواند پاسخ رمزشده را برایش بفرستد: گوشی وصل می‌شود ولی ترافیکی ندارد. تانلی که پیش از این تغییر نصب شده، تا وقتی دستور نصب سمت ایرانش دوباره اجرا نشود، همان مقصد قبلی را نگه می‌دارد.