تانل معکوس چیست؟ راهنمای کامل Reverse Tunnel برای دسترسی به سرور پشت NAT

تانل معکوس چیست؟

در حالت عادی، اتصال از سمت شما شروع می‌شود و مستقیم به آی‌پی و پورت سرور مقصد می‌رسد؛ پس مقصد باید آی‌پی عمومی داشته باشد و فایروالِ سر راه، اتصال ورودی را بپذیرد. سرور دفتر پشت NAT، سرور خانگی روی اینترنتی با CGNAT یا سرور داخل شبکهٔ سازمانی که هیچ پورت ورودی‌ای باز نمی‌کند، این شرایط را ندارند. تانل معکوس برای همین وضعیت ساخته شده است: جهت شروع اتصال را برعکس می‌کند.

در تانل معکوس، سرورِ داخلی (که به آن «کلاینت تانل» هم می‌گویند) یک اتصال خروجی به سرور واسطی برقرار می‌کند که آی‌پی عمومی دارد. اتصال خروجی تقریباً در همهٔ شبکه‌ها مجاز است. سرور واسط، که در این مقاله به آن رله می‌گوییم، روی یکی از پورت‌هایش منتظر می‌ماند و هر درخواستی را که به آن پورت برسد، از داخل همان اتصالِ باز به سرور داخلی می‌فرستد. پاسخ هم از همین مسیر برمی‌گردد.

در منابع فارسی نام‌های «تانل معکوس»، «تانل ریورس» و «تونل معکوس» همه به همین مفهوم اشاره دارند و در مستندات انگلیسی اصطلاح‌های Reverse Tunnel و Remote Port Forwarding را می‌بینید.

تانل معکوس چطور کار می‌کند؟

ابزارهای مختلف جزئیات متفاوتی دارند، ولی منطق همهٔ آن‌ها یکی است:

1. اتصال کنترلی: سرور داخلی به پورت مشخصی روی رله وصل می‌شود و با توکن یا کلید، هویت خود را ثابت می‌کند.
2. ثبت سرویس: اعلام می‌کند کدام سرویس (مثلاً SSH روی پورت 22) باید روی کدام پورتِ رله در دسترس باشد.
3. گوش دادن روی رله: رله روی همان پورت منتظر می‌ماند؛ از دید بیرون، انگار سرویس روی خود رله اجرا می‌شود.
4. عبور ترافیک: اتصال کاربر از داخل تانل به سرور داخلی و سپس به سرویس محلی (مثلاً 127.0.0.1:22) می‌رسد و پاسخ از همان مسیر برمی‌گردد.
5. زنده نگه داشتن: کلاینت با پیام‌های دوره‌ای (Keepalive) اتصال را زنده نگه می‌دارد و پس از قطعی دوباره وصل می‌شود.

نکتهٔ مهم این است که تانل معکوس هیچ پورت ورودی‌ای روی سرور داخلی باز نمی‌کند. فایروال سرور داخلی می‌تواند همهٔ ورودی‌ها را ببندد و فقط اتصال خروجی به رله را مجاز بداند. در عوض، رله به نقطهٔ ورود سرویس شما تبدیل می‌شود و امنیت آن اهمیت دوچندان پیدا می‌کند.

چه زمانی به تانل معکوس نیاز دارید؟

تانل معکوس ابزاری برای دسترسی به زیرساخت خودتان است. رایج‌ترین کاربردهای مشروع آن:

• دسترسی مدیریتی به سرور پشت NAT: سرور دفتر، NAS یا سرور آزمایشگاهی که آی‌پی عمومی ندارد ولی باید از بیرون با SSH مدیریتش کنید.
• عبور از CGNAT: بعضی اپراتورهای اینترنت ثابت و همراه، یک آی‌پی عمومی را بین چند مشترک تقسیم می‌کنند. در این حالت باز کردن پورت روی مودم (Port Forwarding) بی‌اثر است و تانل معکوس راه عملی است.
• انتشار موقت یک سرویس توسعه: مثلاً وقتی درگاه پرداخت یا یک سرویس پیام‌رسان باید برای تست به Webhook روی لپ‌تاپ برنامه‌نویس پیام بفرستد.
• پشتیبانی از راه دور: شرکت خدماتی به سرور مشتری دسترسی پیدا می‌کند، بدون اینکه مشتری پورتی روی فایروال باز کند؛ مشتری هر وقت بخواهد تانل را قطع می‌کند.
• مانیتورینگ: دستگاه‌ها و سرورهای پراکنده پشت شبکه‌های مختلف، داده یا داشبوردشان را به یک سرور مرکزی می‌رسانند.

