آموزش راه اندازی WireGuard VPN روی سرور مجازی لینوکس

آنچه می‌سازید

یک VPN مبتنی بر WireGuard روی سروری که مالک آن هستید، حدود 40 خط پیکربندی دارد: یک جفت کلید، یک فایل رابط (interface)، یک تنظیم sysctl، یک قانون NAT و یک حفره در فایروال. نصب آن بسیار ساده است، بنابراین بخش عمده این راهنما به مواردی می‌پردازد که ممکن است دچار اختلال شوند، مانند مجوزهای کلید، AllowedIPs، فورواردینگ و DNS.

WireGuard یک تونل لایه 3 در سطح هسته (kernel) است که از نسخه 5.6 لینوکس به بعد در خط اصلی (mainline) قرار گرفته است؛ بنابراین Ubuntu 24.04 و Debian 13 آن را بدون نیاز به ماژول خارجی ارائه می‌دهند. در این پروتکل خبری از مذاکره رمزنگاری (cipher negotiation)، مرجع صدور گواهی (CA) یا مرحله نام کاربری/رمز عبور نیست: هر همتا (peer) صرفاً یک کلید عمومی به همراه آدرس‌های IP مجاز برای آن کلید است. بسته‌ای که در بررسی MAC شکست بخورد، بدون هیچ پاسخی دور ریخته می‌شود، بنابراین پورت به اسکن‌ها پاسخ نمی‌دهد. روی دیگر سکه این است که سرور احراز هویتی وجود ندارد، بنابراین حذف دسترسی به معنای حذف یک همتا از روی سیستم است.

ابتدا مجازی‌سازی را بررسی کنید

WireGuard به هسته‌ای نیاز دارد که بتوانید ماژولی را در آن بارگذاری کنید؛ این قابلیت در VPSهای مبتنی بر KVM به‌صورت پیش‌فرض فعال است. در مجازی‌سازی‌های مبتنی بر کانتینر که از هسته میزبان استفاده می‌کنند، مانند OpenVZ یا LXC، دستور اول با خطای RTNETLINK answers: Operation not supported مواجه می‌شود و در این حالت باید از پیاده‌سازی فضای کاربری (userspace) یعنی wireguard-go استفاده کرد. ابتدا با دستور sudo modprobe wireguard && echo ok وضعیت را بررسی کنید.

تولید کلیدها بدون نشت آن‌ها

یک /etc/wireguard/server.key که برای همه قابل خواندن باشد، عملاً به معنای نبود VPN است. خط معمول umask 077 && wg genkey | sudo tee ... کار می‌کند: مگر اینکه sudoers گزینه umask_override را تنظیم کرده باشد که به‌صورت پیش‌فرض غیرفعال است. sudo مقدار umask شما را با مقدار پیش‌فرض خود یعنی 0022 ترکیب می‌کند و هرگز آن را کاهش نمی‌دهد، بنابراین فایلی که tee ایجاد می‌کند دارای مجوز 600 است. آنچه باعث نشت کلیدها می‌شود، اجرای آن pipe بدون umask 077، تحت یک umask عادی 022، یا روی سیستمی است که sudoers آن گزینه umask_override را فعال کرده باشد. مجوز را به‌طور صریح تنظیم کنید تا دیگر اهمیتی نداشته باشد.

sudo apt update && sudo apt install -y wireguard nftables
sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server.key'
sudo sh -c 'wg pubkey < /etc/wireguard/server.key > /etc/wireguard/server.pub'
sudo chmod 600 /etc/wireguard/server.key

جفت کلید کلاینت را به همان روش تولید کنید. wg genpsk یک کلید پیش‌اشتراکی (pre-shared key) اختیاری اضافه می‌کند که در هر پیکربندی یک خط است.

رابط سرور: /etc/wireguard/wg0.conf

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <contents of /etc/wireguard/server.key>

[Peer]
PublicKey = <laptop public key>
PresharedKey = <psk, optional>
AllowedIPs = 10.8.0.2/32

