مراقب بينج لا يستطيع التمييز بين نفق معطوب ونفق سليم

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

الاختبار هو الجزء الذي يحدد كل ما عداه.

ما يثبته بينج إلى الإنترنت فعليًا

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

لا يظهر أي من اتجاهي الخطأ في رمز الخروج. المراقب المبني على تلك الإشارة هو رمية عملة مع جدول cron.

افحص شيئًا يعيش خلف النفق

ip -brief addr show tun0
ip route get 10.100.20.10
nc -z -w3 10.100.20.10 443

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

أبقِ الفحص محدودًا في الزمن وأعطه رمز خروج مميزًا. الفحص الذي يتعلق ثلاثين ثانية يحوّل المراقب إلى كاشف انقطاع بفارق زمني مدمج.

اختر بين سطر واحد وحلقة

* * * * * nc -z -w5 10.100.20.10 443 || myvpn reconnect

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

failures=0
while sleep 30; do
  if nc -z -w5 10.100.20.10 443; then failures=0
  else failures=$((failures+1)); fi
  if [ $failures -ge 3 ]; then myvpn reconnect; failures=0; fi
done

تلك الحلقة تعدّ الإخفاقات المتتالية بدلًا من نسبة على مدى نافذة. النافذة تحتاج ساعة وذاكرة عينات، ومعظم أخطاء المراقبات المكتوبة يدويًا تسكن في تلك الحسابات.

التحويل إلى خادم آخر قرار مختلف

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

لا تفحص العنوان العام لخادم VPN نفسه من داخل نفق كامل. ذلك الفحص يعتمد على الشيء الذي يختبره، ويبلّغ بالنجاح بينما المسار الذي كان عليه التحقق قد ذهب.

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