لماذا قد يبدو الـ VPN متصلًا بينما لا يعمل شيء

يُبلّغ عميلك عن حالة «متصل» بينما تبقى الواجهة قائمة وتنتهي مهلة المتصفح، وليس أي من هذه العبارات الثلاث كاذبًا. تصف «متصل» طبقة لا علاقة لها بالصفحة التي طلبتها. تحديد الطبقة التي تُبلّغ يتطلب طلبًا جديدًا واحدًا ونظرة واحدة إلى العدّاد الذي يثبت أن حركة المرور تحركت. إعادة التشغيل تُلقي بهذا الدليل وتعيد بناء الظروف التي كنت تحاول مراقبتها.

ثلاثة أشياء مختلفة تُسمّى «متصل»

في الأسفل، قد تعني «متصل» أن عملية عميل تعمل وتحتفظ بمقبس نحو نظير. وفوق ذلك، قد تعني أن واجهة موجودة بعنوان، وهو ما يمكن لجهاز دائم أو روتين استرداد أن ينشئه دون أي جلسة حيّة خلفه. وعلى مستوى التحكّم، قد تعني أنه تم التفاوض على ارتباط، وهذا لا يقول شيئًا عمّا إذا كانت حزمة واحدة قد عبرت تحته. كل واحد من هذه يصمد أمام أعطال لا تصمد أمامها الأخرى، والعميل يعرض عادةً أقواها التي يستطيع ادّعاءها.

أيقونة خضراء ونفق ميت أمران متوافقان لا متناقضان؛ فهما يُبلّغان عن كائنين مختلفين. وهذا هو السبب كله في أن هذا العطل يُشخَّص باستمرار كخطأ في العميل.

أرسل طلبًا واحدًا غير ضار إلى وجهة تحتاجها فعلًا قبل أن تلمس الخادم الخفي، وأبقِ كتلة حركة المرور المباشرة المطلوبة في مكانها أثناء عملك. إعادة التشغيل تمحو ترتيب الأحداث ثم تعيد إنشاءها قريبة بما يكفي لإخفاء السبب، ولهذا تعود التذكرة نفسها بعد أسبوع ولا جديد فيها. طلب واحد وقراءة عدّاد واحدة والمُحرّض الذي أنتج العطل هي الحد الأدنى من الدليل.

أي عدّاد يثبت أن الحزم تحركت

في IPsec، ارتباط IKE وارتباط CHILD كائنان منفصلان، والطفل وحده يحمل العدّادات التي تجيب عن هذا السؤال. اسرد الطفل، وراقب هل تزداد الحزم في الاتجاهين، وقارن ذلك بما يحاول التطبيق فعله. ارتباط مثبّت على صفر نتيجة مختلفة عن ارتباط يتزايد بينما يفشل التطبيق؛ فالأول يعني أن حركة المرور لا تُختار، والثاني يعني أنها تتحرك والعطل أبعد. اقرأ العدّادات مرتين بفاصل بضع ثوانٍ، لأن عيّنة واحدة لا تُظهر اتجاهًا.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

العدّادات الصفرية تشير إلى الاختيار: التوجيه، أو السياسة، أو نطاق أسماء غادرت منه الحزمة، أو واجهة لم يربطها العميل أبدًا. العدّادات المتزايدة تشير بعيدًا عن النفق، لذا تابع مع التمرير في الطرف البعيد، وتحليل الأسماء، ومسار العودة، وخدمة الوجهة، بهذا الترتيب. البروتوكول الذي لا يملك كائن طفل منفصل يعرض الدليل نفسه بمصطلحاته، لذا استخدم ما يبلّغ عنه عن حالة النظير وأعداد الحزم بدل استعارة مفردات IPsec. شكل القراءة يهم أكثر من الأداة التي أنتجته.

أين يقع العطل بعد أن تتحرك العدّادات

بوّابة تجيب على عنوان إدارتها الخاص تُثبت أن البوّابة تعمل، لا أن شيئًا خلفها يخدم طلبك، لذا اختبر الطرف البعيد لا الصندوق في الوسط. تحليل الأسماء يخفي الأعطال أفضل من غيره، لأن مُحلّلًا لا يمكن الوصول إليه عبر النفق ينتهي إلى مهلة بطريقة تبدو مطابقة لاتصال ميت. عمليتا بحث تفصلان بين هذه الحالات، وكلتاهما رخيصة. اسأل أولًا المُحلّل الذي يدفعه النفق، ثم اسأل مُحلّلًا عامًا عن الاسم نفسه.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

اسم يُحلّ عبر المُحلّل العام لكن ليس عبر مُحلّل النفق يعني أن مسار DNS مكسور، أما اسم يُحلّ عبر كليهما وما زالت مهلة المتصفح تنتهي فيه فيشير إلى مسار العودة أو إلى الخدمة. إذا نجح الـ ping بالعنوان وما زال التطبيق يرفض، فقد أوصلت الشبكة الطلب ورفضته الخدمة، وهذه مرحلة لاحقة تمامًا.

سجّل المُحرّض ثم غيّر شيئًا واحدًا

سجّل ما سبق العطل: فترة خمول، أو تغيّر شبكة، أو تجديد مفتاح، أو حاسوب محمول استُؤنف، أو نظام استُعيد. هذه تُنتج آليات مختلفة، والنظام المستعاد وحده هو الذي يُصلح نفسه عادةً، وهو بالضبط الحالة التي لا تُعلّمك شيئًا. إعادة التشغيل تزيل ترتيب الأحداث ثم تعيد إنشاء ظروف قريبة بما يكفي لإخفاء السبب. اكتب المُحرّض بينما ما زال قابلًا للتكرار.

ثم أجْرِ تصحيحًا واحدًا مدعومًا وأعد الطلب الأصلي مع المُحرّض الذي أنتج العطل. الخمول أسهل مُحرّض للتكرار، لذا هو أسرع تأكيد على أن الإصلاح عالج الآلية لا العَرَض.

ما تريد الإبلاغ عنه هو دليل على أن حركة المرور التي قصدت إرسالها وصلت إلى الخدمة التي قصدت الوصول إليها. أيقونة تتحول إلى الأخضر، وصفحة مخزّنة مؤقتًا تُحمّل، وعدّاد يتحرك، كلها تُثبت أقل من طلب واحد مكتمل تجاه الوجهة المقصودة. أبقِ الطلب وقراءة العدّاد والمُحرّض معًا، حتى يستطيع الشخص التالي التمييز بين إصلاح ومصادفة.