chmod 600 آن را اجرا کنید؛ هشدار هنگام راه‌اندازی مبنی بر اینکه فایل برای همه قابل‌دسترسی است، به این معنی است که این مرحله را نادیده گرفته‌اید. Address آدرس سرور در داخل تونل است که ماسک کل زیرشبکه VPN را حمل می‌کند. محدوده‌ای را انتخاب کنید که در دنیای واقعی با آن برخورد نخواهید کرد؛ 192.168.1.0/24 با نیمی از روترهای خانگی که کلاینت‌های شما پشت آن‌ها قرار دارند تداخل پیدا می‌کند و در نتیجه، تونل بدون هیچ پیامی، مسیر محلی را جایگزین می‌کند.

مقدار AllowedIPs یک peer در سمت سرور، یک /32 است؛ یعنی همان آدرس تونلی که متعلق به آن کلاینت است. اگر به دو peer آدرس IP مجاز یکسانی بدهید، ترافیک به سمتی هدایت می‌شود که آخرین بار پیکربندی شده است و اولی بدون نمایش هیچ خطایی، دریافت ترافیک را متوقف می‌کند. مقدار SaveConfig را تنظیم‌نشده باقی بگذارید، در غیر این صورت wg-quick down این فایل را بر اساس وضعیت زنده (live state) بازنویسی می‌کند.

تبدیل سرور به روتر

یک سرور لینوکسی بسته‌هایی را که خطاب به خودش نباشند، دور می‌ریزد. قابلیت Forwarding و Source NAT به‌صورت پیش‌فرض غیرفعال هستند.

printf 'net.ipv4.ip_forward = 1\nnet.ipv6.conf.all.forwarding = 1\n' \
  | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

یک sysctl -w خام تا زمان reboot بعدی کار می‌کند و پس از آن بی‌سروصدا از کار می‌افتد. NAT به اینترفیس خروجی (egress) نیاز دارد؛ یعنی کارت شبکه‌ای که به اینترنت متصل است، نه wg0. فرض را بر eth0 نگذارید؛ نام اینترفیس خود را از ip route show default استخراج کنید، زیرا ایمیج‌های فعلی از نام‌هایی مانند enp1s0 یا ens3 استفاده می‌کنند.

فایروال: پورت و مسیر فوروارد

یک فایل nftables هم فیلتر و هم NAT را پوشش می‌دهد. دستور /etc/nftables.conf را بنویسید؛ این دستور مجموعه قوانین موجود را پاکسازی می‌کند، بنابراین اگر سرور شما قبلاً توسط ufw یا Docker مدیریت می‌شود، از این مرحله صرف‌نظر کنید.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    udp dport 51820 accept
  }
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "wg0" oifname "enp1s0" accept
  }
}

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.8.0.0/24 oifname "enp1s0" masquerade
  }
}

آن را با sudo systemctl enable --now nftables اعمال کنید، در حالی که یک نشست SSH دوم باز نگه داشته‌اید: policy drop به همراه یک غلط تایپی در قانون SSH، دسترسی شما به سرور خودتان را مسدود می‌کند. توجه کنید که زنجیره forward چه چیزی را مجاز نمی‌کند، wg0 تا wg0. همتایان (Peers) به اینترنت دسترسی دارند، نه به یکدیگر؛ برای یک VPN همتا‌به‌همتا، iifname "wg0" oifname "wg0" accept را اضافه کنید. این‌که یک همتا در خود سرور به چه چیزی دسترسی داشته باشد، وظیفه این زنجیره نیست: بسته‌هایی که مقصدشان خود سرور است از hook ورودی (input) عبور می‌کنند، نه forward؛ بنابراین زنجیره input تصمیم‌گیرنده است و طبق آنچه نوشته شده، به همتا اجازه می‌دهد فقط به SSH دسترسی داشته باشد و نه چیز دیگر، حتی پینگ به 10.8.0.1. در آنجا iifname "wg0" icmp type echo-request accept را اضافه کنید، به‌علاوه یک قانون iifname "wg0" برای هر سرویسی که می‌خواهید فقط از طریق تونل قابل دسترسی باشد؛ این موضوع زمانی اهمیت پیدا می‌کند که سرور شما نقش یک محیط توسعه از راه دور که Claude Code را در tmux اجرا می‌کند را دارد و شما ترجیح می‌دهید آن بخش را به‌صورت عمومی در معرض دید قرار ندهید.