اگر سرور شما آی‌پی عمومی دارد و فقط پورتی در فایروال بسته است، معمولاً راه درست‌تر باز کردن کنترل‌شدهٔ همان پورت با فایروال UFW است، نه ساختن تانل.

تانل معکوس در برابر تانل مستقیم و VPN سایت‌به‌سایت

تانل مستقیم (Forward)

• اتصال از سمت کاربر به سرور مقصد شروع می‌شود
• مقصد باید آی‌پی عمومی و پورت باز داشته باشد
• برای دسترسی به سرویسی روی سرور قابل‌دسترس مناسب است
• پیکربندی ساده‌تر و مسیر کوتاه‌تر

در برابر

تانل معکوس (Reverse)

• اتصال از سمت سرور داخلی به سرور رله شروع می‌شود
• سرور داخلی به آی‌پی عمومی یا پورت باز نیاز ندارد
• برای سرور پشت NAT، CGNAT یا فایروال سازمانی مناسب است
• یک سرور رله و یک گام اضافه در مسیر لازم دارد

تانل مستقیم (Local Port Forwarding) وقتی به کار می‌آید که مقصد در دسترس است و فقط می‌خواهید ترافیک یک سرویس را رمزنگاری‌شده عبور دهید؛ مثلاً اتصال به پایگاه داده‌ای که فقط روی localhost سرور گوش می‌دهد. VPN سایت‌به‌سایت (مثل WireGuard یا IPsec) به‌جای منتشر کردن چند پورت، دو شبکه را مثل یک شبکهٔ خصوصی به هم وصل می‌کند.

قاعدهٔ ساده: برای چند سرویس مشخص، تانل معکوس کافی و کم‌خطرتر است، چون فقط همان پورت‌ها منتشر می‌شوند؛ برای اتصال کامل دو شبکه، VPN سایت‌به‌سایت تمیزتر است.

مقایسهٔ ابزارهای تانل معکوس: SSH، FRP، GOST، nps و rathole

جدول زیر محبوب‌ترین ابزارهای متن‌باز و یک گزینهٔ مدیریت‌شده را مقایسه می‌کند. وضعیت پروژه‌ها را در آبان ۱۴۰۵ از مخزن رسمی آن‌ها در GitHub بررسی کرده‌ایم.

همهٔ این ابزارها متن‌باز هستند: OpenSSH با مجوز BSD، FRP، rathole و cloudflared با Apache-2.0، GOST با MIT و nps با GPL-3.0.

SSH: ساده‌ترین تانل معکوس

OpenSSH روی تقریباً همهٔ سرورهای لینوکس نصب است و برای یک تانل معکوس ساده کافی است. محدودیت‌هایش: فقط TCP را منتقل می‌کند، پس از قطعی باید دوباره اجرا شود (با systemd حل می‌شود) و مدیریت ده‌ها پورت با آن سخت است. اگر با SSH آشنا نیستید، اول راهنمای ورود با کلید SSH و تغییر پورت را بخوانید.

FRP: استاندارد عملی برای استفادهٔ دائمی

FRP (Fast Reverse Proxy) پرستاره‌ترین و فعال‌ترین پروژهٔ این حوزه است: frps روی رله و frpc روی سرور داخلی اجرا می‌شود. از نسخهٔ 0.52 به بعد، پیکربندی پیشنهادی TOML است و فرمت INI منسوخ شده است. FRP برای وب‌سایت‌ها مسیریابی بر اساس نام دامنه دارد و حالت‌های STCP و XTCP، سرویس را فقط برای کلاینت‌های دارای کلید مشترک در دسترس می‌گذارند.

GOST، nps، rathole و Cloudflare Tunnel

