آموزش وایرگارد (WireGuard)؛ راه‌اندازی تانل Site-to-Site بین دو سرور لینوکس

وقتی دو سرور در دو دیتاسنتر مختلف دارید، مثلاً یک سرور در ایران و یک سرور در خارج، یا دفتر و دیتاسنتر، دیر یا زود لازم می‌شود آن‌ها را مثل دو عضو یک شبکهٔ خصوصی به هم وصل کنید: دیتابیس فقط روی آدرس خصوصی در دسترس باشد، بکاپ‌ها از مسیر رمزنگاری‌شده منتقل شوند و سرویس‌های داخلی هیچ پورتی روی اینترنت نداشته باشند. به این نوع اتصال Site-to-Site می‌گویند و امروز ساده‌ترین و سریع‌ترین ابزار برای آن، وایرگارد یا WireGuard است.

در این آموزش توضیح می‌دهیم وایرگارد چیست، چرا برای تانل وایرگارد بین سرورها انتخاب خوبی است و چطور قدم‌به‌قدم یک اتصال WireGuard Site to Site بین دو سرور لینوکس بسازیم: نصب، ساخت کلید، فایل پیکربندی دو طرف، مسیریابی با AllowedIPs، فایروال، Keepalive، سرویس systemd و تنظیم MTU. در پایان، وایرگارد را کوتاه با GRE و IPsec و OpenVPN مقایسه می‌کنیم و اشتباهات رایج را مرور می‌کنیم. همهٔ آدرس‌های عمومی این مقاله آدرس‌های مخصوص مستندات‌اند (203.0.113.10 و 198.51.100.20)؛ آن‌ها را با آدرس سرورهای خودتان جایگزین کنید.

وایرگارد (WireGuard) چیست؟

وایرگارد یک پروتکل و نرم‌افزار متن‌باز VPN است که در لایهٔ شبکه کار می‌کند: یک رابط شبکهٔ مجازی مثل wg0 می‌سازد و هر بستهٔ IP که به این رابط فرستاده شود، رمزنگاری می‌شود و داخل یک بستهٔ UDP به طرف مقابل می‌رسد. طرف مقابل بسته را باز می‌کند، اصالتش را بررسی می‌کند و بستهٔ اصلی را تحویل شبکه می‌دهد. از دید برنامه‌ها، دو سرور فقط دو آدرس خصوصی در یک شبکه‌اند.

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

• کد کوچک و داخل هستهٔ لینوکس: ماژول وایرگارد از نسخهٔ 5.6 در هستهٔ اصلی لینوکس قرار دارد؛ پس روی توزیع‌های جدید چیزی جز ابزار wg لازم نیست نصب شود. کد کوچک یعنی بررسی امنیتی ساده‌تر.
• رمزنگاری ثابت و مدرن: وایرگارد مذاکرهٔ الگوریتم ندارد و مجموعهٔ ثابتی از الگوریتم‌های مدرن را به کار می‌برد: Curve25519 برای تبادل کلید، ChaCha20-Poly1305 برای رمزنگاری و BLAKE2s برای هش، بر پایهٔ چارچوب Noise. در نتیجه چیزی برای پیکربندی اشتباه وجود ندارد.
• هویت با کلید عمومی: هر طرف یک جفت کلید دارد، شبیه کلید SSH. نام کاربری، رمز یا گواهی لازم نیست.
• بی‌صدا: وایرگارد به بسته‌هایی که با کلید معتبر امضا نشده‌اند پاسخ نمی‌دهد؛ پس پورت آن در اسکن‌ها تقریباً بسته به نظر می‌رسد.
• روتینگ با کلید: هر Peer فهرستی از آدرس‌های مجاز (AllowedIPs) دارد که هم مسیر خروجی را تعیین می‌کند و هم فیلتر ورودی است. این مفهوم را جلوتر کامل توضیح می‌دهیم.

چرا وایرگارد برای اتصال Site-to-Site؟

اتصال Site-to-Site یعنی دو شبکه یا دو سرور به‌طور دائمی و مستقیم به هم وصل باشند، نه یک کاربر به یک سرور. برای این کار چند گزینه وجود دارد: تانل GRE ساده است ولی رمزنگاری ندارد؛ تانل SSH فقط چند پورت TCP مشخص را جابه‌جا می‌کند؛ IPsec قدرتمند ولی پیچیده است. وایرگارد در میانهٔ این طیف قرار می‌گیرد: مثل GRE یک اتصال کامل لایهٔ شبکه می‌دهد، مثل IPsec رمزنگاری قوی دارد و پیکربندی‌اش در حد چند خط است.

