الخلاصة

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

الموجّه اختبر طريق العودة

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

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

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

المسارات البديلة تحتاج إلى انتشار متسق

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

لكن القائمة لا تمثل كل طريق يمكن أن تسلكه الحزمة. تشترط RFC 3704 أن تصل إعلانات المسارات ذات الصلة باتساق إلى كل موجّه يجري الفحص. وقد تظهر البادئة لدى مزود ولا تصل إلى آخر بسبب سياسة توجيه أو route-map. إذا حُجب الإعلان فقد تُحجب الحزمة أيضاً. وهكذا يعتمد إعداد محلي ظاهرياً على قرارات تحكم موزعة بين نطاقات إدارية.

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

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

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

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

المصادر