در سروری که از ufw استفاده می‌کند: ufw allow 51820/udp، DEFAULT_FORWARD_POLICY="ACCEPT" در /etc/default/ufw، و یک قانون *nat از نوع POSTROUTING MASQUERADE در ابتدای /etc/ufw/before.rules قرار دهید.

راه‌اندازی با systemd

sudo systemctl enable --now wg-quick@wg0
sudo wg show

wg-quick رابط را ایجاد می‌کند، آدرس‌ها را می‌افزاید و مسیرهای استخراج‌شده از AllowedIPs را نصب می‌کند. enable --now نیمه مهم ماجراست: یک wg-quick up wg0 که به‌صورت دستی اجرا شود، پس از reboot بعدی از بین می‌رود و ارتقای هسته (kernel) به معنای reboot است. واحدی (unit) که پس از یکی از این rebootها بالا نیاید، تا زمانی که کسی برای اتصال تلاش نکند خاموش می‌ماند؛ بنابراین یک drop-in از نوع OnFailure= در مسیر wg-quick@wg0 که به سرور ntfy خودتان اشاره می‌کند، ارزان‌ترین راه برای مطلع شدن از این وضعیت روی گوشی، به‌جای شنیدن آن از زبان کاربری است که دسترسی‌اش قطع شده است.

پیکربندی کلاینت و تنظیمی که همه در آن اشتباه می‌کنند

[Interface]
PrivateKey = <laptop private key>
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

AllowedIPs همزمان دو وظیفه متفاوت را انجام می‌دهد و ترکیب این دو، منشأ اصلی سردرگمی در WireGuard است.

در جهت خروجی، این یک جدول مسیریابی است. بسته‌ای که مقصد آن با AllowedIPs یک همتا (peer) مطابقت داشته باشد، رمزنگاری شده و به آن همتا ارسال می‌شود. 0.0.0.0/0, ::/0 همه چیز را به داخل تونل می‌فرستد؛ این یک تونل کامل (full tunnel) است که در آن سرور به عنوان مسیر پیش‌فرض (default route) عمل می‌کند. تونل تفکیک‌شده (split tunnel) لیست محدودتری است: AllowedIPs = 10.8.0.0/24, 10.20.0.0/16 ترافیک VPN به علاوه یک شبکه خصوصی پشت سرور را حمل می‌کند و بقیه ترافیک مسیر محلی خود را حفظ می‌کنند. همین لیست محدود است که به شما اجازه می‌دهد سرویس‌ها را کاملاً از اینترنت عمومی دور نگه دارید؛ برای مثال یک نمونه Nextcloud خصوصی روی یک VPS که به آدرس تونل محدود شده است، یا ماشین‌های مجازی آزمایشگاهی با مجازی‌سازی تو در تو که روی همان دستگاه اجرا می‌شوند، برای همتاها قابل دسترسی باقی می‌مانند و برای دیگران نامرئی هستند.

در جهت ورودی، این یک لیست کنترل دسترسی (ACL) است. بسته رمزگشایی‌شده‌ای که از یک همتا می‌آید و آدرس مبدأ آن در AllowedIPs آن همتا نباشد، دور ریخته می‌شود. به همین دلیل است که سرور برای لپ‌تاپ، 10.8.0.2/32 را لیست می‌کند: درج 0.0.0.0/0 در آن بخش، به کلاینت اجازه می‌دهد هر آدرسی را در تونل جعل (spoof) کند.

PersistentKeepalive برای کلاینت‌هایی است که پشت NAT قرار دارند، جایی که روتر نگاشت UDP را فقط تا زمانی که بسته‌ها در جریان هستند باز نگه می‌دارد. وقتی این زمان منقضی شود، سرور دیگر نمی‌تواند به کلاینت دسترسی پیدا کند. PersistentKeepalive = 25 این نگاشت را باز نگه می‌دارد؛ آن را روی کلاینت تنظیم کنید، نه روی سروری که IP عمومی دارد.

DNS و نشت اطلاعاتی که کسی به آن توجه نمی‌کند

