تشخيص مشاكل تكوين الروابط الخاصة في Azure Key Vault

Introduction

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

إذا كنت جديداً على هذه الميزة، راجع دمج مفتاح Vault مع Azure Private Link.

المشاكل التي تغطيها هذه المقالة

• لا تزال استعلامات DNS الخاصة بك تسترد عنوان IP عام لخزنة المفاتيح، بدلاً من عنوان IP خاص تتوقعه من استخدام ميزة الارتباطات الخاصة.
• تفشل جميع الطلبات التي يقدمها عميل معين يستخدم ارتباطا خاصا مع المهلات أو أخطاء الشبكة، والمشكلة ليست متقطعة.
• يتضمن مفتاح vault عنوان IP خاص، ولكن الطلبات لا تزال تحصل على 403 استجابة باستخدام ForbiddenByFirewall رمز خطأ داخلي.
• تستخدم روابط خاصة، ولكن لا يزال مفتاح vault الخاص بك يقبل الطلبات من الإنترنت العام.
• يتضمن مفتاح vault الخاص بك نقطتي نهاية خاصتين. تعمل الطلبات التي تستخدم أحدهما بشكل جيد، ولكن الطلبات التي تستخدم الأخرى تفشل.
• لديك اشتراك آخر أو مفتاح vault أو شبكة افتراضية تستخدم روابط خاصة. تريد إجراء توزيع مماثل جديد، ولكن لا يمكنك الحصول على روابط خاصة للتشغيل هناك.

المشاكل التي تغطيها هذه المقالة

• هناك مشكلة الاتصال المتقطع. في بعض حالات العملاء، تجد أن عدد من الطلبات يعمل جيداً فيما يفشل عدد آخر. نادرا ما تحدث مشاكل متقطعة بسبب مشكلة في تكوين الارتباطات الخاصة؛ وهي علامة على التحميل الزائد للشبكة أو العميل.
• أنت تستخدم منتج Azure يدعم BYOK (إحضار المفتاح الخاص بك) أو CMK (مفاتيح مدارة من العملاء) أو الوصول إلى البيانات السرية المخزنة في مفتاح Vault. عند تمكين جدار الحماية في إعدادات مفتاح Vault، لا يمكن لهذا المنتج الوصول إلى مفتاح Vault الخاص بك. راجع الوثائق الخاصة بالمنتج. تأكد من أنها تنص صراحةً على دعم key vaults مع تمكين جدار الحماية. اتصل بالدعم لهذا المنتج المُحدد، إذا لزم الأمر.

كيفية قراءة هذه المقالة

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

لنبدأ!

1. تأكد من أن تملك اتصال العميل

تأكد من تشغيل العميل في الشبكة الظاهرية

يهدف هذا الدليل إلى مساعدتك في إصلاح الاتصالات في مفاتيح Vault التي تنشأ من رمز التطبيق. ومن الأمثلة على ذلك التطبيقات والبرامج النصية التي تنفذ فيAzure Virtual Machines، ومجموعاتAzure Service Fabric، وخدمةAzure App Service، وخدمةAzure Kubernetes (AKS)، وغيرها. ينطبق هذا الدليل أيضاً على عمليات الوصول التي تتم في واجهة المستخدم على الويب في مدخل Microsoft Azure، حيث يصل المتصفح إلى مفتاح Vault مباشرة.

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

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

إذا كنت تستخدم حلاً مداراً، فراجع الوثائق المحددة

تتطلب خدمات Azure المدارة تكوينا مختلفا

لا ينطبق هذا الدليل على الخدمات التي تديرها Microsoft والتي تصل إلى Key Vault الخاص بك من خارج الشبكة الظاهرية. تتضمن هذه السيناريوهات ما يلي:

• تم تكوين Azure Storage باستخدام التشفير الثابت
• Azure SQL باستخدام مفاتيح يديرها العميل
• Azure Event Hubs تقوم بتشفير البيانات باستخدام المفاتيح الخاصة بك
• وصول Azure Data Factory إلى بيانات الاعتماد المخزنة في Key Vault
• Azure Pipelines استرداد البيانات السرية من Key Vault

