RIPE صارت تُدرّس منع تسريب المسارات. وهذا سبب أهميته.
صار منهج RIPE NCC لأمن توجيه BGP يتضمن نظرية منع تسريب المسارات واكتشافه استنادًا إلى RFC 9234، إلى جانب مختبر عملي لإعداد BGP Roles واستكشاف Only-To-Customer. 1
وحين يُدرِج السجل الإقليمي شيئًا في منهجه المعتاد، يكون قد انتقل من اقتراح تجريبي إلى ممارسة تشغيلية موصى بها.
الفجوة التي يتركها RPKI
كتبنا الأسبوع الماضي عن الحد الذي يتوقف عنده RPKI. ويستحق القيد الأساسي التكرار: RPKI لا يُنهي تسريبات المسارات.
فتسريب المسار ليس مصدرًا مزوَّرًا. المصدر مشروع والتفويض يجتاز التحقق بلا شائبة. المشكلة في الانتشار. إذ تتلقى شبكة مسارًا من قرين أو مزود أعلى ثم تعيد إعلانه إلى جهة أخرى لم يكن ينبغي أن يصلها. وفجأة تعلن شبكة إقليمية صغيرة نفسها طريقًا إلى أجزاء واسعة من الإنترنت، فتتبعها حركة البيانات، لأن BGP يصدّق ما يُقال له.
وتاريخيًا تسببت تسريبات المسارات ببعض أكبر حوادث التوجيه العالمية المسجلة، وهي في الغالب الأعم حوادث عرضية: مرشّح ناقص، أو سياسة طُبِّقت على الجلسة الخطأ، أو قالب نُسخ عن جار آخر.
ولا يرى RPKI شيئًا من ذلك، لأن كل إعلان في السلسلة له مصدر صالح.
Roles وOTC باختصار
يأخذ RFC 9234 ما يعرفه الجميع أصلًا بصورة غير رسمية — هذه الجلسة مع عميل، وتلك مع مزود أعلى، وثالثة مع قرين — ويجعله صريحًا داخل البروتوكول نفسه. 2
فتضبط على كل جلسة eBGP دورًا: provider أو customer أو route server أو route server client أو peer. وتُتبادل إمكانية Role في رسالة OPEN، فيؤكد الطرفان طبيعة العلاقة ويرفضان الإعدادات غير المتوافقة. ومتى عُرفت الأدوار، أتاحت خاصية Only-To-Customer، وهي خاصية مسار اختيارية عابرة، للموجّهات أن تُعلّم وتكتشف الإعلانات التي ذهبت حيث لا تسمح العلاقة التجارية. 2
وجمال الفكرة أنها تضيف تحققًا على مستوى البروتوكول إلى مسألة ظلت دومًا مسألة ترشيح. فمنع التسريب بالطريقة التقليدية يعني الاحتفاظ بمرشّحات بادئات دقيقة لكل جار، وهو عمل هائل وعرضة للخطأ ومتأخر دائمًا. أما Roles وOTC فتتيح للموجّهات المتوافقة اكتشاف كثير من التسريبات بنيويًا، انطلاقًا من العلاقة نفسها، فتقلّ الحاجة إلى مرشّحات لكل جار على حدة.
تقلّ لا تنعدم. فـ RFC 9234 يقف إلى جانب ضوابطك القائمة لا بديلًا عنها، وتبقى بحاجة إلى الترشيح عبر IRR، والتحقق من المصدر عبر RPKI، وحدود max-prefix، وترشيح bogon. وما يزول هو افتراض أن تلك المرشّحات هي كل ما يفصل بين سياسة كُتبت بخطأ مطبعي وبين تسريب.
كما أن نشره سهل نسبيًا: بضعة أسطر لكل جلسة في BIRD أو FRR أو JunOS، ويتراجع بسلاسة حين لا يدعمه الطرف الآخر.
التحكم الذي نمنحه للعملاء
نشغّل AS210464، وموقفنا أن العميل يجب أن يستطيع التحكم في توجيهه دون فتح تذكرة.
ويبدأ ذلك بالتحقق عبر RPKI من المسارات التي نقبلها، أي التحقق من المصدر بوصفه الحد الأدنى. ثم تأتي مجموعة كاملة من مجتمعات BGP تمنحك ضوابط «على شكل التسريب» مباشرة داخل إعلاناتك: لا تعلن لنظام مستقل بعينه، ولا للعملاء، ولا للأقران المباشرين، ولا لأقران نقاط التبادل، ولا لخوادم المسارات، ولا للمزودين الأعلى، إضافة إلى ضوابط إقليمية، وprepend من مرة إلى ثلاث، وlocal-preference للمسارات الاحتياطية، والتوجيه إلى الثقب الأسود عن بُعد حين تحتاج إسقاط البادئة على حافتنا لا على خادمك.
وتوجد هذه المجموعة لأن نطاق الإعلان ينبغي أن يكون قرارك أنت، معبّرًا عنه داخل الإعلان ذاته، لا مرشّحًا يتولاه أحدهم عندنا يدويًا ويخطئ فيه يومًا ما.
تبدأ جلسات BGP من €5 شهريًا. ومع كل جهاز افتراضي يأتي نطاق /48 من IPv6 قابل للتوجيه؛ وإن كنت تحتاج مساحة للإعلان لا للاستخدام فقط، فإما تحضرها أو تستأجرها منا. وتُقام الجلسات مقابل عناوين بوابة محلية، 10.0.0.1 وfd10::1، مع تفعيل multihop من جهتك بقيمة TTL تساوي 255، ويمكنك التحقق مما تراه موجّهاتنا فعلًا عبر looking glass من تيرانا أو سكوبيه أو أمستردام أو دبلن، دون حساب ودون مكالمة مبيعات.
ثلاثة أمور تستحق بعد ظهر يوم
إن كنت تشغّل BGP، فابدأ بضبط الأدوار على جلسات eBGP، وابدأ بالمزودين الأعلى، حيث يُحدث التسريب أكبر ضرر.
وما دمت هناك، راجع تفويضاتك. فالأخطاء التشغيلية، مثل التفويضات القديمة وقيم maxLength السخية أكثر من اللازم، تبقى من أكثر أسباب الإعلانات غير الصالحة وفق RPKI شيوعًا، ولذلك يبقى حادث التوجيه الأرجح في مستقبلك هو الذي تتسبب به أنت.
وادرس منهج RIPE إن كنت في المنطقة. فالمختبرات أسرع طريقة للتآلف مع الأدوار ومع OTC.
تبقى تسريبات المسارات من أنماط أعطال الإنترنت القليلة التي تستطيع فيها جلسة واحدة مضبوطة خطأً أن تُضعف الخدمة لشبكات لم تسمع بك قط. والحل اليوم قياسي ويُدرَّس ورخيص. ولم يبقَ من الأعذار الكثير.