آدرس IP عمومی تغییر کرد و VPN ترافیک را عبور نداد

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

چهار بررسی را به ترتیب انجام دهید و در اولین موردی که شکست می‌خورد توقف کنید.

کدام نشانی واقعاً تغییر کرد

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

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

بگذارید پروتکل جابه‌جایی را مدیریت کند

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

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

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

اتصال بیرونی کهنه را پاک کنید

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

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

با یک درخواست تازه دوباره بیازمایید

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

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

اگر درخواست تازه‌ای موفق شود و درخواست قدیمی هرگز از سر گرفته نشود، تونل درست شده و برنامه فقط باید دوباره متصل شود.