مقایسهٔ Backhaul و Rathole با GOST و FRP؛ کدام ابزار تانل برای چه کاری مناسب است؟

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

در جست‌وجوهای فارسی به این انتخاب گاهی «متود تانل» هم گفته می‌شود و نام‌هایی مثل «تانل بکهال» و «تانل رتهول» زیاد دیده می‌شوند. در این مقاله چهار ابزار رایج متن‌باز، یعنی Backhaul، Rathole، GOST و FRP، را از نظر پروتکل، امنیت، کارایی، سادگی پیکربندی و وضعیت نگهداری مقایسه می‌کنیم و برای هر سناریو گزینهٔ مناسب را پیشنهاد می‌دهیم. تمرکز این مقاله کاربردهای مدیریتی و مشروع است: دسترسی به سرور دفتر، انتشار سرویس پشت NAT، اتصال سرور به سرور، توسعهٔ وب‌هوک و پایش.

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

هر چهار ابزار از دو جزء تشکیل شده‌اند:

• سرور (روی رله): روی سروری با آی‌پی عمومی اجرا می‌شود، روی یک پورت کنترلی منتظر اتصال کلاینت می‌ماند و پورت‌های سرویس‌ها را برای کاربران باز می‌کند.
• کلاینت (روی سرور داخلی): پشت NAT اجرا می‌شود، اتصالی خروجی به رله برقرار می‌کند، با توکن یا کلید هویتش را ثابت می‌کند و ترافیک را به سرویس محلی (مثلاً 127.0.0.1:22) تحویل می‌دهد.

تفاوت ابزارها در جزئیات است: اتصال کنترلی روی چه پروتکلی برقرار می‌شود، آیا رمزنگاری پیش‌فرض است، آیا چند جلسه روی یک اتصال ترکیب می‌شوند (Multiplexing)، آیا UDP پشتیبانی می‌شود و پیکربندی چقدر ساده است. این ابزارها با تانل‌های لایهٔ IP مثل تانل GRE فرق دارند: GRE دو شبکه را به هم وصل می‌کند، ولی این ابزارها پورت به پورت کار می‌کنند و از پشت NAT هم عبور می‌کنند.

معرفی چهار ابزار

FRP: استاندارد عملی و پرکاربرد

FRP (Fast Reverse Proxy) با زبان Go نوشته شده و با بیش از ۱۱۰ هزار ستاره در گیت‌هاب، پرکاربردترین ابزار این دسته است. آخرین نسخهٔ آن در زمان نگارش، v0.71.1 (مهر ۱۴۰۵) است و مجوز Apache-2.0 دارد. پیکربندی با TOML، YAML یا JSON انجام می‌شود و از TCP، UDP، مسیریابی بر اساس دامنه برای HTTP و HTTPS، داشبورد وب و حالت‌هایی مثل STCP (دسترسی فقط با کلید مشترک) و XTCP (اتصال مستقیم نقطه‌به‌نقطه) پشتیبانی می‌کند. رمزنگاری TLS بین کلاینت و سرور در نسخه‌های جدید به‌طور پیش‌فرض فعال است.

Rathole: سبک و سریع با Rust

Rathole با زبان Rust نوشته شده و هدفش کارایی بیشتر و مصرف منابع کمتر از FRP است؛ فایل اجرایی آن می‌تواند تا حدود ۵۰۰ کیلوبایت کوچک شود و روی روترها و دستگاه‌های کم‌منابع هم اجرا شود. توکن برای هر سرویس اجباری است و برای رمزنگاری می‌توانید پروتکل Noise (بدون نیاز به گواهی) یا TLS را انتخاب کنید. Rathole از TCP و UDP پشتیبانی می‌کند، ولی عمداً قابلیت‌هایی مثل مسیریابی دامنه برای HTTP را ندارد و توصیه می‌کند این کار را به Nginx بسپارید. آخرین نسخهٔ رسمی آن v0.5.0 (مهر ۱۴۰۲) است، هرچند مخزن همچنان تغییرات دریافت می‌کند.

GOST v3: چاقوی سوئیسی تونل‌سازی

GOST (GO Simple Tunnel) در نسخهٔ ۳ یک ابزار عمومی پروکسی و تانل است که ده‌ها پروتکل انتقال و رمزنگاری را پشتیبانی می‌کند و می‌تواند زنجیره‌ای از چند گام بسازد. پورت فورواردینگ مستقیم و معکوس، تانل TCP و UDP و پیکربندی با خط فرمان، YAML یا JSON از قابلیت‌های آن است. آخرین نسخهٔ آن v3.3.2 (آبان ۱۴۰۵) با مجوز MIT است. این انعطاف یک هزینه هم دارد: پیکربندی GOST برای کار ساده، از FRP و Rathole پیچیده‌تر است.

