النفق ما زال قائمًا والمسار اختفى: فصل عطلين في VPN

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

ثلاث مراحل تبدو كحدث واحد

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

لهذا السبب يكون السؤال الأول عن المرحلة التي انكسرت، لا عن البروتوكول المسؤول. والجواب يحدد من يملك الحادثة وأي أداة يستخدمها الفحص التالي.

اقرأ المسار المثبَّت أولًا

اسأل النواة إلى أين يذهب المرور فعليًا نحو الوجهة المعطلة. ip route get يطبع القفزة التالية والواجهة وعنوان المصدر الذي ستستخدمه النواة، وهو يجيب عن وجهة واحدة لا عن الجدول كله. إذا كان الجواب يسمي النفق، فجدول التمرير ما زال يعتقد أن المسار موجود والمشكلة تقع فوقه.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

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

ثم انظر إلى رؤية البروتوكول نفسه

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

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

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

عندما تختلف الساعات

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

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

استعادة بلا حلقة

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

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