بالنسبة لهذه السيناريوهات، يجب التحقق مما إذا كانت خدمة Azure المحددة تدعم الوصول إلى Key Vaults مع تمكين جدران الحماية. تستخدم العديد من الخدمات ميزة "الخدمات الموثوق بها " للوصول بأمان إلى Key Vault الخاص بك على الرغم من قيود جدار الحماية. ومع ذلك، لا تظهر جميع خدمات Azure في قائمة الخدمات الموثوق بها لأسباب معمارية مختلفة.

إذا كنت تواجه مشكلات مع خدمة Azure معينة تصل إلى Key Vault الخاص بك، فراجع وثائق تلك الخدمة أو اتصل بفريق الدعم الخاص بها للحصول على إرشادات محددة.

تدعم بعض منتجات Azure مفهوم حقن vnet. بعبارات بسيطة، يضيف المنتج جهاز شبكة إلى الشبكة الظاهرية للعميل، ما يسمح له بإرسال الطلبات كما لو تم توزيعه إلى الشبكة الظاهرية. ومن الأمثلة البارزة على ذلك Azure Databricks. يمكن لمنتجات مثل هذه تقديم طلبات إلى مفتاح vault باستخدام الروبط الخاصة، وقد يساعد دليل استكشاف الأخطاء وإصلاحها في ذلك.

2. تأكد من أن الاتصال تمت الموافقة عليه ونجح

تتحقق الخطوات التالية من اعتماد اتصال نقطة النهاية الخاصة ونجاحه:

1. انتقل إلى مدخل Microsoft Azure وافتح مورد مفتاح vault الخاص بك.
2. في القائمة الظاهرة على اليسار، حدد ⁧⁩الشبكات⁧⁩.
3. حدد علامة التبويب Private endpoint connections لمشاهدة جميع اتصالات نقطة النهاية الخاصة وحالاتها الخاصة. إذا لم تكن هناك اتصالات، أو إذا كان الاتصال الخاص بالشبكة الظاهرية مفقوداً، يجب عليك إنشاء نقطة نهاية خاصة جديدة. وسيتم تغطية هذه النقطة في وقت لاحق.
4. لا زالنا في اتصالات نقطة النهاية الخاصة، ابحث عن الاتصال الذي تقوم بتشخيصه وتأكد من أن "حالة الاتصال" تمت الموافقة عليها و "حالة التوفير" قد نجحت.
   • إذا كان الاتصال في حالة "معلق"، فقد تتمكن من الموافقة عليه فقط.
   • إذا كان الاتصال "مرفوض" أو "فشل" أو "خطأ" أو "قطع الاتصال" أو حالة أخرى، فإنه ليس فعالا على الإطلاق، يجب عليك إنشاء مورد نقطة نهاية خاصة جديد.

قد يكون من المفيد حذف الاتصالات غير الفعالة لاتصالات فعالة ومنظمة.

3. تأكد من أن جدار حماية مفتاح vault تم تكوينه بشكل صحيح

هام

تغيير إعدادات جدار الحماية قد يؤدي إلى حذف إمكانية الوصول من العملاء الشرعيين التي لا تزال غير مستخدمة للروابط الخاصة. تأكد من أنك على علم بالآثار المترتبة على كل تغيير في تكوين جدار الحماية.

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

1. انتقل إلى مدخل Microsoft Azure وافتح مورد مفتاح vault الخاص بك.
2. في القائمة الظاهرة على اليسار، حدد ⁧⁩الشبكات⁧⁩.
3. تأكد من تحديد علامة التبويب جدران الحماية والشبكات الظاهرية في الأعلى.
4. إذا وجدت السماح بالوصول العام من جميع الشبكات محددا ، فإن هذا يفسر لماذا لا يزال العملاء الخارجيون قادرين على الوصول إلى مخزن المفاتيح. إذا كنت ترغب في أن يكون Key Vault متاحا فقط عبر Private Link، فحدد Disable Public Access.

تنطبق العبارات التالية أيضاً على إعدادات جدار الحماية:

• لا تتطلب ميزة الروابط الخاصة تحديد أي "شبكة افتراضية" في إعدادات جدار حماية مفتاح vault. يجب أن تعمل جميع الطلبات التي تستخدم عنوان IP الخاص بمفتاح vault (انظر القسم التالي)، حتى إذا لم يتم تحديد شبكة افتراضية في إعدادات جدار حماية المفاتيح.
• لا تتطلب ميزة الروابط الخاصة تحديد أي عنوان IP خاص في إعدادات جدار حماية مفتاح vault. مرة أخرى نؤكد، يجب أن تعمل جميع الطلبات التي تستخدم عنوان IP خاص بمفتاح vault، حتى إذا لم يتم تحديد عنوان IP في إعدادات جدار الحماية.

إذا كنت تستخدم روابط خاصة، فإن الدوافع الوحيدة لتحديد الشبكة الظاهرية أو عنوان IP في جدار حماية المفاتيح هي:

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

4. تأكد من أن قبو المفتاح يحتوي على عنوان IP خاص

ما الفرق بين عناوين IP الخاصة والعامة؟

عنوان IP الخاص دائماً ما يكون له أحد التنسيقات التالية:

• ‎10.x.x.x: أمثلة: 10.1.2.3، 10.56.34.12.
• ‎172.16.x.x إلى ‎172.32.x.x: أمثلة: 172.20.1.1،172.31.67.89.
• ‎192.168.x.x: أمثلة: 192.168.0.1، 192.168.100.7

يتم حجز عناوين IP ونطاقات معينة:

• ‎224.x.x.x: الإرسال المتعدد
• 255.255.255.255: البث
• ‎127.x.x.x: التكرار الحلقي
• ‎169.254.x.x: الرابط المحلي
• ‎168.63.129.16: ‏DNS داخلي

جميع عناوين IP الأخرى عامة.

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

العثور على عنوان IP خاص بمفتاح vault في الشبكة الظاهرية

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

1. انتقل إلى مدخل Microsoft Azure وافتح مورد مفتاح vault الخاص بك.
2. في القائمة الظاهرة على اليسار، حدد ⁧⁩الشبكات⁧⁩.
3. حدد علامة التبويب Private endpoint connections . تعرض طريقة العرض الناتجة جميع اتصالات نقطة النهاية الخاصة وحالاتها الخاصة.
4. ابحث عن الاتصال الذي تقوم بتشخيصه وتأكد من أن "حالة الاتصال" معتمدة وأن حالة التوفير ناجحة. إذا كانت الحالة مختلفة، فارجع إلى المقاطع السابقة من المستند.
5. عندما تعثر على العنصر المناسب، انقر فوق الارتباط الموجود في عمود نقطة النهاية الخاصة . يفتح الإجراء مورد نقطة النهاية الخاصة.
6. قد تعرض صفحة نظرة عامة مقطع يسمى إعدادات DNS المخصصة. تأكد من وجود إدخال واحد فقط يطابق اسم مضيف مفتاح vault. يظهر هذا الإدخال عنوان IP الخاص بمفتاح vault.
7. يمكنك أيضا تحديد الارتباط في واجهة الشبكة والتأكد من أن عنوان IP الخاص هو نفسه المعروض في الخطوة السابقة. واجهة الشبكة هي جهاز ظاهري يمثل مفتاح vault.

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

إشعار

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

5. تحقق من تحليل DNS

دقة DNS هي عملية ترجمة اسم مضيف مفتاح Vault (مثال: fabrikam.vault.azure.net) إلى عنوان IP (مثال: 10.1.2.3). تظهر الأقسام الفرعية التالية النتائج المتوقعة من تحليل DNS في كل سيناريو.

مفاتيح Vault بدون رابط خاص

هذا القسم مخصص لتعلم الأغراض إذا كان مفتاح Vault ليس له نقطة نهاية خاصة متصلة في الحالة المعتمدة، عندئذ سيعطى حل اسم المضيف نتيجة مماثلة لهذه الحالة:

Windows:

C:\> nslookup fabrikam.vault.azure.net

Non-authoritative answer:
Address:  52.168.109.101
Aliases:  fabrikam.vault.azure.net
          data-prod-eus.vaultcore.azure.net
          data-prod-eus-region.vaultcore.azure.net

Linux:

joe@MyUbuntu:~$ host fabrikam.vault.azure.net

fabrikam.vault.azure.net is an alias for data-prod-eus.vaultcore.azure.net.
data-prod-eus.vaultcore.azure.net is an alias for data-prod-eus-region.vaultcore.azure.net.
data-prod-eus-region.vaultcore.azure.net has address 52.168.109.101

