SSD Nodes Learn Hosting plans →
راهنماها Matt Connorتوسط Matt Connor · به‌روزرسانی شده 2026-10-05

آموزش مسیریابی شبکه خانگی از طریق WireGuard

اگر handshake برقرار است اما به 192.168.20.10 دسترسی ندارید، مشکل از تنظیمات AllowedIPs یا IP forwarding است. این راهنما 4 مرحله حیاتی برای رفع این اختلال را بررسی می‌کند.

چرا شبکه خانگی شما از طریق WireGuard پاسخ نمی‌دهد

برای مسیریابی به شبکه خانگی (LAN) از طریق WireGuard، چهار تنظیم مجزا باید با یکدیگر هماهنگ باشند. اگر سه مورد از چهار مورد درست باشد، همچنان تونلی خواهید داشت که کاملاً سالم به نظر می‌رسد؛ همین موضوع باعث می‌شود عیب‌یابی این خطا گیج‌کننده باشد. wg show یک handshake اخیر را گزارش می‌دهد، ping 10.8.0.1 در چند میلی‌ثانیه پاسخ می‌دهد، اما ping 192.168.20.10 هیچ پاسخی برنمی‌گرداند.

در اینجا لیست کامل، به ترتیبی که یک بسته (packet) با آن‌ها مواجه می‌شود، آمده است. منظور از LAN، شبکه محلی و خصوصی پشت روتر خانگی شماست.

  1. AllowedIPs در کلاینت باید زیرشبکه (subnet) مقصد را پوشش دهد، در غیر این صورت بسته هرگز وارد تونل نمی‌شود.
  2. AllowedIPs در سرور باید آدرس تونل کلاینت را پوشش دهد، در غیر این صورت بسته به محض رمزگشایی حذف می‌شود.
  3. net.ipv4.ip_forward در سرور باید 1 باشد، زیرا لینوکس هر بسته‌ای را که به خود آن دستگاه آدرس‌دهی نشده باشد، حذف می‌کند.
  4. شبکه LAN باید مسیری برای بازگشت به 10.8.0.0/24 داشته باشد؛ این کار از طریق یک قانون masquerade روی سرور یا یک static route روی روتر خانگی انجام می‌شود.

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

شبکه‌ای که این راهنما از آن استفاده می‌کند

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

  • شبکه محلی (LAN) خانگی 192.168.20.0/24 است. روتر خانگی 192.168.20.1 است.
  • سرور WireGuard یک دستگاه لینوکسی در همان LAN است. رابط شبکه محلی آن enp1s0 دارای آدرس 192.168.20.5 و رابط تونل آن wg0 دارای آدرس 10.8.0.1 است.
  • میزبانی که می‌خواهید به آن دسترسی داشته باشید، یک NAS (ذخیره‌ساز متصل به شبکه) در آدرس 192.168.20.10 است.
  • کلاینت یک لپ‌تاپ در مکانی دیگر است که در داخل تونل آدرس 10.8.0.2 را دارد.

سرور، دستگاهی در شبکه LAN است و نه خودِ روتر. این حالت معمول، یعنی استفاده از یک Raspberry Pi یا یک مینی‌کامپیوتر قدیمی است. این موضوع برای قانون 4 اهمیت دارد: روتر شما از وجود تونل بی‌خبر است مگر اینکه به آن اطلاع دهید، و هر میزبان در شبکه LAN ترافیک خارج از زیرشبکه (off-subnet) خود را به سمت آن روتر می‌فرستد.

اگر اتصال خانگی شما فاقد IP عمومی است، هیچ‌کدام از این موارد به‌تنهایی کار نمی‌کند، زیرا هیچ‌چیز در اینترنت نمی‌تواند یک handshake با خانه شما برقرار کند. بخشی که به قرار دادن یک VPS در میان می‌پردازد، این مورد را پوشش می‌دهد. همان چهار قانون در آنجا نیز صدق می‌کنند، با این تفاوت که یک peer اضافه برای مدیریت وجود دارد.