• GOST (نسخهٔ 3): ابزار چندمنظورهٔ پروکسی و تانل با ده‌ها پروتکل انتقال و پورت‌فورواردینگ معکوس (rtcp و rudp). انعطافش زیاد است، ولی همین انعطاف خطای پیکربندی را محتمل‌تر می‌کند؛ برای منتشر کردن یک سرویس ساده، FRP یا rathole خواناترند.
• nps: پنل وب کامل برای تعریف کلاینت‌ها و تانل‌ها دارد، اما آخرین تغییرات کد مخزن اصلی به سال ۲۰۲۴ برمی‌گردد و صدها issue باز دارد؛ یعنی وصله‌های امنیتی سریع منتشر نمی‌شوند. اگر از آن استفاده می‌کنید، رمز پیش‌فرض را بلافاصله عوض کنید و پنل را با فایروال فقط به آی‌پی خودتان محدود کنید.
• rathole: با Rust نوشته شده و همان کار FRP را با مصرف حافظهٔ کمتر انجام می‌دهد. پیکربندی TOML آن کوتاه است و از Noise یا TLS استفاده می‌کند؛ داشبورد و مسیریابی دامنه ندارد، ولی برای سرورهای کم‌منابع مناسب است.
• Cloudflare Tunnel: شبکهٔ Cloudflare را جای رله می‌گذارد، ولی سرویس شما را به یک ارائه‌دهندهٔ خارجی وابسته می‌کند؛ دسترس‌پذیری آن را برای کاربران داخل ایران جداگانه بسنجید. برای انتشار دائمی سایت، سرور با آی‌پی عمومی به‌همراه CDN معمولاً پایدارتر است.

راه‌اندازی تانل معکوس با SSH

فرض کنید سرور دفتر (پشت NAT) باید از طریق یک سرور رله با آی‌پی عمومی قابل مدیریت باشد. ابتدا روی رله یک کاربر مخصوص تانل بسازید تا تانل با حساب اصلی شما اجرا نشود:

# روی سرور رله
sudo adduser --disabled-password --gecos "" tunnel

سپس روی سرور دفتر یک کلید اختصاصی بسازید و کلید عمومی را در فایل /home/tunnel/.ssh/authorized_keys روی رله قرار دهید. برای اینکه این کلید فقط اجازهٔ همین تانل را داشته باشد، ابتدای خط را محدود کنید:

restrict,port-forwarding,permitlisten="localhost:2222" ssh-ed25519 AAAA... office-tunnel

restrict همهٔ امکانات را می‌بندد، port-forwarding فقط فورواردینگ را دوباره مجاز می‌کند و permitlisten (از OpenSSH 7.8 به بعد) گوش دادن را به همین آدرس و پورت محدود می‌کند. حالا روی سرور دفتر تانل را برقرار کنید:

# روی سرور دفتر (پشت NAT)
ssh -N -R 2222:localhost:22 \
  -o ServerAliveInterval=30 -o ServerAliveCountMax=3 \
  -o ExitOnForwardFailure=yes -l tunnel relay.example.com

با این دستور، پورت 2222 فقط روی localhost رله باز می‌شود؛ پس ابتدا وارد رله شوید و از آنجا با ssh -p 2222 admin@localhost به سرور دفتر وصل شوید. این پیش‌فرض عمداً امن است؛ با فعال کردن GatewayPorts در sshd_config، سرویس داخلی برای کل اینترنت باز می‌شود. برای سرویس‌های وب، بهتر است پورت روی localhost بماند و Nginx روی رله با SSL جلوی آن قرار بگیرد؛ روش کار را در راهنمای Nginx Reverse Proxy ببینید.

پایدار کردن تانل SSH با systemd

تانل دستی با بستن ترمینال یا قطعی اینترنت از کار می‌افتد؛ پس روی سرور دفتر یک سرویس systemd بسازید (راهنمای سرویس systemd):

# /etc/systemd/system/reverse-tunnel.service
[Unit]
Description=Reverse SSH tunnel to relay
After=network-online.target
Wants=network-online.target

[Service]
User=tunnel
ExecStart=/usr/bin/ssh -N -R 2222:localhost:22 -i /home/tunnel/.ssh/id_ed25519 -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -l tunnel relay.example.com
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

