تانل GRE چیست؟ آموزش راه‌اندازی تانل GRE بین دو سرور لینوکس

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

در این آموزش توضیح می‌دهیم GRE چیست و چطور کار می‌کند، چه زمانی از آن استفاده کنید و چه زمانی سراغ WireGuard یا IPsec بروید، و سپس قدم‌به‌قدم یک تانل GRE بین دو سرور لینوکس می‌سازیم: از ساخت رابط و مسیریابی تا فایروال، MTU، MSS و پایدار کردن تانل پس از ری‌استارت. این مقاله سومین قسمت از مجموعهٔ تانل و شبکهٔ سرور مجلهٔ کلودیفای است.

تانل GRE چیست؟

GRE مخفف Generic Routing Encapsulation است؛ پروتکلی که شرکت Cisco طراحی کرد و در RFC 2784 استاندارد شد. ایدهٔ آن ساده است: یک بستهٔ IP کامل (با آدرس‌های خصوصی دو شبکه) داخل یک هدر GRE و سپس داخل یک بستهٔ IP جدید (با آدرس‌های عمومی دو سرور) قرار می‌گیرد. روترهای اینترنت فقط بستهٔ بیرونی را می‌بینند و آن را به سرور مقصد می‌رسانند. سرور مقصد هدرهای بیرونی را برمی‌دارد و بستهٔ اصلی را طوری تحویل می‌گیرد که انگار مستقیم از یک کابل شبکهٔ محلی رسیده است.

چند ویژگی GRE را از بقیهٔ تانل‌ها متمایز می‌کند:

• پروتکل لایهٔ IP است، نه پورت: GRE پروتکل IP شمارهٔ 47 است و روی TCP یا UDP اجرا نمی‌شود. بنابراین «پورت GRE» وجود ندارد و در فایروال باید قانون را بر اساس پروتکل نوشت. اگر با تفاوت پروتکل و پورت آشنا نیستید، پورت شبکه چیست؟ را بخوانید.
• بدون حالت (Stateless): دو سر تانل هیچ دست‌دادن (Handshake) یا اتصالی برقرار نمی‌کنند. هر سر فقط بسته‌ها را بسته‌بندی و ارسال می‌کند؛ حتی اگر طرف مقابل خاموش باشد، رابط تانل همچنان «UP» نشان داده می‌شود.
• بدون رمزنگاری و احراز هویت: محتوای بسته‌ها در GRE به‌صورت متن ساده عبور می‌کند و هر کسی که مسیر را ببیند، می‌تواند آن را بخواند.
• حمل هر نوع ترافیک لایهٔ ۳: GRE علاوه بر IPv4 و IPv6، ترافیک Multicast را هم عبور می‌دهد؛ به همین دلیل پروتکل‌های مسیریابی مثل OSPF و BGP روی آن به‌خوبی کار می‌کنند.

ساختار بسته و سربار GRE

در حالت پایه، GRE روی IPv4 دقیقاً ۲۴ بایت به هر بسته اضافه می‌کند: ۲۰ بایت هدر IP بیرونی و ۴ بایت هدر GRE. اگر از گزینهٔ Key یا Checksum استفاده کنید، هر کدام ۴ بایت دیگر اضافه می‌کنند. همین سربار است که MTU تانل را از ۱۵۰۰ به ۱۴۷۶ کاهش می‌دهد؛ موضوعی که در بخش MTU به آن برمی‌گردیم.

هدر IP بیرونی (۲۰ بایت)آی‌پی عمومی دو سرور؛ پروتکل 47

هدر GRE (۴ بایت)نوع بستهٔ داخلی؛ گزینه‌های Key و Checksum اختیاری‌اند

هدر IP داخلیآدرس‌های خصوصی دو سر تانل یا شبکه‌های پشت آن‌ها

دادهٔ اصلی (TCP، UDP یا ICMP)بدون تغییر و بدون رمزنگاری عبور می‌کند

لینوکس چند نوع تانل مبتنی بر GRE دارد که نباید با هم اشتباه شوند:

در این آموزش از نوع gre استفاده می‌کنیم که برای اتصال سرور به سرور رایج‌ترین گزینه است.

چه زمانی GRE مناسب است؟

GRE را برای این سناریوها انتخاب کنید:

