تانل SSH؛ آموزش Local و Remote و Dynamic Port Forwarding بین دو سرور با مثال

تقریباً هر سرور لینوکسی OpenSSH دارد و بیشتر مدیران سرور هر روز با آن وارد سرور می‌شوند. اما SSH فقط برای باز کردن ترمینال نیست: همان اتصال رمزنگاری‌شده می‌تواند ترافیک برنامه‌های دیگر را هم جابه‌جا کند. به این قابلیت پورت‌فورواردینگ SSH یا به زبان رایج تانل SSH می‌گویند. با آن می‌توانید به دیتابیسی که فقط روی 127.0.0.1 سرور گوش می‌دهد وصل شوید، پنل مدیریتی شبکهٔ خصوصی دیتاسنتر را از لپ‌تاپ خودتان باز کنید یا سرور دفتری را که پشت NAT است از طریق یک سرور واسط مدیریت کنید.

در این مقاله سه نوع تانل SSH، یعنی Local و Remote (همان SSH Reverse) و Dynamic، را با مثال‌های واقعی توضیح می‌دهیم، نشان می‌دهیم چطور تانل SSH بین دو سرور را دائمی و امن کنیم و رایج‌ترین خطاها را بررسی می‌کنیم. اگر هنوز با خود SSH راحت نیستید، اول راهنمای اتصال به سرور لینوکس با SSH و ورود با کلید SSH و تغییر پورت را بخوانید. همهٔ آدرس‌های این مقاله آدرس‌های مخصوص مستندات‌اند (203.0.113.10 و 198.51.100.20)؛ آن‌ها را با آدرس سرورهای خودتان جایگزین کنید.

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

وقتی با SSH به سرور وصل می‌شوید، یک اتصال TCP رمزنگاری‌شده بین کلاینت و سرور برقرار می‌شود. پروتکل SSH روی همین اتصال چند «کانال» مستقل می‌سازد: یکی برای ترمینال، یکی برای انتقال فایل و هر تعداد که لازم باشد برای پورت‌فورواردینگ. در تانل SSH، یک طرف روی یک پورت منتظر اتصال می‌ماند و هر اتصالی که به آن برسد، داخل یک کانال تازه به طرف دیگر منتقل می‌شود. طرف دیگر هم اتصال را به مقصد نهایی تحویل می‌دهد.

سه نکتهٔ پایه را از همین ابتدا در نظر داشته باشید:

• فقط TCP: پورت‌فورواردینگ معمولی SSH فقط اتصال‌های TCP را منتقل می‌کند. برای UDP یا اتصال لایهٔ شبکه بین دو سرور، ابزارهایی مثل تانل GRE یا WireGuard مناسب‌ترند.
• رمزنگاری تا سر تانل: ترافیک بین دو سر SSH رمزنگاری می‌شود، ولی مسیر آخر، از سرور SSH تا مقصد نهایی، به همان شکلی است که برنامه می‌فرستد. اگر مقصد روی همان سرور (127.0.0.1) باشد، این مسیر اصلاً از شبکه عبور نمی‌کند.
• «localhost» نسبی است: در دستور تانل، آدرس مقصد از دید طرفی تفسیر می‌شود که اتصال را تحویل می‌دهد. در -L، localhost یعنی خود سرور SSH؛ در -R، یعنی سیستمی که دستور را اجرا کرده است. بیشتر سردرگمی‌ها از همین‌جا شروع می‌شود.

سه نوع پورت‌فورواردینگ در یک نگاه

Local Port Forwarding با -L

در Local Forwarding، پورتی روی سیستم شما باز می‌شود و هر اتصالی که به آن برسد، از داخل SSH به سرور می‌رود و سرور آن را به مقصد مشخص‌شده تحویل می‌دهد. شکل کلی دستور این است:

ssh -L [آدرس_محلی:]پورت_محلی:مقصد:پورت_مقصد  کاربر_و_سرور

مثال ۱: اتصال امن به دیتابیس روی سرور