کاربردهای مشروع و رایج Site-to-Site:

• دیتابیس و Redis روی شبکهٔ خصوصی: سرور برنامه در یک دیتاسنتر و دیتابیس در دیتاسنتر دیگر، بدون باز کردن پورت دیتابیس روی اینترنت.
• بکاپ رمزنگاری‌شده: انتقال منظم بکاپ از سرور ایران به سرور خارج یا برعکس، روی آدرس خصوصی.
• پایش و مدیریت متمرکز: Prometheus یا Zabbix روی یک سرور، همهٔ سرورهای دیگر را از طریق تانل پایش می‌کند.
• اتصال دفتر به دیتاسنتر: شبکهٔ داخلی دفتر به سرورهای دیتاسنتر وصل می‌شود تا سرویس‌های داخلی شرکت فقط از شبکهٔ خصوصی در دسترس باشند.
• تکرار و همگام‌سازی: Replication دیتابیس یا همگام‌سازی فایل بین دو لوکیشن برای افزایش دسترس‌پذیری.

پیش‌نیازها و طرح شبکه

پیش از نوشتن هر فایلی، طرح آدرس‌ها را روی کاغذ مشخص کنید. در این مثال دو سرور داریم:

دو نکته در انتخاب آدرس مهم است. اول، رنج تانل و شبکه‌های داخلی نباید با هم یا با شبکهٔ خصوصی دیتاسنتر تداخل داشته باشند؛ پیش از انتخاب، با ip addr و ip route آدرس‌های موجود را ببینید. دوم، اگر فقط خود دو سرور باید به هم برسند و شبکه‌ای پشت آن‌ها نیست، ستون شبکهٔ داخلی را نادیده بگیرید؛ پیکربندی ساده‌تر می‌شود.

هر دو سرور به لینوکس با هستهٔ 5.6 یا جدیدتر نیاز دارند؛ اوبونتو 22.04 و 24.04 و دبیان 12 همگی این شرط را دارند. نسخهٔ هسته را با uname -r ببینید. اگر با پورت‌های TCP و UDP آشنا نیستید، مقالهٔ پورت شبکه چیست؟ پیش‌زمینهٔ خوبی است.

نصب وایرگارد روی لینوکس

روی هر دو سرور، بستهٔ ابزارهای وایرگارد را نصب کنید:

sudo apt update
sudo apt install -y wireguard

این بسته ابزار wg برای مدیریت رابط و اسکریپت wg-quick برای بالا آوردن رابط از روی فایل پیکربندی را نصب می‌کند. ماژول هسته از قبل وجود دارد. روی توزیع‌های خانوادهٔ RHEL مثل AlmaLinux و Rocky، بستهٔ متناظر wireguard-tools است.

ساخت کلیدهای خصوصی و عمومی

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

sudo -i
cd /etc/wireguard
umask 077
wg genkey | tee private.key | wg pubkey > public.key
cat public.key

umask 077 باعث می‌شود فایل کلید فقط برای root قابل خواندن باشد. خروجی cat public.key را برای پیکربندی سرور مقابل یادداشت کنید. اگر می‌خواهید یک لایهٔ محافظت اضافه داشته باشید، با wg genpsk یک کلید مشترک (PresharedKey) بسازید و در هر دو طرف قرار دهید؛ این کلید از کانال امن مثل SSH با کلید منتقل شود، نه پیام‌رسان یا ایمیل.

فایل پیکربندی wg0.conf در دو سرور

فایل /etc/wireguard/wg0.conf را روی سرور A بسازید. به‌جای عبارت‌های راهنما، کلید خصوصی همین سرور و کلید عمومی سرور B را قرار دهید:

# /etc/wireguard/wg0.conf  (سرور A)
[Interface]
Address = 10.200.0.1/24
ListenPort = 51820
PrivateKey = SERVER_A_PRIVATE_KEY

[Peer]
# سرور B
PublicKey = SERVER_B_PUBLIC_KEY
Endpoint = 198.51.100.20:51820
AllowedIPs = 10.200.0.2/32, 10.10.2.0/24
PersistentKeepalive = 25

