آموزش تانل 6to4 و تانل IPv6 (sit) بین دو سرور لینوکس و میکروتیک

گاهی یکی از سرورهای شما IPv6 دارد و دیگری ندارد؛ مثلاً ارائه‌دهندهٔ یک لوکیشن هنوز IPv6 نمی‌دهد، یا می‌خواهید چند سرور را با یک بلوک IPv6 مشترک مدیریت کنید. در این شرایط معمولاً عبارت تانل 6to4 جست‌وجو می‌شود، ولی بیشتر آموزش‌های قدیمی همان روش کلاسیک 6to4 را توضیح می‌دهند که امروز عملاً کنار گذاشته شده است. در این آموزش اول توضیح می‌دهیم 6to4 کلاسیک چه بود و چرا دیگر نباید به آن تکیه کرد، و سپس روش درست و امروزی تانل IPv6 بین دو سرور را با sit و ip6ip6 در لینوکس و رابط 6to4 در میکروتیک، قدم‌به‌قدم راه می‌اندازیم.

مثال‌ها از آدرس‌های مستندسازی استفاده می‌کنند: سرور A با IPv4 عمومی 203.0.113.10 که IPv6 بومی دارد و ارائه‌دهنده بلوک 2001:db8:aaaa::/48 را به آن مسیریابی کرده است، و سرور B با IPv4 عمومی 198.51.100.20 که IPv6 ندارد. برای لینک تانل از زیرشبکهٔ 2001:db8:aaaa:ffff::/64 استفاده می‌کنیم.

مروری بر IPv6 برای مدیر سرور

IPv6 نسخهٔ جدید پروتکل اینترنت با آدرس‌های ۱۲۸ بیتی است. اگر با مفاهیم پایه آشنا نیستید، اول آی‌پی چیست؟ را بخوانید. چند نکته که در تانل‌سازی اهمیت دارد:

• پیشوند و زیرشبکه: آدرس‌ها به شکل پیشوند تقسیم می‌شوند. اندازهٔ استاندارد یک زیرشبکه /64 است و ارائه‌دهنده‌ها معمولاً یک /64، /56 یا /48 به هر سرور یا مشتری می‌دهند.
• پیشوند روی لینک در برابر پیشوند مسیریابی‌شده: اگر ارائه‌دهنده فقط یک /64 روی کارت شبکهٔ سرور گذاشته باشد، آن آدرس‌ها «روی لینک» هستند و روتر ارائه‌دهنده انتظار دارد هر آدرس مستقیم روی همان کارت شبکه پاسخ دهد. اگر یک بلوک به سمت سرور شما «مسیریابی» شده باشد، می‌توانید بخشی از آن را بدون ترفند اضافه به تانل بدهید. پیش از شروع، این را از ارائه‌دهندهٔ سرور A بپرسید.
• ICMPv6 حیاتی است: کشف همسایه (NDP)، تنظیم خودکار آدرس و پیام Packet Too Big برای تشخیص MTU همگی روی ICMPv6 کار می‌کنند. بستن کامل ICMPv6 در فایروال، شبکهٔ IPv6 را خراب می‌کند.
• روترها بسته را تکه نمی‌کنند: در IPv6 فقط فرستنده می‌تواند بسته را تکه‌تکه کند. اگر بسته از MTU مسیر بزرگ‌تر باشد، روتر آن را دور می‌اندازد و پیام Packet Too Big برمی‌گرداند. حداقل MTU مجاز در IPv6، عدد ۱۲۸۰ است.
• آدرس‌های خصوصی: اگر فقط شبکهٔ داخلی بین سرورها لازم دارید، رنج ULA یعنی fd00::/8 معادل رنج‌های خصوصی IPv4 است و نیازی به آدرس عمومی ندارد.

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