فرض کنید PostgreSQL روی سرور 203.0.113.10 فقط روی 127.0.0.1:5432 گوش می‌دهد؛ یعنی کاری درست انجام داده‌اید و پورت دیتابیس را روی اینترنت باز نکرده‌اید. برای کار با آن از لپ‌تاپ، کافی است:

ssh -N -L 5433:127.0.0.1:5432 -l deploy -p 2222 203.0.113.10

حالا ابزار دیتابیس روی لپ‌تاپ را به 127.0.0.1 و پورت 5433 وصل کنید؛ اتصال از داخل SSH به خود سرور می‌رسد. فلگ -N می‌گوید فرمانی اجرا نشود و فقط تانل برقرار بماند. پورت محلی را عمداً 5433 گذاشته‌ایم تا با دیتابیس احتمالی روی لپ‌تاپ تداخل نداشته باشد. نصب و پشتیبان‌گیری دیتابیس را در راهنمای نصب و بکاپ دیتابیس توضیح داده‌ایم.

مثال ۲: دسترسی به پنل داخل شبکهٔ خصوصی

مقصد لازم نیست خود سرور SSH باشد. اگر سرور شما در شبکهٔ خصوصی دیتاسنتر به سروری با آدرس 10.0.0.5 دسترسی دارد که داشبورد پایش را روی پورت 3000 اجرا می‌کند:

ssh -N -L 8080:10.0.0.5:3000 -l deploy -p 2222 203.0.113.10

حالا با باز کردن http://127.0.0.1:8080 در مرورگر، داشبورد را می‌بینید، بی‌آنکه سرور 10.0.0.5 هیچ پورتی روی اینترنت داشته باشد. مسیر بین 203.0.113.10 و 10.0.0.5 رمزنگاری SSH ندارد؛ پس این روش فقط برای شبکهٔ خصوصی قابل اعتماد مناسب است.

آدرس محلی را باز نکنید

به‌طور پیش‌فرض، پورت محلی فقط روی localhost باز می‌شود و فقط خود شما به آن دسترسی دارید. اگر آدرس محلی را صریحاً 0.0.0.0 بدهید، هر کسی در شبکهٔ شما، مثلاً وای‌فای کافه یا شبکهٔ دفتر، می‌تواند از تانل شما به دیتابیس سرور برسد. جز در موارد کاملاً کنترل‌شده، آدرس محلی را خالی یا 127.0.0.1 بگذارید.

ذخیرهٔ تانل در فایل config

به‌جای تایپ دستور طولانی، تانل را در ~/.ssh/config تعریف کنید:

Host db-tunnel
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    LocalForward 5433 127.0.0.1:5432
    ExitOnForwardFailure yes
    ServerAliveInterval 30

از این پس ssh -N db-tunnel همان تانل را برقرار می‌کند. اگر سرور مقصد فقط از طریق یک سرور واسط (Bastion) در دسترس است، خط ProxyJump bastion را اضافه کنید تا SSH ابتدا به آن سرور وصل شود و از داخل آن به مقصد برسد. ProxyJump امن‌تر از فعال کردن Agent Forwarding با -A است، چون کلید شما هرگز در اختیار سرور واسط قرار نمی‌گیرد.

فلگ‌های پرکاربرد

$ ssh -f -N -L 5433:127.0.0.1:5432 -p 2222 -l deploy 203.0.113.10$ ss -tlnp | grep 5433LISTEN 0 128 127.0.0.1:5433 0.0.0.0:* users:(("ssh",pid=4121,fd=5))$ psql -h 127.0.0.1 -p 5433 -U app -d appdb -c 'select 1' ?column?----------        1(1 row)$ 

Remote Port Forwarding یا SSH Reverse با -R

