لماذا يؤدي إضافة بادئة Azure VPN إلى قطع الاتصال

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

ثلاثة كائنات، واحد منها يحمل البادئة

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

هناك حجز ثالث يجب إبقاؤه في الاعتبار. GatewaySubnet يستضيف نسخ البوابة المُدارة، ويجب أن يحمل هذا الاسم بالضبط، ومن المتوقع بالنسبة لطرازات SKU غير الأساسية أن يكون /27 على الأقل.

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

لماذا يُزال الاتصال هو نفسه

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

ذلك الحذف هو الانقطاع، فتعامل معه كتغيير مجدول له بداية ونهاية متوقعة بدلاً من تعديل سريع. في PowerShell التسلسل قصير: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force، ثم Set-AzLocalNetworkGateway مع -AddressPrefix الجديدة، ثم New-AzVirtualNetworkGatewayConnection مع -SharedKey نفسه والبوابتين نفسيهما. إعادة استخدام المفتاح مهمة، لأن الطرف الآخر لا يُعاد تكوينه، والمفتاح الجديد يعني التنسيق مع من يملك الجهاز البعيد. وإذا كان فريق آخر يدير ذلك الجهاز، فاتفق معه على النافذة الزمنية قبل أن تحذف أي شيء.

عندما يجب إعادة بناء البوابة نفسها

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

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

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

اقرأ الحالة، لا شارة البوابة

اقرأ الحالة من المورد بدلاً من الشارة في البوابة الإلكترونية. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 يُرجع ConnectionStatus مع عدّادات البايتات الداخلة والخارجة، والعدّادات هي ما يفصل نفقاً متصلاً لا يحمل شيئاً عن نفق لم يُنشأ قط.

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

تفسّر المؤقتات فئة من الانقطاعات التي تُنسب خطأً إلى VPN. موازن التحميل في Azure يغلق التدفقات الخاملة بعد المهلة المكوّنة، وهي أربع دقائق افتراضياً حين كُتبت هذه الملاحظات وقابلة للزيادة، لذا فإن خادم OpenVPN على جهاز ظاهري بلا keepalive يمكن أن يسقط كل بضع دقائق بينما يبدو كل شيء آخر سليماً. والبوابة التي تعيد المنصة تدويرها يمكنها أيضاً أن تقطع اتصال VNet بتطبيق Web App، وهذا الفشل يقع على جانب المنصة لا في تكوين العميل. والدليل هو ما إذا كان الانقطاع يتبع فاصلاً ثابتاً أم تغييراً قمت به.

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

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