مشاركة عبر

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

  • مقالة

مقدمة

تساعد هذه المقالة المستخدمين على تشخيص وإصلاح المشكلات التي تتضمن مفتاح 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 بعيد يتم توفيره عند الطلب بدلاً من مستعرض المستخدم.

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

هذا الدليل غير قابل للتطبيق على الحلول التي تتم إدارتها من قبل Microsoft، حيث يتم الوصول إلى مفتاح Vault بواسطة منتج Azure الموجود بشكل مستقل عن الشبكة الظاهرية للعميل. ومن الأمثلة على هذه السيناريوهات تخزين Azure أو Azure SQL المكون للتشفير في حالة الثبات، وتشفير Azure Event Hubs للبيانات باستخدام المفاتيح التي يوفرها العميل، ووصول Azure Data Factory إلى بيانات اعتماد الخدمة المخزنة في مخزن المفاتيح، واسترجاع Azure Pipelines للبيانات السرية من مخزن المفاتيح، وسيناريوهات أخرى مشابهة. في هذه الحالات، يجب عليك التحقق مما إذا كان المنتج يدعم مفاتيح vaults مع تمكين جدار الحماية. يتم تنفيذ هذا الدعم عادة مع ميزة "الخدمات الموثوق بها" جدار حماية "مفتاح 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 الخاص والدقيق لمفتاح vault الخاص بك بالإضافة إلى تمكين الروابط الخاصة. للعثور على هذا العنوان اتبع هذا الإجراء:

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

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

إشعار

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

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

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

هذا القسم مخصص لتعلم الأغراض إذا كان مفتاح 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 لا يحتوي على نقطة نهاية خاصة متصلة في الحالة المعتمدة، وبالتالي لا يحتاج مفتاح Vault لدعم الروابط الخاصة.

إذا كان مفتاح 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. وهذا يعني أن وحدة البيانات الخاصة بمفتاح vault جاهزة لقبول الطلبات من الروابط الخاصة.

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

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

إذا كان مفتاح 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 الخاصة. المزيد عن هذه النقطة سيتم شرحه لاحقاً.

إشعار

النتيجة الموضحة أعلاه تحدث فقط عندما يكون الجهاز الظاهري متصل بالشبكة الظاهرية التي تم فيها إنشاء نقطة النهاية الخاصة. إذا لم يكن لديك VM موزعاً في الشبكة الظاهرية التي تتضمن نقطة النهاية الخاصة، قم بتوزيع واحدة ووصلها عن بعد بها، ثم نفذ 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 التي تنشأ من الشبكة الظاهرية عن الأسماء في منطقة DNS الخاصة. هذا مطلوب لتحليل العنوان الصحيح الذي تم إجراؤه في الأجهزة الظاهرية المتصلة بالشبكة الظاهرية حيث تم إنشاء نقطة النهاية الخاصة.

إشعار

إذا قمت بحفظ الارتباط للتو، فقد يستغرق الأمر بعض الوقت حتى يدخل هذا حيز التنفيذ، حتى بعد أن تعلمك البوابة بإن العملية قد اكتملت. قد تحتاج أيضاً إلى إعادة تشغيل الجهاز الظاهري الذي تستخدمه لاختبار تحليل 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 العام لمفتاح vault له الاسم المستعار fabrikam.privatelink.vaultcore.azure.net (لاحظ أن لاحقة اسم مضيف مفتاح vault تطابق اسم منطقة DNS الخاصة بالضبط)، فسيبحث استعلام DNS عن A سجل بالاسم في منطقة DNS fabrikamالخاصة. إذا A تم العثور على السجل، يتم إرجاع عنوان IP الخاص به في استعلام DNS، ويتم تنفيذ أي بحث آخر في تسجيل DNS العام.

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

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

الاستعلام عن /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.