در Remote Forwarding جهت برعکس است: پورت روی سرور SSH باز می‌شود و اتصال‌هایی که به آن می‌رسند، به سیستمی برمی‌گردند که دستور را اجرا کرده است. به همین دلیل به آن SSH Reverse یا تانل معکوس SSH هم می‌گویند. کاربرد اصلی‌اش وقتی است که سیستم شما پشت NAT یا فایروال سازمانی است و آی‌پی عمومی ندارد، ولی می‌تواند به بیرون وصل شود.

ssh -R [آدرس_روی_سرور:]پورت_روی_سرور:مقصد:پورت_مقصد  کاربر_و_سرور

مثال: مدیریت سرور دفتر از طریق رله

سرور دفتر پشت NAT است و سرور رله 198.51.100.20 آی‌پی عمومی دارد. روی سرور دفتر اجرا می‌کنیم:

ssh -N -R 127.0.0.1:2222:localhost:22 \
  -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 \
  -l tunnel 198.51.100.20

این دستور پورت 2222 را روی localhost رله باز می‌کند و آن را به پورت SSH خود سرور دفتر می‌رساند. حالا مدیر ابتدا وارد رله می‌شود و از آنجا با ssh -p 2222 -l admin localhost به سرور دفتر وصل می‌شود؛ یا از لپ‌تاپ خودش، با ProxyJump از روی رله، مستقیم به همان پورت می‌رسد.

GatewayPorts و انتشار سرویس

به‌طور پیش‌فرض، سرور OpenSSH پورت‌های -R را فقط روی localhost باز می‌کند، حتی اگر در دستور آدرس دیگری بدهید. این رفتار با گزینهٔ GatewayPorts در sshd_config تعیین می‌شود: مقدار no (پیش‌فرض) فقط localhost، مقدار yes همهٔ آدرس‌ها و مقدار clientspecified آدرسی را که کلاینت می‌خواهد مجاز می‌کند. توصیهٔ ما این است که GatewayPorts را روی no نگه دارید و اگر می‌خواهید سرویس وبی را از طریق رله منتشر کنید، Nginx را روی رله جلوی پورت localhost قرار دهید تا SSL، لاگ و محدودیت دسترسی داشته باشید. روش آن را در راهنمای Nginx Reverse Proxy ببینید.

یک کاربرد رایج دیگر، توسعهٔ وب‌هوک است: برنامه‌ای که روی لپ‌تاپ روی پورت 3000 اجرا می‌شود، با -R 127.0.0.1:8080:localhost:3000 روی رله در دسترس قرار می‌گیرد و Nginx رله با دامنه و SSL، درخواست‌های سرویس بیرونی را به آن می‌رساند. سازوکار کامل تانل معکوس و مقایسهٔ SSH با FRP را در مقالهٔ تانل معکوس چیست؟ و مقایسهٔ ابزارهای تخصصی‌تر را در مقایسهٔ Backhaul و Rathole با GOST و FRP آورده‌ایم.

Dynamic Port Forwarding با -D

در دو حالت قبل، مقصد در خود دستور ثابت است. در Dynamic Forwarding، SSH روی سیستم شما یک پروکسی SOCKS می‌سازد و هر برنامه‌ای که از این پروکسی استفاده کند، خودش مقصد را اعلام می‌کند؛ سرور SSH اتصال را به همان مقصد برقرار می‌کند. کاربرد مدیریتی‌اش وقتی است که در شبکهٔ خصوصی سرور چند سرویس داخلی دارید و نمی‌خواهید برای هرکدام یک -L جدا بسازید:

ssh -N -D 127.0.0.1:1080 -l deploy -p 2222 203.0.113.10

حالا ابزارهایی که SOCKS را پشتیبانی می‌کنند، از طریق سرور به شبکهٔ خصوصی دسترسی دارند. برای مثال، بررسی سلامت یک سرویس داخلی:

curl --socks5-hostname 127.0.0.1:1080 http://10.0.0.5:3000/api/health

