توقف دو ثانیه‌ای: تقصیر VPN بود یا Wi-Fi؟

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

دو ثبت، نه یکی

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

پایشگری که هر دقیقه یک بار بررسی می‌کند نمی‌تواند قطع‌های دو ثانیه‌ای را ببیند. گزارش دادن آن روز به عنوان سالم از نظر فنی درست و در عمل بی‌فایده است. بازه نمونه‌برداری را کنار هر نتیجه‌ای که نقل می‌کنید بگذارید.

پیوند دسترسی هنگام یخ‌زدن برنامه چه کرد

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

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

ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address show

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

به دنبال سابقه راه‌اندازی دوباره بگردید

یک داده‌گرام UDP ازدست‌رفته به‌تنهایی باعث نمی‌شود Community OpenVPN مذاکره TLS تازه‌ای آغاز کند. رفتار راه‌اندازی دوباره از ping-restart پیروی می‌کند، و ممکن است مقدار جاری را سرور تحمیل کرده باشد؛ راهنمای 2.6 آن زمان‌سنج‌ها را تعریف می‌کند. تحویل برای لحظه‌ای می‌شکند، آستانه هرگز عبور نمی‌شود، و گزارش خالی می‌ماند. پس در گزارش حوالی توقف به دنبال خط راه‌اندازی دوباره، اتصال تازه یا شناسه نشستی که تغییر کرده بگردید. اگر هیچ‌کدام از این سه ظاهر نشود، تونل احتمالاً کاری نکرده و زمان‌سنج هرگز مشکل نبوده است.

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

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

بگذارید مقایسه تصمیم بگیرد چه چیزی اصلاح شود

وقتی هر دو ثبت کنار هم باشند، تخصیص معمولاً خودش نوشته می‌شود. رخداد پیوند مسیریاب در هر دو مسیر یعنی موضوع، اتصال دسترسی است. تونل ساکت و مسیر ساده قابل استفاده یعنی موضوع، مذاکره است.

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

گزارشی که از بازبینی سالم بیرون می‌آید به چهار چیز پاسخ می‌دهد: یخ‌زدگی چقدر طول کشید، کدام مسیرها به پاسخ دادن ادامه دادند، تونل در آن ثانیه چه ثبت کرد، و پایشگر هر چند وقت نمونه می‌گیرد. این چهار واقعیت به خواننده بعدی امکان می‌دهند مشاهده را بازتولید کند نه اینکه به خلاصه اعتماد کند. درصد زمان کار دقیقاً همان بازه‌ای را پنهان می‌کند که برایتان مهم است، و عبارت "VPN افتاد" هم همین کار را می‌کند.