Backhaul: تمرکز بر تعداد اتصال زیاد

Backhaul ابزار تانل معکوس دیگری با زبان Go است که برای تعداد زیاد اتصال هم‌زمان بهینه شده است. حالت‌های انتقال آن شامل TCP، TCPMux، UDP، WebSocket و WSS و نسخه‌های Mux آن‌هاست؛ Multiplexing را با SMUX انجام می‌دهد، می‌تواند UDP را روی TCP منتقل کند و یک رابط وب ساده برای پایش دارد. پیکربندی با یک فایل TOML انجام می‌شود. آخرین نسخهٔ آن v0.7.2 (شهریور ۱۴۰۴) با مجوز AGPL-3.0 است و از آن زمان تغییری در مخزن ثبت نشده است؛ این موضوع برای استفادهٔ بلندمدت باید در نظر گرفته شود.

دربارهٔ nps

nps یک ابزار قدیمی‌تر با پنل وب کامل است، اما آخرین نسخهٔ رسمی آن به سال ۱۴۰۰ برمی‌گردد، آخرین تغییر مخزن در خرداد ۱۴۰۳ ثبت شده و صدها گزارش باز دارد. برای سرویس جدید و در معرض اینترنت، استفاده از آن را توصیه نمی‌کنیم.

جدول مقایسهٔ کلی

ارقام زیر در آبان ۱۴۰۵ از صفحهٔ گیت‌هاب هر پروژه بررسی شده‌اند:

مقایسهٔ فنی: پروتکل، رمزنگاری، UDP و Multiplexing

چند نکته دربارهٔ این جدول:

• رمزنگاری پیش‌فرض اهمیت دارد. در Backhaul، حالت‌های TCP و WS رمزنگاری ندارند و فقط WSS با گواهی TLS ترافیک را رمز می‌کند. در Rathole هم رمزنگاری را باید خودتان فعال کنید. FRP در نسخه‌های جدید TLS را به‌طور پیش‌فرض روشن می‌کند.
• Multiplexing همیشه سریع‌تر نیست. ترکیب چند جلسه روی یک اتصال، تعداد اتصال‌های TCP را کم و راه‌اندازی جلسهٔ جدید را سریع می‌کند، ولی اگر همان یک اتصال دچار Packet Loss شود، همهٔ جلسه‌ها با هم کند می‌شوند.
• UDP روی TCP راه‌حل موقت است. انتقال UDP داخل TCP برای DNS یا بازی‌های حساس به تأخیر، به‌خاطر بازارسال بسته‌ها تأخیر را بالا می‌برد. اگر به UDP واقعی نیاز دارید، حالت UDP بومی یا یک VPN لایهٔ IP مثل WireGuard مناسب‌تر است.

FRP

• کامل‌ترین امکانات و داشبورد
• TLS پیش‌فرض و احراز هویت با توکن یا OIDC
• مسیریابی دامنه برای HTTP و HTTPS
• جامعهٔ بزرگ و نسخه‌های منظم

در برابر

Rathole

• بسیار سبک؛ مناسب سرور کم‌منابع
• توکن اجباری برای هر سرویس
• رمزنگاری Noise یا TLS به انتخاب شما
• مسیریابی HTTP را به Nginx می‌سپارد

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

اگر فقط یک یا دو پورت را موقت لازم دارید، شاید اصلاً به ابزار جداگانه نیاز نداشته باشید؛ ssh -R روی هر سرور لینوکس موجود است. راه‌اندازی آن را در بخش SSH مقالهٔ تانل معکوس آورده‌ایم.

پیش از انتخاب، این پنج سؤال را بپرسید

اگر هنوز مطمئن نیستید، پاسخ این پرسش‌ها انتخاب را تقریباً قطعی می‌کند:

1. چند سرویس و از چه نوعی؟ برای یک پورت SSH، هر ابزاری کافی است. برای چند سایت با دامنه‌های مختلف، مسیریابی دامنهٔ FRP کار را ساده می‌کند و در Rathole باید Nginx را جلوی آن بگذارید.
2. آیا به UDP واقعی نیاز دارید؟ اگر سرویس شما DNS، VoIP یا بازی است، ابزاری را انتخاب کنید که UDP را بومی منتقل کند، نه داخل TCP.
3. منابع سرور چقدر است؟ روی روتر، Raspberry Pi یا سرور ۵۱۲ مگابایتی، Rathole کمترین مصرف را دارد.
4. چه کسی و تا کی آن را نگهداری می‌کند؟ برای سرویسی که سال‌ها باید کار کند، ابزاری با نسخه‌های منظم و جامعهٔ بزرگ ریسک کمتری دارد. پیش از انتخاب، تاریخ آخرین نسخه و تعداد گزارش‌های باز مخزن را ببینید.
5. مجوز نرم‌افزار با کار شما سازگار است؟ اگر قصد دارید ابزار را تغییر دهید و به‌صورت سرویس به دیگران ارائه کنید، شرایط مجوزهای AGPL و GPL با Apache و MIT فرق دارد.