پارامتر AllowedIPs دو عملکرد متفاوت دارد

یک تنظیم واحد، دو وظیفه را انجام می‌دهد و تفسیر یکسان آن در هر دو سمت، اشتباهی است که دلیل اصلی اکثر این تیکت‌هاست. WireGuard این مکانیزم را cryptokey routing می‌نامد که جزئیات آن در نحوه اتصال کلیدهای عمومی به محدوده‌های IP در WireGuard توضیح داده شده است.

در جهت خروجی، AllowedIPs یک جدول مسیریابی است. wg-quick هر ورودی را به مسیری تبدیل می‌کند که به wg0 اشاره دارد. یک بسته برای 192.168.20.10 تنها در صورتی رمزنگاری شده و برای یک peer ارسال می‌شود که آن peer ادعای مالکیت محدوده‌ای را داشته باشد که شامل آن آدرس است. اگر فقط 10.8.0.0/24 را لیست کنید، لپ‌تاپ شما ترافیک LAN را از طریق Wi-Fi محلی ارسال می‌کند؛ جایی که یا بسته از بین می‌رود و یا به یک 192.168.20.10 کاملاً متفاوت می‌رسد.

در جهت ورودی، AllowedIPs یک لیست کنترل دسترسی (ACL) است. پس از اینکه WireGuard یک بسته را از یک peer رمزگشایی می‌کند، آدرس مبدأ داخلی آن را با AllowedIPs آن peer مطابقت می‌دهد و اگر مطابقت نداشته باشد، بسته را حذف (drop) می‌کند. هیچ خط لاگ یا شمارنده‌ای برای این حذف وجود ندارد. بسته به‌سادگی ناپدید می‌شود.

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

جفت فایل‌های پیکربندی منطبق

کلاینت، /etc/wireguard/wg0.conf:

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

[Peer]
PublicKey = <server public key>
Endpoint = home.example.com:51820
AllowedIPs = 10.8.0.0/24, 192.168.20.0/24
PersistentKeepalive = 25

سرور، /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <server private key>
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <laptop public key>
AllowedIPs = 10.8.0.2/32

روتر خانگی نیز به یک port forward برای UDP 51820 به سمت 192.168.20.5 نیاز دارد، در غیر این صورت handshake هرگز آغاز نمی‌شود و کلاینت خطای Handshake for peer 1 did not complete after 5 seconds, retrying را لاگ می‌کند. این راهنما فرض می‌کند که شما از آن مرحله عبور کرده‌اید.

چهار خط با یک پیکربندی full-tunnel ساده تفاوت دارند و هر کدام عامدانه انتخاب شده‌اند.

  • عبارت AllowedIPs = 10.8.0.0/24, 192.168.20.0/24 در کلاینت، به جای 0.0.0.0/0, ::/0. این یک split tunnel است: زیرشبکه تونل و شبکه محلی (LAN) خانه از طریق wg0 عبور می‌کنند و بقیه ترافیک مسیر محلی خود را حفظ می‌کند. مرور وب شما از طریق اتصال خانگی‌تان انجام نمی‌شود، که معمولاً وقتی فقط به NAS نیاز دارید، همین مطلوب است.
  • عبارت AllowedIPs = 10.8.0.2/32 در سرور، که به جای یک محدوده، تنها یک آدرس است. اگر 10.8.0.0/24 را در آنجا بنویسید، آن کلاینت واحد ممکن است هر آدرسی را در داخل تونل تصاحب کند. اگر بعداً peer دومی با محدوده هم‌پوشان اضافه کنید، ترافیک به سمتی هدایت می‌شود که آخرین بار پیکربندی شده است، بدون اینکه هیچ خطایی چاپ شود.
  • عبارت PersistentKeepalive = 25 فقط در کلاینت. کلاینت پشت NAT قرار دارد و روتر آن پس از یک یا دو دقیقه سکوت، نگاشت UDP را فراموش می‌کند، بنابراین سرور دیگر نمی‌تواند به آن دسترسی پیدا کند. سرور دارای آدرس عمومی است و به keepalive نیاز ندارد.
  • هنوز هیچ خط DNS = وجود ندارد. افزودن آن، وضوح نام (name resolution) را برای کل ماشین کلاینت تغییر می‌دهد. بخش DNS در ادامه توضیح می‌دهد که قبل از فعال‌سازی، چه کاری انجام می‌دهد.

