کلید قطع روتر که FORWARD، OUTPUT و IPv6 را پوشش می‌دهد
کلید قطعی که فقط در FORWARD ساخته شود روتر را آزاد به نشتی می‌گذارد، و قواعد فقط IPv4، IPv6 را باز می‌گذارند. زنجیره‌ها را مرتب کنید و با تونل قطع‌شده آزمایش کنید.
به روتر وارد می‌شوید، مجموعه‌ای از قواعد کلید قطع را از یک پست انجمن می‌چسبانید، و LAN همان لحظه‌ای که تونل می‌افتد مرور را متوقف می‌کند. دو روز بعد روتر هنوز رکورد DNS پویای خود را از طریق WAN معمولی به‌روزرسانی می‌کند، و لپ‌تاپ مهمان هنوز به سایت‌های IPv6 می‌رسد. هر دو رفتار عادی است، چون قواعد چسبانده‌شده یک زنجیره و یک خانواده نشانی را پوشش می‌دادند و هیچ‌یک از این دو تمام روتر نیست. عبور به‌ترتیب از مسیرهای بسته‌ها دقیقاً نشان می‌دهد چه چیزی جا افتاده است.
از روتر شروع کنید، نه از لپ‌تاپ
سیاست در سطح روتر برای یک دفتر کوچک جذاب است، چون هر دستگاهی پشت آن همان رفتار را به ارث می‌برد و هیچ‌کس نمی‌تواند فراموش کند که کلیدی روی کلاینت روشن کند. همچنین یک نقطه واحد برای آزمایش پس از هر به‌روزرسانی فرم‌ور به شما می‌دهد. آنچه نمی‌دهد پوشش خودکار ترافیک خود روتر یا خانواده نشانی دوم است، و همین دو شکاف پشت بیشتر استقرارهای ناموفق است.
پیش از تغییر هر چیزی، سه واقعیت را روی کاغذ بنویسید: نام رابط WAN، نام پل LAN، و نشانی و پورت نقطه پایانی VPN. هر سه را در قواعد لازم دارید، و حدس زدن نام رابط‌ها رایج‌ترین دلیل بی‌اثر ماندن مجموعه قواعدی است که درست به نظر می‌رسد.
سه مسیری را که یک بسته می‌تواند طی کند مرور کنید
ترافیک از لپ‌تاپ به اینترنت ارسال می‌شود، پس از زنجیره FORWARD می‌گذرد. ترافیکی که خود روتر تولید می‌کند، مثل ارسال DNS، پرس‌وجوهای NTP، به‌روزرسانی‌های DDNS و کانال کنترل VPN، از OUTPUT می‌گذرد. ترافیک مدیریتی که به روتر نشانی شده است از INPUT وارد می‌شود.
بنابراین کلید قطعی که فقط در FORWARD ساخته شود از کلاینت‌ها محافظت می‌کند و از هیچ چیز دیگری. جدول نشان می‌دهد چرا نشتی صحنه آغازین قابل پیش‌بینی است و نه مرموز.
| Packet path | Example | Chain that sees it |
|---|---|---|
| LAN client to WAN or tunnel | Browser request | FORWARD |
| Router-originated | DDNS update, NTP | OUTPUT |
| Addressed to the router | SSH from the LAN | INPUT |
در بیشتر طرح‌ها به کلید قطع روی INPUT نیاز ندارید، اما باید دسترسی مدیریتی را در حالی که تونل قطع است فعال نگه دارید. وگرنه در نخستین خرابی VPN با کابل کنسول به دفتر می‌روید.
قواعد را طوری مرتب کنید که تونل هنوز بالا بیاید
کلید قطع کاری فهرست مجوزهایی است که به رد ختم می‌شود، و ترتیب است که آن را کلید قطع می‌کند نه آجر. نخست loopback، نقطه پایانی VPN، پاسخ‌های جریان‌های برقرار و رابط تونل را مجاز کنید؛ بقیه را در آخر رد کنید.
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECTنقطه پایانی در این مرحله باید یک نشانی باشد، نه نام میزبان. همین‌که رد نهایی DNS را مسدود کند، قاعده‌ای که نام میزبان ارائه‌دهنده را ذکر می‌کند دیگر قابل تفکیک نیست، و تونل پس از راه‌اندازی مجدد هرگز دوباره بالا نمی‌آید. اگر ارائه‌دهنده نقاط پایانی را می‌چرخاند، نام را پیش از اعمال سیاست تفکیک کنید و آن قاعده را از همان اسکریپت تازه کنید.
شکل را در FORWARD برای ترافیک کلاینت‌ها تکرار کنید و یک قاعده مدیریتی صریح بالای رد بگذارید. آن قاعده مدیریتی را باریک اما در دسترس نگه دارید و آن را با باز کردن نشست دوم SSH پیش از بستن نشست اول تأیید کنید. قفل شدن بیرون در حین تغییر کلید قطع به‌قدری رایج است که برایش برنامه بریزید. روی روتری که WireGuard اجرا می‌کند، allowed-ips همتا تعیین می‌کند چه چیزی وارد تونل می‌شود، در حالی که این قواعد تعیین می‌کنند چه چیزی مجاز است بدون آن خارج شود.
IPv6 به درِ خودش نیاز دارد
همه موارد بالا IPv4 است. اگر LAN شما IPv6 کارآمد دارد و تونل فقط IPv4 حمل می‌کند، هر دستگاه پوشش‌داده‌شده هنوز مسیر مستقیمی به اینترنت دارد که قواعد جدید شما هرگز آن را نمی‌بیند. لپ‌تاپ دوپشته با کمال میل آن را ترجیح می‌دهد، و کلید قطع فقط از دید کسی که با IPv4 آزمایش می‌کند خراب به نظر می‌رسد.
ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPTاینجا هم ترتیب مهم است: مجوز loopback باید پیش از رد WAN بیاید، وگرنه سرویس‌های محلی روی روتر به شکل‌های عجیب شروع به شکست می‌کنند. اگر شبکه اصلاً از IPv6 استفاده نمی‌کند، خاموش کردن آن روی WAN و LAN ساده‌تر است و چیزی برای فراموش کردن باقی نمی‌ماند.
برخی کلاینت‌های VPN مسیر پیش‌فرض را فقط برای IPv4 نصب می‌کنند و مسیر پیش‌فرض IPv6 موجود را دست‌نخورده می‌گذارند. جدول مسیریابی را پس از اتصال تونل بررسی کنید، نه اینکه فرض کنید کلاینت این کار را انجام داده است.
با تونل قطع‌شده این را ثابت کنید
تونل را از روتر متوقف کنید و از سه نقطه به این ترتیب آزمایش کنید:
# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | headجست‌وجوی مسیر به شما می‌گوید بسته کجا می‌رفت، و شمارنده‌ها می‌گویند آیا قواعد شما هرگز مطابقت داشته‌اند یا نه. قاعده‌ای که پس از یک آزمایش ناموفق صفر بسته دارد از هیچ چیز محافظت نمی‌کند، و علت معمول نام رابطی است که با آنچه تایپ کرده‌اید فرق دارد. ترافیکی را که روتر تولید می‌کند صریحاً آزمایش کنید، چون آزمایش از سمت LAN نمی‌تواند OUTPUT را به کار بیندازد.
حالت خرابی را پیش از آنکه لازم شود تعیین کنید. fail-closed کلاینت‌ها را تا بازگشت تونل آفلاین نگه می‌دارد؛ fail-open دسترسی معمول WAN را برمی‌گرداند و هدف را برای ترافیکی که برایتان مهم بود خراب می‌کند. مسیر blackhole به استخر VPN با متریک بالا لایه دومی مفید برای طرح‌های fail-closed است، چون وقتی مسیر تونل ناپدید می‌شود زنده می‌ماند به‌جای بازگشت به مسیر پیش‌فرض.
تنظیم را تنها زمانی بپذیرید که یک کلاینت LAN، یک درخواست تولیدشده توسط روتر و یک درخواست IPv6 همه با تونل قطع‌شده شکست بخورند، و هر سه پس از بالا آمدن دوباره کار کنند.