با وجود AllowedIPs = 0.0.0.0/0 و نبود خط DNS =، کلاینت از resolverای استفاده می‌کند که از شبکه محلی یاد گرفته است، یعنی روتر کافه در 192.168.1.1. آن مسیر (route) نسبت به مسیر پیش‌فرض اختصاصی‌تر است، بنابراین پرس‌وجوهای DNS از طریق لینک محلی و به‌صورت متن آشکار (cleartext) ارسال می‌شوند، در حالی که سایر ترافیک‌ها از داخل تونل عبور می‌کنند. ترافیک شما خصوصی است، اما لیست نام‌هایی که جستجو می‌کنید، خیر.

دو گزینه صادقانه وجود دارد. گزینه اول: DNS را به یک resolver عمومی (DNS = 9.9.9.9) اشاره دهید تا پرس‌وجوها از داخل تونل عبور کرده و از سرور شما خارج شوند؛ هرچند آن resolver همچنان پرس‌وجوهای شما را می‌بیند. گزینه دوم: unbound یا dnsmasq را اجرا کنید که به 10.8.0.1 متصل باشد، DNS = 10.8.0.1 را تنظیم کنید، و udp dport 53 iifname "wg0" accept را به زنجیره ورودی (input chain) اضافه کنید؛ اگر آن خط را تنظیم کنید و resolver را فراموش کنید، هیچ چیزی resolve نخواهد شد.

در کلاینت‌های لینوکسی، wg-quick تنظیمات DNS را از طریق resolvconf اعمال می‌کند؛ اگر این مورد وجود نداشته باشد، شما resolvconf: command not found را دریافت می‌کنید. بسته openresolv را نصب کنید، یا در کلاینتی که از systemd-resolved استفاده می‌کند، PostUp = resolvectl dns %i 10.8.0.1 را تنظیم نمایید.

افزودن و حذف همتاها بدون قطع تونل

راه‌اندازی مجدد رابط شبکه برای افزودن یک کاربر، باعث قطع اتصال تمام کاربران متصل می‌شود. بلوک [Peer] را به wg0.conf اضافه کنید و سپس مجموعه همتاها را به‌صورت درجا بارگذاری مجدد کنید.

sudo bash -c 'wg syncconf wg0 <(wg-quick strip wg0)'

دستور wg-quick strip پیکربندی را بدون کلیدهای مخصوص Address (مانند DNS و PostUp) چاپ می‌کند و syncconf تغییرات را در حالی که نشست‌های فعال برقرار هستند، اعمال می‌نماید. این دستور فقط همتاها را به‌روزرسانی می‌کند: تغییر در Address همچنان نیازمند یک چرخه کامل down/up است. برای لغو دسترسی، از sudo wg set wg0 peer <public key> remove استفاده کنید و سپس بلوک مربوطه را از فایل حذف کنید، در غیر این صورت با بارگذاری مجدد بعدی، آن همتا بازمی‌گردد.

حالت‌های شکست و پیام‌های مرتبط

هندشیک (Handshake) هرگز کامل نمی‌شود. wg show همتای (peer) موردنظر را بدون latest handshake نشان می‌دهد و کلاینت لاگ زیر را ثبت می‌کند:

Handshake for peer 1 (10.0.0.10:51820) did not complete after 5 seconds, retrying (try 2)

هیچ بسته‌ای دریافت نمی‌شود یا هیچ بسته‌ای پذیرفته نمی‌شود. به ترتیب بررسی کنید: آیا پورت UDP 51820 روی فایروال VPS و فایروال شبکهٔ ارائه‌دهنده (که در اکثر پنل‌ها یک کنترل جداگانه است) باز است؟ آیا آدرس Endpoint و پورت صحیح هستند؟ آیا کلیدها جابه‌جا نشده‌اند؟ کلید موجود در بلوک [Peer] کلاینت باید کلید عمومی سرور باشد و بالعکس؛ قرار دادن کلید خصوصی یا کلید عمومی خودِ کلاینت، دقیقاً همین نشانه را ایجاد می‌کند. دستور sudo tcpdump -ni any udp port 51820 روی سرور نشان می‌دهد که آیا اصلاً بسته‌ای دریافت می‌شود یا خیر. ماژول هسته به‌صورت پیش‌فرض چیزی لاگ نمی‌کند؛ پیام‌های WireGuard تنها پس از فعال‌سازی دیباگ پویا (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control) در dmesg ظاهر می‌شوند. با فعال بودن این قابلیت، عدم تطابق کلید به‌صورت خطای invalid-MAC drop نمایش داده می‌شود.