• شبکهٔ خصوصی بین سرورهای خودتان: مثلاً سرور اپلیکیشن در یک دیتاسنتر و سرور پایگاه داده در دیتاسنتر دیگر که باید با آدرس خصوصی با هم ارتباط داشته باشند.
• اتصال دفتر به دیتاسنتر با روتر سازمانی: بیشتر روترهای Cisco، MikroTik و Juniper از GRE پشتیبانی می‌کنند و سمت دیگر می‌تواند یک سرور مجازی لینوکس باشد.
• اجرای پروتکل‌های مسیریابی: اگر می‌خواهید بین دو سایت BGP یا OSPF اجرا کنید، GRE چون Multicast را عبور می‌دهد، انتخاب طبیعی است.
• لایهٔ زیرین برای IPsec: در طراحی کلاسیک «GRE over IPsec»، تانل GRE مسیریابی را انجام می‌دهد و IPsec رمزنگاری را.
• آزمایشگاه و آموزش شبکه: راه‌اندازی GRE چند دقیقه طول می‌کشد و برای یادگیری مفاهیم Encapsulation و مسیریابی عالی است.

GRE برای این موارد مناسب نیست: انتقال داده‌های حساس بدون لایهٔ رمزنگاری، اتصال از پشت NAT (چون GRE پورت ندارد، بیشتر مودم‌ها و NATها نمی‌توانند آن را درست ترجمه کنند) و شبکه‌هایی که پروتکل‌های غیر TCP و UDP را مسدود می‌کنند. اگر یک سر شما پشت NAT است، تانل معکوس راه‌حل مناسب‌تری است.

مقایسهٔ GRE با WireGuard، IPsec و تانل SSH

خلاصهٔ این جدول: اگر به رمزنگاری نیاز دارید و هر دو سر لینوکس هستند، WireGuard معمولاً ساده‌تر و امن‌تر است. اگر یک سر روتر سازمانی است یا به پروتکل مسیریابی نیاز دارید، GRE (به‌تنهایی یا همراه IPsec) انتخاب بهتری است.

GRE

• بدون رمزنگاری و احراز هویت
• پروتکل 47، بدون پورت
• عبور Multicast و پروتکل‌های مسیریابی
• سازگار با روترهای سازمانی
• از بیشتر NATها عبور نمی‌کند

در برابر

WireGuard

• رمزنگاری و احراز هویت با کلید
• روی یک پورت UDP اجرا می‌شود
• Multicast را عبور نمی‌دهد
• مناسب اتصال امن سرورهای لینوکس
• از NAT به‌خوبی عبور می‌کند

پیش‌نیازهای راه‌اندازی تانل GRE

پیش از شروع این موارد را آماده کنید:

1. دو سرور لینوکس با آی‌پی عمومی ثابت: در این آموزش «سرور A» با آی‌پی 198.51.100.10 و «سرور B» با آی‌پی 203.0.113.20 را فرض می‌کنیم. این آدرس‌ها نمونه‌های مستندسازی‌اند؛ آن‌ها را با آی‌پی سرورهای خودتان جایگزین کنید. معیارهای انتخاب سرور مناسب را در خرید سرور ایران برای تانل توضیح داده‌ایم.
2. دسترسی root و مجازی‌سازی کامل: ماژول کرنل ip_gre باید قابل بارگذاری باشد. روی سرورهای کانتینری ممکن است این امکان وجود نداشته باشد.
3. یک زیرشبکهٔ خصوصی برای تانل: ما از 10.200.0.0/30 استفاده می‌کنیم؛ 10.200.0.1 برای سرور A و 10.200.0.2 برای سرور B. این زیرشبکه نباید با شبکه‌های موجود شما تداخل داشته باشد.
4. عبور پروتکل 47 در شبکهٔ ارائه‌دهنده: بعضی شبکه‌ها پروتکل‌های غیر TCP و UDP را مسدود می‌کنند. پیش از خرید دائمی، با یک سرور ساعتی تست کنید.

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

آموزش راه‌اندازی تانل GRE بین دو سرور لینوکس

گام ۱: بارگذاری ماژول کرنل

روی هر دو سرور، ماژول GRE را بارگذاری کنید و مطمئن شوید که پس از ری‌استارت هم بارگذاری می‌شود:

sudo modprobe ip_gre
lsmod | grep gre
echo ip_gre | sudo tee /etc/modules-load.d/gre.conf

اگر دستور modprobe خطا داد، کرنل سرور از GRE پشتیبانی نمی‌کند یا نوع مجازی‌سازی اجازهٔ بارگذاری ماژول را نمی‌دهد.

گام ۲: ساخت رابط تانل روی سرور A

# روی سرور A (198.51.100.10)
sudo ip tunnel add gre1 mode gre local 198.51.100.10 remote 203.0.113.20 ttl 255
sudo ip addr add 10.200.0.1/30 dev gre1
sudo ip link set gre1 mtu 1476 up

