الأسطورة هي أن تشفير حركة المرور عبر اقتران ExpressRoute الخاص يتطلب جهاز شبكة ظاهريًا. وهذا غير صحيح. يدعم Azure بوابة Site-to-Site VPN Gateway يكون طرف نفقها عنوان RFC1918 خاصًا يُنقل عبر الدائرة، والجهاز اختياري وليس بنيويًا. وما تخفيه أسطورة الجهاز هو الجزء الذي يضر فعلًا: تمكين الطرف الخاص على كائن واحد بدلًا من كائنَين، والسماح لمسار اقتران مباشر بأن يتغلب بهدوء على المسار المشفَّر.

من أين جاءت الأسطورة

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

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

مكِّن الطرف الخاص على المستويين

ابدأ من اتصال اقتران خاص فعّال في ExpressRoute مرتبط بالشبكة الظاهرية VNet التي تحتوي بوابة VPN. يجب أن يصل الجانب المحلي بالفعل إلى العناوين الخاصة المعنية عبر تلك الدائرة، لأن النفق سيستخدم تلك العناوين وسيلة نقل. ثم شرط البوابة المسبق: يتطلب إجراء Microsoft الخاص بـ VPN بعنوان IP خاص بوابة مبنية على مورد IP عام من نوع Standard. عنونة النفق الخاصة لا تُلغي ذلك الشرط، وهو ما يفاجئ من يفترضون أن كلمة «خاص» تعني «لا IP عام في أي مكان».

مكِّن العلَم الآن في الموضعين. لإعداد البوابة مفتاحها الخاص لعناوين IP الخاصة، وللاتصال الفردي Site-to-Site مفتاح ثانٍ يجعل ذلك الاتصال يستخدم العنوان الخاص. ضبط أحد المفتاحين دون الآخر هو أكثر إعداد ناقص شيوعًا؛ فالنفق إما يفشل في التأسيس أو يتأسس على الطرف الخطأ.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

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

الأسطورة الثانية: النفق القائم يعني أن حركتك مشفَّرة

مسارَان يصلان الآن إلى شبكة التطبيقات: مسار الاقتران الخاص المباشر والمسار عبر VPN. كلاهما يعمل، ومسار واحد فقط يطبِّق طبقة IPsec هذه. توثِّق Microsoft أنه عندما تُعلن بادئات متطابقة عبر ExpressRoute وعبر VPN، يفضِّل Azure مسار ExpressRoute المباشر، لذا فإن نفقًا سليمًا بعدادات سليمة لا يُثبت شيئًا عن الوجهة التي ذهبت إليها حزم التطبيقات.

طرق التوجيه الموثَّقة هي نطاق شامل على ExpressRoute مع نطاق محمي أكثر تحديدًا على VPN، أو بادئات منفصلة على المسارين. للتوضيح، يمكن أن يحمل الاقتران الخاص 10.40.0.0/16 بينما يعلن VPN البادئة 10.40.12.0/24. تفوز البادئة الأكثر تحديدًا ويبقى بقية النطاق مباشرًا.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

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

حدِّد ما يحدث عند سقوط النفق

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

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

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

مقالات ذات صلة