• رساندن IPv6 به سروری که آن را ندارد: سرویسی که باید روی IPv6 هم در دسترس باشد، یا ابزاری که برای آزمایش یا به‌روزرسانی به مقصدهای IPv6 نیاز دارد.
• یک بلوک آدرس واحد برای چند سرور: آدرس‌دهی یکسان و قابل پیش‌بینی برای سرورهای چند لوکیشن، بدون وابستگی به آدرس‌های هر ارائه‌دهنده.
• شبکهٔ خصوصی IPv6 بین دو سایت: اتصال دو شبکهٔ داخلی که با IPv6 آدرس‌دهی شده‌اند.
• آزمایش و مهاجرت: آماده کردن سرویس‌ها برای IPv6 پیش از اینکه همهٔ لوکیشن‌ها IPv6 بومی داشته باشند.

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

6to4 در سال ۲۰۰۱ با RFC 3056 معرفی شد تا شبکه‌هایی که فقط IPv4 داشتند، بدون هماهنگی با هیچ ارائه‌دهنده‌ای به IPv6 دسترسی پیدا کنند. ایده ساده بود: از هر آی‌پی عمومی IPv4 یک پیشوند IPv6 در بازهٔ 2002::/16 ساخته می‌شود. مثلاً از 203.0.113.10، با نوشتن چهار بخش آن به شکل هگزادسیمال، پیشوند 2002:cb00:710a::/48 به دست می‌آید. بسته‌ها بین دو شبکهٔ 6to4 مستقیم داخل IPv4 جابه‌جا می‌شدند و برای رسیدن به بقیهٔ اینترنت IPv6، به یک «رلهٔ» عمومی فرستاده می‌شدند که RFC 3068 برای آن آدرس anycast یعنی 192.88.99.1 را تعیین کرده بود.

در عمل این طرح مشکلات جدی داشت:

• رله‌های ناشناس و غیرقابل کنترل: هر کسی می‌توانست رله راه بیندازد و مسیر رفت و برگشت ممکن بود از رله‌های مختلف و دور عبور کند. کیفیت، تأخیر و حتی در دسترس بودن رله در اختیار شما نبود.
• مسیرهای نامتقارن و خرابی خاموش: وقتی یک رله از کار می‌افتاد یا بسته‌ها را دور می‌انداخت، اتصال بدون هیچ پیام خطای روشنی قطع می‌شد و برنامه‌ها روی IPv6 معطل می‌ماندند.
• ناسازگاری با NAT: 6to4 به آی‌پی عمومی روی خود دستگاه نیاز داشت و پشت NAT کار نمی‌کرد.
• نگرانی‌های امنیتی: پذیرفتن بسته‌های پروتکل ۴۱ از هر مبدأ، امکان جعل و سوءاستفاده را بیشتر می‌کرد.

به همین دلایل، IETF در سال ۲۰۱۱ با RFC 6343 توصیه کرد 6to4 به‌طور پیش‌فرض خاموش باشد و در سال ۲۰۱۵ با RFC 7526 سازوکار رلهٔ anycast و پیشوند 192.88.99.0/24 را رسماً منسوخ کرد. نسخه‌ای که ارائه‌دهندگان اینترنت خودشان مدیریت می‌کنند، یعنی 6rd، هنوز در برخی شبکه‌ها استفاده می‌شود، ولی آن هم به زیرساخت ارائه‌دهنده وابسته است. نتیجه برای مدیر سرور روشن است: روی 6to4 خودکار و رله‌های عمومی حساب نکنید. همان سازوکار بسته‌بندی، یعنی IPv6 داخل IPv4 با پروتکل ۴۱، را به‌صورت تانل دستی نقطه‌به‌نقطه بین دو سروری که خودتان کنترل می‌کنید استفاده کنید. نام «6to4» در منوی میکروتیک هم دقیقاً همین تانل دستی است.

انواع تانل IPv6 در لینوکس

sit رایج‌ترین گزینه برای رساندن IPv6 به سروری است که فقط IPv4 دارد. ip6ip6 برای وقتی است که هر دو سر IPv6 دارند و می‌خواهید یک پیشوند یا شبکهٔ داخلی IPv6 را از یک مسیر مشخص عبور دهید. ipip6 حالت برعکس است: رساندن IPv4 به سروری که فقط IPv6 دارد. GRE را در آموزش تانل GRE در لینوکس کامل توضیح داده‌ایم؛ یک تانل GRE روی IPv4 می‌تواند IPv6 را هم حمل کند و برای پروتکل‌های مسیریابی و Multicast مناسب‌تر است.