یک full tunnel به شبکه LAN نیز دسترسی پیدا می‌کند، زیرا 0.0.0.0/0 با تمام آدرس‌ها مطابقت دارد. این کار هزینه تمام ترافیک شما و یک تداخل زیرشبکه را به همراه دارد که نمی‌توانید از سمت کلاینت آن را برطرف کنید.

چرا یکسان بودن زیرشبکه در هر دو سمت باعث اختلال می‌شود

یک زیرشبکه خانگی انتخاب کنید که تقریباً هیچ‌کس دیگری از آن استفاده نمی‌کند، مانند 192.168.20.0/24 یا 10.44.7.0/24. مقادیر 192.168.1.0/24 و 192.168.0.0/24 تنظیمات پیش‌فرض کارخانه‌ای در اکثر روترهای خانگی هستند، بنابراین دیر یا زود لپ‌تاپ شما در شبکه یک کافه یا هتل قرار می‌گیرد که دقیقاً از همان محدوده استفاده می‌کند.

این تداخل یک توقف کامل ایجاد می‌کند و در دو حالت مختلف به شکل متفاوتی بروز می‌یابد. در حالت split tunnel، برنامه wg-quick تلاش می‌کند مسیری را برای پیشوندی اضافه کند که از قبل روی رابط Wi-Fi وجود دارد؛ ip route add این درخواست را رد می‌کند و رابط شبکه بالا نمی‌آید:

RTNETLINK answers: File exists

در حالت full tunnel، برنامه wg-quick قوانین مسیریابی مبتنی بر سیاست (policy routing) را نصب می‌کند که عمداً مسیرهای دقیق‌تر را از جدول اصلی دور نگه می‌دارد. مسیر محلی 192.168.1.0/24 بر تونل اولویت پیدا می‌کند، بنابراین هر بسته‌ای که برای شبکه محلی راه دور ارسال می‌شود، از طریق لینک محلی خارج می‌گردد. تونل برقرار است، دست‌دادن (handshake) به‌درستی انجام شده، اما NAS غیرقابل دسترس است. تغییر شماره‌گذاری (renumbering) شبکه محلی خانگی تنها راه‌حل قطعی است.

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

ip route show default
printf 'net.ipv4.ip_forward = 1\n' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

اولین دستور، نام واقعی رابط LAN را به شما می‌دهد. ایمیج‌های فعلی از نام‌هایی مانند enp1s0 یا ens3 استفاده می‌کنند و به‌ندرت از eth0؛ بنابراین یک قانون masquerade که رابط اشتباهی را هدف قرار دهد، با هیچ‌چیز مطابقت نخواهد داشت. آخرین دستور باید مقدار net.ipv4.ip_forward = 1 را چاپ کند. اجرای یک sudo sysctl -w ساده همان مقدار را تنظیم می‌کند، اما پس از reboot بعدی از بین می‌رود و این همان گزارش کلاسیک «تا سه‌شنبه کار می‌کرد» است.

فوروارد کردن ترافیک همچنین باید از سد فایروال عبور کند. در Ubuntu با فعال بودن ufw، بسته‌های فوروارد شده حذف (drop) می‌شوند مگر اینکه DEFAULT_FORWARD_POLICY="ACCEPT" در فایل /etc/default/ufw تنظیم شده باشد. Docker به‌طور خودکار همین سیاست را اعمال می‌کند؛ بنابراین اگر sudo iptables -S FORWARD | head -1 روی سیستمی که هرگز به‌صورت دستی فایروال نشده است، مقدار -P FORWARD DROP را چاپ کند، به این معناست که Docker این کار را انجام داده است و ترافیک تونل شما به یک قانون accept صریح نیاز دارد.