گزینهٔ --socks5-hostname باعث می‌شود نام‌ها هم در سمت سرور ترجمه شوند؛ پس نام‌های داخلی شبکهٔ خصوصی هم کار می‌کنند. اگر می‌خواهید چند پنل داخلی را در مرورگر باز کنید، یک پروفایل جدا برای مرورگر بسازید و پروکسی SOCKS را فقط در همان پروفایل تنظیم کنید تا مرور معمول شما از سرور عبور نکند. Dynamic Forwarding ابزاری برای دسترسی مدیریتی به منابع خودتان است؛ پورت آن را هم مثل بقیه فقط روی 127.0.0.1 باز کنید، چون پروکسی SOCKS بدون احراز هویت روی شبکه، به هر کسی اجازهٔ استفاده از سرور شما را می‌دهد.

تانل SSH بین دو سرور

یکی از جست‌وجوهای رایج، تانل SSH بین دو سرور است؛ مثلاً سرور برنامه باید به دیتابیسی روی سرور دیگر وصل شود و دو سرور شبکهٔ خصوصی مشترک ندارند. به‌جای باز کردن پورت دیتابیس روی اینترنت، روی سرور برنامه یک Local Forward دائمی می‌سازیم تا برنامه به 127.0.0.1:5433 وصل شود و اتصال رمزنگاری‌شده به دیتابیس برسد.

ابتدا روی سرور دیتابیس یک کاربر مخصوص تانل بسازید و روی سرور برنامه یک کلید اختصاصی بدون رمز برای همین کار تولید کنید (ssh-keygen -t ed25519 -f /etc/ssh-tunnel/id_db). کلید عمومی را با محدودیت‌هایی که در بخش بعد توضیح می‌دهیم در authorized_keys کاربر تانل قرار دهید. پیش از ساخت سرویس، یک بار دستی وصل شوید تا اثرانگشت سرور در known_hosts ثبت شود؛ هرگز StrictHostKeyChecking=no را برای تانل دائمی به کار نبرید، چون بررسی هویت سرور را خاموش می‌کند.

برای ارتباط سنگین و دائمی بین دو سرور، تانل SSH همیشه بهترین انتخاب نیست. SSH همه‌چیز را از یک اتصال TCP عبور می‌دهد و با از دست رفتن بسته‌ها، همهٔ کانال‌ها با هم کند می‌شوند. برای اتصال کامل دو شبکه، تانل GRE همراه با رمزنگاری یا WireGuard مناسب‌تر است؛ روش کامل را در آموزش اتصال سایت‌به‌سایت با WireGuard ببینید.

محدود کردن کلید تانل در authorized_keys

کلیدی که برای تانل می‌سازید، به‌طور پیش‌فرض همهٔ اختیارات کاربر را دارد: ترمینال، اجرای فرمان و فورواردینگ به هر مقصدی. اگر آن کلید از سرور برنامه یا دفتر به سرقت برود، مهاجم به همین اختیارات می‌رسد. OpenSSH اجازه می‌دهد ابتدای هر خط authorized_keys گزینه‌هایی بنویسید که کلید را فقط به همان تانل محدود کنند. برای تانل -L از سرور برنامه به دیتابیس:

restrict,port-forwarding,permitopen="127.0.0.1:5432",from="192.0.2.15" ssh-ed25519 AAAA... app-to-db

و برای تانل -R از سرور دفتر به رله:

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

علاوه بر این، می‌توانید در /etc/ssh/sshd_config برای کاربر تانل یک بلوک جدا تعریف کنید تا حتی اگر کسی خط authorized_keys را تغییر داد، محدودیت‌ها سر جایشان بمانند:

Match User tunnel
    AllowTcpForwarding remote
    PermitListen localhost:2222
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no
    ForceCommand /bin/false

برای کاربری که تانل -L می‌سازد، AllowTcpForwarding local و PermitOpen 127.0.0.1:5432 را جایگزین کنید. پس از هر تغییر، با sudo sshd -t پیکربندی را بررسی کنید و تا مطمئن نشده‌اید که ورود اصلی‌تان سالم است، نشست فعلی را نبندید. در توزیع‌های جدید اوبونتو، نام سرویس ssh است و با sudo systemctl reload ssh تغییرات اعمال می‌شود.

