VPN گیرکرده پس از راهاندازی مجدد روتر: سه چیزی که تغییر کرد
پروفایل تغییر نکرد، اما مسیر زیر آن تغییر کرد. پیش از بازنشانی اعتبارنامهها، نشانی محلی، نگاشت ترجمهشده و مسیر را بررسی کنید.
روتر راهاندازی را تمام میکند، لپتاپ به همان SSID میپیوندد و VPN در حالت متصل میماند بیآنکه چیزی حرکت کند. پروفایل ذخیرهشده سالم است. آنچه زیر آن منقضی شد مسیر بود و کارخواه همچنان وضعیتی را نگه میدارد که برای مسیر قدیمی ساخته بود.
سه شرط راهحل را تعیین میکند. آنها را به ترتیب بررسی کنید، زیرا شرطهای بعدی اگر اولی همین حالا توقف را توضیح دهد، تلاش هدررفته است.
شرط یک: نشانی محلی تغییر کرده است
راهاندازی مجدد میتواند نشانی دیگری به دستگاه بدهد. آنگاه VPN که با نقطه پایانی محلی ثابت پیکربندی شده، همچنان از پیوندی استفاده میکند که دیگر وجود ندارد. همین برای کارخواهی هم صادق است که سوکت خود را به نشانی قدیمی بسته بود. رابط تونل میتواند بالا بماند در حالی که هر بسته تولیدشدهاش به جایی بیفایده میرود.
نشانیای که کارخواه استفاده میکند را با نشانیای که رابط اکنون دارد مقایسه کنید. مسیر پیشفرضی که به دروازهای اشاره میکند که آن هم تغییر کرده، همان نوع مشکل با نامی دیگر است.
ip -4 addr show
ip route show default
ip route get 203.0.113.10
شرط دو: نگاشت ترجمهشده از میان رفته است
روترهای خانگی جریانهای خروجی را ترجمه میکنند و آن نگاشتها در حافظه زندگی میکنند. راهاندازی مجدد همه آنها را پاک میکند. این برای اتصال جدید بیضرر و برای تونلی که باور دارد جریان موجودش هنوز معتبر است کشنده است. سپس طرف مقابل چیزی نمیبیند، پس کارخواه هرگز خطایی نمیگیرد که بتواند بر اساس آن عمل کند.
اینجاست که تونل بدون keepalive بهجای شکست پرصدا، بیصدا متوقف میشود. محدودیتهای مستند WireGuard همان شکل شکست را توصیف میکنند. وضعیت نادرست نقطه پایانی بهجای تشخیص، بستههای دورریخته تولید میکند.
keepalive پایدار 25 ثانیهای کاهشدهنده معمول است، زیرا نگاشت را پیش از آنکه مهلت بیکاری منقضی شود تازه میکند. اما نگاشتی را که از پیش رفته ترمیم نمیکند. keepalive را با منطق اتصال مجدد جفت کنید، نه اینکه آن را یک راهحل بدانید.
شرط سه: نشانی عمومی تغییر کرده است
اگر نشانی خارجی خود روتر تغییر کرده باشد، هر چیزی در طرف دور که بر اساس نشانی مبدأ فیلتر میکند اکنون همتای دیگری میبیند. ممکن است تونل بالا بیاید و سرور همچنان ترافیک را دور بریزد؛ این شبیه کارخواه خراب به نظر میرسد و در واقع سیاستی در آن سر است.
نشانی خارجی را پیش و پس از راهاندازی مجدد ثبت کنید. وقتی این دو متفاوت باشند، پرسش از کارخواه به کسی منتقل میشود که فهرست مجاز را نگه میدارد و بازنشانی اعتبارنامهها روی لپتاپ کمکی نمیکند.
به ترتیب درست بازیابی کنید
نخست هر ورود لازم به دروازه اسیر را کامل کنید، سپس بگذارید کارخواه با رویه پشتیبانیشدهاش دوباره وصل شود، نه اینکه فرایند را بکشید. ببینید آیا هویت و ترافیک داده هر دو برمیگردند، زیرا اینها دو مرحله متفاوت از یک اتصالاند.
صفحه ذخیرهشده در حافظه پنهان چیزی را اثبات نمیکند، و نه برنامه گپاری که خودش دوباره وصل شده. نقطه پایانیای را که واقعاً برایتان مهم است با درخواستی تازه بیازمایید. سیاست ترافیک مستقیم را در طول وقفه برقرار نگه دارید، زیرا تلاش برای اتصال مجدد مسدودسازی نیست.
وقتی این پس از هر راهاندازی مجدد تکرار میشود، ثبت اهمیت بیشتری از تلاش دوباره دارد. نشانی محلی، دروازه، نشانی خارجی و وضعیت کارخواه را پیش و پس یادداشت کنید، سپس دو ستون را مقایسه کنید. این شکایت مبهم را به اشکالی در چرخه عمر تبدیل میکند که کسی میتواند رفعش کند و جلوی سومین جایگزینی گواهیها بهخاطر مهلت نگاشت را میگیرد.