آموزش راه اندازی 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 ... قابل اطمینان نیست، زیرا sudo از umask اختصاصی خود برای فایلی که tee ایجاد می‌کند استفاده می‌کند. سطح دسترسی (mode) را به‌صورت صریح تنظیم کنید.

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 را بنویسید؛ این فایل مجموعه قوانین موجود را پاکسازی (flush) می‌کند، بنابراین اگر سرور شما قبلاً توسط 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 همتا‌به‌همتا (P2P)، دستور iifname "wg0" oifname "wg0" accept را اضافه کنید. همین زنجیره تعیین می‌کند که یک همتا به چه چیزی روی خود سرور دسترسی داشته باشد؛ این موضوع زمانی اهمیت پیدا می‌کند که سرور شما همزمان نقش یک ماشین توسعه از راه دور که Claude Code را در tmux اجرا می‌کند را دارد و شما نمی‌خواهید آن بخش را به‌صورت عمومی در معرض دید قرار دهید.

در سروری که از ufw استفاده می‌کند: ufw allow 51820/udp، دستور DEFAULT_FORWARD_POLICY="ACCEPT" را در /etc/default/ufw وارد کنید و یک قانون POSTROUTING MASQUERADE با *nat در ابتدای فایل /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 تنها پس از فعال‌سازی dynamic debug (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control) در dmesg ظاهر می‌شوند. با فعال بودن این قابلیت، عدم تطابق کلیدها به‌صورت خطای invalid-MAC نمایش داده می‌شود.

Handshake موفق است، اما اینترنت قطع است. دستور 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 به این معناست که نام رابط خروجی (egress interface) اشتباه است؛ افزایش شمارنده بدون دریافت پاسخ، نشان‌دهنده مشکل در سیاست‌های زنجیره 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] کلاینت کاهش دهید؛ ابتدا 1420، سپس 1380 و در نهایت 1280 را امتحان کنید. اگر کاهش MTU مشکل توقف صفحات را حل کرد اما سرعت همچنان پایین بود، از حدس زدن اعداد رند دست بردارید و از طریق یافتن MTU واقعی مسیر با روش دو‌بخشی و محدود کردن TCP MSS اقدام کنید؛ این کار باعث می‌شود دلایلی که به تونل مربوط نیستند نیز حذف شوند.

رابط (Interface) بالا نمی‌آید. خطای 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 برای به‌روزرسانی‌های هسته هستند و اگر wg-quick@wg0 را فعال کرده باشید، خودبه‌خود دوباره بالا می‌آید.

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

تمام این موارد به یک سیستم‌عامل Linux که کنترل آن را در دست دارید، یک 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 را اجرا کنید.