این سرویس با کاربر محلی tunnel روی سرور دفتر اجرا می‌شود؛ پیش از فعال‌سازی، این کاربر را بسازید، کلید را در مسیر بالا بگذارید و یک بار دستی به رله وصل شوید تا اثرانگشت آن در known_hosts ثبت شود. سپس با sudo systemctl daemon-reload و sudo systemctl enable --now reverse-tunnel سرویس را فعال کنید و با systemctl status reverse-tunnel وضعیتش را ببینید. با Restart=always، systemd پس از هر قطعی، ۱۰ ثانیه بعد تانل را دوباره برقرار می‌کند؛ بنابراین معمولاً به autossh نیازی نیست.

راه‌اندازی تانل معکوس با FRP

برای چند سرویس یا استفادهٔ طولانی‌مدت، FRP مدیریت‌پذیرتر است. فایل‌های اجرایی را از صفحهٔ انتشار رسمی پروژه در GitHub بگیرید و پیش از اجرا، checksum آن‌ها را با فایل منتشرشده در همان صفحه مقایسه کنید. روی رله فایل frps.toml را بسازید:

# /etc/frp/frps.toml  (روی سرور رله)
bindPort = 7000
auth.method = "token"
auth.token = "یک-رشتهٔ-تصادفی-طولانی"
allowPorts = [ { start = 6000, end = 6010 } ]

گزینهٔ allowPorts جلوی این را می‌گیرد که کلاینتی (حتی با توکن درست) پورت دلخواهی روی رله باز کند. روی سرور داخلی هم فایل frpc.toml را بسازید:

# /etc/frp/frpc.toml  (روی سرور داخلی)
serverAddr = "relay.example.com"
serverPort = 7000
auth.method = "token"
auth.token = "یک-رشتهٔ-تصادفی-طولانی"
transport.tls.enable = true

[[proxies]]
name = "office-ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6001

سپس frps -c /etc/frp/frps.toml را روی رله و frpc -c /etc/frp/frpc.toml را روی سرور داخلی اجرا کنید و هر دو را مثل نمونهٔ SSH به سرویس systemd تبدیل کنید. توکن را با openssl rand -hex 32 بسازید و هرگز در مخزن کد یا پیام‌رسان منتشر نکنید. TLS در نسخه‌های جدید FRP پیش‌فرض است و نوشتن صریح آن ضرری ندارد.

در این نمونه، SSH سرور داخلی روی پورت 6001 رله منتشر می‌شود. اگر نمی‌خواهید این پورت برای همه باز باشد، در فایروال رله فقط آی‌پی خودتان را مجاز کنید یا از نوع stcp استفاده کنید تا فقط کلاینتی با کلید مشترک به آن وصل شود.

امنیت تانل معکوس: چک‌لیست ضروری

تانل معکوس عملاً یک در پشتی به شبکهٔ داخلی شماست. اگر درست ایمن نشود، هر کسی که به رله دسترسی پیدا کند، به سرور داخلی هم می‌رسد. این موارد را رعایت کنید:

• فقط پورت‌های لازم را منتشر کنید. هر سرویس اضافه، سطح حملهٔ اضافه است. پنل‌های مدیریتی و پایگاه داده را مستقیم روی رله منتشر نکنید.
• احراز هویت قوی: برای SSH فقط ورود با کلید، برای FRP و rathole توکن تصادفی طولانی. رمزهای پیش‌فرض (به‌ویژه در nps) را همان روز اول عوض کنید.
• فایروال روی رله: پورت کنترلی تانل و پورت‌های منتشرشده را فقط برای آی‌پی‌های لازم باز کنید. راهنمای UFW و Fail2ban برای همین کار است.
• حداقل دسترسی: کلاینت تانل را با کاربر غیر root اجرا کنید و روی رله هم برای تانل کاربر جداگانه با دسترسی محدود بسازید.
• رمزنگاری را خاموش نکنید. SSH همیشه رمزنگاری‌شده است؛ در FRP و rathole هم TLS یا Noise را فعال نگه دارید، به‌خصوص وقتی سرویس داخلی خودش رمزنگاری ندارد.
• به‌روزرسانی و پایش: نرم‌افزار تانل و سیستم‌عامل رله را مرتب به‌روز کنید، لاگ اتصال‌ها را نگه دارید و با دیدن اتصال ناشناس، توکن یا کلید را فوراً عوض کنید. نشانه‌های هک شدن سرور را هم بشناسید.
• هماهنگی با مالک شبکه: اگر سرور داخلی متعلق به سازمان یا مشتری است، تانل را فقط با اجازهٔ مسئول شبکه راه بیندازید.