مهاجرت از یک ابزار به دیگری

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

نمای کلی راه‌اندازی

صرف‌نظر از ابزار، مراحل راه‌اندازی یکسان است:

1. آماده کردن رله: یک سرور با آی‌پی عمومی ثابت، فایروال فعال و دسترسی SSH امن. معیارهای انتخاب آن را در خرید سرور ایران برای تانل ببینید.
2. نصب از منبع رسمی: فایل اجرایی را فقط از صفحهٔ Releases مخزن رسمی دانلود کنید و در صورت وجود، چک‌سام آن را بررسی کنید.
3. پیکربندی سرور: پورت کنترلی، توکن قوی و فهرست سرویس‌ها و پورت‌های منتشرشده را مشخص کنید.
4. پیکربندی کلاینت: نشانی رله، همان توکن و نشانی سرویس محلی را وارد کنید.
5. اجرای دائمی: هر دو طرف را به‌صورت سرویس systemd اجرا کنید تا پس از ری‌استارت یا خطا خودکار بالا بیایند.
6. فایروال و پایش: فقط پورت کنترلی و پورت‌های لازم را باز کنید و وضعیت سرویس‌ها را پایش کنید.

برای نمونه، پیکربندی Rathole برای در دسترس گذاشتن SSH یک سرور دفتر، بر اساس مستندات رسمی پروژه، این شکل را دارد:

# server.toml  (روی رله)
[server]
bind_addr = "0.0.0.0:2333"

[server.services.office_ssh]
token = "REPLACE_WITH_LONG_RANDOM_TOKEN"
bind_addr = "0.0.0.0:5202"

# client.toml  (روی سرور دفتر)
[client]
remote_addr = "relay.example.com:2333"

[client.services.office_ssh]
token = "REPLACE_WITH_LONG_RANDOM_TOKEN"
local_addr = "127.0.0.1:22"

با این پیکربندی، اتصال به پورت 5202 رله به SSH سرور دفتر می‌رسد. در استفادهٔ واقعی، بخش transport را روی noise یا tls بگذارید تا اتصال کنترلی رمزنگاری شود، و دسترسی به پورت 5202 را در فایروال به آی‌پی‌های مدیران محدود کنید. نمونهٔ کامل پیکربندی FRP را هم در مقالهٔ تانل معکوس آورده‌ایم.

نکات امنیتی مشترک

رله به نقطهٔ ورود سرویس‌های شما تبدیل می‌شود؛ پس امنیت آن مهم‌تر از خود سرور داخلی است:

• توکن قوی و یکتا: در Backhaul توکن اختیاری است؛ هرگز آن را خالی نگذارید. برای ساخت توکن از openssl rand -hex 32 استفاده کنید و برای هر سرویس توکن جدا بگذارید.
• رمزنگاری اتصال کنترلی: TLS یا Noise را فعال کنید، به‌ویژه وقتی ترافیک از شبکه‌هایی عبور می‌کند که کنترلی روی آن‌ها ندارید.
• آدرس گوش‌دادن محدود: پورت‌هایی که فقط باید از داخل رله در دسترس باشند (مثل داشبورد FRP یا رابط وب Backhaul) را روی 127.0.0.1 ببندید و با تانل SSH به آن‌ها وصل شوید، نه روی 0.0.0.0.
• فایروال سخت‌گیر: با UFW فقط پورت کنترلی و پورت‌های منتشرشده را باز کنید و در صورت امکان آن‌ها را به آی‌پی‌های مشخص محدود کنید. فهرست پورت‌های رایج را در پورت شبکه چیست؟ ببینید.
• SSH امن روی رله: ورود با کلید و پورت غیرپیش‌فرض و Fail2ban را فعال کنید.
• به‌روزرسانی و لاگ: نسخه‌ها را به‌روز نگه دارید، لاگ‌ها را بررسی کنید و قابلیت‌هایی مثل Sniffer در Backhaul را فقط هنگام عیب‌یابی روشن کنید، چون حجم لاگ و داده‌های حساس را بالا می‌برند.
• کاربر غیر root: سرویس تانل را با یک کاربر محدود اجرا کنید تا آسیب‌پذیری احتمالی ابزار، کل سرور را درگیر نکند.