چرا پاسخ‌ها هرگز بازنمی‌گردند

قوانین 1 تا 3 را به‌درستی اعمال کنید تا پینگ واقعاً به NAS برسد. با این حال، همچنان چیزی مشاهده نمی‌کنید، زیرا پاسخ راهی برای بازگشت ندارد. NAS پاسخ را به 10.8.0.2 می‌فرستد که آدرسی خارج از زیرشبکهٔ خودش است، بنابراین بسته را به gateway پیش‌فرض خود، یعنی روتر خانگی در 192.168.20.1 تحویل می‌دهد. آن روتر هرگز نامی از 10.8.0.0/24 نشنیده است، بنابراین پاسخ را به gateway پیش‌فرض خودش، یعنی اتصال اینترنت شما، می‌فرستد و در آنجا بسته دور ریخته می‌شود. درخواست می‌رسد اما پاسخ از بین می‌رود.

گزینه A: استفاده از masquerade روی سرور WireGuard. سرور آدرس مبدأ هر بستهٔ فوروارد شده را به 192.168.20.5، یعنی آدرس LAN خودش، تغییر می‌دهد. اکنون NAS درخواستی از یک همسایه در زیرشبکهٔ خودش می‌بیند، مستقیماً به سرور پاسخ می‌دهد و سرور تغییر آدرس را معکوس کرده و آن را به داخل تونل بازمی‌گرداند. هیچ چیز دیگری در LAN نیاز به تغییر ندارد.

این دستور را در بلوک [Interface] سرور قرار دهید تا قانون همزمان با interface ایجاد و حذف شود:

PostUp = iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE

روی سیستمی که از قبل توسط nftables مدیریت می‌شود، آن را در /etc/nftables.conf بنویسید:

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

کلمهٔ کلیدی counter را حفظ کنید. بدون آن، sudo nft list ruleset قانون را بدون شمارندهٔ بسته چاپ می‌کند، در حالی که همین شمارنده دقیقاً به شما می‌گوید که آیا قانون در حال استفاده است یا خیر.

Masquerade مزیت دومی هم دارد که به‌راحتی نادیده گرفته می‌شود. بسیاری از میزبان‌ها فایروالی دارند که فقط اتصالات از زیرشبکهٔ خودشان را می‌پذیرد. اشتراک‌گذاری فایل در ویندوز به‌صورت پیش‌فرض این‌گونه عمل می‌کند و چندین پنل مدیریتی NAS نیز همین‌طور هستند. بستهٔ ارسالی از 10.8.0.2 توسط میزبان مقصد دور ریخته می‌شود، حتی اگر routing شما بی‌نقص باشد. پس از masquerade، مبدأ یک آدرس LAN است، بنابراین آن قوانین مطابقت پیدا می‌کنند. هزینهٔ این کار این است که هر کلاینت تونل در لاگ‌های تمام میزبان‌های LAN به شکل 192.168.20.5 دیده می‌شود، بنابراین نمی‌توانید کلاینت‌ها را از هم تشخیص دهید و قوانین مبتنی بر کلاینت روی دستگاه‌های LAN کار نخواهند کرد.

گزینه B: یک static route روی روتر خانگی. به روتر بگویید که 10.8.0.0/24 پشت 192.168.20.5 قرار دارد. روی یک روتر لینوکسی، این کار با یک دستور انجام می‌شود:

sudo ip route add 10.8.0.0/24 via 192.168.20.5

