شبكة VPN واحدة من موقع إلى موقع لعدة VPCs على AWS Transit Gateway

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

مرفق الـ VPN ومرفقات الـ VPC كائنات منفصلة على البوابة نفسها، ولهذا يجب بناء علاقات التوجيه بعد ذلك.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

لماذا لا تمثّل المزاوجة الاختصار الذي يأمله الناس

البديل المغري هو إنهاء الـ VPN على VPC A ومزاوجة VPC B به. المزاوجة العادية بين VPCs لا توفّر عبوراً من الحافة إلى الحافة عبر اتصال الـ VPN الخاص بـ A. الطرف النظير يصل إلى العناوين التي توفّرها المزاوجة نفسها، وحافة الـ VPN ليست واحدة منها. العبور هو ما يمنحه المركز؛ أما المزاوجة فتمنحك زوجاً.

هذا القيد خاصية من خصائص المزاوجة، وليس حصة يمكنك رفعها.

الربط والنشر يقومان بعملين مختلفين

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

المركز الصغير المتصل بالكامل هو الحالة السهلة.

ضع كل مرفق في جدول واحد، فتُحل بادئات الـ VPN وبادئتا الـ VPC بصفاء. وهذا يسمح أيضاً بقابلية وصول بين VPCs ربما لم تقصدها المؤسسة، لأن الجدول المشترك لا يعرف مفهوم الطرف الفرعي.

مسارات أحمال العمل تسكن في مكان آخر

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

اختر التوجيه الديناميكي أو الساكن عن قصد؛ فالمزاوجة لا توفّر أياً منهما.

اعزل الأطراف الفرعية دون فقدان الوصول المحلي

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

هذا عزل للتوجيه، وليس تخويلاً على مستوى التطبيق.

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

ما لا يصلحه المركز

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

اتصال الـ VPN ومركز العبور أصبحا الآن بنية تحتية مشتركة.

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

الانتقال من ترتيب قائم على virtual private gateway يستحق الخطة الصريحة نفسها. ابنِ المرفقات والسياسات، وانقل مسار حمل عمل واحد تحت السيطرة، وتأكد من العلاقات المسموحة والمرفوضة قبل إيقاف المسار القديم. تساعد المركزية عندما تمنح فريق الشبكة مكاناً واحداً لإدارة الاتصال المشترك، وتضر عندما تخفي مَن يجوز له الوصول إلى مَن خلف جدول واحد كبير.