WireGuard روی داده همراه کار می‌کند، اما روی همان Wi-Fi نه
درخواستی که از داخل LAN به نشانی عمومی روتر فرستاده می‌شود مسیری متفاوت از درخواست داده همراه طی می‌کند. نخست بیرون را بیازمایید، سپس مسیری محلی برگزینید.
تونل روی داده همراه بالا می‌آید و بعد در خانه، با همان پروفایل، همان کلید همتا و بدون هیچ تغییری در پیکربندی، در حالت «در حال اتصال» می‌ماند. تفاوت در مسیر است: درخواستی که از داخل LAN به نشانی عمومی روتر می‌رود، همان سفر درخواستی نیست که از اینترنت می‌رسد. بیشتر دروازه‌های خانگی یا مسیر بازگشت را پیاده نمی‌کنند یا آن را فقط برای برخی پروتکل‌ها پیاده می‌کنند. این باعث می‌شود نشانه شبیه کلید خراب دیده شود، در حالی که هیچ چیز درباره کلید تغییر نکرده است. پیش از دست زدن به کلید، پورت‌فوروارد یا پروفایل کلاینت، مشخص کنید کدام مسیر شکست خورده است.
یک نشانی، دو مسیر متفاوت
از بیرون، بسته‌ای به نشانی عمومی روتر می‌رسد و قاعده پورت‌فوروارد آن را به شنونده WireGuard روی میزبان داخلی می‌سپارد. از درون، کلاینت همان نشانی عمومی را شماره‌گیری می‌کند، پس بسته از کلاینت خارج می‌شود، به روتر می‌رسد و باید به سمت LAN بازگردانده شود. همان چرخش بازگشت جایی است که دو مسیر از هم جدا می‌شوند، زیرا روتر باید جریانی را ترجمه کند که هم‌زمان از یک واسط خارج و دوباره به آن وارد می‌شود. بسیاری از پیاده‌سازی‌ها آن را رها می‌کنند به‌جای ترجمه، و کلاینت سپس منتظر دست‌دادنی می‌ماند که هرگز فرستاده نشد.
این رفتار را معمولاً NAT loopback یا hairpinning می‌نامند، و به روتر مربوط است نه به WireGuard؛ RFC 4787 موارد ترجمه‌ای را برمی‌شمارد که دروازه ممکن است آن را پشتیبانی کند یا نکند. خود WireGuard درباره مسیر نظری ندارد، زیرا تنها بسته‌هایی را می‌بیند که به واسط آن می‌رسند. وقتی روتر جریان را رها می‌کند، دیمن هیچ چیزی دریافت نمی‌کند، کلاینت اتمام وقت دست‌دادن را گزارش می‌دهد و گزارش سرور خالی می‌ماند. پس گزارش خالی نشانه‌ای است از اینکه بسته کجا متوقف شده، نه گواهی بر اینکه سرور از کار افتاده است. همین هم دلیل آن است که نصب دوباره چیزی را تغییر نمی‌دهد.
عکس آن هم مهم است: گزارشی از سرور که تلاش دست‌دادن از نشانی LAN را نشان می‌دهد، ثابت می‌کند بسته رسیده و مسیر سالم است، و این بررسی را به کلیدها و نشانی‌های مجاز می‌برد. گزارش را برای آنچه ثابت می‌کند بخوانید، نه برای آنچه امید داشتید ببینید.
پیش از هر تغییری آن را بازتولید کنید
با همان دستگاه و همان پروفایل از یک شبکه خارجی مجاز آزمایش کنید، سپس بی‌آنکه چیزی را تغییر دهید آزمایش را داخل LAN تکرار کنید. یک دست‌دادن کامل در بیرون و کلاینتی که در درون هرگز از دستگاه خارج نمی‌شود، وضعیت را بازتولید می‌کند به‌جای آنکه درباره‌اش گمانه زده شود. هر دو تلاش باید از همان پروفایل استفاده کنند، وگرنه مقایسه چیزی را ثابت نمی‌کند.
سپس ببینید نام نقطه پایانی برای این دستگاه به چه نشانی تجزیه می‌شود. این سه فرمان همچنین نشان می‌دهند کلاینت واقعاً کدام نشانی را شماره‌گیری کرده است:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netفرمان نخست می‌گوید واسط در این لحظه از کدام نقطه پایانی استفاده می‌کند، و دو فرمان دیگر نشان می‌دهند نام روی این ماشین به چه چیزی تجزیه می‌شود. کلاینتی که در همان شبکه سرور نشسته و نشانی عمومی را شماره‌گیری می‌کند، مسیر hairpin را می‌آزماید. کلاینتی که نشانی LAN را شماره‌گیری می‌کند چنین نمی‌کند، و شکست در آنجا به بررسی دیگری تعلق دارد. همین تمایز تعیین می‌کند که بخش بعدی اصلاً کاربرد دارد یا نه.
راه‌های پشتیبانی‌شده برای رسیدن به سرور نزدیک
پاکیزه‌ترین چیدمان، پاسخ split-horizon است: نام عمومی برای اینترنت به نشانی عمومی و برای کلاینت‌های درون به نشانی LAN سرور تجزیه می‌شود. پروفایل یک نام نقطه پایانی نگه می‌دارد و resolver مسیر را انتخاب می‌کند. این کار به کنترل پاسخ داخلی DNS نیاز دارد، که روتر خانگی معمولاً فراهم می‌کند و یک سازمان می‌تواند آگاهانه ترتیبش را بدهد. بدون آن کنترل، گزینه‌های باقی‌مانده یک ویژگی روتر یا پروفایل دومی است.
ویژگی روتر همان بازتاب است: دروازه جریان درون‌به‌بیرون را ترجمه می‌کند و دوباره به درون می‌فرستد. جایی که کار می‌کند به تغییر کلاینت نیازی نیست، و جایی که کار نمی‌کند هیچ تنظیم کلاینتی نجاتش نمی‌دهد. آن را با نگاه کردن به گزارش سرور در خلال یک تلاش داخلی بیازمایید، نه با خواندن فهرست ویژگی‌های روتر.
تغییر پروفایل به یک نشانی خصوصی، تشخیص است نه طراحی. ثابت می‌کند سرور در LAN پاسخ می‌دهد، و همان لحظه‌ای که لپ‌تاپ از خانه بیرون می‌رود همان پروفایل را از کار می‌اندازد.
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
پروفایل را بیرون از خانه هم قابل استفاده نگه دارید
هر مسیری که انتخاب کنید، بررسی هویت را دست نزنید. نشانی نقطه پایانی همان هویت همتا نیست، و تغییر نشانی هرگز توجیه‌کننده پذیرش یک کلید عمومی نامرتبط نیست که تصادفاً پاسخ می‌دهد. WireGuard با کلید احراز هویت می‌کند، پس میزبان اشتباه دست‌دادن را شکست می‌دهد نه اینکه به چیزی غیرمنتظره دسترسی بدهد.
اگر نشانی عمومی جابه‌جا شود، DNS پویا همان چیزی است که نام را سودمند نگه می‌دارد، و رفتار بازتازه‌سازی کلاینت تعیین می‌کند تغییر چقدر زود اعمال شود. پس از تغییر نشانی این را از بیرون بیازمایید، چون حالت LAN نمی‌تواند آن را اعتبارسنجی کند. مراقب resolverی باشید که پاسخ قدیمی را بیش از عمر رکورد در حافظه نگه می‌دارد. نامی که هنوز به نشانی پیشین اشاره می‌کند، درست مثل سروری دیده می‌شود که از کار افتاده است.
بنویسید پروفایل از کدام نام استفاده می‌کند و آن نام در دو سوی مرز به چه چیزی تجزیه می‌شود. پروفایلی که به ویژگی روتری وابسته است که هیچ‌کس ثبتش نکرده، یک تماس پشتیبانی است که منتظر به‌روزرسانی بعدی firmware است. همان یادداشت هم به نفر بعدی می‌گوید شکست داخلی همان مورد شناخته‌شده hairpin است یا چیز تازه.