شبكة VPN السحابية تحتاج إلى BGP: لماذا تفشل بروتوكولات التوجيه الأخرى

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

النفق قائم والمسار مفقود

اكتمال المرحلتين 1 و2 يثبت أن الطرفين يتفقان على الحماية، لا أن أيًا منهما يعرف أين يرسل حركة المرور. فهذان جهازا حالة منفصلان بأنماط فشل منفصلة.

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

ما يمنحك المزوّد إياه فعليًا

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

توثّق Google Cloud التوجيه الديناميكي بـ BGP لخدمة HA VPN، حيث يتعلم Cloud Router مسارات الأقران ويورّد مسارات ديناميكية مخصصة مؤهلة إلى VPC. وتوثّق AWS Site-to-Site VPN خيارًا بين التوجيه الثابت والديناميكي، وتصف فحوص حيوية BGP بأنها مفيدة لتجاوز فشل النفق مع دعم فحوص الصحة أيضًا للأجهزة التي لا تدعم BGP. ولا ينبغي استنتاج سلوك أي منصتين من اسم منتج الأخرى.

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

حماية النفق وقابلية الوصول مهمتان منفصلتان

يحمي IPsec حركة المرور المختارة للنفق. ويوفّر BGP معلومات قابلية الوصول التي تجعل البادئة مؤهلة. والنفق العامل لا يثبت أن البادئة المتوقعة أُعلنت أو قُبلت أو ثُبّتت.

تخيّل فرعًا يُعلن 10.42.0.0/16 عبر مساري نفق مؤهلين. أزل مسارًا صالحًا للاستخدام، فقد يتغيّر اختيار المسار دون أن يحرّر أحد مسار كل حمل عمل. الكشف واختيار المسار وتعافي التطبيق ليست لحظية، وليست متطابقة بين عمليات النشر، لذا على اختبار تجاوز الفشل أن يراقب التسلسل كاملًا لا أول حزمة تعبر.

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

أين تنهار افتراضات OSPF

إن تشغيل OSPF أو IS-IS أو أي بروتوكول آخر داخل نفق IPsec ممكن تمامًا على جهاز مُدار ذاتيًا تملك فيه الطرفين وتصميم إعادة التوجيه. وهذه الحقيقة لا تقول شيئًا عن خدمة مُدارة تقدّم BGP وحده نمطًا للتوجيه الديناميكي.

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

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

اقرأ متطلب الخدمة ثم صمّم

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

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

أبقِ عقد الخدمة مع سجل التغيير. وحين يسأل أحد لاحقًا لماذا لا يستطيع النفق تشغيل OSPF، فالجواب حدّ منتج لا قيد بروتوكول، وينبغي أن يذكر السجل ذلك.