الخلاصة

  • قالت Cloudflare إن تعديلاً هدفه إزالة مراجع قديمة إلى قوائم بادئات خاصة بموقع بوغوتا أبقى في سياسة تصدير IPv6 المولّدة شرط route-type internal متبوعاً بالإجراء accept.
  • أدى حذف آخر قيد ضيق إلى توسيع مجموعة المسارات المؤهلة للتصدير، مع بقاء الإعداد الناتج قابلاً للاستخدام من الناحية التركيبية.
  • بدأ الأثر، وفق التسلسل الزمني المنشور، عندما شغّلت الأتمتة التغيير على موجّه واحد في ميامي عند الساعة 20:25 بالتوقيت العالمي، وانتهى الأثر العام بعد تراجع يدوي عند 20:50.
  • نسبت Cloudflare إلى الواقعة ازدحاماً بين ميامي وأتلانتا، وارتفاعاً في زمن الاستجابة، وفقداً أعلى لبعض حركة عملائها، وإسقاط حركة لا تخص الوجهات الواقعة باتجاه المصب، بلغ ذروته نحو 12 غيغابت في الثانية.
  • وصفت الشركة مسارات متعلَّمة من النظير Meta، ذي النظام المستقل AS32934، خرجت من AS13335 باتجاه مزود العبور AS3356؛ وهذا خلل في علاقة التصدير، لا إعلان منشأ زائفاً ولا اختطافاً للمسار.
  • أظهر استعلام محدود زمنياً في RIPEstat عدد 1,548 حدثاً، احتوى 1,440 منها على AS13335 وAS32934 معاً، بما يؤيد ظهور النمط على المجمعات العامة دون أن يثبت سبب الإعداد الداخلي أو مقدار الضرر.
  • لا تكفي صلاحية منشأ RPKI لمنع تسرّب علاقة إذا ظل النظام المستقل الأصلي مخولاً بإعلان البادئة؛ فصلاحية المنشأ ليست تصريحاً لكل مسار وسيط.
  • يجب أن تقارن تجربة أولية على موجّه واحد تغير مجموعة المسارات وتغير Adj-RIB-Out لكل جار قبل الإرسال، وأن تتوقف تلقائياً عند مخالفة علاقة نظير أو مزود أو عميل.
  • لا يكتمل التراجع بإصلاح الموجّه وحده؛ بل يجب تصحيح المصدر المولّد أيضاً، وتعليق الأتمتة، والتحقق خارجياً من السحوبات، ثم استئنافها تحت مسؤولية مسماة.

الواقعة التي ينبغي تحليلها، والوقائع التي ينبغي إبقاؤها خارجها

تنحصر هذه الدراسة في تسرّب مسارات IPv6 الذي قالت Cloudflare إنه بدأ من موجّه طرفي واحد في ميامي يوم 22 يناير 2026. لا يصح دمجه مع واقعة سحب بادئات BYOIP في فبراير 2026، أو حادثة 1.1.1.1 في يونيو 2024، أو مشكلة تهيئة تغييرات BGP في 2022، أو سحب 1.1.1.1 في 2025، أو أي تسرّبات تعود إلى مشغلين آخرين. هذه الحدود ضرورية لأن لكل واقعة آلية مختلفة، وسلسلة أدلة مختلفة، ومسؤوليات تشغيلية مختلفة.

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

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

تسلسل زمني دقيق للحدث والاستعادة

قالت Cloudflare إن تغيير المستودع دُمج عند الساعة 19:52 بالتوقيت العالمي يوم 22 يناير 2026. كان الغرض المعلن إزالة مراجع قديمة إلى قوائم بادئات مرتبطة ببوغوتا. لا يثبت وقت الدمج وحده أن الأثر بدأ فوراً، لأن المصدر النصي ليس هو السياسة الفعلية على الموجّه، ولأن الأتمتة لم تكن قد طبقت التغيير بعد.

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

بدأ التحقيق عند الساعة 20:40، ثم رُفعت الواقعة بوصفها حادثاً عند 20:44. عند 20:50 تراجع مشغل يدوياً عن سياسة الموجّه وأوقف الأتمتة مؤقتاً. وبذلك حدّدت Cloudflare نافذة الأثر العام بخمس وعشرين دقيقة، من 20:25 إلى 20:50، وقالت إن الأثر اقتصر على IPv6.