هندشیک موفق است، اما اینترنت وصل نیست. ping 10.8.0.1 موفقیت‌آمیز است اما ping 1.1.1.1 با timeout مواجه می‌شود: یعنی forwarding یا NAT تنظیم نشده است. بررسی کنید که sysctl net.ipv4.ip_forward مقدار 1 را نشان دهد، سپس در حالی که کلاینت دستور ping را اجرا می‌کند، شمارنده‌ها را با sudo nft list ruleset یا sudo iptables -t nat -L POSTROUTING -n -v مشاهده کنید. صفر بودن تعداد بسته‌ها در قانون masquerade به این معناست که نام اینترفیس خروجی اشتباه است؛ افزایش شمارنده بدون دریافت پاسخ، به سیاست‌های زنجیره forward اشاره دارد.

اینترنت وصل است، اما نام‌ها (DNS) حل نمی‌شوند. ping 1.1.1.1 موفق است و curl https://example.com مقدار Could not resolve host را برمی‌گرداند. خط DNS وجود ندارد یا به یک resolver اشاره می‌کند که از داخل تونل در دسترس نیست.

برخی سایت‌های HTTPS باز نمی‌شوند. SSH و ping به‌خوبی کار می‌کنند اما صفحات سنگین متوقف می‌شوند. این مشکل مربوط به path MTU است: تونل سربار (overhead) اضافه می‌کند و برخی لینک‌های میانی، بسته‌های بزرگ را بدون ارسال پیام ICMP به مبدأ، حذف می‌کنند. مقدار MTU را در بخش [Interface] کلاینت تنظیم کنید. در یک لینک معمولی 1500 بایتی، wg-quick به‌صورت خودکار 1420 (1500 منهای 80 بایت سربار) را انتخاب می‌کند، بنابراین نوشتن 1420 تغییری ایجاد نمی‌کند: مقدار 1380 و سپس 1280 را امتحان کنید. اگر کاهش MTU مشکل توقف صفحات را حل کرد اما سرعت همچنان پایین است، از حدس زدن اعداد رند دست بردارید و طبق یافتن MTU واقعی مسیر از طریق روش دو‌نیم‌سازی و تنظیم TCP MSS عمل کنید؛ این کار باعث می‌شود عللی که مربوط به تونل نیستند نیز حذف شوند.

اینترفیس اجرا نمی‌شود. Address already in use به این معناست که فرایند دیگری پورت UDP 51820 را اشغال کرده است. خطای Cannot find device wg0 پس از یک up ناموفق، معمولاً به این معناست که فایل پیکربندی رد شده است؛ journalctl -u wg-quick@wg0 -n 50 را مطالعه کنید.

مهاجرت از Streisand یا OpenVPN

پروژه Streisand دیگر پشتیبانی نمی‌شود و مخزن آن آرشیو شده است. اجرای یک VPN بر پایه ابزارهای خودکارِ رهاشده، یک مشکل امنیتی تدریجی ایجاد می‌کند. امکان ارتقای درجا (in-place upgrade) وجود ندارد و PKI مربوط به OpenVPN نیز قابل تبدیل نیست؛ WireGuard فاقد گواهی، CA و تاریخ انقضا است، بنابراین هر کلاینت باید یک جفت کلید جدید دریافت کند.

مهاجرت را به‌صورت موازی انجام دهید؛ WireGuard روی پورت UDP 51820 می‌تواند در کنار OpenVPN روی پورت 1194 در همان سرور فعالیت کند. سرویس wg0 را راه‌اندازی کنید، کلاینت‌ها را یکی‌یکی منتقل کنید و سپس سرویس قدیمی را متوقف نمایید. مدل نام کاربری/رمز عبور و ابطال گواهی در OpenVPN به WireGuard منتقل نمی‌شود؛ اگر به سیستم حساب کاربری یا مسیر حسابرسی (audit trail) نیاز دارید، آن را در لایه‌ای بالاتر از WireGuard پیاده‌سازی کنید.

