عندما تتداخل مسارات النفق المنقسم: أي بادئة تفوز

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

1. اكتب الوجهة والمصدر

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

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

2. اسأل النواة عن المسار الذي اختارته

لا تقرأ جدول المسارات وتستنتج الإجابة. اطرح السؤال نفسه الذي تطرحه الحزمة، بعنوان المصدر نفسه: ip route get 10.20.4.10 from 10.8.0.2 على Linux، أو Find-NetRoute -RemoteIPAddress 10.20.4.10 في PowerShell. يُسمّي الناتج المسار الذي سيُستخدم فعلاً، وهو غالباً ليس المسار الذي توقعته من قراءة الجدول.

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

3. تحقق مما إذا كانت قاعدة سياسة قد أعادت توجيه البحث

قبل الاستشارة بجدول المسارات، تمر النواة على قواعد السياسة الخاصة بها. يمكن لقاعدة أن ترسل حركة المرور من مصدر معين أو مستخدم معين أو علامة جدار ناري إلى جدول آخر تماماً، لذا قد لا تُستشار البادئة الفائزة في الجدول الرئيسي لهذا التدفق أبداً. يسرد ip rule show القواعد بترتيب التقييم، ويوضح ip route show table 100 ما يحتويه الجدول المختار فعلاً.

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

4. افصل التعادل في التوجيه عن خطة عناوين مكررة

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

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

5. تأكد من أن المحلّل يتفق مع المسار

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

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

6. أعد الاتصال، وافحص الحالة المطبقة، ثم اختبر التدفقين

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

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