لماذا يتطلب اتصال نقطة إلى موقع بوابة Azure VPN قائمة على التوجيه

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

الترتيب أهم من الخطوات الفردية. إذا أخطأت التسلسل، فسيمتد انقطاع الموقع إلى الموقع إلى ما بعد نافذة الصيانة.

ما تفعله البوابة القائمة على النهج فعلاً

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

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

لماذا تحتاج مجموعة العملاء إلى تلك الواجهة

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

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

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

النوع ثابت عند الإنشاء

تذكر Microsoft أنه لا يمكن تغيير بوابة الشبكة الظاهرية بين القائمة على النهج والقائمة على التوجيه بعد النشر. لا يوجد أمر تحويل ولا مفتاح تبديل في البوابة الإلكترونية. إنشاء بوابة ثانية في الشبكة الفرعية نفسها ليس حلاً بديلاً أيضاً، لأن Azure تسمح ببوابة واحدة لكل شبكة ظاهرية. لذا فإن الترحيل هو إزالة وإعادة بناء وإعادة اتصال.

يضم ذلك أيضاً قرار SKU إلى البناء نفسه. الانتقال إلى SKU أكبر لاحقاً هو استبدال آخر للبوابة مع انقطاع آخر.

بوابة واحدة، وشبكة فرعية واحدة اسمها GatewaySubnet

تعيش البوابة في شبكة فرعية باسم GatewaySubnet، ولا تشغلها إلا بوابة واحدة. تحديد حجم تلك الشبكة الفرعية جزء من التحضير، لأن SKU أكبر يحتاج عناوين أكثر ولا يمكن تصغير الشبكة الفرعية بعد ذلك. سجّل إعدادات الموقع إلى الموقع الحالية والمفتاح المشترك وبوابة الشبكة المحلية والتوجيهات الفعالة قبل لمس أي شيء. ثم تعامل مع النافذة على أنها انقطاع، لأن نفق الموقع إلى الموقع يبقى معطلاً حتى يتم تكوين الاتصال الجديد.

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

ما لا يصلحه الاستبدال

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

إذا كانت المتطلبات تتعلق فعلاً بـ المرور بين المواقع، فإن الجواب هو جهاز نظير قائم على التوجيه أو طوبولوجيا ينتهي فيها كل وجهة على حدة. احسم ذلك قبل الوعد بموعد، لأن استبدال البوابة وحده لن يحققه.

ترتيب العمليات والفحوص

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

أعد إنشاء حزم العملاء بعد أي تغيير في الطوبولوجيا، وأبقِ المجموعة بعيداً عن كل نطاق محلي ونطاق مقترن. القيود والفروق بين وحدات SKU مجموعة في مرجع إعدادات Azure VPN Gateway.