VPN من موقع AWS إلى Azure: اكتب مسار العودة أولاً
نفق سحابي متصل لا يثبت شيئًا حتى يوجّه كل نطاق فرعي لأحمال العمل حركته إلى البادئة البعيدة. نفّذ الخطة بالترتيب ثم اختبر الخدمة.
سيعمل النفق. هذا ما يحدث عادةً، لأن IKE يحتاج فقط إلى مقترحات متطابقة وعنوان نظير يمكن الوصول إليه. وما يفشل بعد ذلك هو مسار العودة: يرسل حمل العمل في AWS الحزم إلى نفق، لكن لا شيء على جانب Azure يعرف كيف يردّ على 10.10.0.0/16، أو أن مسار Azure موجود في جدول لا يستخدمه النطاق الفرعي لحمل العمل. اكتب خطة المسارات قبل أن تلمس أي وحدة تحكم، وسيصبح النفق أقل أجزاء المهمة إثارةً.
الخطوة 1: ثبّت خطة العناوين
اعمل بقيم ملموسة. حمل عمل في AWS موجود على 10.10.1.20 داخل 10.10.0.0/16 ويحتاج TCP 443 إلى خدمة Azure على 10.20.1.30 داخل 10.20.0.0/16. يجب ألا يتداخل النطاقان، والاختبار المقبول هو زوج الخدمة، لا النفق.
اكتب هذه الحقائق الأربع قبل أي شيء آخر، لأن كل خطوة لاحقة تُفحص مقابلها.
الخطوة 2: حدّد البوابة التي تملك كل طرف
يمكن أن ينتهي AWS Site-to-Site VPN على بوابة خاصة افتراضية أو بوابة عبور، وهذان مالكا توجيه مختلفان. وتوفّر Azure بوابة VPN المُدارة، وبشكل منفصل أجهزة قائمة على الأجهزة الافتراضية يديرها العملاء بأنفسهم. سجّل أي زوج لديك، لأن القفزة التالية تختلف في كل تركيب.
بالنسبة إلى بوابة مُدارة، لا تنسخ مسارًا يشير إلى عنوان جهاز خاص مُخمَّن. وبالنسبة إلى جهاز، لا تفترض أن نشر المسارات في السحابة يضبط نظام تشغيل الضيف، لأنه لا يفعل ذلك.
الخطأ في ذلك ينتج خطة تبدو كاملة وتوجّه الحزم إلى عنوان لا يردّ أبدًا.
الخطوة 3: اكتب المسار الذي يستخدمه كل حمل عمل فعلاً
كل حدّ أدناه بحث منفصل، والمسار في أحدها ليس مسارًا للحزمة. املأ الجدول بقيمك قبل أن يصبح النفق نشطًا.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
في AWS، جدول مسارات النطاق الفرعي لحمل العمل مسؤوليتك حتى بعد أن يصبح BGP أو النفق سليمًا؛ نظرة عامة على التوجيه تعتبر ذلك جزءًا من الاتصال. وفي Azure، يرتبط جدول المسارات المعرّفة من المستخدم بنطاق فرعي بدلًا من أن يُربط بالشبكة الافتراضية، لذا افحص المسار الفعّال على NIC الخاص بحمل العمل لا في شفرة VNet.
يمكن لبوابة Azure المُدارة أن تتعلّم البادئة البعيدة عبر نشر البوابة، ويمكن لـ UDR أن تتجاوز ذلك القرار. أضف UDR عندما يكون لديك سبب، لا بدافع العادة. وإن أضفت واحدة، وجّهها إلى القفزة التالية التي تنشرها البوابة لمسار VPN بدلًا من اختراع عنوان جهاز. ثم أعد قراءة المسارات الفعّالة على NIC، لأن NIC هو المكان الذي يُتخذ فيه القرار فعلاً.
الخطوة 4: وحّد النطاق
في BGP، قارن ما يعلنه كل طرف بما تعلّمه الطرف الآخر فعلاً، بادئةً بادئة. وفي التوجيه الساكن، قارن النطاقات البعيدة المُهيّأة بمسارات حمل العمل التي كتبتها في الخطوة 3.
علاقة IKE تتفق على التشفير ليست دليلًا على أن أي طرف تعلّم 10.10.0.0/16 أو 10.20.0.0/16. يمكن أن يكون نفقان قائمين بينما يعلن أحد الطرفين /24 واحدًا بدلًا من /16 الذي خططت له. افحص البادئة في جدول التوجيه، لا في حالة النفق. يظهر عدم التطابق لاحقًا كنطاق فرعي يعمل وآخر لا يردّ أبدًا.
الخطوة 5: اختبر الخدمة من المصدر الحقيقي
اسمح بالتدفق المقصود في مجموعات أمان AWS وقوائم ACL للشبكة، وفي NSG في Azure، وفي أي مرشّح جهاز على المسار. ثم افتح اتصالًا واحدًا من 10.10.1.20 إلى عنوان الخدمة والمنفذ المعتمدين وتأكد من أن الردّ يعود إلى المصدر نفسه.
مجموعات الأمان السحابية وNSG كلتاهما ذات حالة، لذا فإن حزمة عودة مرفوضة عرض من أعراض التوجيه لا قاعدة نسيت كتابتها بالاتجاه المعاكس.
اختبار ping من أي بوابة لا يحسم شيئًا. ICMP إلى عنوان بوابة يمرّن مسار مستوى التحكم، لا خدمة TCP المُمرَّرة التي يحتاجها حمل العمل.
التراجع والسجلات
سجّل مالكي المسارات بجانب معرّفات النفق، واحتفظ بجداول المسارات قبل التغيير. وإن كان لا بد من إزالة التغيير، فأزل مسارات حمل العمل قبل تفكيك النفق، كي لا يبقى نطاق فرعي يشير إلى قفزة تالية لم تعد موجودة.
عندها يصبح نقل نطاق فرعي أو إرفاق spoke لاحقًا له مكان واحد محدد للتحديث، بدلًا من نفق يعمل ويحمل اللوم على مسار لم يملكه قط.