روترهای خانگی صفحه‌ای به نام Static Routes یا Routing در تنظیمات پیشرفته دارند: مقصد 10.8.0.0، ماسک 255.255.255.0، و gateway 192.168.20.5. آن را در پیکربندی ذخیره‌شدهٔ روتر ثبت کنید، زیرا دستور ip route add که در محیط لینوکس تایپ می‌شود، با reboot بعدی از بین می‌رود.

این روش آدرس واقعی کلاینت را حفظ می‌کند، بنابراین لاگ‌ها و قوانین مبتنی بر کلاینت در LAN شما معنادار باقی می‌مانند. این روش به روتری نیاز دارد که از static route پشتیبانی کند و فقط به میزبان‌هایی کمک می‌کند که از آن روتر به‌عنوان gateway پیش‌فرض استفاده می‌کنند. هر میزبانی که فایروال محلی با محدودیت زیرشبکه دارد، همچنان به قانون خاص خود برای 10.8.0.0/24 نیاز خواهد داشت. با masquerade شروع کنید، زیرا به هیچ چیزی خارج از سیستمی که کنترلش در دست شماست نیاز ندارد، و هرگاه به آدرس‌های واقعی کلاینت نیاز داشتید، به سراغ static route بروید.

چگونه تشخیص دهیم کدام‌یک از چهار مورد اشتباه است

از سمت کلاینت به سمت بیرون حرکت کنید. هر مرحله به شما می‌گوید که آیا بسته به آن نقطه رسیده است یا خیر.

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

ip route get 192.168.20.10

پاسخ باید نام dev wg0 را نشان دهد. اگر نام رابط Wi-Fi شما را نشان می‌دهد، قانون 1 اشتباه است و AllowedIPs کلاینت، زیرشبکه LAN را پوشش نمی‌دهد. یک ping: connect: Network is unreachable به همان خط اشاره دارد.

آیا بسته‌ها به سرور می‌رسند؟ این دستور را روی سرور اجرا کنید و سپس از کلاینت، NAS را ping کنید:

sudo tcpdump -ni wg0 icmp

یک مسیر سالم، IP 10.8.0.2 > 192.168.20.10: ICMP echo request را نشان می‌دهد؛ جایی که ICMP همان پروتکل کنترل پیام اینترنت است که ping از آن استفاده می‌کند. اگر با وجود handshake سالم، چیزی در اینجا مشاهده نمی‌کنید، یعنی قانون 2 برقرار است: AllowedIPs سرور برای آن peer شامل 10.8.0.2 نیست، بنابراین بسته در مرحله رمزگشایی و پیش از رسیدن به wg0 حذف شده است.

آیا بسته‌ها به سمت LAN خارج می‌شوند؟ روی سرور، سمت LAN را مانیتور کنید:

sudo tcpdump -ni enp1s0 icmp

اگر درخواست‌ها روی wg0 قابل مشاهده هستند اما در اینجا چیزی دیده نمی‌شود، یعنی قانون 3 برقرار است؛ بنابراین forwarding غیرفعال است یا یک قانون FORWARD بسته را حذف کرده است. اگر درخواست‌ها در اینجا با مبدأ 10.8.0.2 دیده می‌شوند اما پاسخی دریافت نمی‌شود، یعنی قانون 4 برقرار است و مسیر بازگشت برای پاسخ وجود ندارد. اگر درخواست‌ها در اینجا با مبدأ 192.168.20.5 دیده می‌شوند و پاسخی دریافت نمی‌شود، یعنی قانون masquerade شما به‌درستی کار می‌کند و خودِ میزبان مقصد در حال رد کردن درخواست است؛ بنابراین فایروال روی NAS را بررسی کنید. همین روال برای هر مورد دیگری نیز صادق است، کافی است icmp را با port 445 یا هر پورت دیگری که مد نظر دارید جایگزین کنید.

دسترسی به IP امکان‌پذیر است اما به نام دامنه خیر

ssh 192.168.20.10 کار می‌کند و ssh nas.home.arpa با خطا مواجه می‌شود:

ssh: Could not resolve hostname nas.home.arpa: Name or service not known

