عندما تتغير بيانات السجل، لماذا قد تختفي شبكة تعمل بالفعل؟

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

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

قد تظل الوصلات المادية سليمة عندما يؤثر تغيير في السجل على قبول المسارات. تتبّع الأدلة وسياسة الجهة المتلقية.

اسأل أولًا: أي سجل تغيّر؟

بادئة IP هي كتلة من العناوين. ورقم النظام المستقل، أو ASN، يعرّف شبكة تتبادل المسارات مع شبكات أخرى. أما BGP فهو البروتوكول الذي تستخدمه هذه الشبكات للإعلان عن الوجهات التي تستطيع الوصول إليها.

توجد إلى جانب هذا التبادل أنواع عدة من السجلات. وهي تجيب عن أسئلة مختلفة:

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

عنوان بريد إلكتروني قديم لجهة اتصال لا يسحب مسار BGP مباشرة. أما غياب مسار عن مرشّح أنشأه مزوّد فقد يمنع ذلك المزوّد من قبوله. ووصف الحالتين بأنهما «بيانات سجل غير صالحة» يحجب الفرق المهم بينهما.

كيف يتحول سجل إلى مسار مرفوض؟

لنفترض وجود مزوّد يبني مرشّحات عملائه من بيانات IRR. إليك تسلسلًا ممكنًا للخلل:

1. يُحذف سجل مسار، أو تتوقف مجموعة مسارات العميل عن تضمينه.
2. لا يُدرج المزوّد ذلك المسار في عملية بناء المرشّح التالية.
3. يصل المرشّح الجديد إلى موجّهات المزوّد، فترفض إعلان العميل.
4. إذا لم يبقَ بديل قابل للاستخدام، يفقد الأشخاص المعتمدون على ذلك المسار إمكانية الوصول.

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

ما المعنى الفعلي للحالة «Invalid» في RPKI؟

عند التحقق من المنشأ، يُقارن المسار المُعلَن ببيانات تفويض جرى التحقق من صحتها. ويحدد RFC 6811 ثلاث نتائج:

• Valid — صالح: يوجد تفويض واحد على الأقل يغطي المسار، ويطابق رقم ASN للمنشأ، ويسمح بطول البادئة المُعلَنة.
• Invalid — غير صالح: توجد بيانات تفويض تغطي المسار، لكن لا يطابق أي منها الشرطين معًا.
• NotFound — غير موجود: لا توجد بيانات تفويض تغطي المسار.

مثلًا، قد يصبح مسار تعلنه الشبكة A في حالة Invalid إذا اختفى التفويض المطابق له بينما بقي تفويض يغطيه للشبكة B. وإذا لم يبقَ أي تفويض يغطيه، تكون النتيجة NotFound بدلًا من ذلك. و«Invalid» هنا نتيجة للتحقق من التوجيه، لا حكمًا على الملكية أو الشرعية المؤسسية. كما أن التحقق من المنشأ لا يصادق على كامل المسار الذي يدّعي إعلان المسار أنه مرّ به.

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

لماذا يفقد بعض الأشخاص الوصول قبل غيرهم؟

لا تستخدم الشبكات كلها المرشّحات نفسها أو المزوّدين أنفسهم أو البيانات نفسها في اللحظة نفسها. ويوضح RFC 7115 أن مخازن RPKI المؤقتة قد تحتفظ بصور مختلفة للبيانات، وأنه لا يوجد فاصل زمني موحّد ومضمون لوصول التحديثات إلى الموجّهات.

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

حدّد الحلقة المعطلة قبل إجراء مزيد من التغييرات

السؤال المفيد لاستعادة الخدمة سؤال محدد: أي نظام توقف عن قبول أي إعلان، ولماذا؟ ويمكن للمشغّل العمل مع المزوّد للإجابة عنه:

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

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

المشكلة الأعمق: الأدلة المفيدة قد تتحول إلى سلطة متركزة

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

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

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

الاستمرارية تحتاج إلى مسار خروج تستطيع الشبكات الأخرى استخدامه

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

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

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

استعد بينما لا تزال الخدمة تعمل

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

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

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