در این دستورها local آی‌پی عمومی همین سرور و remote آی‌پی عمومی سرور مقابل است. گزینهٔ ttl 255 باعث می‌شود بستهٔ بیرونی در مسیرهای طولانی حذف نشود. به‌جای ip tunnel add می‌توانید از شکل جدیدتر ip link add gre1 type gre local ... remote ... ttl 255 هم استفاده کنید؛ نتیجه یکی است.

گام ۳: ساخت رابط تانل روی سرور B

روی سرور B همان دستورها را با جابه‌جا کردن local و remote و آدرس دوم زیرشبکه اجرا کنید:

# روی سرور B (203.0.113.20)
sudo ip tunnel add gre1 mode gre local 203.0.113.20 remote 198.51.100.10 ttl 255
sudo ip addr add 10.200.0.2/30 dev gre1
sudo ip link set gre1 mtu 1476 up

گام ۴: باز کردن پروتکل 47 در فایروال

اگر فایروال فعال است، بسته‌های GRE را فقط از آی‌پی سرور مقابل بپذیرید. در UFW (نسخهٔ ۰.۳۶ به بعد، موجود در اوبونتو ۲۲.۰۴ و ۲۴.۰۴) این کار با گزینهٔ proto gre انجام می‌شود:

# روی سرور A؛ روی سرور B آی‌پی را با 198.51.100.10 عوض کنید
sudo ufw allow proto gre from 203.0.113.20
# یا با nftables
sudo nft add rule inet filter input ip saddr 203.0.113.20 ip protocol gre accept

قانون nftables بالا فرض می‌کند جدول inet filter و زنجیرهٔ input از قبل وجود دارند. جزئیات کار با UFW را در آموزش فایروال UFW ببینید. هرگز GRE را برای همهٔ آی‌پی‌ها باز نکنید؛ چون GRE احراز هویت ندارد، هر کسی که آی‌پی مبدأ را جعل کند می‌تواند بسته به تانل شما تزریق کند.

گام ۵: تست اتصال

# روی سرور A
ip -d link show gre1
ping -c 4 10.200.0.2
# بررسی عبور بسته‌های GRE روی رابط اصلی
sudo tcpdump -ni eth0 ip proto 47

اگر پینگ پاسخ داد، تانل کار می‌کند. اگر پاسخی نیامد، با tcpdump روی هر دو سرور ببینید بسته‌ها به کجا می‌رسند: اگر روی سرور A ارسال می‌شوند ولی روی سرور B دیده نمی‌شوند، مشکل از فایروال یا شبکهٔ ارائه‌دهنده است. نام رابط اصلی ممکن است به‌جای eth0 چیزی مثل ens3 باشد؛ آن را با ip -br a پیدا کنید. برای عیب‌یابی مسیر هم از ping، traceroute و mtr کمک بگیرید.

مسیریابی: اتصال شبکهٔ پشت سرورها

تا این‌جا فقط دو سرور از طریق آدرس‌های 10.200.0.1 و 10.200.0.2 به هم دسترسی دارند. اگر پشت سرور B یک شبکهٔ خصوصی (مثلاً 192.168.20.0/24 در دفتر یا دیتاسنتر) وجود دارد و می‌خواهید سرور A به آن برسد، یک مسیر اضافه کنید:

# روی سرور A: ترافیک شبکهٔ 192.168.20.0/24 از تانل برود
sudo ip route add 192.168.20.0/24 via 10.200.0.2 dev gre1
# روی سرور B: فعال کردن ارسال بسته بین رابط‌ها
echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/90-gre-forward.conf
sudo sysctl --system

سرورها یا روتر داخل شبکهٔ 192.168.20.0/24 هم باید بدانند پاسخ را به کجا بفرستند؛ یا سرور B دروازهٔ پیش‌فرض آن‌هاست، یا روی روتر آن شبکه مسیری به سمت 10.200.0.0/30 و شبکهٔ سرور A اضافه می‌کنید. اگر بسته فقط در یک جهت عبور می‌کند، معمولاً مسیر برگشت فراموش شده است.

یک هشدار مهم: هرگز مسیر پیش‌فرض سرور را به داخل تانل نبرید، مگر اینکه دقیقاً بدانید چه می‌کنید. اگر مسیر رسیدن به آی‌پی عمومی سر دیگر هم از داخل تانل بگذرد، تانل خودش را قطع می‌کند و دسترسی SSH را هم از دست می‌دهید.

MTU و MSS: مهم‌ترین علت کندی تانل GRE