هیچ مشکلی در تونل وجود ندارد. فرایند تبدیل نام به IP (Name resolution) یک مسیر مجزا است و لپ‌تاپ شما همچنان از DNS resolverای استفاده می‌کند که از طریق Wi-Fi محلی دریافت کرده است. آن resolver هیچ اطلاعی از نام‌های موجود در شبکه خانگی شما ندارد.

برای اینکه نام‌های شبکه خانگی به درستی کار کنند، باید دو شرط برقرار باشد. آدرس resolver باید در سمت کلاینت درون AllowedIPs قرار بگیرد، در غیر این صورت پرس‌وجوی DNS (Domain Name System) هرگز وارد تونل نمی‌شود. همچنین، resolver باید اجازه پاسخ‌دهی به پرس‌وجویی را داشته باشد که آدرس مبدأ آن 10.8.0.2 است. بسیاری از resolverهای خانگی به‌صورت پیش‌فرض این درخواست‌ها را رد می‌کنند: dnsmasq که با local-service اجرا می‌شود، فقط به پرس‌وجوهای زیرشبکه‌های متصل مستقیم پاسخ می‌دهد و Pi-hole نیز در حالت پیش‌فرض خود فقط درخواست‌های محلی را می‌پذیرد. یک قانون masquerade این مشکل را پنهان می‌کند، زیرا پس از بازنویسی آدرس، پرس‌وجو از سمت 192.168.20.5 دریافت می‌شود.

تنظیمات سمت کلاینت تنها یک خط است:

DNS = 192.168.20.1

در کلاینت‌های لینوکسی که به openresolv یا معادل آن نیاز دارند، در غیر این صورت wg-quick با خطای resolvconf: command not found متوقف می‌شود. پیش از اعمال تنظیمات در سیستم‌هایی که از systemd-resolved استفاده می‌کنند، از عملکرد آن آگاه باشید: wg-quick آن سرورها را به‌صورت انحصاری ثبت می‌کند؛ بنابراین تا زمانی که تونل برقرار است، تمام جست‌وجوهای لپ‌تاپ به سمت resolver خانگی شما هدایت می‌شود، نه فقط نام‌های شبکه خانگی. نتیجه را با resolvectl status wg0 بررسی کنید. اگر می‌خواهید نام‌های شبکه خانگی در خانه و سایر موارد به‌صورت محلی حل شوند، این همان split DNS است و رفع مشکل DNS روی تونل WireGuard پیکربندی کامل آن را پوشش می‌دهد.

آیا در خانه IP عمومی ندارید؟ از یک VPS به عنوان واسط استفاده کنید

اگر صفحه وضعیت روتر شما یک آدرس WAN در محدوده 100.64.0.0/10 یا یک آدرس خصوصی 192.168.x.x را نشان می‌دهد، شما پشت CGNAT (ترجمه آدرس شبکه در سطح اپراتور) قرار دارید و هیچ handshakeای از سمت اینترنت نمی‌تواند به خانه شما برسد. از آنجا که handshake خروجی همچنان به طور عادی کار می‌کند، راه حل استفاده از یک گره سوم با آدرس عمومی است. یک VPS کوچک نقش هاب را ایفا می‌کند و سیستم خانگی به آن متصل می‌شود.