لكن نهاية أثر التوجيه لا تساوي نهاية الاستعادة الكاملة. ظل المصدر الذي ولّد الإعداد بحاجة إلى التصحيح. قالت Cloudflare إن تغيير المستودع أُعيد عند الساعة 21:47، ثم قرر المشغلون عند 22:07 أن الأتمتة عادت إلى حالة سليمة، وأزيل الإيقاف عنها عند 22:40. يفصل هذا التسلسل بين إصلاح الحالة الجارية على الموجّه، وإصلاح المصدر، وفحص الأتمتة، ثم الإذن باستئنافها. وهذه طبقات لا يجوز اختزالها في عبارة واحدة مثل «جرى التراجع».

كيف تحوّل تنظيف ضيق إلى تفويض تصدير أوسع

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

بحسب تفسير Cloudflare، بقي في البند المولّد شرط route-type internal. هذا التعبير لم يقتصر على المسارات التي كان التغيير يقصد التعامل معها، بل شمل مسارات غير خارجية، ومنها مسارات متعلَّمة عبر iBGP. ومع استمرار الإجراء accept، لم يصبح البند فارغاً بالمعنى الحرفي، بل صار ناقص القيود من الناحية الدلالية. سمح ذلك بتمييز مسارات IPv6 موزعة داخلياً وقبول تصديرها إلى نظراء ومزودي عبور في ميامي.

هذه هي نقطة المساءلة الأساسية. قد يبدو الفرق في المصدر صغيراً ومنطقياً إذا نُظر إليه كإزالة لمراجع لم تعد مستخدمة. وقد تجتاز السياسة الناتجة فحص البنية النحوية؛ فالأوامر قابلة للتفسير، والمصطلحات معروفة للموجّه، ولا توجد بالضرورة جملة مكسورة. لكن السؤال الحاسم ليس: «هل يقبل الجهاز الإعداد؟» بل: «ما مجموعة المسارات التي سيقبل هذا البند تصديرها بعد التغيير مقارنة بما قبل التغيير؟»

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

ثماني طبقات من الأدلة لا يجوز دمجها

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

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

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

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

الطبقة الرابعة هي Loc-RIB، أي مجموعة المسارات التي اختارها BGP محلياً. وجود مسار داخلياً لا يعني وجوب إرساله إلى جار خارجي، لكنه يحدد ما يمكن أن يصل إلى بوابة التصدير.

الطبقة الخامسة هي Adj-RIB-Out لكل جار. هذه أقرب صورة إلى ما أعده الموجّه للإعلان بعد تطبيق السياسة. يجب فحصها على مستوى الجار، والعائلة العنوانية، والبادئة، والمسار، والسمات ذات الصلة.

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

الطبقة السابعة هي حالة RIB وFIB وقياسات الحركة. لا يكفي أن يظهر مسار في بروتوكول التوجيه؛ يجب تمييز ما ثُبّت في جداول إعادة التوجيه، وكيف انتقلت الحركة، وما إذا ارتبط ذلك بزمن استجابة أو فقد أو إسقاط.

الطبقة الثامنة هي الملاحظة الخارجية عبر مجمعات المسارات. وهي تثبت ما رآه مراقبون خارج الشبكة، لكنها لا تكشف وحدها القالب الداخلي أو سبب قبول التغيير أو كل الأجهزة المتأثرة.

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

علاقة المسار أهم من صحة البادئة وحدها

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

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

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

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

مسارات النظراء والمزودين والعملاء والمشغل نفسه

يمكن تصميم القيود باعتبار كل مسار حاملاً لأصل تشغيلي، لا لمنشأ BGP فقط. فالمسار الذي أنشأه المشغل بنفسه يختلف عن مسار عميل يدفع للحصول على العبور، وكلاهما يختلف عن مسار نظير أو مزود.

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

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

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

النوعان الثالث والرابع في تصنيف RFC 7908

وصفت Cloudflare الواقعة بأنها مزيج من تسرّبَي المسار من النوعين الثالث والرابع وفق RFC 7908. يفيد هذا التصنيف في وصف الاتجاه غير المقصود لانتشار معلومات الوصول بين علاقات أنظمة مستقلة مختلفة.

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

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

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

مثال البادئة ومسار النظام المستقل

نشرت Cloudflare البادئة 2a03:2880:f077::/48 مثالاً، وذكرت مسار النظام المستقل 64112 22850 174 3356 13335 32934. يسمح هذا المثال برؤية AS13335 وAS32934 في المسار الذي ظهر خارج شبكة Cloudflare، مع AS3356 في السلسلة التي تعكس اتجاه الانتشار الموصوف نحو مزود العبور.

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