پیش‌نیازها

• دو سرور لینوکس با IPv4 عمومی ثابت و مجازی‌سازی کامل مثل KVM؛ تانل‌های لایهٔ IP روی کانتینرهای اشتراکی معمولاً کار نمی‌کنند. جزئیات را در خرید سرور ایران برای تانل آورده‌ایم.
• یک سرور با IPv6 بومی و ترجیحاً یک بلوک مسیریابی‌شده. سرور مجازی ایران کلودیفای در کنار IPv4، IPv6 هم دارد؛ اندازه و نوع پیشوند هر سرویس را پیش از طراحی بررسی کنید.
• دسترسی کنسول از پنل، تا اگر تغییر مسیر یا فایروال اتصال SSH را قطع کرد، راه بازگشت داشته باشید.
• نبود NAT بین دو سرور. اگر یکی از سرورها پشت NAT است، به‌جای sit از WireGuard استفاده کنید.

راه‌اندازی تانل sit بین دو سرور لینوکس

روی سرور A، که IPv6 دارد، رابط تانل را بسازید، آدرس لینک تانل را بدهید و فوروارد IPv6 را فعال کنید:

sudo ip tunnel add sit1 mode sit local 203.0.113.10 remote 198.51.100.20 ttl 255
sudo ip link set sit1 up mtu 1480
sudo ip -6 addr add 2001:db8:aaaa:ffff::1/64 dev sit1
sudo sysctl -w net.ipv6.conf.all.forwarding=1

یک نکتهٔ مهم: وقتی فوروارد IPv6 روشن شود، لینوکس به‌طور پیش‌فرض دیگر به پیام‌های Router Advertisement گوش نمی‌دهد. اگر سرور A آدرس یا مسیر پیش‌فرض IPv6 خود را به‌صورت خودکار از ارائه‌دهنده می‌گیرد، روی کارت شبکهٔ اصلی مقدار accept_ra را روی ۲ بگذارید تا اتصال IPv6 خود سرور A قطع نشود:

sudo sysctl -w net.ipv6.conf.eth0.accept_ra=2

روی سرور B، همان رابط را با جابه‌جا کردن آدرس‌ها بسازید و مسیر پیش‌فرض IPv6 را به سرور A بفرستید:

sudo ip tunnel add sit1 mode sit local 198.51.100.20 remote 203.0.113.10 ttl 255
sudo ip link set sit1 up mtu 1480
sudo ip -6 addr add 2001:db8:aaaa:ffff::2/64 dev sit1
sudo ip -6 route add default via 2001:db8:aaaa:ffff::1 dev sit1

ابتدا از سرور B آدرس تانل سرور A را پینگ کنید و سپس یک مقصد عمومی IPv6 را آزمایش کنید:

ping -6 -c 3 2001:db8:aaaa:ffff::1
curl -6 -sI https://example.com | head -1

$ sudo ip tunnel add sit1 mode sit local 198.51.100.20 remote 203.0.113.10 ttl 255$ sudo ip link set sit1 up mtu 1480$ sudo ip -6 addr add 2001:db8:aaaa:ffff::2/64 dev sit1$ sudo ip -6 route add default via 2001:db8:aaaa:ffff::1 dev sit1$ ip -6 route show defaultdefault via 2001:db8:aaaa:ffff::1 dev sit1 metric 1024 pref medium$ 

اگر اولین پینگ جواب داد ولی دومی نه، مشکل معمولاً در سرور A است: یا فوروارد فعال نیست، یا ارائه‌دهنده پیشوند 2001:db8:aaaa::/48 را واقعاً به سرور A مسیریابی نکرده است. در حالت دوم، ارائه‌دهنده فقط آدرس‌هایی را تحویل می‌دهد که روی کارت شبکهٔ اصلی سرور A پاسخ دهند. راه‌حل استاندارد، گرفتن یک پیشوند مسیریابی‌شده از ارائه‌دهنده است. راه جایگزین، «پروکسی NDP» است: سرور A به جای سرور B به درخواست‌های کشف همسایه پاسخ می‌دهد. این روش با net.ipv6.conf.eth0.proxy_ndp = 1 و ثبت هر آدرس با ip -6 neigh add proxy کار می‌کند، ولی برای تعداد زیاد آدرس دست‌وپاگیر است؛ پیش از استفاده، شرایط ارائه‌دهنده را هم بررسی کنید.