کارایی تانل معکوس: پینگ، پهنای باند و ترافیک

ترافیک تانل معکوس به‌جای رفتن مستقیم به مقصد، اول به رله می‌رسد. سه نکته را در نظر بگیرید:

• تأخیر (پینگ): تأخیر نهایی تقریباً برابر است با تأخیر کاربر تا رله به‌اضافهٔ تأخیر رله تا سرور داخلی. اگر کاربران و سرور داخلی هر دو در یک کشورند، رله را هم در همان کشور انتخاب کنید تا مسیر رفت‌وبرگشت طولانی نشود. برای اندازه‌گیری مسیر از ping، traceroute و mtr استفاده کنید و مفهوم پینگ و تأخیر را بدانید.
• پهنای باند: سرعت تانل از کندترین بخش مسیر (پورت رله، اینترنت سرور داخلی یا CPU درگیر رمزنگاری) بیشتر نمی‌شود.
• ترافیک دوبرابر روی رله: هر بایت تانل یک بار وارد رله و یک بار از آن خارج می‌شود؛ این را در برآورد هزینهٔ ترافیک لحاظ کنید. تفاوت را در ترافیک ورودی و خروجی سرور و نحوهٔ محاسبهٔ ترافیک سرور ایران توضیح داده‌ایم.

اگر ارتباط ناپایدار شد، پیش از تغییر تنظیمات تانل، در دیده‌بان شبکهٔ کلودیفای ببینید اختلال کلی در شبکه وجود دارد یا نه.

سرور رله را چطور انتخاب کنیم؟

رله لازم نیست قوی باشد؛ برای چند تانل SSH یا FRP، سرور مجازی ۱ هسته و ۱ گیگابایت رم کافی است. آنچه اهمیت دارد:

• آی‌پی عمومی ثابت: کلاینت‌ها باید همیشه رله را با یک آدرس ثابت (یا یک نام دامنه) پیدا کنند.
• مکان نزدیک به کاربران: اگر کاربران و سرور داخلی در ایران هستند، سرور مجازی ایران تأخیر کمتری می‌دهد. اگر کاربران یا سرویس‌های شما خارج از ایران‌اند، سرور مجازی خارج در کشوری نزدیک به آن‌ها مناسب‌تر است. مقایسهٔ این دو را در سرور ایران یا خارج؟ بخوانید.
• پورت و ترافیک کافی: سرعت پورت و سقف ترافیک رله را با حجم واقعی تانل (و ترافیک دوبرابر) بسنجید. برای تست‌های موقت، صورتحساب ساعتی هزینه را به مدت واقعی استفاده محدود می‌کند.

پلن‌های سرور مجازی کلودیفای با آی‌پی عمومی تحویل داده می‌شوند. اگر هدف، میزبانی دائمی یک سایت است، به‌جای انتشار آن از پشت NAT، سایت را مستقیم روی سرور مجازی ببرید؛ راهنمای میزبانی سایت روی سرور مجازی همین مسیر را توضیح می‌دهد.

عیب‌یابی رایج تانل معکوس

نکتهٔ حقوقی و شرایط استفاده

تانل معکوس فناوری استانداردی برای مدیریت زیرساخت است، ولی مسئولیت استفاده از آن با شماست: فقط روی سرورها و شبکه‌هایی تانل بسازید که مالکشان هستید یا اجازهٔ کتبی دارید، و قوانین کشور محل سرور و شرایط استفادهٔ دیتاسنتر را رعایت کنید.

ادامهٔ این مجموعه

این مقاله شروع مجموعهٔ آموزش‌های تانل و شبکهٔ سرور در مجلهٔ کلودیفای است. راهنمای انتخاب سرور برای تانل، آموزش تانل GRE در لینوکس، مقایسهٔ Backhaul و Rathole با GOST و FRP، آموزش کامل تانل SSH با Local و Remote و Dynamic Forwarding و آموزش اتصال سایت‌به‌سایت با WireGuard هم منتشر شده‌اند. همچنین مقالهٔ DNS شکن چیست؟ نشان می‌دهد چرا تغییر DNS با تانل فرق دارد.

سؤالات متداول