الخلاصة

  • نحو الساعة 02:24 بالتوقيت العالمي في 6 نوفمبر 2012، لاحظت Cloudflare أن خدمات Google لا يمكن الوصول إليها من أجزاء من الإنترنت. وأظهر مسار نشرته أن الحركة مرت عبر AS4436 ثم PCCW/AS3491 ثم Moratel/AS23947 قبل أن تصل إلى الأصل الشرعي لـ Google، وهو AS15169 [1].
  • وصفت Cloudflare الاضطراب بأنه محدود واستمر نحو 27 دقيقة، وقدرت أنه ربما أثر في 3 إلى 5 في المئة من مستخدمي الإنترنت مع أثر أكبر حول هونغ كونغ. هذه تقديرات Cloudflare وليست إحصاء مستقلا شاملا [1].
  • أدرجت RFC 7908 لاحقا حادث Moratel-PCCW مثالا على تسريب من النوع الرابع: مسارات تعلمتها شبكة من نظير جانبي ثم أعلنتها إلى مزود عبور خارج النطاق المقصود [2].
  • رجحت Cloudflare أولا وجود إعلان خاطئ. وسجل تحديثها تصريح Moratel بأن عطلا غير متوقع في العتاد أنشأ الحالة الشاذة وأن الحدث لم يكن خبيثا [1]. ولا يحتوي السجل العام على أدلة داخلية تكفي لحسم تسلسل العطل بدقة.
  • تمتد المسؤولية إلى التصدير والاستيراد معا. كان على Moratel منع المسارات غير المصرح بها من مغادرة الجلسة، وكان على PCCW التمييز بين مسار عميل مسموح به ومسار تعلمه العميل عبر علاقة أخرى. كما كانت مهام الكشف والسحب وحفظ الأدلة واختبار الإصلاح مشتركة.

ما الذي يثبته السجل العام

قالت Cloudflare إن فريقها لاحظ قرب الساعة 02:24 بالتوقيت العالمي أن خدمات Google غير متاحة من شبكتها. بدت العلامة الأولى شبيهة بمشكلة DNS، لأن الوصول إلى محلل Google العام 8.8.8.8 فشل أيضا. لكن تتبع المسار أظهر انتقال الحركة عبر عنوان تابع لـ Moratel في إندونيسيا، وهو التفاف غير متوقع لحركة آتية من شبكة Cloudflare في كاليفورنيا ومتجهة إلى Google [1].

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

ذكرت Cloudflare أنها تواصلت مع زميل في Moratel. صُحح الإعلان الشاذ نحو الساعة 02:50، وعاد التوجيه إلى حالته الطبيعية بعد نحو ثلاث دقائق [1]. قصر المدة لا يلغي الأثر. قد تظل خوادم الوجهة سليمة، بينما يفقد مستخدمون بعيدون الوصول إليها بسبب خلل في المسار بين الأنظمة المستقلة. عندئذ قد تبحث فرق التطبيقات وDNS والدعم داخل أنظمتها رغم أن العطل الفعلي يقع في علاقة توجيه خارج سيطرتها المباشرة.

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

لماذا تصنفه RFC 7908 تسريبا من النوع الرابع

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

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

تعرف RFC 7908 تسريب المسار بأنه نشر إعلان توجيه خارج نطاقه المقصود. ويصف النوع الرابع نظاما مستقلا يعلن إلى مزود العبور مسارات تعلمها من نظير جانبي. وتذكر الوثيقة تسريب بادئات Google بين Moratel وPCCW مثالا صريحا على هذه الفئة [2].

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

واجب الإثبات على جانب التصدير

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

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

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

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

واجب القبول لدى المزود الأعلى

وصفت Cloudflare شبكة PCCW بأنها مزود العبور الأعلى لـ Moratel، وقالت إن PCCW وثقت بالمسارات المرسلة ونشرتها [1]. وتحدد بيانات RDAP الحالية AS3491 باسم PCCWG-APAC-HK وتربطه بـ PCCW Global (HK) Limited [6]. يدعم ذلك استمرارية هوية الكيان في الدليل، لكنه لا يثبت وحده كل بند تجاري أو دور جلسة كان قائما في 2012.

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

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

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