اگر پشت سرور B یک شبکهٔ داخلی دارید و می‌خواهید آن هم IPv6 بگیرد، یک /64 دیگر از همان بلوک، مثلاً 2001:db8:aaaa:100::/64، به شبکهٔ داخلی B بدهید و روی سرور A مسیر آن را به تانل بفرستید: sudo ip -6 route add 2001:db8:aaaa:100::/64 via 2001:db8:aaaa:ffff::2 dev sit1. در این حالت فوروارد IPv6 روی سرور B هم باید روشن باشد.

تانل ip6ip6 و ipip6

وقتی هر دو سرور IPv6 دارند، تانل ip6ip6 بسته‌های IPv6 را داخل IPv6 بسته‌بندی می‌کند. این برای عبور دادن یک پیشوند داخلی از مسیری مشخص، یا جدا کردن ترافیک یک شبکه از ترافیک عادی سرور کاربرد دارد. فرض کنید سرور A آدرس 2001:db8:aaaa::10 و سرور B آدرس 2001:db8:bbbb::20 دارد:

sudo ip -6 tunnel add ip6t1 mode ip6ip6 local 2001:db8:aaaa::10 remote 2001:db8:bbbb::20 encaplimit none
sudo ip link set ip6t1 up mtu 1460
sudo ip -6 addr add fd00:66::1/64 dev ip6t1

روی سرور B همین دستورها را با جابه‌جا کردن آدرس‌ها و آدرس fd00:66::2 اجرا کنید. در این مثال برای لینک تانل از رنج خصوصی ULA استفاده کرده‌ایم. گزینهٔ encaplimit none سرآیند اختیاری محدودیت بسته‌بندی را حذف می‌کند تا سربار دقیقاً ۴۰ بایت بماند؛ اگر آن را حذف کنید، لینوکس چند بایت دیگر اضافه می‌کند و MTU باید کمی کوچک‌تر باشد. با mode ipip6 همین تانل IPv4 را روی IPv6 حمل می‌کند؛ این حالت برای سروری که فقط IPv6 دارد و باید به یک مقصد IPv4 برسد مفید است.

پایدار کردن تانل با Netplan

دستورهای ip تا ری‌استارت بعدی معتبرند. در اوبونتو، Netplan بخش tunnels را با حالت‌های sit و ip6ip6 و ipip6 و ip6gre پشتیبانی می‌کند. روی سرور B فایلی مثل /etc/netplan/60-sit1.yaml بسازید:

network:
  version: 2
  tunnels:
    sit1:
      mode: sit
      local: 198.51.100.20
      remote: 203.0.113.10
      mtu: 1480
      addresses:
        - "2001:db8:aaaa:ffff::2/64"
      routes:
        - to: "::/0"
          via: "2001:db8:aaaa:ffff::1"

سپس با sudo netplan try تغییر را آزمایش کنید؛ اگر اتصال قطع شد و تأیید نکردید، Netplan پس از مهلت کوتاهی تنظیمات قبلی را برمی‌گرداند. روی سرور A هم همین کار را با آدرس‌های خودش انجام دهید و مقدارهای sysctl را در فایلی مثل /etc/sysctl.d/99-ipv6-tunnel.conf ثبت کنید. اگر Netplan ندارید، روش سرویس oneshot در راهنمای ساخت سرویس systemd، همان‌طور که در آموزش GRE استفاده کردیم، هم کار می‌کند.

تانل IPv6 در میکروتیک

در RouterOS، رابط sit با نام 6to4 شناخته می‌شود، ولی با تعیین آدرس مقابل، همان تانل دستی نقطه‌به‌نقطه است و ربطی به رله‌های عمومی ندارد. اگر سرور B یک روتر میکروتیک باشد، تنظیمات معادل در RouterOS 7 این است:

