فشل DNS في Azure P2S عندما يكون المُحلِّل في شبكة ظاهرية مقترنة

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

تخيّل حاسوبًا محمولًا ينفق نفقًا إلى بوابة في VNet2، بينما وحدة تحكم المجال التي تخدم DNS تجلس في VNet1.

طوبولوجيتان، فرق واحد

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

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

الجانب أ: اسمح بعبور البوابة لدى مالك البوابة

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

اضبط Allow gateway transit على اقتران VNet2 تجاه VNet1. الخاصية تنتمي إلى كائن الاقتران لا إلى مورد البوابة، لذا تقرؤها وتغيّرها من شفرة الاقتران. هذا كل الجانب أ.

الجانب ب: استخدم بوابات بعيدة على النظير

النصف الآخر هو الصورة المعكوسة: على اقتران VNet1 عائدًا إلى VNet2، فعّل Use remote gateways. تشغيل العلامة نفسها على الطرفين، أو على طرف واحد فقط، يترك مسارًا نصف مبني والعراض الأصلي دون تغيير. الشبكة التي تضم بوابة VPN وحدها تسمح بالعبور، والنظير هو الجانب الذي يستخدمه.

اقرأ الخاصيتين على الشبكتين بدلًا من الوثوق بشفرة البوابة التي فتحتها آخر مرة.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

رؤية الزوج جنبًا إلى جنب أسرع طريق لالتقاط إعداد معكوس. اقتران يبلّغ عن AllowGatewayTransit false على جانب البوابة يفسّر الفشل كله دون التقاط حزم.

ما يجب أن يتلقاه العميل مع ذلك

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

استعلم عن المُحلِّل من الحاسوب المحمول المتصل قبل تغيير أي شيء آخر.

nslookup dc01.corp.example 10.1.0.4

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

قارن العقد نفسه على جانب الموقع إلى الموقع

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

يجب منح العبور على كلا الاقترانين، والمفتاح الذي يمنحه يقيم على الاقتران لا على نوع العميل.

قبل أن تلوم البوابة

يحتفظ Windows بقائمة مُحلِّلات لكل محوّل شبكة، لذا تأكد مما تلقته واجهة النفق فعلًا قبل أن تلوم البوابة.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

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

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