WireGuard پس از بی‌کاری شکست می‌خورد: ابتدا جهت را بیازمایید

پیش از هر تغییر تنظیمات چهار پرسش مطرح است: آیا همان منبع در حالی که کارخواه فعال است کار می‌کند، دوره بی‌کاری چقدر طول کشید، دستگاه خوابید یا شبکه را عوض کرد، و آیا خطا فقط در ترافیکی دیده می‌شود که طرف مقابل آغاز می‌کند. پاسخ‌ها یک نگاشت NAT منقضی را از رادیوی خواب‌رفته و از برنامه کهنه جدا می‌کنند. آن‌ها همچنین می‌گویند آیا keepalive به‌کلی مرتبط است. از جهت شروع کنید، چون یک فرمان هزینه دارد و نیمی از علت‌های ممکن را حذف می‌کند.

کدام جهت شکست می‌خورد؟

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

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

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

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

خواب، رادیو و وضعیت برنامه

روی تلفن یا لپ‌تاپ، دستگاه خواب‌رفته ممکن است دسترسی شبکه را کاملاً از دست داده باشد، و keepalive نه می‌تواند رادیوی خاموش را بازگرداند و نه یک captive portal برآورده‌نشده را کامل کند. سکوهای همراه به‌حکم سیاست کار پس‌زمینه را متوقف می‌کنند، بنابراین اینکه ترافیک دوره‌ای ادامه یابد به سکو و به آنچه برنامه با آن مذاکره کرده بستگی دارد. اتصال انباره‌شده سومین حالت و گمراه‌کننده‌ترین است، چون بازگشت تونل با دوباره وصل شدن برنامه به آن یکی نیست.

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

keepalive در واقع چه می‌کند

PersistentKeepalive به‌طور دوره‌ای یک بسته خالی احرازشده به همتا می‌فرستد، که برای زنده نگه داشتن نگاشت NAT میان همتاها و به‌روز ماندن نقطه پایانی طرف مقابل کافی است، چنان‌که شروع سریع WireGuard توصیف می‌کند. این کار رادیوی خواب‌رفته، مسیر گم‌شده یا برنامه‌ای را که هرگز دوباره تلاش نمی‌کند درست نمی‌کند. فاصله را از راه تنظیمات پشتیبانی‌شده کارخواه انتخاب کنید و فقط به این دلیل که نمایشگر وضعیت ساکت می‌شود، مقدار تهاجمی را همه‌جا فعال نکنید.

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

منتظر فاصله‌ای بمانید که پیش‌تر شکست می‌خورد

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

در هر آزمون یک تغییر را نگه دارید و مدت بی‌کاری استفاده‌شده را بنویسید. بدون آن هر مقایسه بعدی می‌لغزد و هیچ‌کس نمی‌تواند بگوید کدام تغییر مهم بود. چهار واقعیت را با هم ثبت کنید: جهت، مدت، وضعیت خواب و رفتار برنامه.