اینترنت معمولاً بسته‌هایی تا ۱۵۰۰ بایت را عبور می‌دهد. چون GRE ۲۴ بایت به هر بسته اضافه می‌کند، بزرگ‌ترین بستهٔ داخلی که بدون تکه‌تکه شدن عبور می‌کند ۱۴۷۶ بایت است. اگر MTU تانل درست نباشد، این علائم را می‌بینید: پینگ کار می‌کند ولی صفحه‌های وب نیمه‌کاره باز می‌شوند، SSH وصل می‌شود ولی با اجرای دستوری که خروجی زیادی دارد قفل می‌شود، یا انتقال فایل وسط کار متوقف می‌شود.

برای پیدا کردن بزرگ‌ترین بستهٔ قابل‌عبور، با پرچم «تکه‌تکه نکن» پینگ بگیرید. عدد -s اندازهٔ داده است و ۲۸ بایت هدر IP و ICMP به آن اضافه می‌شود:

ping -M do -s 1448 -c 3 10.200.0.2   # 1448 + 28 = 1476

اگر این پینگ خطای message too long داد، عدد را کم کنید تا پاسخ بگیرید و MTU رابط را بر اساس آن تنظیم کنید.

مشکل دوم برای ترافیک TCP است که از تانل عبور می‌کند (نه ترافیکی که خود سرور تولید می‌کند). دستگاه‌های پشت تانل نمی‌دانند MTU کمتر شده است و اگر پیام‌های ICMP در مسیر مسدود باشند، بسته‌های بزرگ بی‌صدا حذف می‌شوند. راه‌حل استاندارد، MSS Clamping روی سرورهای دروازه است تا اندازهٔ سگمنت TCP در همان شروع اتصال اصلاح شود:

# iptables
sudo iptables -t mangle -A FORWARD -o gre1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
# معادل در nftables (زنجیرهٔ forward از قبل وجود دارد)
sudo nft add rule inet filter forward oifname "gre1" tcp flags syn tcp option maxseg size set rt mtu

اگر از MSS ثابت استفاده می‌کنید، مقدار مناسب برای GRE روی IPv4، عدد ۱۴۳۶ (یعنی ۱۴۷۶ منهای ۴۰ بایت هدر IP و TCP) است. اگر تانل GRE را داخل تانل دیگری (مثلاً IPsec) قرار داده‌اید، سربار آن لایه را هم کم کنید.

پایدار کردن تانل پس از ری‌استارت

دستورهای ip فقط تا ری‌استارت بعدی معتبرند. ساده‌ترین روش قابل‌حمل برای پایدار کردن تانل، یک سرویس systemd از نوع oneshot است. این فایل را روی سرور A بسازید (روی سرور B آدرس‌ها را جابه‌جا کنید):

# /etc/systemd/system/gre1.service
[Unit]
Description=GRE tunnel gre1 to server B
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/ip tunnel add gre1 mode gre local 198.51.100.10 remote 203.0.113.20 ttl 255
ExecStart=/usr/sbin/ip addr add 10.200.0.1/30 dev gre1
ExecStart=/usr/sbin/ip link set gre1 mtu 1476 up
ExecStop=/usr/sbin/ip link del gre1

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now gre1.service
systemctl status gre1.service

اگر مسیرهای اضافه (گام مسیریابی) هم دارید، آن‌ها را به‌صورت خط‌های ExecStart بعدی به همین فایل اضافه کنید. روش‌های دیگر مثل بخش tunnels در Netplan یا فایل‌های .netdev در systemd-networkd هم کار می‌کنند، ولی به نسخهٔ سیستم‌عامل و نحوهٔ مدیریت شبکهٔ سرور وابسته‌اند.

Keepalive و پایش سلامت تانل

برخلاف روترهای Cisco که برای GRE گزینهٔ Keepalive دارند، کرنل لینوکس برای GRE سازوکار Keepalive داخلی ندارد. پیامد عملی این است که اگر سر دیگر خاموش شود یا مسیر اینترنت قطع شود، رابط gre1 همچنان UP می‌ماند و سرور ترافیک را به داخل تانلی می‌فرستد که به جایی نمی‌رسد.

سه راه رایج برای تشخیص قطعی:

• پایش پینگ: آدرس سر دیگر تانل (10.200.0.2) را با ابزاری مثل Uptime Kuma پایش کنید تا هنگام قطعی هشدار بگیرید.
• پروتکل مسیریابی: اگر روی تانل BGP یا OSPF (مثلاً با FRRouting) اجرا می‌کنید، خود پروتکل با پیام‌های Hello قطعی را تشخیص می‌دهد و مسیر را برمی‌دارد. افزودن BFD زمان تشخیص را به کمتر از یک ثانیه می‌رساند.
• اسکریپت سلامت: یک تایمر systemd یا Cron که هر دقیقه پینگ می‌گیرد و در صورت قطعی، رویداد را ثبت یا مسیر پشتیبان را فعال می‌کند.

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

