لماذا لا يستطيع مسار الشبكة الفرعية في AWS VGW اختيار نفق VPN واحد

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

طبقتان قيد اللعب: مسار VPC الذي يحدد البوابة، واختيار البوابة نفسها للنفق. والخلط بينهما ينتج تعديلات تبدو صحيحة في جدول المسارات ولا تحرّك حزمة واحدة.

طبقتان تبدوان كطبقة واحدة

يجيب مسار الشبكة الفرعية عن سؤال واحد: لهذه الوجهة، أي ارتباط؟ هدفه هو البوابة الخاصة الافتراضية، ومقياسه ينافس فقط مسارات أخرى في الجدول نفسه. لا شيء في ذلك المدخل يميّز النفق الأول من النفق الثاني، ولا الاتصال A من الاتصال B. البادئة الأكثر تحديدًا هي مطابقة وجهة مختلفة، وليست اختيارًا أدق للمسار.

تجيب البوابة عن السؤال التالي: بين الأنفاق التي تحتفظ بها لتلك البادئة، أيها يحمل حركة المرور الآن. يأتي ذلك القرار من صحة النفق وسمات BGP المستلمة من بوابة العميل، ولا يظهر أبدًا في جدول مسارات الشبكة الفرعية.

ما تقارنه VGW فعليًا

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

بين المسارات المؤهّلة للبادئة نفسها، تفضّل AWS مسار AS_PATH الأقصر. وعندما يتساوى مساران في الطول تقارن MED، رهنًا بالشرط الموثّق بشأن أول AS في المسار. اقرأ الترتيب المنشور بدلًا من الرواية الشائعة، لأن الرواية الشائعة تُسقط عادةً خطوة الصحة واستثناء المسار الثابت. ومن نتائج ذلك: ثلاثة تقديمات مسبقة على اتصال الاحتياطي تجعل الاتصال الأساسي أقصر تمامًا، وهذه هي الطريقة المعتادة للتعبير عن الأفضلية.

التقديم المسبق، ومتى لا يفعل شيئًا

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

تحقّق من المسار المستلم على جانب AWS بعد التغيير. فالتقديم المسبق الذي لم يغادر جهاز العميل أبدًا يبدو تمامًا كتقديم تجاهلته AWS.

المسارات الثابتة تتجاهل الحجة بأكملها

إذا كان الاتصال يستخدم التوجيه الثابت فلا يوجد AS_PATH لإطالته. توثّق AWS مسارات VPN الثابتة على أنها تتقدم على المسارات المتعلّمة عبر BGP للبادئة نفسها، لذا لا يتصرف التصميم المختلط كتصميم ديناميكي بالكامل. حدّد نوع التوجيه أولًا، ثم اختر آلية الأفضلية الموجودة له.

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

لماذا تكون بوابة العبور جوابًا مختلفًا

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

اختر النموذج قبل الآلية: نشط واحتياطي بأفضلية مثبّتة، أو نشط ونشط بـ ECMP.

ما يجب التحقق منه بعد الضبط

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

ثم نفّذ اختبار الفشل المعتمد وراقب المسار الباقي وهو يحمل الخدمة. فالأفضلية الموجودة في فرق إعدادات فقط ليست أفضلية بعد.