لماذا يحتاج مشغلو الشبكات إلى تفويض مصدر المسار (ROA)

يربط تفويض مصدر المسار كتلة عناوين بشبكة مسموح لها بالإعلان عنها. لكنه لا يضمن الرحلة بأكملها.

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

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

ابدأ بالإعلان الذي تنوي إصداره

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

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

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

النشر والتحقق مهمتان منفصلتان

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

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

نفّذ التغيير بالترتيب الصحيح

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

لا توجد لحظة موحدة ترى فيها جميع الموجهات سجلًا جديدًا. فلنشر RPKI والتحقق منها وتحديث الموجهات توقيتات خاصة بها؛ وتقليل قيمة TTL في DNS لا يتحكم فيها. وتناقش RFC 7115 الاختلافات التشغيلية المتعلقة بذاكرات التخزين المؤقت والتحديثات.

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

واصل إجراء الفحوص الأخرى

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

ينبغي أن يخدم الأمن القائمين على تشغيل الشبكة

يرى لو هينغ في الملاحظة 28 أن حفظ السجلات الضروري يجب ألا يتحول إلى عقاب تقديري. فالتفويض الموقّع المفيد إقرار تقني، وليس تفويضًا بلا حدود للمؤسسة التي تتولى إدارة السجلات المحيطة به.

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

تابع قراءة لماذا يتغير رقم ASN المصدر لبادئة IPv4 للتمييز بين تغيير التوجيه وتغيير الحائز.