پشتیبان‌گیری، ارتقا و چالش‌های مقیاس‌پذیری

/etc/wireguard همان سرور است. از آن پشتیبان بگیرید (sudo tar czf wg-backup.tgz -C /etc wireguard، با مجوز 600، و خارج از سرور نگهداری شود) تا بتوانید در عرض چند دقیقه آن را روی یک VPS جدید بازسازی کنید. اگر کلید خصوصی سرور را گم کنید، تمام پیکربندی‌های کلاینت باید دوباره صادر شوند، زیرا کلاینت‌ها کلید عمومی سرور را پین (pin) می‌کنند. ارتقاها شامل یک apt upgrade معمولی به‌علاوه یک reboot برای به‌روزرسانی‌های هسته (kernel) است و اگر wg-quick@wg0 را فعال کرده باشید، خودبه‌خود بازمی‌گردد.

وضعیت هر همتا کوچک است و عملیات رمزنگاری در هسته انجام می‌شود، بنابراین سقف توانایی شما، CPU و پهنای باند VPS است، نه چیزی در این پیکربندی. آن را با iperf3 در طول تونل اندازه‌گیری کنید و به ارقام منتشرشده اعتماد نکنید. آنچه در مقیاس بزرگ چالش‌برانگیز است، عملیات نگهداری است. هر همتا به یک IP تونل منحصربه‌فرد نیاز دارد و ویرایش دستی شصت بلوک [Peer] باعث می‌شود AllowedIPs تکراری به‌طور ناخواسته وارد شوند: پیکربندی‌ها را با یک اسکریپت تولید کنید. یک سرور یعنی یک نقطه پایانی UDP و یک نقطه شکست؛ WireGuard قابلیت خوشه‌بندی (clustering) ندارد: افزونگی (redundancy) به معنای یک سرور دوم با کلیدهای مخصوص خودش است. چرخش کلیدها (Key rotation) دستی باقی می‌ماند، پس یادداشت کنید چه کسی چه کلیدی را در اختیار دارد و چگونه باید یکی را باطل کرد. هنگامی که این حساب‌وکتاب از یک فایل متنی فراتر رفت، پاسخ معمول استفاده از یک control plane در بالای همان data plane هسته است، و یک سرور NetBird خودمیزبان تخصیص آدرس، توزیع همتایان و کلیدهای راه‌اندازی را که در غیر این صورت باید دستی انجام دهید، مدیریت می‌کند. اگر اجرای آن control plane برای شما یک سرور اضافه محسوب می‌شود، Tailscale آن را برای شما میزبانی می‌کند و طرح رایگان شخصی آن، شش کاربر با دستگاه‌های نامحدود و در ابتدا تا 50 منبع تگ‌شده مانند سرورها را پوشش می‌دهد، که برای اکثر ناوگان‌های شخصی کافی است و نیازی به پرداخت هزینه ندارند. پس از آن نقطه، هزینه‌ها بر اساس تعداد افراد محاسبه می‌شود نه ماشین‌ها، بنابراین آنچه یک خانواده یا تیم کوچک واقعاً می‌پردازد به تعداد انسان‌هایی بستگی دارد که لاگین دارند، نه تعداد همتایانی که باید دستی در wg0.conf وارد می‌کردید. در آن سمت، حساب‌وکتاب split-tunnel AllowedIPs به تبلیغ محدوده‌های خصوصی شما از طریق یک subnet router تبدیل می‌شود که یک‌بار از یک VPS اعلام شده و به‌صورت مرکزی تأیید می‌شود، به‌جای اینکه در هر فایل کلاینت کپی شود. این‌که آیا این معامله ارزشش را دارد یا خیر، به این بستگی دارد که یک control plane میزبانی‌شده واقعاً به چه چیزی دسترسی دارد، و هرگز کلیدهایی که ترافیک شما را رمزنگاری می‌کنند در اختیار ندارد، اگرچه تصمیم می‌گیرد کدام همتایان از وجود یکدیگر مطلع شوند.