دائمی کردن تانل SSH با systemd

تانلی که در ترمینال باز کرده‌اید، با بستن ترمینال، قطعی اینترنت یا ری‌استارت سرور از بین می‌رود. برای تانل دائمی بین دو سرور، یک سرویس systemd بسازید (راهنمای ساخت سرویس systemd). روی سرور برنامه:

# /etc/systemd/system/db-tunnel.service
[Unit]
Description=SSH local forward to database server
After=network-online.target
Wants=network-online.target

[Service]
User=tunnel
ExecStart=/usr/bin/ssh -N -T -L 127.0.0.1:5433:127.0.0.1:5432 -i /etc/ssh-tunnel/id_db -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -p 2222 -l tunnel 203.0.113.10
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

کاربر محلی tunnel باید اجازهٔ خواندن کلید را داشته باشد و فقط خودش (chmod 600). سپس با sudo systemctl daemon-reload و sudo systemctl enable --now db-tunnel سرویس را فعال کنید و با systemctl status db-tunnel و journalctl -u db-tunnel -f وضعیتش را ببینید. ترکیب ServerAliveInterval و ExitOnForwardFailure باعث می‌شود تانلِ مرده یا ناقص زود بسته شود و Restart=always آن را دوباره بسازد؛ به همین دلیل معمولاً به autossh نیازی ندارید. نمونهٔ سرویس تانل معکوس را هم در مقالهٔ تانل معکوس چیست؟ آورده‌ایم.

نکات امنیتی تانل SSH

• فقط ورود با کلید: روی سرورهایی که تانل می‌پذیرند، ورود با رمز را خاموش کنید و پورت SSH را تغییر دهید؛ روش امن آن را در ورود با کلید SSH و تغییر پورت ببینید.
• محافظت در برابر حدس رمز: Fail2ban تلاش‌های ناموفق ورود را مسدود می‌کند و فایروال UFW پورت SSH را به آی‌پی‌های لازم محدود می‌کند.
• localhost در هر دو سر: پورت‌های -L و -D را روی 127.0.0.1 و پورت‌های -R را با GatewayPorts no روی localhost سرور نگه دارید. انتشار عمومی را به Nginx با SSL بسپارید.
• یک کلید برای هر تانل: برای هر تانل کلید جدا با نام واضح بسازید تا در صورت نشت، فقط همان کلید را از authorized_keys حذف کنید.
• Agent Forwarding خاموش: برای عبور از سرور واسط از ProxyJump استفاده کنید، نه -A.
• بازبینی دوره‌ای: با ss -tlnp پورت‌های باز را ببینید و لاگ ورود را با journalctl -u ssh بررسی کنید.

کارایی تانل SSH

تانل SSH برای کارهای مدیریتی، دیتابیس با ترافیک متوسط و پنل‌های وب کاملاً کافی است، ولی چند محدودیت دارد که بهتر است بدانید:

• TCP درون TCP: همهٔ کانال‌ها از یک اتصال TCP عبور می‌کنند. روی مسیرهای پر از Packet Loss، یک بستهٔ گم‌شده همهٔ کانال‌ها را معطل می‌کند. کیفیت مسیر را با ping، traceroute و mtr بسنجید.
• فشرده‌سازی: گزینهٔ -C روی لینک‌های کند و داده‌های متنی کمک می‌کند، ولی روی لینک سریع یا دادهٔ فشرده فقط CPU مصرف می‌کند.
• ترافیک روی رله دو بار شمرده می‌شود: در تانل -R، رله هر بایت را یک بار دریافت و یک بار ارسال می‌کند. در سرور مجازی ایران کلودیفای فقط ترافیک خروجی (هر گیگابایت ۱٬۲۵۰ تومان) محاسبه می‌شود؛ جزئیات را در صفحهٔ ترافیک و پهنای باند ببینید.
• برای ترافیک سنگین: اگر چند سرویس پرترافیک را دائماً جابه‌جا می‌کنید، ابزارهای تخصصی تانل معکوس یا تانل لایهٔ شبکه انتخاب بهتری‌اند.