1. توکن قوی و جدا برای هر سرویس

   با openssl rand بسازید و هرگز توکن نمونهٔ مستندات را به کار نبرید.

2. رمزنگاری اتصال کنترلی

   TLS یا Noise را فعال کنید؛ در Backhaul فقط حالت WSS رمزنگاری دارد.

3. داشبورد فقط روی localhost

   رابط وب و API را روی 127.0.0.1 ببندید و با تانل SSH به آن وصل شوید.

4. فایروال سخت‌گیر روی رله

   فقط پورت کنترلی و پورت‌های لازم را باز و در صورت امکان به آی‌پی‌های مشخص محدود کنید.

5. سرویس دائمی و به‌روزرسانی

   ابزار را با systemd و کاربر غیر root اجرا کنید و نسخه‌ها را به‌روز نگه دارید.

کارایی و منابع سرور

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

• رله کوچک کافی است: برای چند سرویس مدیریتی، یک سرور ۱ هسته و ۱ گیگابایت رم با هر چهار ابزار راحت کار می‌کند. Rathole در همین شرایط کمترین رم را مصرف می‌کند.
• رمزنگاری بار CPU دارد: در سرعت‌های بالا، TLS یا Noise یک هسته را درگیر می‌کند؛ اگر ترافیک زیاد است، ۲ هسته در نظر بگیرید.
• تست بنچمارک خودتان را انجام دهید: نتیجهٔ بنچمارک‌های منتشرشده در مخزن هر پروژه به سخت‌افزار و شبکهٔ آزمایش بستگی دارد. با iperf3 از داخل تانل و ابزارهای تست سرعت و کیفیت سرور روی سناریوی واقعی خودتان مقایسه کنید.
• ترافیک دو بار شمرده می‌شود: رله هر بایت را یک بار دریافت و یک بار ارسال می‌کند. در سرور مجازی ایران کلودیفای فقط ترافیک خروجی (هر گیگابایت ۱٬۲۵۰ تومان) محاسبه می‌شود و ورودی رایگان است؛ جزئیات را در صفحهٔ ترافیک و پهنای باند ببینید.

اشتباهات رایج در انتخاب و راه‌اندازی ابزار تانل

• انتخاب بر اساس محبوبیت در شبکه‌های اجتماعی: ابزاری که در ویدیوها زیاد دیده می‌شود، لزوماً برای کار شما مناسب یا به‌روز نیست. وضعیت نگهداری مخزن را بررسی کنید.
• اجرای اسکریپت‌های نصب ناشناس: اسکریپت‌های «نصب یک‌خطی» از منابع غیررسمی ممکن است تنظیمات ناامن یا کد مخرب داشته باشند. فقط از مخزن رسمی نصب کنید و اسکریپت را پیش از اجرا بخوانید.
• خالی گذاشتن توکن یا استفاده از توکن نمونه: رشته‌هایی مثل your_token در مستندات فقط نمونه‌اند.
• باز گذاشتن داشبورد روی اینترنت: داشبورد بدون رمز یا با رمز پیش‌فرض، راه ورود مستقیم به تنظیمات تانل است.
• فراموش کردن سرویس دائمی: اجرای ابزار در یک ترمینال باز، با قطع SSH یا ری‌استارت متوقف می‌شود. اگر موقتاً لازم است، از tmux یا screen استفاده کنید، ولی برای سرویس واقعی systemd را به کار ببرید.
• اشتباه گرفتن تانل با تغییر DNS: تغییر DNS مسیر ترافیک را عوض نمی‌کند؛ تفاوت را در DNS شکن چیست؟ توضیح داده‌ایم.

عیب‌یابی سریع

برای عیب‌یابی مسیر شبکه از ping، traceroute و mtr و برای خطای اتصال SSH از رفع Connection timed out کمک بگیرید. وضعیت شبکهٔ دیتاسنترهای کلودیفای را هم در صفحهٔ وضعیت ببینید.

سرور رله را از کجا تهیه کنیم؟

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

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

این ابزارها نرم‌افزارهای متن‌باز استاندارد برای مدیریت زیرساخت‌اند، ولی مسئولیت استفاده از آن‌ها با شماست. فقط روی سرورها و شبکه‌هایی تانل بسازید که مالکشان هستید یا اجازهٔ کتبی دارید، قوانین کشور محل سرور و شرایط استفادهٔ ارائه‌دهنده را رعایت کنید و به مجوز هر نرم‌افزار (به‌ویژه AGPL در Backhaul و GPL در nps) هنگام تغییر یا ارائهٔ آن به دیگران توجه داشته باشید. بند «استفادهٔ مجاز» در شرایط استفادهٔ کلودیفای کاربردهای ممنوع را مشخص کرده است.

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

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

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