لماذا لا تظهر جلسة BGP في جدول توجيه VPC

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

هناك أمران مختلفان يُخلطان هنا: الاقتران بخادم توجيه، وتثبيت المسارات في جدول.

الأسطورة: شغّل BGP وستتعلم VPC البادئات

BGP محادثة بين طرفين، وفي هذا التصميم الطرفان هما برنامج التوجيه على جهازك ونقطة نهاية VPC Route Server التي تضعها AWS في شبكة فرعية تملكها. تلك المحادثة تحمل البادئات. وهي لا تمس جدول توجيه الشبكات الفرعية لأحمال العمل، لأن تلك الجداول لا تتعلم إلا عبر نشر يجب تفعيله على كل منها. وإلى أن يحدث ذلك، لا تعرف بنية VPC شيئًا عما يعرفه الجهاز.

خطوات الإعداد منفصلة لسبب: الاقتران، وإنشاء نقطة النهاية، والاقتران بالنظير، ثم تفعيل النشر.

Route Server مستوى تحكم، وليس نفقًا

لا يقوم Route Server بتشفير حزمة واحدة أو تمريرها أو فحصها. إنه موجود لتبادل BGP مع الجهاز وتسليم البادئات الناتجة إلى جداول التوجيه المهيأة لاستقبالها. مستوى البيانات لم يتغير: الحزم ما زالت تخرج عبر واجهة شبكة الجهاز، وتسافر في نفق VPN الخاص به، وتعود بالطريق نفسه.

هذا يعني أن فحص المصدر والوجهة على نسخة التمرير ما زال مهمًا، لأن النسخة تمرر الآن حركة موجهة إلى شخص آخر.

مجموعات الأمان وضوابط الشبكة الفرعية ما زالت تنطبق على التدفق الممرر أيضًا. لن يجعل Route Server جهازًا يُسقط الحركة يمررها، ولن يصلح مسار عودة مفقودًا على الطرف البعيد.

النشر لكل جدول توجيه، لا لكل VPC

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

افحص الجدول الفعّال للشبكة الفرعية المحددة بدلًا من قائمة البادئات التي يعلنها الجهاز. واجهة API تجيب عن هذا السؤال مباشرة: aws ec2 associate-route-server و aws ec2 enable-route-server-propagation --route-table-id <id> هما الخطوتان اللتان ينساهما الناس، و aws ec2 describe-route-tables --route-table-ids <id> تُظهر ما إذا وصلت البادئة كإدخال route server أصلًا.

الجهاز ما زال يحمل كل حزمة

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

اربط الإعلان بالمسار البعيد الحقيقي: أعلن البادئة عندما يكون النفق والشبكة البعيدة يعملان، واسحبها عندما لا يعملان.

اسحب بادئة وراقب ما يحدث

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

نقل مسار إلى جهاز ثانٍ لا ينقل الجلسات التي كان يحملها، لأن حالة NAT والجدار الناري تبقى مع الجهاز الأول.

لمجموعة ثابتة من بادئات تعد بالعشرات، تبقى المسارات الثابتة في جداول VPC الجواب الأرخص. ويستحق Route Server مكانه عندما تتغير قائمة البادئات فعليًا وتكون سياسة السحب شيئًا يمكنك شرحه للشخص المناوب.