كيف تميّز حلقة التوجيه من تقلّب المسار على مواقع VPN
تسبّب حلقة التوجيه والمسار المتقلّب الفقد المتقطّع نفسه. ثلاث فحوص على البوابات تفصل بينهما قبل أن تغيّر أي شيء.
موقعان ونفق واحد وبادئة بعيدة تستجيب لبعض الوقت ثم تصمت. الغريزة أن نسمّي ذلك حلقة توجيه، وأحيانًا يكون ذلك بالضبط ما هو عليه. لكنّ الحلقة والمسار المتقلّب ينتجان الشكوى نفسها، ويحتاجان إلى إصلاحين متعاكسين: أحدهما قرار إعادة توجيه لا ينتهي أبدًا، والآخر بادئة تظل تغادر الجدول. ثلاث ملاحظات تفصل بينهما، ويمكنك جمع الثلاث من سطر أوامر البوابة قبل أن تلمس أي مرشّح أو تعيد تشغيل نفق.
تُحسم الحلقة قفزة بقفزة. يختار الموقع A الموقع B كقفزة تالية للوجهة، ويختار B الموقع A للوجهة نفسها، فتنتهي صلاحية الحزمة على TTL بعد رحلتين ذهابًا وإيابًا. أما التقلّب فيحسمه بروتوكول التوجيه بدلًا من ذلك: تُسحب البادئة أو تُعاد تثبيتها أو تُستبدل بقفزة تالية بديلة، فبعض الحزم لا مسار لها إطلاقًا بينما تتبع أخرى مسارًا سليمًا تمامًا.
الفحوص الثلاثة التي تحسم السؤال
لا تحتاج إلى التقاط حزم لتتخذ القرار الأول. تحتاج إلى حالة البادئة على الطرفين، وإلى القفزة التالية التي يختارها كل جانب، وإلى عدد قفزات يتكرّر أو لا يتكرّر. إذا بقيت البادئة مثبّتة بالقفزة التالية نفسها بينما يفشل المرور، فالحلقة تقيم في مسار إعادة التوجيه. وإذا اختفت البادئة وعادت، فالخلل أعلى من إعادة التوجيه، والإصلاح مكانه بروتوكول التوجيه لا مسار ثابت.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
تحذير واحد قبل أن تبدأ. إذا كنت تقرأ هذا عبر النفق الذي يدور، فإن جلستك تموت لحظة تغيير المسار. افتح طرفية أو مسار إدارة لا يعتمد على البادئة التي أنت على وشك إصلاحها.
الفحص الأول: هل البادئة مستقرة أم تتخبّط
اسأل النواة عمّا ثبّته، لا عمّا يَعِد به ملف الإعداد. على بوابة لينكس ينفّذ ip route get 10.20.30.40 البحث نفسه الذي ينفّذه مسار إعادة التوجيه، بما في ذلك جداول السياسات، بينما يعرض ip route show 10.20.30.0/24 الإدخال نفسه. أما ip monitor route فيبثّ كل تغيير لحظة حدوثه، وهو أسرع طريقة لمراقبة بادئة تصل وتغادر.
على موجّه يشغّل FRR أو BIRD، جدول إعادة التوجيه ليس هو المثير للاهتمام. يعيد show ip bgp 10.20.30.0/24 المسار المختار ومدة تشغيله؛ ومدة تشغيل تُعاد ضبطها كل بضع دقائق هي تقلّب يمكنك تسميته، لا حلقة. ويعرض show ip bgp summary حالة الجيران وأعداد البادئات، فيرفع عن مسار إعادة التوجيه اللوم عن نظير يظل يسقط.
اكتب الجواب قبل أن تغيّر أي شيء. الاستقرار عشر دقائق بينما فشلت اختبارات الاتصال، والاختفاء أربع مرات في عشر دقائق، يقودان إلى خطوتين تاليتين مختلفتين. الحالة الثانية تجعل كل نظرية عن المسار الثابت غير ذات صلة.
الفحص الثاني: هل تشير القفزة التالية رجوعًا إلى نفق الوصول
الحلقة تحتاج إلى بوابتين تتفقان. على الموقع الذي يستقبل الحزمة، انظر إلى المسار الذي ستستخدمه الحزمة للمغادرة: ip route get 10.20.30.40 from 10.10.5.20 مع عنوان المصدر الحقيقي، لأن قاعدة سياسة قد تجيب بشكل مختلف عن الجدول الرئيسي. ثم كرّر البحث على الموقع الذي أرسلها. إذا اختار كل جانب الآخر كقفزة تالية للبادئة نفسها، فقد أثبتت الحلقة ولن يضيف أي التقاط شيئًا.
السبب دائمًا تقريبًا إعلان ما كان يجب ألا يعبر النفق. المسار الافتراضي الذي يُعاد توزيعه في النفق، أو التجميع الذي يغطي شبكة الموقع البعيد الفرعية، أو مسار ثابت يشير إلى النظير على سبيل الاحتياط، كلها تخلق القفزة التالية التبادلية نفسها. قد يكون النفق قائمًا بالكامل ومع ذلك يحمل المرور في دائرة؛ وتشرح ملاحظات إعادة التوجيه في strongSwan الجانب الخاص بالتوجيه من هذا الشرط.
يستحق WireGuard ملاحظة خاصة، لأنه لا يوجد إعلان لإلقاء اللوم عليه. يسرد wg show نطاقات AllowedIPs لكل نظير، ولا تقبل النواة وجهة لنظير إلا إذا وقعت داخل ذلك النطاق. والحلقة هناك هي نطاق AllowedIPs متداخل أو مسار ثابت يشير رجوعًا عبر الواجهة، فالإصلاح مكانه هذان الموضعان ولا مكان غيرهما.
الفحص الثالث: اقرأ عدد القفزات، لا النجوم
يعرض traceroute -n -I 10.20.30.40 المسار كما يعرضه mtr -n -r -c 20 10.20.30.40، وغالبًا ينجو وضع ICMP من الترشيح الذي يبتلع مجسّات UDP. تبدو الحلقة كتسلسل قصير متكرّر من عنوانَي البوابة نفسيهما مع صعود TTL في كل مرة. أما السقوط فيبدو كنجوم بعد آخر بوابة أجابت، وقفزة صامتة واحدة ليست دليلًا على أي شيء.
عندما يكون المسار غامضًا، اقرأ TTL على السلك. يُظهر tcpdump -ni any -vv icmp على البوابتين TTL لكل حزمة وعنوان المصدر لكل رد بتجاوز المهلة. إذا وصلت حزمة إلى الموقع البعيد بـ TTL أقل من عدد القفزات التي يمكن أن يحتويها المسار، فثمة شيء يضيف قفزات لا يظهرها لك traceroute، وهذا يحدث عندما يجيب جدار حماية أحد الموقعين عن المجسّات نيابة عن الآخر.
أصلح مالك البادئة، ثم تحقّق من الاتجاهين
حدّد أي موقع يُنشئ الوجهة وأي مسارات عبور مسموح بها، ثم غيّر الإعلان أو المسار الثابت عند ذلك المالك. تصحيح الموقع المستقبِل مغري وعادةً خطأ: فهو يخفي الحلقة عن بادئة واحدة ويترك الإعلان السيئ مكانه للبادئة التالية. وسمات المسار وقوائم التوزيع وقواعد أفق الانقسام موجودة لإيقاف هذا عند المصدر، وهي أرخص من مرشّح يطابق بادئة واحدة.
بعد التغيير، تحقّق من الذهاب والعودة بشكل منفصل، لأن الحلقة قد تُستبدل بثقب أسود دون أي تحسّن مرئي في العَرَض. شغّل ip route get من الطرفين، وأرسل مرورًا من مضيف ليس البوابة، واترك ip monitor route يعمل لمؤقّت احتجاز واحد على الأقل حتى لا يُحسب التقلّب إصلاحًا.
قبل أن تغيّر أي شيء، أكّد هذه النقاط الخمس: البادئة مستقرة أو متخبّطة، والقفزة التالية على الطرفين تشير إلى نفق، وعدد القفزات يتكرّر أو لا، وموقع واحد يملك البادئة، وأنت تحتفظ بمسار إدارة يصمد أمام التغيير. إذا كان أي من الخمسة مجهولًا، فالأربعة الأخرى تخمينات.