/interface 6to4 add name=sit1 local-address=198.51.100.20 remote-address=203.0.113.10 mtu=1480
/ipv6 address add address=2001:db8:aaaa:ffff::2/64 interface=sit1 advertise=no
/ipv6 route add dst-address=::/0 gateway=2001:db8:aaaa:ffff::1
/ip firewall filter add chain=input protocol=ipv6-encap src-address=203.0.113.10 action=accept place-before=0

قانون آخر پروتکل ۴۱ را فقط از آی‌پی سرور A می‌پذیرد. اگر می‌خواهید شبکهٔ داخلی پشت روتر هم IPv6 بگیرد، یک /64 دیگر روی رابط داخلی با advertise=yes تعریف کنید تا دستگاه‌ها با SLAAC آدرس بگیرند، و حتماً قوانین /ipv6 firewall filter را برای محافظت از شبکهٔ داخلی تنظیم کنید. رابط 6to4 در RouterOS گزینهٔ keepalive هم دارد که قطع شدن تانل را تشخیص می‌دهد.

MTU در تانل IPv6

چون روترهای IPv6 بسته را تکه نمی‌کنند، MTU نادرست در تانل IPv6 مستقیماً به گم شدن بسته‌های بزرگ منجر می‌شود. علامت آن آشناست: پینگ و SSH کار می‌کنند، ولی صفحه‌های بزرگ HTTPS یا انتقال فایل گیر می‌کند. برای آزمایش، از سرور B بستهٔ بزرگ و بدون تکه‌تکه شدن بفرستید:

ping -6 -M do -s 1432 -c 3 2001:db8:aaaa:ffff::1

عدد ۱۴۳۲ به‌اضافهٔ ۸ بایت سرآیند ICMPv6 و ۴۰ بایت سرآیند IPv6، برابر ۱۴۸۰ است. اگر پاسخ نیامد، MTU مسیر IPv4 بین دو سرور کمتر از ۱۵۰۰ است؛ عدد را کم کنید تا مقدار سالم را پیدا کنید و MTU تانل را مطابق آن تنظیم کنید. هرگز MTU را کمتر از ۱۲۸۰ نگذارید. اگر سرور A ترافیک یک شبکه را فوروارد می‌کند، قانون ip6tables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu اندازهٔ MSS اتصال‌های TCP را با MTU تانل هماهنگ می‌کند. کیفیت مسیر را هم با ابزارهای ping، traceroute و mtr بسنجید.

فایروال: پروتکل ۴۱ و ip6tables و nftables

دو لایهٔ فایروال باید درست تنظیم شود. لایهٔ اول، بستهٔ بیرونی است: تانل sit از پروتکل IP شمارهٔ ۴۱ استفاده می‌کند که پورت ندارد. آن را فقط برای آی‌پی سرور مقابل باز کنید. روی سرور A با فایروال UFW:

sudo ufw allow from 198.51.100.20 to any proto ipv6

در UFW، نام ipv6 در قانون به همین پروتکل ۴۱ اشاره دارد. با iptables معادل آن sudo iptables -A INPUT -p 41 -s 198.51.100.20 -j ACCEPT و با nftables، قانونی مثل ip saddr 198.51.100.20 ip protocol 41 accept در زنجیرهٔ input است.

لایهٔ دوم، خود ترافیک IPv6 است و همان جایی است که بیشتر مدیران فراموش می‌کنند. سرور B تا امروز آدرس IPv6 نداشت و حالا یک آدرس عمومی دارد؛ هر سرویسی که روی همهٔ آدرس‌ها گوش می‌دهد، از این لحظه از اینترنت IPv6 در دسترس است. اگر از UFW استفاده می‌کنید، مطمئن شوید در فایل /etc/default/ufw مقدار IPV6=yes است تا قانون‌ها روی IPv6 هم اعمال شوند. با nftables، یک جدول جداگانه برای IPv6 به این شکل حداقل‌های لازم را رعایت می‌کند:

table ip6 filter6 {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    meta l4proto ipv6-icmp accept
    tcp dport 22 accept
  }
}

این جدول فقط ترافیک IPv6 را فیلتر می‌کند و ICMPv6 را باز می‌گذارد، چون کشف همسایه و تشخیص MTU به آن وابسته‌اند. پورت‌های دیگر را فقط در صورت نیاز اضافه کنید. روی سرور A، اگر ترافیک سرور B را فوروارد می‌کند، زنجیرهٔ forward را هم با همین منطق تنظیم کنید.