همه این‌ها به یک سیستم‌عامل لینوکس که کنترلش در دست شماست، یک IP عمومی، یک هسته که بتوانید ماژول در آن بارگذاری کنید و یک فایروال که از ابتدا تا انتها تحت مالکیت شماست، نیاز دارد.

FAQ

چرا هندشیک WireGuard هرگز کامل نمی‌شود؟

wg show اگر در لیست کردن یک peer هیچ latest handshake دیده نمی‌شود، یعنی بسته‌ها دریافت نمی‌شوند یا پذیرفته نمی‌شوند. پورت UDP 51820 را هم در فایروال VPS و هم در فایروال شبکهٔ ارائه‌دهندهٔ خود بررسی کنید، Endpoint میزبان و پورت را تأیید کنید، سپس مطمئن شوید کلیدها جابه‌جا نشده باشند؛ بلوک [Peer] در کلاینت باید حاوی کلید عمومی سرور باشد. دستور sudo tcpdump -ni any udp port 51820 روی سرور نشان می‌دهد که آیا اصلاً بسته‌ای دریافت می‌شود یا خیر؛ dmesg تنها پس از فعال‌سازی دیباگ پویا (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control) خطاهای هندشیک WireGuard را گزارش می‌کند و در آن صورت، عدم تطابق کلید به صورت یک drop با عنوان invalid-MAC ظاهر می‌شود.

تونل متصل می‌شود اما اینترنت ندارم. چه چیزی کم است؟

اگر ping 10.8.0.1 کار می‌کند اما ping 1.1.1.1 با timeout مواجه می‌شود، مشکل از forwarding یا NAT است. تأیید کنید که sysctl net.ipv4.ip_forward مقدار 1 را نشان می‌دهد و این مقدار در /etc/sysctl.d/ تنظیم شده است، نه فقط با یک دستور sysctl -w که پس از reboot از بین می‌رود. سپس قانون masquerade را بررسی کنید که رابط خروجی واقعی شما را از ip route show default، enp1s0 یا ens3 (و به ندرت eth0) نام‌گذاری می‌کند.

آیا به خط DNS = در پیکربندی کلاینت نیاز دارم؟

در یک تونل کامل و بدون خط DNS =، کلاینت از resolverای استفاده می‌کند که از شبکهٔ محلی یاد گرفته است؛ در نتیجه آن پرس‌وجوها به صورت متن آشکار (cleartext) از طریق لینک محلی ارسال می‌شوند، در حالی که بقیه ترافیک از تونل عبور می‌کند. DNS را به یک resolver عمومی اشاره دهید، یا unbound/dnsmasq را که به 10.8.0.1 متصل است اجرا کنید و udp dport 53 iifname "wg0" را در زنجیرهٔ input باز کنید.

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

این دستور دو وظیفه دارد. در خروجی، یک جدول مسیریابی است: ترافیکی که با AllowedIPs یک peer مطابقت داشته باشد، رمزنگاری شده و به آن peer ارسال می‌شود. در ورودی، یک لیست کنترل دسترسی (ACL) است: بسته‌ای که رمزگشایی شده اما مبدأ آن خارج از AllowedIPs آن peer باشد، drop می‌شود. به همین دلیل است که سمت سرور برای هر کلاینت یک /32 لیست می‌کند، در حالی که سمت کلاینت ممکن است 0.0.0.0/0 را لیست کند.

آیا WireGuard روی هر VPS اجرا می‌شود؟

روی یک VPS با مجازی‌ساز KVM، این ابزار با ماژول درون‌هسته‌ای (in-kernel) و بدون نیاز به تنظیمات اضافی کار می‌کند. در مجازی‌سازی‌های کانتینری که هستهٔ میزبان را به اشتراک می‌گذارند، مانند OpenVZ یا LXC، دستور modprobe wireguard با خطای Operation not supported شکست می‌خورد و جایگزین آن، پیاده‌سازی فضای کاربری (userspace) یعنی wireguard-go است. پیش از هر کار دیگری، sudo modprobe wireguard && echo ok را اجرا کنید.