HA VPN من Google إلى موجّه Cisco: خطّط لمورد النظير أولاً
سمِّ الواجهتين في Google ومورد النظير وعقد IKEv2 وكل جلسة BGP قبل تهيئة موجّه Cisco، ثم اختر نظيراً واحداً أو نظيرين.
القرار الأول في HA VPN بين Cisco وGoogle ليس أي ملف تعريف تشفير تستخدم، بل هل ستنهي الأنفاقَ أجهزةٌ محلية واحدة أم اثنتان. بوابة HA VPN في Google لها واجهتان، وكل واحدة تتوقع نفق نظير مقابل. وهذا يمنحك نفقين سواء كان لديك موجّهان أم لا، والفرق هو هل يمكن لمصدر طاقة واحد أو ترقية برمجية أن تُسقط التصميم بأكمله.
القرار: جهاز نظير واحد أم جهازان
اختر التخطيط وفق ثلاثة شروط: هل يمكنك قبول نقطة فشل محلية، وهل يجب استخدام واجهتي السحابة معاً، وكم من إعادة التقارب تتحمله أحمالك. إذا كان أي من الثلاثة متطلباً صارماً، فالإجابة الصادقة هي جهازا نظير.
احسم ذلك قبل أن تفتح وحدة تحكم، لأن الإجابة تغيّر عدد الأنفاق وجلسات BGP التي يجب أن تصفها ورقة العمل.
اكتب ورقة العمل قبل أي أمر
تحتوي ورقة العمل على خمسة صفوف، وكل صف يحتاج إلى مسؤول:
| Row | What it records |
|---|---|
| Google side | Project, VPC, region, HA VPN gateway, and the external address of each interface |
| Peer side | The Cisco external addresses, plus the external peer VPN gateway resource that represents them |
| Tunnel pairs | Which peer interface maps to each Google interface, with IKE version, secret and crypto parameters |
| Routing | Cloud Router, local and remote AS numbers, and one inside BGP pair per tunnel |
| Workloads | Approved on-premises and VPC prefixes, and what firewall policy should permit between them |
يصف مورد النظير الخارجي واجهاتك داخل Google Cloud، وإنشاؤه لا يهيّئ موجّه Cisco. هذا التباين يفاجئ من يتوقعون أن تكون وحدة تحكم السحابة مصدر الحقيقة للطرفين. إنه إعلان بما يجب أن تتوقعه Google، وما زال على الموجّه أن يطابقه. دليل بوابة النظير من Google يربط هذا الإعلان بعمل النفق وBGP وجدار الحماية وIKE الذي ما زال مستحقاً عليك.
إذا لم يكن لصف مسؤول، فسيملؤه من يكون في المناوبة أثناء التحويل.
افصل أدوار العناوين الثلاثة
تحمل عناوين النظير العامة تبادل IPsec الخارجي. وينتمي زوج BGP الداخلي إلى الاتصال المنطقي المحمي الذي يجري فوقه. وتصف بادئات LAN وVPC المعلنة الأحمال خلف ذلك الاتصال. ونسخ عنوان داخلي لجهاز ظاهري إلى حقل النظير الخارجي يخلط الدورين الأولين، ويظهر الفشل كمشكلة تفاوض لا كمشكلة إدخال بيانات.
خطط نفقَي نظير متقابلين، واحداً لكل واجهة HA VPN. استخدام واجهتي السحابة لا يزيل بحد ذاته نقطة الفشل المحلية، لأن كلا النفقين قد يهبط على نفس الهيكل.
اكتب دور العنوان بجانب كل قيمة في ورقة العمل. هذه العادة الواحدة تمنع معظم الخلط.
ترجم ورقة العمل إلى إصدار Cisco
ابدأ من وثائق النظير المدعومة أو من قالب تهيئة Google المطابق لمنصتك، ثم طابق كل عنصر نائب مع ورقة العمل. افحص مصادقة IKEv2 ومقترحات ESP وPFS ونموذج النفق والتوجيه معاً، لأن عدم التطابق في أحدها يظهر عادة كعدم تطابق في آخر. استخدم المنصة وإصدار البرنامج الفعليين لاختيار ما هو مدعوم، لأن وصفة Classic VPN نقطة انطلاق مختلفة.
أبقِ السر المشترك خارج لقطات الشاشة ومرفقات التذاكر وملاحظات الدعم. المفتاح المشترك مسبقاً الذي يُلصق في تعليق قضية هو كشف لبيانات اعتماد، لا أثر لاستكشاف الأخطاء.
إذا اختلف القالب وورقة العمل، توقف وحل الأمر على الورق. لن يحكم الجهاز بدلاً منك.
اقبل كل نفق بدليله الخاص
تحتاج HA VPN إلى جلسات BGP، والنجاح في تفاوض IKE لا يثبت إلا المرحلة الأولى. يجب أن تنهض الجلسة الداخلية، ويجب الإعلان عن البادئات المقصودة وقبولها، ويجب أن توجد مسارات مفيدة وأذونات جدار حماية قبل انتقال حركة الأحمال. وتسجيل ذلك كضوء أخضر واحد يخفي أي مرحلة فشلت فعلاً.
سجل دليل القبول لكل نفق: ارتباطات الأمان المتفاوض عليها، وحالة جار BGP، والبادئات المكتسبة المتوقعة، ومسار الحمل المقصود. ثم نفّذ فحص فشل واستعادة مضبوطاً، لأن النفق الذي لم يفشل قط نفقٌ لم يُختبر مسار استعادته.
هذا السجل قابل لإعادة الاستخدام عند تغيّر التصميم في المرة القادمة، وهو الفرق بين تشغيل متبادل وبين جزء أمر ضاعت افتراضاته.