سترى أن الاسم يحل إلى عنوان IP عام، ولا يوجد privatelink أي اسم مستعار. الاسم المستعار موضح لاحقاً، لا تقلق بشأنه الآن.

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

حل مفتاح Vault مع الرابط الخاص من جهاز الإنترنت الإجباري

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

Windows:

C:\> nslookup fabrikam.vault.azure.net

Non-authoritative answer:
Address:  52.168.109.101
Aliases:  fabrikam.vault.azure.net
          fabrikam.privatelink.vaultcore.azure.net
          data-prod-eus.vaultcore.azure.net
          data-prod-eus-region.vaultcore.azure.net

Linux:

joe@MyUbuntu:~$ host fabrikam.vault.azure.net

fabrikam.vault.azure.net is an alias for fabrikam.privatelink.vaultcore.azure.net.
fabrikam.privatelink.vaultcore.azure.net is an alias for data-prod-eus.vaultcore.azure.net.
data-prod-eus.vaultcore.azure.net is an alias for data-prod-eus-region.vaultcore.azure.net.
data-prod-eus-region.vaultcore.azure.net has address 52.168.109.101

الفرق الملحوظ عن السيناريو السابق هو أن هناك اسم مستعار جديد مع القيمة {vaultname}.privatelink.vaultcore.azure.net. وحدة بيانات المخزن الرئيسي جاهزة لقبول الطلبات من الروابط الخاصة.

هذا لا يعني أن الطلبات التي يتم تنفيذها من الأجهزة خارج الشبكة الظاهرية (مثل تلك التي استخدمتها للتو) تستخدم ارتباطات خاصة - فهي لا تستخدمها. يمكنك التحقق من هذا، بأنك ستجد أن اسم المضيف لا يزال يحل إلى عنوان IP عام. يمكن فقط للأجهزة المتصلة بالشبكة الظاهرية استخدام الروابط الخاصة.

إذا لم تجد privatelink الاسم المستعار، فهذا يعني أن مفتاح Vault لا يحتوى على أية نقاط نهاية خاصة متصلة في Approved الحالة. عد إلى هذا القسم قبل إعادة المحاولة.

حل مفتاح Vault مع الرابط الخاص من جهاز الشبكة الظاهرية

إذا كان مفتاح Vault يتضمن نقطة نهاية خاصة واحدة أو أكثر متصلة في حالة الموافقة وقمت بحل اسم المضيف من جهاز إجباري متصل بالشبكة الظاهرية حيث تم إنشاء نقطة النهاية الخاصة، فستجد الاستجابة التالية:

Windows:

C:\> nslookup fabrikam.vault.azure.net

Non-authoritative answer:
Address:  10.1.2.3
Aliases:  fabrikam.vault.azure.net
          fabrikam.privatelink.vaultcore.azure.net

Linux:

joe@MyUbuntu:~$ host fabrikam.vault.azure.net

fabrikam.vault.azure.net is an alias for fabrikam.privatelink.vaultcore.azure.net.
fabrikam.privatelink.vaultcore.azure.net has address 10.1.2.3

هناك اختلافان ملحوظان. أولاً، يتم تحليل الاسم إلى عنوان IP خاص. يجب أن يكون هذا عنوان IP الذي وجدناه في القسم المقابل من هذه المقالة. ثانيا، لا توجد أسماء مستعارة أخرى بعد privatelink هذا الاسم. يحدث هذا لأن خوادم DNS الخاصة بالشبكة الظاهرية قد اعترضت سلسلة من الأسماء المستعارة وتم إرجاع عنوان IP الخاص مباشرة من الاسم fabrikam.privatelink.vaultcore.azure.net. هذا الإدخال هو في الواقع A سجل في منطقة DNS الخاصة.

إشعار

تحدث هذه النتيجة فقط في جهاز ظاهري متصل بالشبكة الظاهرية حيث تم إنشاء نقطة النهاية الخاصة. إذا لم يكن لديك جهاز ظاهري تم نشره في الشبكة الظاهرية التي تحتوي على نقطة النهاية الخاصة، فوزع واحدة واتصل بها عن بعد، ثم قم بتنفيذ nslookup الأمر (Windows) أو host الأمر (Linux).

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

