WireGuard تنها پس از آنکه سرور ابتدا بفرستد کار می‌کند: شناخت نقطه پایانی
موفقیت وابسته به جهت معمولاً یعنی یک همتا هرگز نشانی دیگری را یاد نگرفته است. نقاط پایانی را مقایسه کنید و سپس بررسی کنید که آیا نگاشت ترجمه منقضی شده است.
به نظر می‌رسد تونل تنها پس از آنکه سرور ابتدا چیزی می‌فرستد کار می‌کند. از سمت کلاینت شروع کنید و هیچ اتفاقی نمی‌افتد، چند ثانیه صبر کنید، دوباره تلاش کنید و موفق می‌شود. تشخیص معمول NAT خراب است، و تشخیص معمول اشتباه است. آنچه تغییر کرده این است که یک همتا فهمیده دیگری کجا زندگی می‌کند.
شناخت نقطه پایانی، نه دسترس‌پذیری
همتای WireGuard تا نداند کجا بفرستد، دست‌دادن را آغاز نمی‌کند. پیکربندی آن را به‌صورت نقطه پایانی از نشانی و درگاه فراهم می‌کند، و وضعیت در حال اجرا نقطه پایانی‌ای را که اکنون باور دارد دنبال می‌کند.
wg show هر دو طرف آن تصویر را چاپ می‌کند، و همتایی که در خروجی نقطه پایانی ندارد نمی‌تواند چیزی را آغاز کند، هرچند کلید عمومی و پیشوندهای مجازش درست باشد. پیش از تغییر هر قاعده‌ای، دید کلاینت را با دید سرور مقایسه کنید، چون این دو اغلب درباره اینکه چه کسی چه چیزی می‌داند توافق ندارند.
چگونه یک همتا نقطه پایانی را یاد می‌گیرد
WireGuard عمداً ساکت است. وقتی بستهٔ به‌درستی احراز هویت‌شده از نشانی‌ای می‌رسد که همتا انتظارش را نداشت، پیاده‌سازی نقطه پایانی آن همتا را به مبدأ جدید به‌روز می‌کند، و گردش روی لپ‌تاپی که شبکه عوض می‌کند همین‌گونه کار می‌کند. این رفتار وابستگی به جهت را توضیح می‌دهد: اگر سرور اول بفرستد و بسته‌اش به کلاینت برسد، کلاینت نشانی فعلی سرور را یاد می‌گیرد و می‌تواند پاسخ دهد. تا آن زمان جایی برای فرستادن ندارد. سازوکار، گردش احراز هویت‌شده است و نه میانبر اعتماد در نخستین استفاده، چون بسته باید پیش از جابه‌جایی نقطه پایانی معتبر می‌بود.
مستندات ابزار wg آن به‌روزرسانی را توصیف می‌کند، و اگر می‌خواهید پیرامون آن طراحی کنید، یک بار خواندنش ارزش دارد.
ترجمهٔ حالت‌دار جهت خودش را اضافه می‌کند
جایی که UDP از دروازهٔ مترجم می‌گذرد، دروازه برای نخستین بسته‌ای که می‌بیند حالت می‌سازد. RFC 4787 آن رفتار و مهلت‌هایی را که در نهایت نگاشت را برمی‌دارند توصیف می‌کند. نگاشت بی‌استفاده منقضی می‌شود، و بستهٔ ورودی از سمت دور سپس پیش از رسیدن به میزبان توسط دروازه دور انداخته می‌شود. تونلی که تمام صبح کار می‌کرد، دقیقاً به همین دلیل بعدازظهر پاسخ دادن را متوقف می‌کند.
این سازوکار دومی و مستقل است که همان نشانهٔ جهت‌دار را تولید می‌کند. هم شناخت نقطه پایانی و هم وضعیت ترجمه باید درست باشند، و درست کردن یکی دیگری را درست نمی‌کند.
جهتی را که واقعاً می‌خواهید پیکربندی کنید
برای کلاینتی که باید اتصال را آغاز کند، نقطه پایانی سرور را در بخش همتاهای کلاینت بگذارید و همان‌جا نگه دارید. تکیه بر اینکه سرور اول بفرستد، تکیه بر تصادفی در ترتیب ترافیک است که در شبکهٔ آرام تغییر خواهد کرد. پیکربندی باید جهت مورد نظر را اعلام کند، نه آن را کشف کند.
برای همتایی پشت ترجمه که باید دسترس‌پذیر بماند، در همان سمت یک keepalive پیوسته فعال کنید. keepalive هر 25 ثانیه مقدار آغازین معمول است، و هدفش باز نگه داشتن نگاشت است نه آزمودن تونل. یک سمت را برای حمل آن انتخاب کنید، چون فعال کردنش در هر دو سمت ترافیک و شلوغی گزارش را دو برابر می‌کند بدون آنکه نتیجه را بهتر کند.
وضعیت را پیش و پس از محرک مقایسه کنید
دو نما را در لحظهٔ شکست ثبت کنید، و سپس دوباره پس از آنکه سرور می‌فرستد. فرمان نخست نقاط پایانی و سن دست‌دادن را نشان می‌دهد. دومی نشان می‌دهد آیا برای درگاه ورودی ترجمه‌ای وجود دارد. ثبت نشان می‌دهد کدام جهت واقعاً از سیم گذشته است، و بررسی مسیر تأیید می‌کند که کلاینت آن ترافیک را جای کاملاً دیگری نمی‌فرستد.
wg show conntrack -L -p udp 2>/dev/null | grep 51820 tcpdump -ni any -c 20 'udp port 51820' ip route get 198.51.100.7
ستون نقطه پایانی و ورودی ترجمه را با هم ثبت کنید. همتای بدون نقطه پایانی و دروازهٔ بدون نگاشت دو خرابی متفاوت‌اند. keepalive تنها یکی از آنها را درست می‌کند.