أضف شبكة فرعية محلية إلى AWS VPN: VGW مقابل Transit Gateway

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

انشر بادئة تستطيع البوابة تسليمها فعليًا

تحتاج البوابة المحلية إلى مسار متابعة نحو الشبكة الجديدة قبل أن يكون أي إعلان ذا معنى. إعلان 10.70.0.0/16 عبر BGP يخبر AWS أين ترسل الحزم لهذا النطاق؛ لكنه لا ينشئ مسار التحويل المحلي الذي يجعل النطاق قابلًا للوصول في الطرف الآخر. تأكد من أن البوابة لديها مسار للبادئة يشير إلى الجهاز الذي يحتفظ بها، وأن الجهاز مُهيأ للرد على تلك العناوين. سياسة التصدير وحدود البادئات المقبولة هي القيد التالي، لأن البادئة التي تُصفّيها الجلسة لا تصل إلى AWS إطلاقًا.

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

المسار الأول: حد البوابة الخاصة الافتراضية

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

جلسة BGP سليمة تثبت وجود القناة. ولا تقول شيئًا عن كون جدول شبكة فرعية معين قد استهلك المسار.

المسار الثاني: بوابة Transit تضيف جدولًا

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

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

انتشار المسار لا يمنح كل ارتباط البادئة أيضًا. إنه يوزعها على الجداول المهيأة لاستقبالها.

مسار الإرجاع قرار سياسة مستقل

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

تداخل العناوين هو الفخ الآخر. النطاقات المنفصلة والمملوكة صراحةً تبقي الأمر بسيطًا؛ أما النطاقات المتداخلة فتعني ترجمة أو إعادة تصميم، وليس أي منهما بديلًا متكافئًا للوصفة نفسها.

اختبر بمصدر في الشبكة الجديدة ووجهة في الشبكة الفرعية للتطبيق، ثم كرر في الاتجاه الآخر. اختبار باتجاه واحد يثبت اتجاهًا واحدًا.

متى يكون الوكيل الحد الأفضل حقًا

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

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