و روی سرور B، فایل متقارن:

# /etc/wireguard/wg0.conf  (سرور B)
[Interface]
Address = 10.200.0.2/24
ListenPort = 51820
PrivateKey = SERVER_B_PRIVATE_KEY

[Peer]
# سرور A
PublicKey = SERVER_A_PUBLIC_KEY
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.200.0.1/32, 10.10.1.0/24

سپس روی هر دو سرور، رابط را بالا بیاورید و وضعیت را ببینید:

sudo chmod 600 /etc/wireguard/wg0.conf
sudo wg-quick up wg0
sudo wg show
ping -c 3 10.200.0.2   # از سرور A

اگر wg show برای Peer خطی با عنوان latest handshake نشان دهد، تانل برقرار است. نبودن این خط یعنی هنوز هیچ بستهٔ معتبری بین دو طرف رد و بدل نشده است؛ معمولاً به‌خاطر فایروال، کلید اشتباه یا Endpoint نادرست.

$ sudo wg showinterface: wg0  listening port: 51820peer: SERVER_B_PUBLIC_KEY  endpoint: 198.51.100.20:51820  allowed ips: 10.200.0.2/32, 10.10.2.0/24  latest handshake: 12 seconds ago  transfer: 1.21 MiB received, 3.48 MiB sent  persistent keepalive: every 25 seconds$ ping -c 1 10.200.0.264 bytes from 10.200.0.2: icmp_seq=1 ttl=64 time=41.8 ms$ 

AllowedIPs و مسیریابی بین دو شبکه

مهم‌ترین و پرخطاترین بخش پیکربندی وایرگارد، AllowedIPs است. این گزینه دو کار هم‌زمان انجام می‌دهد که مستندات وایرگارد به آن Cryptokey Routing می‌گوید:

• در خروج: وقتی بسته‌ای به مقصد 10.10.2.15 به رابط wg0 می‌رسد، وایرگارد Peerی را پیدا می‌کند که این آدرس در AllowedIPs آن است و بسته را با کلید همان Peer رمزنگاری می‌کند.
• در ورود: وقتی بسته‌ای از یک Peer می‌رسد، وایرگارد فقط در صورتی آن را می‌پذیرد که آدرس مبدأ داخل AllowedIPs همان Peer باشد. بسته‌ای با مبدأ دیگر دور ریخته می‌شود.

wg-quick هنگام بالا آوردن رابط، برای هر رنج در AllowedIPs به‌طور خودکار یک مسیر در جدول روتینگ اضافه می‌کند. به همین دلیل هرگز در اتصال Site-to-Site، AllowedIPs = 0.0.0.0/0 ننویسید: این مقدار به معنای «همهٔ اینترنت از طریق این Peer» است و مسیر پیش‌فرض سرور را عوض می‌کند. در بهترین حالت اتصال SSH شما قطع می‌شود و در بدترین حالت سرور از شبکه خارج می‌شود. فقط آدرس تانل طرف مقابل (/32) و شبکه‌های داخلی پشت آن را بنویسید.

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

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system

دوم، دستگاه‌های شبکهٔ داخلی هر طرف باید بدانند برای رسیدن به شبکهٔ طرف مقابل، بسته را به سرور وایرگارد بدهند. این کار با یک مسیر ثابت روی روتر آن شبکه انجام می‌شود، مثلاً «رنج 10.10.2.0/24 از طریق سرور A». جزئیات بیشتر مسیریابی بین دو شبکه را در بخش مسیریابی آموزش تانل GRE آورده‌ایم؛ همان منطق برای وایرگارد هم صدق می‌کند.

فایروال: باز کردن UDP 51820

وایرگارد فقط یک پورت UDP لازم دارد. اگر از فایروال UFW استفاده می‌کنید، پورت را فقط برای آی‌پی طرف مقابل باز کنید. روی سرور A:

sudo ufw allow from 198.51.100.20 to any port 51820 proto udp
sudo ufw status numbered

و روی سرور B همین دستور را با آی‌پی سرور A اجرا کنید. اگر بین دو شبکهٔ داخلی بسته فوروارد می‌شود، UFW به‌طور پیش‌فرض ترافیک عبوری را مسدود می‌کند؛ با قانون‌های ufw route allow in on wg0 out on eth1 و برعکس، فقط مسیرهای لازم را باز کنید و نام رابط شبکهٔ داخلی را با ip link پیدا کنید. اگر دیتاسنتر شما فایروال شبکه‌ای جداگانه در پنل دارد، پورت را آنجا هم باز کنید.

