تجمّد لثانيتين: هل كان السبب VPN أم Wi-Fi؟
توقّف لمدة ثانيتين وجلسة VPN جديدة حدثان مختلفان. ضع مسار الوصول والنفق على خطين زمنيين منفصلين قبل أن تغيّر أي مؤقّت.
التجمّد الذي يستمر ثانيتين ثم يتعافى يبدو متطابقًا سواء أعاد النفق التفاوض أم تعثّر الراديو. من الممكن أيضًا ألّا يكون هناك أي انقطاع على الإطلاق، وهذا الاحتمال يستحق الاختبار أولًا. فقدان قصير للحزم وإعادة تفاوض وتوقّف أحد التطبيقات تبدو جميعها متطابقة بالنسبة للشخص الذي يكتب على لوحة المفاتيح. واحد فقط من هذه الثلاثة يُصلَح بتعديل إعدادات النفق.
سجّلان لا سجل واحد
سجّل ما حدث للاتصال في الطبقة السفلى، وبشكل منفصل ما فعله النفق نفسه. ثم ضع توقّف التطبيق مقابل السجلين. هذه سلاسل أحداث مستقلة تتزامن أحيانًا، ووصف الثلاثة جميعًا بأنها انقطاع يفترض الإجابة من البداية.
المراقب الذي يفحص مرة كل دقيقة لا يستطيع رؤية انقطاع يستمر ثانيتين. الإبلاغ عن ذلك اليوم بأنه سليم صحيح تقنيًا وعديم الفائدة عمليًا. ضع فترة أخذ العينات بجانب كل نتيجة تقتبسها.
ماذا فعل رابط الوصول أثناء تجمّد التطبيق
تحدّد فترة أخذ العينات والمهلة ما كان بإمكان المراقب رؤيته، لذا سجّل الاثنين بجانب النتيجة. غياب الانقطاعات المسجّل لا يعني الكثير عندما يأخذ الجهاز عينة كل ستين ثانية. ثم افحص ثلاثة مواضع بطوابع زمنية: الموجّه المحلي، ومضيف خارجي معتمد يُبلغ عبر المسار العادي، ومورد خلف النفق.
أكّد المسارات أولًا، لأن الهدف العام قد يكون هو نفسه موجّهًا عبر النفق فيقيس النفق بدل مسار الوصول. الأدلة التي تؤرّخ الانقطاع فعليًا تقع في طبقة أدنى: أحداث الربط على الموجّه، وسجلات إعادة التزامن على المودم، وعنوان WAN تغيّر. العدّاد التراكمي للأخطاء يخبرك بأن شيئًا ما حدث خطأ، لكنه لا يخبرك متى أبدًا. اربط تلك السجلات بنافذة الحادث بدل قراءتها بمعزل عن غيرها.
ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address showعدّاد ارتفع أمس لا يفسّر شيئًا عن تجمّد حدث هذا الصباح. احصر الربط في النافذة التي أبلغ عنها المستخدم.
ابحث عن سجل إعادة التشغيل
حزمة UDP مفقودة لا تجعل OpenVPN من Community تبدأ تفاوض TLS جديدًا بمفردها. يتبع سلوك إعادة التشغيل ping-restart، وقد تكون القيمة السارية قد دُفعت من الخادم؛ ويحدّد دليل 2.6 تلك المؤقّتات. ينقطع التسليم لحظة، ولا يُعبر الحد أبدًا، ويبقى السجل فارغًا. لذا ابحث في السجل حول التوقّف عن سطر إعادة تشغيل أو اتصال جديد أو معرّف جلسة تغيّر. إن لم يظهر أي من الثلاثة، فالأرجح أن النفق لم يفعل شيئًا ولم يكن المؤقّت هو المشكلة أصلًا.
تقصير كل نبضة إبقاء يجعل الاكتشاف يبدو أسرع وينقل الخط الذي يصبح عنده التعثّر إعادة اتصال. كل إعادة اتصال تكلّف جولة مصادقة وإعادة تثبيت للمسارات. وتمديد المؤقّت لا يشتري شيئًا سوى نافذة أطول يظل فيها مسار ميت يبدو حيًا. كلا الخيارين قرار ضبط له ثمن، وليس تحسينًا مجانيًا.
غياب الحدث دليل أيضًا، وهو النوع الذي يتخطاه الناس لأن شيئًا في السجل لا يلفت الانتباه إليه. سجّل البحث الذي أجريته، لا نتيجته فقط.
دع المقارنة تحدّد ما يجب إصلاحه
مع وضع السجلين جنبًا إلى جنب، يكتب الإسناد نفسه عادة. حدث ربط على الموجّه في كلا المسارين يعني أن اتصال الوصول هو الموضوع. نفق هادئ ومسار عادي صالح للاستخدام يعني أن التفاوض هو الموضوع.
| What you observed | Tunnel log at that second | Where to look next |
|---|---|---|
| two-second pause, plain path answers throughout | nothing | the monitor's resolution, then a loss burst |
| pause plus a router link event, plain path stops and returns | no restart line | the access link, not the tunnel timer |
| pause, then a new session identifier | restart line | the restart threshold and what triggered it |
| one application freezes while both paths answer | nothing | that application and its server-side work |
كل صف خيط للتحقيق وليس حكمًا: نقاط الطرف تُنزل أولوية ICMP، ووجهتان لا تتشاركان المسار بالضرورة. أبقِ ساعات العميل والبوابة والتطبيق متوافقة حتى تكون المقارنة ممكنة أصلًا. الصف الذي يناسب عمودين يحتاج ملاحظة أخرى، لا قرارًا.
التقرير الذي ينجو من المراجعة يجيب عن أربعة أشياء: كم استمر التجمّد، وأي المسارات ظلّت تستجيب، وما سجّله النفق في تلك الثانية، وكم مرة يأخذ المراقب عينة. هذه الحقائق الأربع تتيح للقارئ التالي إعادة إنتاج الملاحظة بدل الثقة بملخّص. نسبة وقت التشغيل تخفي بالضبط الفترة التي تهمّك، وكذلك عبارة "سقط الـ VPN".