سياسة جدار الحماية في EVPN: البوابة المركزية مقابل IRB الموزع
البوابات المركزية تمرر حركة المستأجرين عبر جدار الحماية، أما IRB الموزع فلا. قارن أين يفحص كل منهما، وما يحتاجه المسار السريع.
يضع تصميمان لشبكة EVPN بوابة المستأجر في مكانين مختلفين، ويرى جدار الحماية حركة مختلفة في كل منهما. مع بوابة مركزية تصل حركة ما بين الشبكات الفرعية إلى جدار الحماية لأن التوجيه يحدث هناك. ومع IRB الموزع توجّه مفاتيح leaf محليا ولا يرى جدار الحماية شيئا ما لم تدخله عمدا. لا أحد النموذجين خطأ. الخطأ هو تعليق جدار حماية عند الحدود وافتراض أن الفابريك ستوصل الحركة إليه.
نموذجان، نقطتا فحص مختلفتان
سمِّ التدفقات التي تحتاج إلى فحص أولا، لأن النموذجين يعالجانها بشكل مختلف.
| Flow class | Centralized gateway | Distributed IRB |
|---|---|---|
| Same subnet | Bridged, not routed | Bridged, not routed |
| Inter-subnet | Routed at the firewall | Routed at the leaf |
| Inter-VRF | At the firewall | Needs leaking or service insertion |
| External | Border firewall | Border firewall |
حركة الشبكة الفرعية نفسها هي الصف الذي ينساه الناس. يتحدث مضيفان على VLAN واحد عبر الجسر، ولا يقف أي جدار حماية موجّه في ذلك المسار ما لم يعترضه تصميم فحص منفصل للطبقة 2. وهذا صحيح في النموذجين، لذا هو ثغرة في التصميم لا مقارنة بينهما.
الصفوف الثلاثة الأخرى هي حيث يختلف النموذجان فعليا.
البوابة المركزية: فحص بسيط وكلفة عبور حقيقية
أبقِ شبكات VLAN الخاصة بالمستأجر كـ خدمات الطبقة 2 وضع بوابات التوجيه الخاصة بها على جدار الحماية. تنتقل حركة ما بين الشبكات الفرعية بعد ذلك إلى تلك البوابة ثم تعود، وربما حتى عندما يكون المضيفان على الـ leaf نفسه. نقطة الفحص لا لبس فيها، وهي الحجة الكاملة لهذا التصميم. الكلفة هي حمل العبور على جدار الحماية إضافة إلى اعتماد مركزي على السعة والتوافر عليك هندسته الآن.
احصر التغيير في بوابات المستأجرين التي تقصدها. إزالة كل عنوان VLAN أوسع من اللازم حين تكون لواجهات الإدارة والـ underlay والمنصة مهام منفصلة. تحقق أيضا من وجود بوابة نشطة ثانية، لأن بوابة لا تزال توجّه حول جدار الحماية تبطل التصميم بهدوء.
هذا النموذج أسهل في الشرح للمدقق. وهو ليس أرخص في التشغيل تلقائيا.
IRB الموزع: مسار سريع بلا فحص افتراضيا
مع بوابات anycast الموزعة، يوجّه كل leaf حركة المستأجر محليا، ويشرح RFC 9135 لماذا يتجنب ذلك إعادة الحركة إلى بوابة مركزية. الفائدة حقيقية، ولها نتيجة مباشرة: لا يمكن استنتاج الفحص من مكان توصيل جدار الحماية. جدار الحماية الموصول بـ leaf حدودي يرى الحركة الخارجية وكل ما تعيد توجيهه إليه صراحة.
أدخل الخدمة بآلية تدعمها المنصة فعليا: إعادة توجيه قائمة على السياسة، أو عقدة خدمة، أو توجيه مضبوط بين شبكات VRF عبر جدار الحماية. طابق الحركة المقصودة عند نقطة دخولها الحقيقية. السياسة المكتوبة على واجهة مواجهة للمضيف لا تغطي حزمة قادمة من الـ overlay.
اقرأ المسارات المثبتة لا المسار الافتراضي المقصود. قد يتجاوز بادئة مستأجر أكثر تحديدا مستوردة مباشرة المسار الافتراضي الذي يشير إلى جدار الحماية، ولن يبدو شيء في التكوين خاطئا.
التناظر خاصية توجيه، وليس ضمانة فحص
يصف IRB المتناظر كيف تتعامل عقد provider edge الداخلة والخارجة مع التوجيه والجسر لتدفق ما. ولا يقول شيئا عن وصول الاتجاهين إلى الجهاز نفسه ذي الحالة. تؤثر ECMP وanycast والتوافر العالي لجدار الحماية جميعا في العقدة التي ترى حركة العودة، ويقرر نموذج الحالة المدعوم في العنقود ما إذا كان ذلك مقبولا.
تتبع مسار العودة صراحة لكل تدفق يهمك. NAT ليس بديلا شاملا عن ذلك العمل، والتصاميم التي تتكئ عليه تجد الثغرة عادة أثناء تجاوز الفشل لا أثناء البناء.
امشِ عبر تدفق مطلوب واحد وتدفق مستبعد عمدا، في الاتجاهين، قبل اعتماد التصميم.
كيف تختار، وما يجب اختباره في كل حال
اختر البوابة المركزية حين تكون تغطية الفحص أهم من سعة العبور وتستطيع تحمل الاعتماد المركزي. واختر IRB الموزع حين يكون التوجيه المحلي هو الهدف، ورصد ميزانية لإدخال خدمة صريح بدل افتراضه.
ثم اختبر التوجيه الذي ثبّتته فعلا، لأن هنا يختلف التصميمان أكثر ما يختلفان:
show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefixأدرج فشل عقدة الخدمة وتعافيها في الاختبار. المسار الاحتياطي الذي يتجاوز الفحص بهدوء قرار مختلف عن سياسة fail-open مخطط لها، وعادة يقصد واحد منهما فقط. يسمي التصميم النهائي أين يوجّه كل صنف من الحركة، وأين يفحص، وماذا يحدث عندما يكون مسار الفحص هذا غير متاح.