هل يحتاج Azure VNet المُقترن إلى بوابة VPN خاصة به؟
يمكن لشبكة VNet مقترنة استخدام بوابة VPN التابعة للمحور مع SKU مدعوم وإعداد واحد في كل اتجاه اقتران. تحقق من المسارات الفعلية، لا من حالة الاقتران.
يظهر VNet فرعي جديد، بينما يملك المحور بالفعل بوابة موقع-إلى-موقع عاملة، والسؤال البديهي هو ما إذا كان عليك دفع تكلفة بوابة ثانية. عادةً لا: يتيح عبور البوابة للشبكة الفرعية استخدام بوابة المحور عبر الاقتران. تحدد ثلاثة شروط ما إذا كان ذلك سينجح، ولا يظهر أي منها في شارة حالة الاقتران. اتصال الاقتران والسماح باستخدام بوابة شخص آخر إعدادان منفصلان، لذا فإن جهازي VM يستطيعان بالفعل تبادل ping لا يثبتان شيئًا عن مسار VPN.
الشرط الأول: البوابة، وافتقار الشبكة الفرعية إليها
يدعم Azure عبور البوابة لأصناف SKU الخاصة بـ VPN Gateway بخلاف Basic، ويمكن لكل من الاقتران الإقليمي والعالمي حمله. تستهلك الشبكة الفرعية بوابة لا تملكها، لذا لا يمكنها أن تملك واحدة خاصة بها: إذا كانت هناك بوابة موجودة بالفعل في الشبكة الفرعية، أو كان خيار البوابة البعيدة محددًا بالفعل، فسيكون إعداد العبور الذي تريده غير متاح أو غير فعّال. تحقق من ذلك قبل أن تبدأ بتصحيح أي شيء، لأن مربع الاختيار المعطّل هو العَرَض وليس الخلل. اقرأ صنف SKU والبوابة الموجودة أولًا، ثم انظر إلى إعدادات الاقتران.
لا تحذف بوابة شبكة فرعية موجودة لجعل الخيار يظهر حتى تعرف ما يعتمد عليها. ترتيب الترحيل أهم من مربع الاختيار.
الشرط الثاني: إعداد واحد في كل اتجاه اقتران
الاقتران كائنان، واحد في كل VNet، وإعدادات العبور تقع على جانبين مختلفين من ذلك الزوج. يجب أن يسمح اقتران المحور باتجاه الشبكة الفرعية لبوابة المحور بخدمة الشبكة الفرعية؛ ويجب أن يقبل اقتران الشبكة الفرعية باتجاه المحور بوابة المحور. دليل عبور البوابة من Microsoft يسمّيها حسب كل اتجاه، وهي الطريقة الوحيدة لإبقائها واضحة:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
يتغير معنى عنصر تحكم يحمل التسمية remote حسب VNet التي تعدّل اقترانها، لذا اقرأ الاتجاه لا الكلمة. اضبط الجانبين، واحفظ، وتأكد من أن الاقتران يظهر كمتصل في المكانين.
الشرط الثالث: مساحة العناوين وحدود الأذونات
لا يمكن للعبور أن يجعل البادئة الوجهة نفسها تعني شبكتين، لذا يجب أن تكون نطاقات المحور والشبكة الفرعية والشبكة المحلية منفصلة قبل أن يعمل أي من هذا. قد تقع شبكات VNet أيضًا في اشتراكات مختلفة أو مستأجرين مختلفين؛ وهذا ليس حظرًا، لكن الهوية التي تنشئ أو تحدّث كل اقتران تحتاج إلى الأذونات المطلوبة على تلك الشبكة. كثيرًا ما تفشل التغييرات العابرة للاشتراكات بسبب الأذونات، ويسهل قراءة الخطأ كأنه مشكلة طوبولوجيا.
اكتب النطاقات والمالكين قبل التغيير. التخمين في أي منهما ينتج اقترانًا يتصل ولا يوجّه شيئًا.
تحقق من المسارات الفعلية، لا من حالة الاقتران
انظر إلى المسارات الفعلية على واجهة الشبكة لعبء عمل في الشبكة الفرعية واعثر على بادئة الشبكة المحلية الفعلية. تحقق من جدول مسارات الشبكة الفرعية وما إذا كان نشر مسارات البوابة معطّلًا، لأن مسارًا يعرّفه المستخدم أو جهاز تفتيش يمكن أن يتجاوز المسار الذي تشير إليه أعلام الاقتران. ثم أكّد الاتجاه الآخر: يجب أن تعرف الشبكة المحلية كيف تصل إلى بادئة الشبكة الفرعية عبر اتصال الموقع إلى الموقع، سواء عبر الإعلانات المتعلَّمة أو عبر مسار صريح وإدخال مطابق للشبكة المحمية على جهاز العميل. إذا كانت البادئة مفقودة على أي من الجانبين، فليست أعلام الاقتران هي ما يجب تغييره.
اختبر خدمة واحدة من عبء عمل في الشبكة الفرعية وتابع الرد. الاختبار من بوابة VPN أو من جهاز VM في المحور يمارس بادئة مصدر مختلفة ومسارًا مختلفًا.
إذا كانت الطوبولوجيا تخدم أيضًا عملاء النقطة إلى الموقع، فتحقق من مساراتهم المثبتة بشكل منفصل. قد تحتاج حزم عميل Windows إلى إعادة توليد بعد تغيير الطوبولوجيا، وهذه مهمة توجيه على جانب العميل وليست دليلًا على فشل مشاركة البوابة.
ما لا تمنحه مشاركة البوابة
عبور البوابة تسهيل توجيه، وليس تفويضًا. لا تزال مجموعات أمان الشبكة وعوامل التصفية المحلية وقواعد مستوى الخدمة تحدد ما يمكن لعبء العمل في الشبكة الفرعية الوصول إليه، لذا فعّل الخدمة المحددة من المصدر إلى الوجهة بدلًا من افتراض أن النفق المشترك يسمح بكل ما خلفه.
الاقتران ليس متعديًا أيضًا بالطريقة التي يأملها الناس. إن إضافة شبكة فرعية أخرى، أو نقطة نهاية خاصة، تقدم متطلبات توجيه ووصول خاصة بها لا يغطيها إعداد العبور الحالي.