توجيه السياسات في IPv6 عندما يشترك رابطان صاعدان في fe80::1

لديك رابطان صاعدان، و ip -6 route show يطبع النقطة التالية نفسها على كليهما: default via fe80::1 dev uplink0 و default via fe80::1 dev uplink1. هذا ليس تعارضًا في العناوين المكررة، ونسخ النقطة التالية المجردة fe80::1 إلى جدول سياسة لا يخبر النواة بأي ارتباط قصدت. السؤال الحقيقي أضيق مما يوحي به العَرَض: هل يحتاج الجدول الثاني إلى ارتباط واحد أم إلى كليهما، وما الذي يُبقي تلك المسارات حية بعد إعادة التشغيل. ثلاثة شروط، تُفحص بالترتيب، تحسم معظم ذلك.

النقطة fe80::1 نفسها جاران مختلفان

عناوين الارتباط المحلي محصورة في ارتباط واحد، لذا fe80::1 ليس عنوانًا واحدًا مطبوعًا مرتين؛ بل جاران يتشاركان لاحقة فحسب. مؤشر المنطقة هو طريقة المضيف في تحديد أيّهما يقصد، لذا fe80::1%uplink0 و fe80::1%uplink1 وجهتان مختلفتان بالنسبة للنواة، وتلك اللاحقة لا تنتقل أبدًا إلى موجّه بعيد. RFC 4007 يصف نموذج المنطقة الكامن وراء هذا، ولهذا يجب أن يحمل جدول السياسة جهازًا مع كل نقطة تالية محلية للارتباط.

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

أزل الجهاز تصبح المسار غير قابل للكتابة. ip -6 route add default via fe80::1 table 200 لا يستطيع تحليل البوابة، و iproute2 يرفضه بـ Error: Nexthop has invalid gateway. أضف dev uplink0 فينجح الأمر، لأن الجهاز هو ما يثبّت النقطة التالية على أحد هذين الجارين. ما لا يستطيع الجهاز إخبارك به هو ما إذا كان uplink0 هو الارتباط الصحيح لهذا الجدول، والمسار المنسوخ من مضيف آخر يجلب معه أسماء واجهات ذلك المضيف، ومن هنا تأتي الأخطاء الحقيقية.

الشرط الأول: ارتباط واحد أم اثنان في الجدول

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

في الحالة الثانية تحدد القاعدة متى يُستشار جدول، ويحدد المسار إلى أين تذهب الحزمة بعد ذلك:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

لا يغني أحد العنصرين عن الآخر، والجدول الذي يحمل مسارًا افتراضيًا فقط قد يفشل في تحليل بوابته. إذا رُفضت الإضافة، أو كان المسار موجودًا لكنه غير صالح للاستخدام، فضع البادئة المتصلة لتلك الواجهة في الجدول نفسه، أو علّم النقطة onlink عندما تكون تلك البادئة موجّهة في مكان آخر. في الكتلة أعلاه، تمثل 2001:db8:100::/48 تلك البادئة المتصلة على uplink1، وليس وجهة عشوائية. قاعدة fwmark لا تستهلك إلا علامة يجب أن يضعها شيء آخر، من قاعدة nftables أو iptables على مسار التمرير أو من SO_MARK على المقبس، لذا فكتلة منسوخة دون مصدر علامة لا تطابق شيئًا.

الشرط الثاني: المقاييس لا تكشف مزوّدًا ميتًا

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

تحقق من الاختيار بعد بناء الجدول، وتحقّق منه كما ستراه النواة. ip -6 route get 2001:db8:100::1 يطبع المسار الذي سيُستخدم، بما في ذلك الجهاز وعنوان المصدر المختار، وهو يحترم قواعد السياسة. عنوان مصدر ينتمي إلى الرابط الصاعد الخطأ هو العلامة المعتادة على أن قاعدة طابقت قبل ما توقعت.

الشرط الثالث: قرّر من يملك الاستمرارية

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

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

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

على موجّه يمرر حركة مضيفين آخرين، افحص net.ipv6.conf.all.forwarding قبل لوم الجدول. مع إيقاف التمرير، تُسقط الحزم الموجّهة إلى شبكة أخرى مهما كان الجدول 201 صحيحًا.

سجّل التصميم ليتمكن الشخص التالي من تدقيقه

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

قبل أن تعتبر الجدول منتهيًا، أكّد الجار بـ ip -6 neigh show dev uplink0، وأعد قراءة ip -6 rule show بحثًا عن حوادث ترتيب، واختبر بحركة تطابق القاعدة بدلًا من بينج يأخذ المسار الافتراضي. ثم أنزل رابطًا صاعدًا واحدًا عن قصد وراقب أي مسار ترتد إليه النواة؛ يجب أن تطابق الإجابة ما كتبته.