إعلانات BGP عبر البوابة الافتراضية مقابل جدول مسارات VPC: ما الذي يغيّر ماذا

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

سمِّ المرفق قبل أن تقرأ أي جدول

ينتهي VPN من موقع إلى موقع إما عند بوابة افتراضية خاصة وإما عند بوابة عبور، ومعرّفات الموارد تحدد نموذج التوجيه المطبق. اقرأها أولًا: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. تجيبك النتيجة عمّا إذا كان الجدول التالي الذي يجب فحصه هو جدول مسارات VPC أم جدول مسارات بوابة العبور.

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

اتجاه AWS إلى المكتب إعلان

بالنسبة لمرفق VGW، تعلن البوابة كتل CIDR المرتبطة بـ VPC الخاص بها إلى بوابة العميل عبر BGP. إضافة مسار شبكة فرعية فردي، أو توجيه مسار نحو VPC مقترن أو نحو جهاز، لا يضيف CIDR مرتبطًا آخر ولا يظهر في ذلك الإعلان. إذا كانت البادئة مفقودة في المكتب، فقارن قائمة المسارات المستلمة بارتباطات VPC قبل تحرير أي جدول مسارات.

للقاعدة البسيطة استثناءات، فاحصرها في نطاقها. يمكن لترتيب VPN CloudHub أن يعيد إعلان بادئات المواقع بين بوابات العميل، ولبوابة العبور قواعد نشر خاصة بها. القول إن VGW تعلن VPC الخاصة بها وحدها افتراض مفيد، وليس قانونًا يغطي كل بنية ستصادفها.

اتجاه المكتب إلى AWS هو نشر زائد اختيار

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

اقرأ الأصل بدلًا من افتراضه: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. الإدخال الذي أصله EnableVgwRoutePropagation جاء من BGP؛ والإدخال الذي أصله CreateRoute كتبه إنسان وسيظل يفوز حتى يحذفه أحد.

دليل تشغيل يبقي الاتجاهين منفصلين

سجّل أربع حقائق على جانب AWS قبل تغيير أي شيء: نوع المرفق، وكتل CIDR المرتبطة بـ VPC، وأصل مسار الشبكة الفرعية للبادئة المعنية، وحالة النفق وBGP. تعيد نداء describe نفسه VgwTelemetry مع عدد المسارات المقبولة لكل نفق، وهو ما يخبرك هل قبلت AWS أي مسارات أصلًا. ثم قارن ذلك بما ثبّته جهاز العميل فعليًا. البادئة الموجودة في BGP والغائبة عن جدول إعادة التوجيه مشكلة استيراد محلي أو أفضل مسار، وليست مشكلة جدول مسارات AWS.

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

ما لا يجب تغييره أثناء وجودك هناك

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

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

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