6. قم بالتحقق من منطقة خادم أسماء المجالات الخاصة DNS

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

تأكد من وجود مورد منطقة DNS الخاصة المطلوبة

يجب أن يكون اشتراك Azure الخاص بك له مورداً لـ منطقة DNS الخاصة بهذا الاسم بالضبط:

privatelink.vaultcore.azure.net

يمكنك التحقق من وجود هذا المورد من خلال الانتقال إلى صفحة الاشتراك في المدخل، وتحديد "الموردين" في القائمة اليسرى. يجب أن تجد اسم المورد privatelink.vaultcore.azure.net، ويجب أن يكون نوع المورد منطقة DNS خاصة.

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

إذا لم يكن لديك هذا المورد، قم بإنشاء مورد خاص جديد في منطقة DNS في اشتراكك. تذكر أن الاسم يجب أن يكون بالضبط privatelink.vaultcore.azure.net، دون مسافات أو نقاط إضافية. إذا حددت الاسم الخطأ، يفشل تحليل الاسم الموضح في هذه المقالة. للحصول على مزيدٍ من المعلومات حول كيفية إنشاء هذا المورد، راجع إنشاء منطقة DNS خاصة في Azure باستخدام مدخل Microsoft Azure. إذا كنت تتبع هذه الصفحة، يمكنك تخطي إنشاء الشبكة الظاهرية لأنه في هذه المرحلة يجب أن يكون لديك واحداً بالفعل. يمكنك أيضا تخطي إجراءات التحقق من الصحة باستخدام الأجهزة الظاهرية.

تأكد من أن منطقة DNS الخاصة مرتبطة بالشبكة الظاهرية

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

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

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

إشعار

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

تأكد من أن منطقة DNS الخاصة تحتوي على سجلات A الصحيحة

باستخدام المدخل، افتح منطقة DNS الخاصة بالاسم privatelink.vaultcore.azure.net. تعرض صفحة نظرة عامة كافة السجلات. بشكل افتراضي، هناك سجل واحد بالاسم @ والنوع SOA، بمعنى بداية السلطة. لا تغير فيه شيئاً.

لكي يعمل حل اسم مفتاح vault، يجب أن يكون هناك A سجل باسم vault بسيط بدون لاحقة أو نقاط. على سبيل المثال، إذا كان اسم المضيف fabrikam.vault.azure.net، يجب أن يكون هناك Aسجل بهذا الاسمfabrikam، بدون أي لاحقة أو نقاط.

أيضاً، يجب أن تكون قيمة Aالسجل (عنوان IP) هو عنوان IP الخاص بمفتاح vault. إذا وجدت A السجل ولكنه يحتوي على عنوان IP خاطئ، يجب إزالة عنوان IP الخاطئ وإضافة عنوان جديد. من المستحسن إزالة السجل بأكمله A وإضافة سجل جديد.

إشعار

كلما قمت بحذف أو تعديل A سجل، قد لا يزال حل الجهاز يعود إلى عنوان IP القديم لأن قيمة TTL (الوقت إلى المباشرة) لم تنتهي صلاحيتها بعد. من المستحسن أن تقوم دائما بتحديد قيمة TTL بمدة لا تقل عن 10 ثانية ولا تزيد عن 600 ثانية (10 دقائق). إذا قمت بتحديد قيمة كبيرة جداً، قد يستغرق عملاك وقتاً طويلاً للاسترداد بعد انقطاع التيار الكهربائي.

تحليل DNS لأكثر من شبكة ظاهرية واحدة

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

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

عليم أن تدرك أنك متحكم في تحليل DNS

كما هو موضح في القسم السابق، يحتوي مفتاح vault المتصل بروابط خاصة على الاسم المستعار في {vaultname}.privatelink.vaultcore.azure.net تسجيله العام. يستخدم خادم DNS المستخدم من قبل الشبكة الظاهرية التسجيل العام، ولكنه يتحقق من كل اسم مستعار لتسجيل خاص ، وإذا تم العثور على واحد، فإنه يتوقف عن اتباع الأسماء المستعارة المعرفة في التسجيل العام.