چهار قانون اصلی تغییر نمی‌کنند. این قوانین اکنون در دو گام اعمال می‌شوند، بنابراین حجم مدیریت آدرس‌ها دو برابر می‌شود.

  • روی VPS، ورودی peer برای سیستم خانگی شامل AllowedIPs = 10.8.0.3/32, 192.168.20.0/24 است: آدرس تونل خودِ سیستم خانگی، به علاوه زیرشبکه‌ای که اجازه دارد از طرف آن صحبت کند.
  • روی VPS، ورودی peer برای لپ‌تاپ همان AllowedIPs = 10.8.0.2/32 باقی می‌ماند.
  • روی لپ‌تاپ، peer مربوط به VPS برابر با AllowedIPs = 10.8.0.0/24, 192.168.20.0/24 تنظیم می‌شود، زیرا اکنون همه چیز به سمت هاب هدایت می‌شود.
  • روی سیستم خانگی، peer مربوط به VPS برابر با AllowedIPs = 10.8.0.0/24 است و سیستم خانگی دارای PersistentKeepalive = 25 است، زیرا اکنون این سمت پشت NAT قرار دارد.
  • سرور VPS نیز به net.ipv4.ip_forward = 1 نیاز دارد و زنجیره forward آن باید اجازه عبور ترافیک از wg0 به wg0 را بدهد، زیرا ترافیک لپ‌تاپ از همان اینترفیسی که وارد می‌شود، خارج می‌گردد. فایروالی که برای یک VPS با تونل کامل (full-tunnel) معمولی نوشته شده باشد، دقیقاً همین مسیر را مسدود می‌کند.

اگر هنوز سمت VPS را راه‌اندازی نکرده‌اید، راه‌اندازی WireGuard روی یک VPS شامل تولید کلید، تنظیمات فایروال و unit مربوط به systemd است. الگوی کلی‌تر برای دسترسی به ماشینی که نمی‌تواند اتصالات ورودی را بپذیرد در ایجاد تونل معکوس از پشت CGNAT توضیح داده شده است. هنگامی که مدیریت دستی آدرس‌های peer دیگر برایتان جذاب نبود، اجرای یک subnet router با Tailscale همان وظیفه مسیریابی را با خودکارسازی مدیریت آدرس‌ها انجام می‌دهد.

پایداری پس از راه‌اندازی مجدد

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

بخش enable --now همان قسمتی است که اکثر افراد از آن صرف‌نظر می‌کنند. اجرای دستی wg-quick up wg0 پس از ارتقای هسته و راه‌اندازی مجدد سیستم از بین می‌رود. دستور wg show باید همتای (peer) مورد نظر را با یک خط latest handshake اخیر و شمارنده‌های انتقال غیرصفر در هر دو جهت نمایش دهد.

افزودن کلاینت دوم در مراحل بعدی نیازی به راه‌اندازی مجدد ندارد، چرا که این کار باعث قطع اتصال تمام کاربران فعال می‌شود:

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

دستور wg-quick strip پیکربندی را بدون کلیدهایی که فقط برای wg-quick قابل‌فهم هستند چاپ می‌کند و syncconf تغییرات را در حالی که نشست‌های زنده در حال اجرا هستند، اعمال می‌کند. این دستور فقط همتاها را به‌روزرسانی می‌کند. تغییر در Address یا افزودن یک خط PostUp جدید همچنان نیازمند اجرای کامل دستورات down و up است.

FAQ

چرا می‌توانم سرور WireGuard را ping کنم اما به هیچ دستگاه دیگری در شبکه خانگی دسترسی ندارم؟

پینگ کردن 10.8.0.1 فقط نشان می‌دهد که تونل برقرار است. دسترسی به سایر بخش‌های شبکه محلی (LAN) یک مسئله مسیریابی است. تنظیمات AllowedIPs در کلاینت باید شامل 192.168.20.0/24 باشد، در غیر این صورت بسته‌ها هرگز وارد تونل نمی‌شوند. سرور نیز باید net.ipv4.ip_forward را روی 1 تنظیم کرده باشد، وگرنه هر بسته‌ای که مقصدش خود سرور نباشد را دور می‌اندازد. همچنین شبکه LAN باید مسیری برای بازگشت به 10.8.0.0/24 داشته باشد. هنگام پینگ کردن، دستور sudo tcpdump -ni enp1s0 icmp را روی سرور اجرا کنید؛ اگر درخواست‌ها با مبدأ 10.8.0.2 خارج می‌شوند اما پاسخی دریافت نمی‌شود، یعنی مسیر بازگشت بسته‌ها مفقود است.