مقایسه با WireGuard و GRE برای IPv6

تانل sit ساده‌ترین و کم‌سربارترین راه است، ولی رمزنگاری ندارد و از NAT عبور نمی‌کند. اگر مسیر بین دو سرور قابل اعتماد نیست یا یکی از سرورها پشت NAT است، IPv6 را داخل WireGuard ببرید: کافی است در بخش Interface یک آدرس IPv6 از لینک تانل و در AllowedIPs سمت سرور B، مقدار ::/0 یا پیشوندهای لازم را بنویسید. WireGuard ترافیک IPv4 و IPv6 را همزمان حمل می‌کند و فقط یک پورت UDP لازم دارد. اگر یک سر تجهیزات سازمانی است، IPv6 را داخل تانل IPsec هم می‌توان برد. GRE وقتی مناسب است که می‌خواهید هم IPv4 و هم IPv6 را از یک تانل ساده عبور دهید یا پروتکل‌های مسیریابی اجرا کنید. مقایسهٔ کلی پروتکل‌ها را در انواع پروتکل VPN آورده‌ایم.

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

• تکیه بر 6to4 خودکار و رلهٔ 192.88.99.1: این سازوکار منسوخ شده و رفتار آن قابل پیش‌بینی نیست.
• پیشوند روی لینک به‌جای پیشوند مسیریابی‌شده: تانل بالا می‌آید ولی ترافیک از سرور A فراتر نمی‌رود.
• خاموش شدن IPv6 خود سرور A پس از فعال کردن فوروارد: فراموش کردن accept_ra = 2 روی سروری که آدرس را خودکار می‌گیرد.
• بستن کامل ICMPv6: کشف همسایه و تشخیص MTU از کار می‌افتد.
• نادیده گرفتن فایروال IPv6: سرویس‌هایی که فقط برای شبکهٔ داخلی بودند، روی IPv6 عمومی در دسترس قرار می‌گیرند.
• MTU نادرست: پینگ سالم است ولی انتقال‌های بزرگ گیر می‌کنند.
• قطع تانل و معطل ماندن برنامه‌ها: وقتی سرور B آدرس IPv6 دارد، برنامه‌ها برای دامنه‌های دارای رکورد AAAA اول IPv6 را امتحان می‌کنند. اگر تانل قطع شود، اتصال‌ها کند می‌شوند. وضعیت تانل را پایش کنید.
• sit پشت NAT: پروتکل ۴۱ معمولاً از NAT عبور نمی‌کند؛ برای این حالت WireGuard را انتخاب کنید.

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

برای دیدن بسته‌های تانل روی کارت شبکهٔ اصلی، sudo tcpdump -ni eth0 ip proto 41 نشان می‌دهد بسته‌ها واقعاً رد و بدل می‌شوند یا نه. وضعیت شبکهٔ دیتاسنترهای کلودیفای را هم در صفحهٔ وضعیت ببینید.

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

تانل sit تقریباً هیچ باری روی پردازنده نمی‌گذارد؛ یک سرور مجازی کوچک برای آن کافی است. مهم‌تر از سخت‌افزار، IPv4 ثابت، IPv6 بومی در دست کم یک طرف، مجازی‌سازی KVM و مسیر پایدار بین دو لوکیشن است. سرور مجازی ایران کلودیفای پورت ۲۵ گیگ و IPv6 دارد و فقط ترافیک خروجی آن محاسبه می‌شود (هر گیگابایت ۱٬۲۵۰ تومان). برای سر دیگر، سرور مجازی خارج را در لوکیشنی نزدیک به کاربرانتان انتخاب کنید و پیش از تصمیم، راهنمای انتخاب لوکیشن با کمترین پینگ را ببینید. برای آزمایش طرح آدرس‌دهی، MTU و فایروال پیش از راه‌اندازی اصلی، سرور ساعتی گزینهٔ اقتصادی است: چند ساعت تست می‌کنید و فقط همان ساعت‌ها را می‌پردازید.

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

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

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

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

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