اشتباهات رایج در تانل SSH

• جابه‌جا نوشتن پورت‌ها: در -L 5433:127.0.0.1:5432، عدد اول همیشه پورتی است که باز می‌شود و دو بخش آخر مقصد. در -R هم همین ترتیب برقرار است، فقط پورت روی سرور باز می‌شود.
• اشتباه گرفتن localhost: در -L، مقصد localhost یعنی خود سرور SSH، نه لپ‌تاپ شما.
• باز کردن پورت روی 0.0.0.0: چه با آدرس صریح در -L و -D و چه با GatewayPorts yes در -R، سرویس داخلی را بی‌دفاع در معرض شبکه قرار می‌دهد.
• اجرای تانل با کاربر root: یک کاربر محدود بسازید؛ اگر کلید نشت کند، دسترسی مهاجم محدود می‌ماند.
• خاموش کردن بررسی هویت سرور: StrictHostKeyChecking=no راه حملهٔ مرد میانی را باز می‌کند.
• نبستن فایروال رله: پورت‌هایی که روی localhost هستند نیازی به قانون فایروال ندارند؛ فقط پورت SSH را باز کنید.
• تانل در ترمینال باز: برای کار موقت از tmux یا screen و برای کار دائمی از systemd استفاده کنید.
• اشتباه گرفتن تانل با تغییر DNS: تغییر DNS مسیر ترافیک را عوض نمی‌کند؛ تفاوت را در DNS شکن چیست؟ توضیح داده‌ایم.

عیب‌یابی تانل SSH

پیش از هر چیز، دستور را با -v اجرا کنید تا SSH مراحل ساخت تانل را نشان دهد. جدول زیر رایج‌ترین پیام‌ها را خلاصه کرده است:

اگر اتصال SSH اصلاً برقرار نمی‌شود، راهنمای رفع Connection timed out در SSH را ببینید. وضعیت شبکهٔ دیتاسنترهای کلودیفای را هم در صفحهٔ وضعیت دنبال کنید.

سرور مناسب برای تانل SSH

برای تانل SSH، سرور قوی لازم نیست؛ یک سرور مجازی ۱ هسته و ۱ گیگابایت رم برای ده‌ها تانل مدیریتی کافی است. آنچه اهمیت دارد آی‌پی عمومی ثابت، مسیر شبکهٔ کوتاه تا دو سر تانل و مدل منصفانهٔ محاسبهٔ ترافیک است. اگر سرور دفتر یا کاربران شما در ایران‌اند، سرور مجازی ایران با پورت ۲۵ گیگ تأخیر کمتری دارد؛ اگر سرویس‌های طرف دیگر در خارج از ایران‌اند، سرور مجازی خارج را در لوکیشنی نزدیک به آن‌ها انتخاب کنید. برای تمرین دستورهای این مقاله یا تست موقت، سرور ساعتی گزینهٔ اقتصادی است: چند ساعت تست می‌کنید و بعد سرور را حذف می‌کنید. معیارهای کامل انتخاب را در خرید سرور ایران برای تانل آورده‌ایم.

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

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

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

این مقاله پنجمین قسمت از مجموعهٔ آموزش‌های تانل و شبکهٔ سرور در مجلهٔ کلودیفای است. قسمت‌های قبلی: تانل معکوس چیست؟، خرید سرور ایران برای تانل، تانل GRE در لینوکس و مقایسهٔ Backhaul و Rathole با GOST و FRP. قسمت بعدی، آموزش اتصال سایت‌به‌سایت با WireGuard، هم منتشر شده است. راهنمای مقایسهٔ پروتکل‌های VPN هم منتشر شده است. آموزش تانل IPsec بین دو سرور و تانل 6to4 و IPv6 هم منتشر شده‌اند.

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