آیا به یک static route روی روتر خانگی نیاز دارم؟

فقط اگر از قانون masquerade استفاده نکنید. قانون masquerade روی سرور WireGuard، آدرس مبدأ ترافیک تونل را به آدرس LAN خودِ سرور تغییر می‌دهد؛ بنابراین میزبان‌های شبکه محلی به همسایه‌ای پاسخ می‌دهند که از قبل می‌شناسند و روتر درگیر نمی‌شود. جایگزین این روش، تعریف یک static route برای 10.8.0.0/24 از طریق آدرس LAN سرور است. این کار زمانی ارزش وقت گذاشتن دارد که بخواهید آدرس‌های واقعی کلاینت‌ها را در لاگ‌های میزبان‌های شبکه محلی ببینید یا قوانین فایروال خاص برای هر کلاینت در آنجا اعمال کنید.

چرا یکسان بودن زیرشبکه (subnet) در هر دو سمت باعث اختلال در تونل می‌شود؟

لپ‌تاپ شما نمی‌تواند دو مسیر برای یک پیشوند (prefix) داشته باشد. اگر شبکه محلی شما آدرس 192.168.1.0/24 را اختصاص دهد و شبکه خانگی شما نیز 192.168.1.0/24 باشد، یک split-tunnel با تنظیم wg-quick up شکست می‌خورد، زیرا ip route add با خطای RTNETLINK answers: File exists درخواست را رد می‌کند. در این حالت یک full tunnel برقرار می‌شود، اما wg-quick قوانین مسیریابی خاصی را اعمال می‌کند که مسیرهای دقیق‌تر را از جدول اصلی خارج می‌کند؛ در نتیجه شبکه محلی برنده شده و شبکه راه دور غیرقابل دسترس می‌ماند. شبکه خانگی خود را به رنج نادری مانند 192.168.20.0/24 تغییر دهید. هیچ راه حلی در سمت کلاینت برای این مشکل وجود ندارد.

می‌توانم با IP به NAS دسترسی داشته باشم اما با نام نه. چه چیزی کم است؟

حل نام (Name resolution) به‌طور خودکار از طریق تونل انجام نمی‌شود. آدرس DNS = 192.168.20.1 (حل‌کننده نام خانگی) را به بلوک [Interface] در کلاینت اضافه کنید و مطمئن شوید که آن آدرس در محدوده AllowedIPs همتا (peer) قرار دارد، وگرنه پرس‌وجو هرگز وارد تونل نمی‌شود. سپس بررسی کنید که آیا resolver به پرس‌وجوهای خارج از زیرشبکه خود پاسخ می‌دهد یا خیر، زیرا dnsmasq با تنظیم local-service و حالت listening محلی Pi-hole، این درخواست‌ها را رد می‌کنند. یک قانون masquerade روی سرور WireGuard با بازنویسی آدرس مبدأ پرس‌وجو، این مشکل را دور می‌زند.

اتصال خانگی من IP عمومی ندارد. آیا همچنان می‌توانم به شبکه محلی خود دسترسی داشته باشم؟

بله، با استفاده از یک گره (node) سوم. پشت CGNAT، آدرس WAN روتر شما خصوصی است، بنابراین هیچ همتایی در اینترنت نمی‌تواند handshake را با آن شروع کند، در حالی که handshake خروجی به‌طور عادی کار می‌کند. WireGuard را روی یک VPS با آدرس عمومی اجرا کنید، دستگاه خانگی را با PersistentKeepalive = 25 به آن متصل کنید و در تنظیمات همتای دستگاه خانگی روی VPS، یک AllowedIPs شامل آدرس تونل آن به همراه 192.168.20.0/24 تعریف کنید. سپس باید قابلیت forwarding را روی VPS فعال کرده و یک قانون forward بنویسید که اجازه عبور ترافیک از wg0 به wg0 را بدهد.

#wireguard#routing#allowedips#vpn#linux-networking