امنیت تانل GRE

چون GRE رمزنگاری ندارد، این قواعد را رعایت کنید:

• محدود کردن آی‌پی مبدأ: فقط آی‌پی عمومی سر مقابل اجازهٔ ارسال پروتکل 47 را داشته باشد.
• رمزنگاری لایهٔ بالاتر: ترافیک حساس داخل تانل را با TLS، SSH یا رمزنگاری خود اپلیکیشن محافظت کنید، یا GRE را داخل IPsec در حالت Transport قرار دهید.
• محدود کردن ترافیک عبوری: با قوانین زنجیرهٔ forward مشخص کنید کدام شبکه‌ها و پورت‌ها اجازهٔ عبور از تانل را دارند.
• کلید GRE را امنیت حساب نکنید: گزینهٔ key فقط برای جدا کردن چند تانل بین دو آی‌پی یکسان است و رمزنگاری یا احراز هویت واقعی ایجاد نمی‌کند.
• پایش لاگ و ترافیک: افزایش ناگهانی ترافیک روی رابط تانل می‌تواند نشانهٔ سوءاستفاده باشد. ابزارهای مانیتورینگ ترافیک سرور را روی gre1 هم اجرا کنید.

ترافیک و هزینهٔ تانل GRE

هر بایتی که از تانل عبور می‌کند، به‌اضافهٔ ۲۴ بایت سربار، از رابط اصلی سرور می‌گذرد و در ترافیک ماهانه حساب می‌شود؛ یعنی سربار GRE حدود ۱٫۶ درصد برای بسته‌های بزرگ است و برای بسته‌های کوچک بیشتر. اگر سرور در نقش دروازه، ترافیک را از یک سر دریافت و به سر دیگر ارسال کند، هم ورودی و هم خروجی ثبت می‌شود. در سرور مجازی ایران کلودیفای فقط ترافیک خروجی محاسبه می‌شود (هر گیگابایت ۱٬۲۵۰ تومان) و ورودی رایگان است؛ جزئیات را در صفحهٔ ترافیک و پهنای باند و مقالهٔ ترافیک ورودی و خروجی سرور ببینید.

عیب‌یابی رایج تانل GRE

اگر پس از تغییر مسیرها دسترسی SSH قطع شد، از کنسول پنل ارائه‌دهنده وارد شوید و با ip route مسیر اشتباه را حذف کنید. برای خطاهای عمومی اتصال هم راهنمای خطای SSH Connection timed out کمک می‌کند.

اشتباهات رایج در راه‌اندازی GRE

• انتظار رمزنگاری از GRE: GRE فقط بسته‌بندی می‌کند؛ برای داده‌های حساس لایهٔ رمزنگاری جداگانه لازم است.
• باز کردن پروتکل 47 برای همه: همیشه آی‌پی مبدأ را محدود کنید.
• فراموش کردن MTU: پیش‌فرض ۱۵۰۰ روی رابط تانل، مهم‌ترین علت کندی و قطعی‌های عجیب است.
• تداخل زیرشبکه‌ها: اگر زیرشبکهٔ تانل با شبکهٔ داخلی یکی از سرورها یا شبکهٔ داکر یکسان باشد، مسیریابی به هم می‌ریزد.
• راه‌اندازی پشت NAT: GRE پورت ندارد و از بیشتر NATها عبور نمی‌کند؛ در این حالت از WireGuard یا تانل معکوس استفاده کنید.
• اشتباه گرفتن تانل با تغییر DNS: تغییر DNS فقط نحوهٔ پیدا شدن آدرس‌ها را عوض می‌کند و مسیر ترافیک را تغییر نمی‌دهد؛ تفاوت را در DNS شکن چیست؟ توضیح داده‌ایم.

کدام سرور برای تانل GRE؟

برای GRE به سرور قدرتمندی نیاز ندارید؛ چون رمزنگاری انجام نمی‌شود، پردازش بسته‌ها بار ناچیزی روی CPU دارد و یک سرور ۱ هسته و ۱ گیگابایت رم معمولاً کافی است. مهم‌تر از پردازنده، آی‌پی عمومی ثابت، سرعت پورت، عبور پروتکل 47 و مسیر شبکهٔ کوتاه بین دو سر است.

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

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

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

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

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

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

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