المسار العام دليل قوي على أن إعلاناً غير معتاد خرج إلى الخارج، لكنه لا يعيد بناء الحالة الخاصة للموجّه في ميامي. لذلك يجب أن يقترن ببيانات داخلية: الجار الذي أُخذ منه المسار، وسمات العلاقة التي حملها، والبند الذي قبله، والجار الذي أُرسل إليه، والفارق في Adj-RIB-Out، والتحديث المنبعث في اللحظة نفسها.

ماذا يثبت نطاق IPv6، وماذا لا يثبت

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

ومن ثم يجب التعامل مع «IPv6 فقط» كحد للواقعة المعلنة، لا كشهادة شاملة على تصميم العزل. في التحقيق الداخلي ينبغي تحديد سبب عدم تأثر IPv4 بالأدلة: هل لم يتغير المصدر الخاص به؟ هل لم يولد البند نفسه؟ هل كانت مجموعة المسارات مختلفة؟ هل توجد سياسة رفض مستقلة؟ الإجابة الموثقة أهم من النتيجة العرضية.

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

لماذا لم تكن تجربة موجّه واحد حاجزاً كافياً

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

يجب أن تسبق الإرسال مقارنة حقيقية بين الحالة القديمة والمرشحة. تبدأ المقارنة بمجموعة المسارات التي سيطابقها كل بند. ثم تحسب تغير Adj-RIB-Out لكل جار: ما البادئات الجديدة، وما المسارات المسحوبة، وما التغير في طول AS_PATH أو المجتمعات أو سمات العلاقة؟ بعد ذلك تطبق حدوداً صريحة، مثل الحد الأقصى لعدد البادئات الجديدة، أو حظر ظهور مسار تعلم من نظير في مخرجات مزود.

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

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

تصميم مقارنة مجموعة المسارات وAdj-RIB-Out

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

ينبغي تقسيم الفروق إلى إضافات وسحوبات وتغييرات سمات. كل إضافة تحتاج سبب سماح واضحاً. إذا كان السبب «البادئة موجودة في Loc-RIB» فقط، فهذا غير كاف؛ فـLoc-RIB يجمع مسارات قابلة للاستخدام محلياً، لكنه لا يمنحها جميعاً حق الخروج إلى كل جار.

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

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

الضرر المعلن وحدود نسبته

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

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

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

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

حدود RPKI والتحقق من صلاحية المنشأ

توفر منظومة RPKI وسيلة للتحقق من أن نظاماً مستقلاً مخول بإعلان بادئة ضمن حدود طول معينة. توضح RFC 6480 بنية الثقة، وتشرح RFC 6811 التحقق من منشأ المسار، بينما تحدد RFC 8210 التفاعل مع مخازن التحقق، وتقدم RFC 7115 إرشاداً تشغيلياً لاستخدام النتائج.

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

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

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

أدوار BGP وميزة OTC في RFC 9234

تقدم RFC 9234 آلية للتفاوض على أدوار BGP بين الجيران، وتعرّف سمة Only-to-Customer، المعروفة اختصاراً بـOTC. الفكرة التشغيلية هي تمثيل جانب من علاقة الاتصال داخل البروتوكول، بحيث يمكن اكتشاف أو رفض انتشار مسار يخالف نموذج العلاقة المتوقع.

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

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

كما لا تعفي الأدوار وOTC المشغل من تصحيح سياسته المحلية. إنها دفاع إضافي ضد خطأ العلاقة، لا بديل عن سياسة تصدير مقيدة وعن اختبار Adj-RIB-Out.

المجتمعات الموثوقة والترشيح الخارجي وASPA: أدوات مختلفة

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

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

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

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

دليل المجمعات العامة: ما الذي رآه الخارج؟

أُجري استعلام RIPEstat BGPlay محدود على البادئة 2a03:2880:f077::/48 من الساعة 20:24 إلى 20:52 بالتوقيت العالمي. أعاد الاستعلام حالة ok و1,548 حدث تحديث، واحتوى 1,440 حدثاً على AS13335 وAS32934 معاً في مسار النظام المستقل.

هذه النتيجة تؤيد أن نمط المسار الذي وصفته Cloudflare كان مرئياً خارج شبكتها خلال النافذة الزمنية ذات الصلة. وهي مفيدة لأنها لا تعتمد على لقطة داخلية اختارها المشغل وحده؛ إذ تعتمد على بيانات تجميع عامة رصدتها بنية RIPE RIS وأتاحها BGPlay.

