آیا VPN پس از تمدید DHCP قطع می‌شود؟ نشانی‌ها را مقایسه کنید
تمدید معمولاً همان نشانی را نگه می‌دارد. پیش از مقصر دانستن اجاره‌نامه، نشانی، دروازه، حل‌کننده و وضعیت مسیر کارخواه را در زمان قطع بررسی کنید.
تمدید اجاره‌نامه و شکست VPN به‌قدری زیاد با هم در گزارش‌ها دیده می‌شوند که مردم نتیجه می‌گیرند یکی علت دیگری است. هم‌زمانی واقعی است؛ علیت معمولاً نه. تمدید یک درخواست تک‌پخشی به کارساز صادرکننده اجاره‌نامه است برای ادامه استفاده از همان پیوند، و کارساز می‌تواند آن را بدون آنکه کارخواه حتی یک نشانی را تغییر دهد تمدید کند. بررسی مقادیر خود کارخواه در اطراف رویداد، اجاره‌نامه‌ای را که بی‌صدا تمدید شده از شبکه‌ای که واقعاً زیر یک تونل در حال اجرا تغییر کرده جدا می‌کند.
از کارخواهی که قطع شد شروع کنید
ابتدا گزارش اتصال کارخواه را باز کنید و زمان قطع را تا ثانیه یادداشت کنید. سپس گزارش شبکه سیستم‌عامل را برای همان دقیقه باز کنید و به ترتیب بخوانید که واسط چه کرد. همین ترتیب تمام پژوهش است: رویداد DHCP پیش از قطع، قطع پیش از رویداد DHCP، و دو رویدادی که چیزی میانشان نیست سه یافته متفاوت‌اند. خطی از گزارش که فقط از اجاره‌نامه یاد می‌کند در حالی که تونل از پیش دوباره متصل می‌شد، تزیین است نه مدرک.
خط زمانی را همان‌طور که پیش می‌روید بنویسید نه آنکه در حافظه نگه دارید. مهرهای زمانی ابزارهای مختلف به‌ندرت کاملاً منطبق می‌شوند و خود اختلاف گاهی توضیح است.
چهار مقدار پیرامون رویداد را مقایسه کنید
چهار مقدار سمت محلی اتصال را به‌اندازه کافی خوب توصیف می‌کنند تا تغییری واقعی را بگیرند: نشانی واسط، دروازه پیش‌فرض، فهرست حل‌کننده‌ها و وضعیت عملیاتی واسط. آن‌ها را در عرض یک دقیقه پس از قطع ثبت کنید و با ثبت‌هایی که هنگام سالم بودن تونل گرفته شده مقایسه کنید.
ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcpنشانی بدون تغییر با دروازه بدون تغییر و فهرست حل‌کننده تغییریافته به حل نام اشاره دارد نه به مسیریابی، و ممکن است تونل زنده مانده باشد در حالی که برنامه‌ها دیگر میزبان‌ها را نمی‌یافتند. دروازه تغییریافته یعنی مسیر خروج از شبکه محلی جابه‌جا شده و همین برای بی‌اعتبار کردن مسیری که به دروازه پیشین اشاره داشت کافی است. اگر هر چهار مقدار با ثبت سالم بخوانند، اجاره‌نامه علت شما نیست و منطق اتصال دوباره خود کارخواه موضوع می‌شود. مقایسه را وقتی نقص دیده می‌شود بگیرید، زیرا ثبت سالمی که پس از راه‌اندازی دوباره گرفته شود تاریخ نشانی متفاوتی دارد و نخواهد خواند.
تمدید چه می‌تواند و چه نمی‌تواند تغییر دهد
RFC 2131 تمدید را درخواستی به کارساز اصلی در نیمه مدت اجاره توصیف می‌کند، با پیوند دوباره به هر کارسازی در هفت‌هشتم اگر تلاش نخست بی‌پاسخ بماند. هیچ‌یک از دو گام نیاز ندارد که کارخواه نشانی متفاوتی بگیرد، و کارساز همکار معمولاً پیوند موجود را تمدید می‌کند. تغییر واقعی نشانی معمولاً از راه دیگری می‌آید: کارسازی که تمدید را رد می‌کند، کارخواهی که وضعیت خود را از دست داده و از نو شروع کرده، یا شبکه‌ای که دستگاه را به بخش متفاوتی برده است.
سمت عمومی اتصال می‌تواند بدون هیچ تغییر محلی تغییر کند. پشت ترجمه درجه اپراتور، نشانی‌ای که همتای VPN می‌بیند ممکن است مستقل از هر کاری که اجاره‌نامه محلی کرده دوباره تخصیص یابد، و آن تخصیص دوباره از درون کارخواه همانند یک شکست شبکه محلی دیده می‌شود. مقایسه نشانی گزارش‌شده محلی با مشاهده سمت همتا تنها راه جدا کردن آن‌هاست.
وقتی کارخواه نمی‌تواند سازگار شود
کارخواهی که انتقال خود را به نشانی کهنه بسته، مسیر کهنه‌ای به همتا را در حافظه پنهان نگه داشته یا هویت واسط را ذخیره کرده ممکن است مسیری را که دیگر وجود ندارد مکرراً بیازماید. این یک نقص سازگاری است و به‌صورت بازفرست‌های مکرر به نشانی‌ای که میزبان دیگر به آن نمی‌رسد دیده می‌شود. برخی کارخواه‌ها آن را بر اساس طراحی مدیریت می‌کنند: برای نمونه WireGuard نقطه پایانی همتا را هنگامی که بسته‌ای با احراز هویت درست از منبعی تازه می‌رسد به‌روز می‌کند.
راه‌اندازی دوباره دستی که سرویس را برمی‌گرداند سرنخی است از اینکه سازگاری کجا شکست خورده، نه مدرکی بر ناسازگاری اجاره‌نامه‌ها و تونل‌ها. سیاست مسدودسازی را در طول آزمون برقرار نگه دارید، وگرنه خود آزمون به قطعی با علتی دیگر تبدیل می‌شود. ثبت کنید که کارخواه خودبه‌خود بازیابی شد، چه مدت طول کشید و کدام نشانی را دوباره آزمود؛ این توالی بیش از علت قطع نمایش‌داده‌شده در واسط به شما می‌گوید.
پیش از سرزنش، رویداد را تکرار کنید
شرط را بازتولید کنید نه آنکه منتظر زمان‌بندی بمانید: اجاره‌نامه را آزاد و دوباره تمدید کنید، یا رویداد کنترل‌شده معادل را اجبار کنید، و ببینید تونل زنده می‌ماند یا نه. در شبکه مدیریت‌شده، هر تغییر نشانی را با مالک شبکه هماهنگ کنید، زیرا تخصیص ایستای دلبخواه می‌تواند با دستگاهی که از پیش آن نشانی را دارد برخورد کند.
پس از یک اصلاح پشتیبانی‌شده، همان رویداد را تکرار کنید و سپس یک برنامه و یک جست‌وجوی نام را بیازمایید، زیرا تونلی که دوباره متصل می‌شود اما DNS را می‌شکند آزمونی ضعیف‌تر از آزمون مهم را می‌گذراند. تغییر مشخصی را که مشاهده کردید با مهر زمانی آن گزارش کنید، نه آنکه اجاره‌نامه زمان‌بندی‌شده را علت بنامید. تفاوت این دو گزارش در این است که نفر بعدی می‌تواند نقص را بازتولید کند یا فقط شایعه را.