ما الذي تثبته سجلات الموارد الحالية وما الذي لا تثبته

تحدد بيانات APNIC RDAP الحالية AS23947 باسم MORATELINDONAP-AS-ID وتربط جهات الاتصال التشغيلية بـ PT. Mora Telematika Indonesia [5]. وتحدد بيانات RDAP الحالية لـ AS3491 الاسم PCCWG-APAC-HK وتربطه بـ PCCW Global (HK) Limited [6]. تساعد هذه السجلات على ربط أرقام الأنظمة المستقلة بهويات الشبكات الحالية.

لكنها لا تعيد بناء حادث 2012 كاملا. يستطيع سجل الموارد توثيق من يحمل أو يشغل رقما شبكيا وكيفية الاتصال بالجهة المسؤولة. ولا يظهر ما قبله جهاز توجيه عند 02:24، أو العلاقة التجارية المطبقة على الجلسة، أو نسخة المرشح النشطة، أو حالة العتاد التي تغيرت.

هذا هو سطح Heng.lu في المقال. السجل دفتر حسابات وحافظ للقيود، وليس بديلا عن الشبكة العاملة. دقة سجل ASN مهمة لهوية الموارد واستمرارية الاتصال والنقل، لكن حكم المساءلة يتطلب مطابقة تلك القيود مع المسار الذي عمل فعليا، والسياسة التي كان ينبغي أن تقيده، والأدلة التي احتُفظ بها بعد الإصلاح.

تظهر استجابة RIPEstat التاريخية للبادئة 8.8.8.0/24 أن AS15169 كان ظاهرا كأصل خلال اليوم المطلوب [4]. إلا أن دقة البيانات المعادة ثماني ساعات، فلا تستطيع إثبات المسار المتسرب القصير أو سحبه دقيقة بدقيقة. لذلك يعتمد المقال على مراقبة Cloudflare المعاصرة لمسار الحدث وعلى تصنيف RFC 7908 اللاحق، ويعامل استجابة RIPEstat كسياق تاريخي محدود فقط.

ضوابط يجب أن تفشل بصورة مغلقة

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

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

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

الضابط الرابع إشارات واعية بالعلاقة. حددت RFC 9234، التي صدرت بعد الحادث بوقت طويل، أدوار BGP وسمة Only-to-Customer. تساعد هذه الآليات على جعل حدود العلاقة قابلة للقراءة آليا وعلى اكتشاف المسارات التي تخالف قواعد الانتشار المتوقعة [3]. وهي سياق لضبط حديث، وليست دليلا على استخدامها لدى المشغلين في 2012.

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

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

شكل الإغلاق العام المفيد

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

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

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

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

لماذا يبقى الحادث مهما

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

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

الخلاصة الأقوى ضيقة. تدعم الأدلة العامة أن تسريب مسار بين Moratel وPCCW أثر في الوصول إلى خدمات Google في 6 نوفمبر 2012، وأن Cloudflare رصدت المسار وساعدت في تصعيده، وأن RFC 7908 صنفته لاحقا كتسريب من نظير إلى مزود عبور [1][2]. ولا تحسم الأدلة العامة تسلسل العطل الداخلي أو التوزيع النهائي للمسؤولية. هذه الفجوة هي واجب المساءلة نفسه: حفظ ما يكفي من حالة التشغيل لكي يمكن اختبار التفسير التالي بدلا من قبوله على الثقة.

المصادر

  1. https://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about/
  2. https://www.rfc-editor.org/rfc/rfc7908.txt
  3. https://www.rfc-editor.org/rfc/rfc9234.txt
  4. https://stat.ripe.net/data/routing-history/data.json?resource=8.8.8.0/24&starttime=2012-11-06T00:00:00&endtime=2012-11-07T00:00:00
  5. https://rdap.apnic.net/autnum/23947
  6. https://rdap.arin.net/registry/autnum/3491