AWS Site-to-Site VPN إلى بوابة NAT: VGW مقابل Transit Gateway

يرسم الجميع المخطط نفسه في المرة الأولى: VPN إلى الـ VPC، ثم بوابة NAT إلى الإنترنت، انتهى. لكن AWS لا تدعم هذا المسار عندما تنتهي الـ VPN على بوابة خاصة افتراضية، والفشل صامت بما يكفي ليعيد الفريق بناءه أكثر من مرة. التصميم الذي يعمل يحتاج إلى Transit Gateway، وهو ما يغيّر البوابة وجداول التوجيه على الجانبين. قارن الشكلين قبل أن ترسم أي شيء.

الطوبولوجيا التي تبدو بديهية وغير مدعومة

وثائق بوابة NAT في AWS ترسم خطًا يفاجئ كل من بنى تصاميم بـ VPC واحدة فقط: لا يمكن توجيه الحركة من اتصال Site-to-Site VPN إلى بوابة NAT عبر بوابة خاصة افتراضية. ونوع البوابة التي تنتهي عليها الـ VPN هو ما يحدد وجود مسار ترجمة أصلًا. ويستمر الخطأ لأن حالة النفق UP ولأن نسخة EC2 في الشبكة الفرعية نفسها تصل إلى الإنترنت بلا مشكلة. ولا تختبر أي من الملاحظتين الاتجاه المعطوب.

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

البوابة الخاصة الافتراضية مقابل Transit Gateway

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

Transit Gateway هو محور إقليمي تظهر فيه الـ VPN وكل VPC فرعية وVPC للخدمات المشتركة كـ ارتباطات. وله جداوله الخاصة التي تختار الارتباط الذي يتلقى بادئة معينة.

هذا المحور هو ما يجعل الخروج المركزي ممكنًا: تهبط الـ VPN كارتباط، وتهبط VPC الخروج كارتباط آخر، ويرسل جدول توجيه الـ Transit Gateway البادئات المتجهة إلى الإنترنت من الأول إلى الثاني. أما مع بوابة خاصة افتراضية فلا يوجد ارتباط ثانٍ لإرسال أي شيء إليه، ولهذا لا يمكن ترقيع التصميم ليصبح موجودًا.

مسار الخروج المدعوم، خطوة بخطوة

للتصميم المرجعي خمس قفزات، وكل سهم قرار توجيه عليك إعداده. تخرج الحركة من شبكة الموقع المحلي إلى ارتباط Site-to-Site VPN، ثم يمرّرها جدول Transit Gateway إلى ارتباط VPC الخروج، حيث يرسلها جدول الشبكة الفرعية إلى بوابة NAT عامة. وتترجم بوابة NAT المصدر، وتحمل بوابة الإنترنت الحزمة إلى الخارج.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

تفصيلان يحددان نجاح القفزات الأخيرة: يجب أن تكون بوابة NAT عامة، بعنوان IP مرن ومسار إلى بوابة إنترنت، لأن بوابة NAT الخاصة تترجم بين الشبكات ولا تصبح مخرجًا للإنترنت أبدًا.

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

مسار العودة هو حيث تفشل هذه التصاميم

بوابة NAT تحتفظ بحالة التدفقات التي رأتها، فتعود ردود الاتصال الصادر بلا قاعدة واردة جديدة. لكن هذه الخاصية لا تنشر خدمة محلية على الإنترنت، والتعامل معها على هذا الأساس هو ما يجعل فريقًا يقضي يومًا في تصحيح اتصال لم يكن لينشأ. ولحركة يبدأها العميل يجب أن تتفق أربعة مسارات: سياسة الموقع المحلي، وجدول Transit Gateway، وجدول شبكة الخروج الفرعية، وجدول شبكة NAT الفرعية. وإن غاب الأخير خرج الطلب بينما يموت الرد داخل AWS.

تحقّق بعميل حقيقي خلف الـ VPN وافحص عنوان المصدر العام الذي يظهره. فإن كان عنوان IP المرن لبوابة NAT فالترجمة تحدث؛ وإن كان غيره فأنت تقيس خروجًا آخر.

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

متى يكون الوكيل الصريح التصميم الأفضل

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

لكنه ليس شفافًا: كل ما يتجاهل إعدادات الوكيل، وكل بروتوكول ليس HTTP، لن يسلك ذلك المسار.

يتوقف الاختيار على ما تتحدثه تطبيقاتك فعلًا ومقدار الهوية التي تحتاجها في السجلات. حيث تتحدث HTTP يستحق الوكيل مكانه؛ وحيث تحتاج خروجًا عامًا لبروتوكولات عشوائية فتصميم Transit Gateway هو ما تدعمه AWS. والحسم مسبقًا أرخص من اكتشافه بعد بناء جداول التوجيه.