يعني هذا المنطق أنه إذا كانت الشبكة الظاهرية مرتبطة بمنطقة DNS خاصة بالاسم privatelink.vaultcore.azure.net، وكان تسجيل DNS العام لمخزن المفاتيح يحتوي على الاسم المستعار fabrikam.privatelink.vaultcore.azure.net (لاحظ أن لاحقة اسم مضيف خزنة المفاتيح تطابق اسم منطقة DNS الخاصة تماما)، فإن استعلام DNS يبحث عن A سجل باسم fabrikamفي منطقة DNS الخاصة. إذا A تم العثور على السجل، يتم إرجاع عنوان IP الخاص به في استعلام DNS، ويتم تنفيذ أي بحث آخر في تسجيل DNS العام.

كما ترى، أنت المسيطر الأول على دقة الاسم. والعقلانية لهذا التصميم هي:

• قد يكون لديك سيناريو مُعقَّد يتضمن خودام DNS مخصصة ودمج مع الشبكات المحلية. في هذه الحالة، تحتاج إلى التحكم في كيفية ترجمة الأسماء إلى عناوين IP.
• قد تحتاج إلى الوصول إلى مفتاح vault بدون روابط خاصة. في هذه الحالة، يجب أن يؤدي حل اسم المضيف من الشبكة الظاهرية إلى إرجاع عنوان IP العام، لأن خزائن المفاتيح بدون ارتباطات خاصة لا تحتوي على privatelink الاسم المستعار في تسجيل الاسم.

7. تحقق من صحة الطلبات الموجهة إلى مفتاح vault تستخدام رابطاً خاصاً

الاستعلام عن /healthstatus نقطة النهاية لمفتاح vault

يوفر مفتاح vault الخاص بك /healthstatus نقطة النهاية، والتي يمكن استخدامها في التشخيصات. تتضمن رؤوس الاستجابة عنوان IP الأصلي، كما هو ظاهر في خدمة مفتاح vault. يمكنك استدعاء نقطة النهاية هذه باستخدام الأمر التالي (تذكر استخدام اسم مضيف مفتاح vault):

Windows (PowerShell):

PS C:\> $(Invoke-WebRequest -UseBasicParsing -Uri https://fabrikam.vault.azure.net/healthstatus).Headers

Key                           Value
---                           -----
Pragma                        no-cache
x-ms-request-id               3729ddde-eb6d-4060-af2b-aac08661d2ec
x-ms-keyvault-service-version 1.2.27.0
x-ms-keyvault-network-info    addr=10.4.5.6;act_addr_fam=InterNetworkV6;
Strict-Transport-Security     max-age=31536000;includeSubDomains
Content-Length                4
Cache-Control                 no-cache
Content-Type                  application/json; charset=utf-8

Linux أو نسخة حديثة من Windows 10 التي تشمل curl :

joe@MyUbuntu:~$ curl -i https://fabrikam.vault.azure.net/healthstatus

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
x-ms-request-id: 6c090c46-0a1c-48ab-b740-3442ce17e75e
x-ms-keyvault-service-version: 1.2.27.0
x-ms-keyvault-network-info: addr=10.4.5.6;act_addr_fam=InterNetworkV6;
Strict-Transport-Security: max-age=31536000;includeSubDomains
Content-Length: 4

إذا لم تحصل على نتيجة مشابهة لذلك، أو إذا حدث خطأ في الشبكة، فهذا يعني أن مفتاح vault الخاص بك غير قابل للوصول عبر اسم المضيف الذي حددته (fabrikam.vault.azure.net في المثال). إما أن اسم المضيف لا يتم حله إلى عنوان IP الصحيح أو أن لديك مشكلة اتصال في مرحلة النقل. قد يكون سبب مشاكل التوجيه، انخفاض اتصال الحزمة وأسباب أخرى. عليك القيام بالتحقق بشكل أكثر تعمقاً في هذا الأمر.

يجب أن تتضمن الاستجابة عنوان x-ms-keyvault-network-info :

x-ms-keyvault-network-info: addr=10.4.5.6;act_addr_fam=InterNetworkV6;

يعرض addrالحقل الموجود فيx-ms-keyvault-network-info رأس عنوان IP الخاص بأصل الطلب. يمكن أن يكون عنوان IP واحداً مما يلي:

• عنوان IP خاص بالجهاز الذي يقوم بالطلب. يشير هذا إلى أن الطلب يستخدم روابط خاصة أو نقاط نهاية الخدمة. هذه هي النتيجة المتوقعة للروابط الخاصة.
• عنوان IP خاص آخر غير ذلك الخاص بالجهاز الذي يقوم بالطلب. يشير هذا إلى أن بعض التوجيه المخصص فعال. لا زال هذا مؤشراً على أن الطلب يستخدم روابط خاصة أو نقاط نهاية الخدمة.
• عنوان IP العام. يشير هذا إلى أن الطلب يتم توجيه إلى الإنترنت من خلال جهاز ترجمة عناوين الشبكة (NAT). ويشير هذا إلى أن الطلب لا يستخدم روابط خاصة، وأن هناك بعض المشكلات التي تحتاج إلى إصلاح. الأسباب الشائعة لذلك هي 1) نقطة النهاية الخاصة ليست في حالة الموافقة والنجاح: و 2) اسم المضيف لا يتم حله إلى عنوان IP خاص بمفتاح vault. تتضمن هذه المقالة إجراءات استكشاف الأخطاء وإصلاحها لكلا الحالتين.