Keepalive و عبور از NAT

وایرگارد ذاتاً «کم‌حرف» است: وقتی داده‌ای برای ارسال نباشد، هیچ بسته‌ای نمی‌فرستد. این برای امنیت و مصرف منابع خوب است، ولی اگر یک سرور پشت NAT یا فایروال حالت‌دار باشد، پس از چند ثانیه تا چند دقیقه بی‌فعالیتی، NAT نگاشت پورت را فراموش می‌کند و طرف مقابل دیگر نمی‌تواند اولین بسته را برساند.

راه‌حل، PersistentKeepalive = 25 در بخش Peer سمتی است که پشت NAT قرار دارد. با این تنظیم، آن سرور هر ۲۵ ثانیه یک بستهٔ کوچک می‌فرستد تا مسیر باز بماند. در این حالت، سرور پشت NAT باید Endpoint طرف مقابل را داشته باشد، ولی طرف مقابل لازم نیست Endpoint آن را بداند؛ وایرگارد آدرس را از اولین بستهٔ معتبر یاد می‌گیرد و اگر آدرس عمومی عوض شود، خودکار به‌روز می‌کند. اگر هر دو سرور آی‌پی عمومی ثابت دارند، Keepalive ضروری نیست ولی ضرری هم ندارد. اگر ارائه‌دهنده یا مسیر شبکه نگرانتان می‌کند، کیفیت مسیر UDP را با iperf3 -u و ابزارهای تست سرعت و کیفیت سرور بسنجید.

اجرای دائمی با systemd

wg-quick یک سرویس systemd آماده با نام wg-quick@ دارد. برای اینکه تانل پس از ری‌استارت خودکار بالا بیاید:

sudo wg-quick down wg0
sudo systemctl enable --now wg-quick@wg0
systemctl status wg-quick@wg0

پس از هر تغییر در wg0.conf، سرویس را با sudo systemctl restart wg-quick@wg0 دوباره راه‌اندازی کنید. اگر فقط Peerها را تغییر داده‌اید و نمی‌خواهید اتصال فعلی قطع شود، از wg syncconf wg0 <(wg-quick strip wg0) استفاده کنید. دربارهٔ ساختار سرویس‌های systemd و خواندن لاگ‌ها، راهنمای ساخت سرویس systemd را ببینید. برای پایش، یک بررسی ساده کافی است: وقتی Keepalive فعال است یا ترافیک جریان دارد، handshake حدوداً هر دو دقیقه تازه می‌شود؛ پس اگر wg show wg0 latest-handshakes زمانی قدیمی‌تر از سه دقیقه نشان دهد، ارتباط مشکل دارد.

MTU: علت اصلی کندی و قطعی‌های عجیب

وایرگارد به هر بسته سربار اضافه می‌کند: ۶۰ بایت روی IPv4 و ۸۰ بایت روی IPv6. به همین دلیل wg-quick به‌طور پیش‌فرض MTU رابط را بر اساس MTU مسیر پیش‌فرض محاسبه می‌کند و در شبکه‌ای با MTU معمول ۱۵۰۰، عدد ۱۴۲۰ را برمی‌گزیند. اگر مسیر واقعی بین دو سرور MTU کمتری داشته باشد، مثلاً به‌خاطر PPPoE در دفتر، یک تانل دیگر در مسیر یا تنظیمات ارائه‌دهنده، بسته‌های بزرگ گم می‌شوند.

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

ping -M do -s 1392 -c 3 10.200.0.2

عدد ۱۳۹۲ به‌اضافهٔ ۲۸ بایت سرآیند، برابر ۱۴۲۰ است. اگر پاسخ نیامد، عدد را کم کنید تا مقدار سالم را پیدا کنید و در بخش [Interface] هر دو طرف، MTU = 1380 یا مقدار پیداشده را بنویسید. در مسیرهای پیچیده، مقدار ۱۲۸۰ تقریباً همیشه کار می‌کند. اگر بین دو شبکهٔ داخلی فوروارد می‌کنید، تنظیم MSS برای TCP هم کمک می‌کند. برای عیب‌یابی خود مسیر شبکه، ping، traceroute و mtr و راهنمای پینگ بالا و Packet Loss را ببینید.

