تعذّر على Azure P2S VPN تحليل اسم نقطة نهاية خاصة

تتصل نفق point-to-site، وتفتح اتصالًا بعنوان IP الخاص، ثم تفتح التطبيق فتحصل على 403 أو على خطأ في الشهادة بدلًا من ذلك. تشير كلتا العلامتين إلى DNS، لكنهما عطلان مختلفان: الأولى تعني أن العميل حلّ العنوان العام، والثانية تعني أنه حلّ العنوان الخاص ثم قدّم اسمًا لا تغطيه الشهادة. نفّذ الفحوص أدناه بالترتيب وتوقّف عند أول إخفاق، لأن إدخالًا في ملف hosts أو إجابة مخزّنة مؤقتًا قد يجعل كل فحص لاحق ينجح لسبب خاطئ. أحتفظ بهذا الترتيب في ملف نصي بجانب ملفات تعريف VPN، لأن الإصلاح لا يغيّر شيئًا في النفق ويغيّر كل شيء فيما يعرفه العميل.

ابدأ بالعنوان الذي يحصل عليه العميل فعليًا

اسأل خادم التحليل مباشرة بدلًا من الوثوق بالتطبيق. على Windows، يُظهر nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net أي عرض استلمه العميل. الإجابة العامة تعني أن لا شيء في المسار سيصل إلى نقطة النهاية؛ أما العنوان الخاص لنقطة النهاية فيعني أن DNS انتهى وأن الفحص التالي هو الاتصال نفسه.

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

افحص المنطقة وربطها والسجل قبل النفق

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

أسماء المناطق تنتمي إلى الخدمات، لا إلى الروابط الخاصة عمومًا. يستخدم App Service عادةً privatelink.azurewebsites.net، وللتخزين وSQL مساحات أسماء خاصة بهما، واستعارة منطقة خدمة أخرى ينتج منطقة موجودة لا تجيب بشيء مفيد.

امنح العميل خادم تحليل يستطيع الوصول إليه فعلًا

يستجيب 168.63.129.16 من الأجهزة الظاهرية في Azure وليس خادم DNS لحاسوب محمول على الجانب الآخر من نفق point-to-site. يحتاج العميل إلى خادم تحليل يمكن الوصول إليه عبر النفق: نقطة نهاية واردة في Azure DNS Private Resolver، أو مُمرِّر داخل الشبكة الظاهرية، أو إدخالات خادم DNS محمولة في ملف تعريف عميل VPN حتى يسأل العميل الشبكة الظاهرية مباشرة.

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

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

استخدم الاسم الذي صدرت الشهادة من أجله

بعد أن يصبح العنوان صحيحًا، يظهر العطل الثاني. ينشر التخزين وApp Service اسمًا مستعارًا privatelink، وهذا الاسم ليس بالضرورة الاسم الموجود في الشهادة. فشل تحميل AzCopy موجّه إلى privatelink.blob.core.windows.net في التحقق؛ أما التحميل نفسه إلى <account>.blob.core.windows.net/<container> فقد حُلّ إلى العنوان الخاص ونجح، فبقي على المسار الخاص دون تجاوز.

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

ترتيب من أربع خطوات يعزل كل طبقة

1. تأكد من أن عميل VPN يحمل عنوانًا من مجمّع point-to-site ولديه مسار إلى العنوان الخاص لنقطة النهاية.
2. حلّل الاسم الدقيق الذي يستخدمه التطبيق وقارن الإجابة بعنوان نقطة النهاية.
3. افتح اتصال TCP بنقطة النهاية على منفذ الخدمة، ثم اقرأ اسم الشهادة المعروض على ذلك الاتصال.
4. اختبر التخويل الآن فقط، لأن مسارًا عاملًا وشهادة صالحة لا يمنحان الوصول إلى المورد بعد.

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

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

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

أين ينتمي إدخال hosts

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

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

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