إشعار

إذا كان الطلب /healthstatus يعمل، ولكن x-ms-keyvault-network-info العنوان مفقود، فمن المحتمل أن نقطة النهاية لا تتصل بخادم مفتاح vault. بما أن الأوامر أعلاه أيضا تتحقق من صحة شهادة HTTPS قد يكون العنوان المفقود مؤشراً على العبث بالبيانات.

استعلم عن عنوان IP لمفتاح vault مباشرة

هام

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

إذا قمت بتثبيت إصدار حديث من PowerShell، يمكنك استخدامه لتخطي عمليات التحقق من -SkipCertificateCheck شهادة HTTPS، ثم يمكنك استهداف عنوان IP الخاص بمفتاح vault مباشرة:

PS C:\> $(Invoke-WebRequest -SkipCertificateCheck -Uri https://10.1.2.3/healthstatus).Headers

إذا كنت تستخدم curl، يمكنك أن تفعل الشيء نفسه مع -k الوسيطة:

joe@MyUbuntu:~$ curl -i -k https://10.1.2.3/healthstatus

يجب أن تكون الاستجابات هي نفسها من المقطع السابق، مما يعني أنه يجب أن تتضمن x-ms-keyvault-network-info عنوان بنفس القيمة. /healthstatusلا يوجد فارق بالنسبة لنقطة النهاية إذا كنت تستخدم اسم مضيف مفتاح vault أو عنوان IP.

إذا وجدت أن x-ms-keyvault-network-info إرجاع قيمة واحدة للطلب يتم باستخدام اسم مضيف مفتاح vault وقيمة أخرى للطلب تتم باستخدام عنوان IP، فإن كل طلب يستهدف نقطة نهاية مختلفة. راجع شرح addrالحقل من x-ms-keyvault-network-info القسم السابق، لتحديد الحالة الخاطئة التي تحتاج لإصلاح.

8. تغييرات وتخصيصات أخرى مؤثرة

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

تشخيص خوادم DNS المخصصة في الشبكة الظاهرية

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

إذا كنت تستخدم خوادم DNS Azure المتاحة افتراضياً، فإن هذا المستند بأكمله قابل للتطبيق.

تشخيص تجاوز المصيفين أو خوادم DNS المخصصة في الجهاز الظاهري

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

وكلاء مختلطة (عابث، الخ)

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

عناصر أخرى قد تؤثر على الاتصال

هذه قائمة غير شاملة للعناصر التي يمكن العثور عليها في سيناريوهات متقدمة أو معقدة:

• إعدادات جدار الحماية، إما جدار حماية Azure المتصل بالشبكة الظاهرية، أو حل جدار حماية مخصص يتم توزيعه في الشبكة الظاهرية أو في الجهاز.
• تناظر الشبكة، والذي قد يؤثر على خوادم DNS المستخدمة وكيفية توجيه نسبة استخدام الشبكة.
• قد تؤثر حلول بوابة ترجمة عناوين الشبكة المخصصة (NAT) على كيفية توجيه حركة المرور، بما في ذلك حركة المرور من استعلامات DNS.