لكن الأرقام لا تعني وجود 1,548 بادئة مختلفة أو 1,548 مستخدماً متأثراً. الحدث في بيانات BGP قد يكون إعلاناً أو سحباً أو تغيراً شاهده نظير تجميع، وقد تتكرر المشاهدات للمسار نفسه عبر نقاط مختلفة. كما أن وجود AS13335 وAS32934 معاً لا يثبت البند الداخلي الذي سمح بالتصدير.

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

استخدام المجمعات الخارجية في الوقاية والاستعادة

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

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

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

الاستعادة يجب أن تصلح مصدر الحقيقة والحالة الجارية

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

التسلسل المنشور يعكس هذه الثنائية. قالت Cloudflare إن مشغلاً أعاد سياسة الموجّه يدوياً وأوقف الأتمتة عند 20:50. ثم أُعيد تغيير المستودع عند 21:47. بعد ذلك قُيّمت صحة الأتمتة عند 22:07، ولم تُستأنف حتى 22:40.

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

ويجب إسناد قرار الانتقال بين هذه الحالات إلى مالك مسمى. عبارة «الأتمتة سليمة» لا تكفي من دون تحديد الاختبارات التي اجتازتها، والبيانات التي فُحصت، ومن أجاز الاستئناف. هذا لا يعني افتراض غياب تلك الأدلة لدى Cloudflare، بل يحدد ما يلزم لإثبات اكتمال الاستعادة.

اتجاهات العلاج المعلنة وحدودها

قالت Cloudflare إنها ستقيّم البنود الفارغة أو الخاطئة في CI/CD، وتضيف احتياطات تعتمد على مجتمعات BGP، وتتحقق من دعم الموردين لأدوار BGP وOTC، وتحسن الاكتشاف المبكر. تتوافق هذه الاتجاهات مع آلية الواقعة لأنها تستهدف المولد، ودلالة العلاقة، والدفاعات المستقلة، وسرعة الرصد.

مع ذلك، الالتزام باتجاه إصلاحي ليس دليلاً على التنفيذ اللاحق، والتنفيذ ليس دليلاً تلقائياً على الفعالية. لإثبات الفعالية يلزم إظهار أن الاختبارات تكتشف الحالة المحددة: حذف آخر قيد مع بقاء accept، واتساع مجموعة المسارات، وظهور مسار نظير في Adj-RIB-Out لمزود. كما يلزم اختبار حالات قريبة، مثل فقد مجتمع العلاقة أو اختلاف سلوك IPv4 وIPv6.

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

معيار عملي للمساءلة في أتمتة التوجيه

يمكن تحويل دروس الواقعة إلى بطاقة مساءلة عملية تتكون من أسئلة قابلة للإثبات:

  1. هل حُددت نية التغيير على مستوى الموقع والعائلة العنوانية والجيران وفئات المسارات؟
  2. هل أنتج المولد سياسة مرشحة خالية من بنود قبول فقدت آخر قيد ضيق؟
  3. هل حُسبت مجموعة المسارات التي يطابقها كل بند قبل التغيير وبعده؟
  4. هل قورنت السياسة المرشحة بالحالة الجارية الفعلية؟
  5. هل صُنفت المسارات حسب الجار المصدر وعلاقة العميل أو النظير أو المزود؟
  6. هل قورنت Adj-RIB-Out لكل جار، لا العدادات الإجمالية فقط؟
  7. هل توجد حدود توقف آلية لعدد المسارات ولانتهاكات العلاقة؟
  8. هل مُنع الإرسال حتى اجتاز الموجّه التجريبي فحص الفروق؟
  9. هل قورنت تحديثات BGP المنبعثة بالتوقعات؟
  10. هل جُمعت حالة Loc-RIB وRIB/FIB والحركة والفقد والإسقاط دون دمج دلالاتها؟
  11. هل تحقق مراقبون خارجيون من المسارات الجديدة والسحوبات؟
  12. هل أصلح التراجع الموجّه والمصدر وأوقف الأتمتة مؤقتاً؟
  13. هل حُدد مالك قرار الاستئناف ومعايير الصحة؟
  14. هل اختُبرت الدفاعات المستقلة، مثل قيود العلاقة وOTC والترشيح، بدلاً من الاكتفاء بوعد استخدامها؟
  15. هل بقيت الأدلة متاحة بعد الحادث بحيث يمكن إعادة بناء السلسلة كاملة؟

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