مقایسهٔ کوتاه وایرگارد با GRE و IPsec و OpenVPN

خلاصه: اگر هر دو سر لینوکس هستند و رمزنگاری می‌خواهید، وایرگارد معمولاً بهترین انتخاب است. اگر یک سر فایروال سخت‌افزاری یا روتری است که فقط IPsec را پشتیبانی می‌کند، IPsec راه استاندارد است؛ آموزش آن را در تانل IPsec با strongSwan ببینید. اگر شبکهٔ میانی مطمئن است و فقط یک اتصال ساده لایهٔ شبکه لازم دارید، GRE کافی است و حتی می‌توانید GRE را روی وایرگارد اجرا کنید تا هم رمزنگاری داشته باشید و هم سازگاری GRE. OpenVPN بیشتر برای اتصال کاربران به شبکه به کار می‌رود تا اتصال دائمی سرور به سرور. مقایسهٔ کامل این پروتکل‌ها را در مقایسهٔ پروتکل‌های VPN ببینید. اگر فقط یک یا دو پورت TCP را باید جابه‌جا کنید، تانل SSH و اگر یک سر پشت NAT است و فقط سرویس خاصی باید منتشر شود، تانل معکوس یا ابزارهای مقایسه‌شده در این مقاله ساده‌ترند.

نکات امنیتی وایرگارد

• کلید خصوصی فقط روی همان سرور: فایل کلید و wg0.conf با مجوز 600 و مالک root. هرگز آن‌ها را در مخزن Git یا پیام‌رسان نگذارید.
• یک جفت کلید برای هر سرور: کلید را بین سرورها کپی نکنید؛ اگر سروری از دست رفت، فقط Peer همان را حذف کنید.
• AllowedIPs حداقلی: فقط آدرس‌هایی که واقعاً لازم‌اند. هر رنج اضافه، دسترسی بیشتری به طرف مقابل می‌دهد.
• پورت فقط برای آی‌پی مقابل: پورت UDP را در فایروال به آی‌پی سرور مقابل محدود کنید.
• سرویس‌ها روی آدرس خصوصی: دیتابیس و پنل‌های داخلی را روی آدرس تانل (10.200.0.x) گوش‌دهی کنید، نه 0.0.0.0.
• به‌روزرسانی هسته و بسته‌ها: چون وایرگارد بخشی از هسته است، به‌روزرسانی امنیتی هسته را جدی بگیرید.

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

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

اشتباهات رایج در راه‌اندازی WireGuard Site to Site

• AllowedIPs = 0.0.0.0/0 روی سرور: مسیر پیش‌فرض عوض می‌شود و اتصال مدیریتی قطع می‌شود. برای Site-to-Site فقط رنج‌های طرف مقابل.
• جابه‌جا گذاشتن کلیدها: در بخش Interface کلید خصوصی همین سرور و در بخش Peer کلید عمومی طرف مقابل. رایج‌ترین علت نبودن handshake همین است.
• فراموش کردن فایروال یا پنل دیتاسنتر: UDP 51820 در UFW باز است، ولی فایروال شبکهٔ ارائه‌دهنده بسته است.
• تداخل رنج آدرس: رنج تانل یا شبکهٔ داخلی با شبکهٔ خصوصی دیتاسنتر یکی است و مسیرها به هم می‌ریزند.
• فعال نکردن ip_forward: دو سرور به هم می‌رسند، ولی شبکه‌های پشت آن‌ها نه.
• Keepalive در سمت اشتباه: سمتی که پشت NAT است باید Keepalive بفرستد.
• نادیده گرفتن MTU: پینگ کار می‌کند ولی انتقال‌های بزرگ گیر می‌کنند.
• اشتباه گرفتن تانل با تغییر DNS: تغییر DNS مسیر ترافیک را عوض نمی‌کند؛ تفاوت را در DNS شکن چیست؟ توضیح داده‌ایم.

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

برای دیدن جزئیات، sudo wg show و journalctl -u wg-quick@wg0 اولین ابزارها هستند. وضعیت شبکهٔ دیتاسنترهای کلودیفای را هم در صفحهٔ وضعیت ببینید.

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

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

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

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

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

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

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