تحليل الاسم للموارد في الشبكات الظاهرية لـ Azure

يمكنك استخدام Azure لاستضافة البنية الأساسية كخدمة (IaaS) والنظام الأساسي كخدمة (PaaS) والحلول المختلطة. لتسهيل الاتصال بين الأجهزة الظاهرية (VMs) والموارد الأخرى المنشورة في شبكة ظاهرية، قد يكون من الضروري السماح لها بالاتصال ببعضها البعض. استخدام الأسماء التي يمكن تذكرها بسهولة ودون تغيير يبسط عملية الاتصال، بدلا من الاعتماد على عناوين IP.

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

• مناطق Azure Private DNS
• تحليل الاسم الموفر من Azure
• تحليل الاسم الذي يستخدم خادم نظام أسماء المجالات (DNS) الخاص بك (والذي قد يقوم بإعادة توجيه الاستعلامات إلى خوادم DNS التي توفرها Azure)
• محلل Azure DNS الخاص

يعتمد نوع تحليل الاسم الذي تستخدمه على المدى الذي تحتاج إليه مواردك للاتصال ببعضها. يوضح الجدول التالي السيناريوهات وحلول تحليل الاسم المقابلة.

مناطق Azure Private DNS هي الحل المفضل وتمنحك المرونة في إدارة مناطق وسجلات DNS. لمزيد من المعلومات، راجع استخدام Azure DNS للمجالات الخاصة.

إشعار

إذا كنت تستخدم DNS المقدم من Azure، يتم تطبيق لاحقة DNS المناسبة تلقائيا على الأجهزة الظاهرية الخاصة بك. بالنسبة لجميع الخيارات الأخرى، يجب عليك إما استخدام أسماء المجالات المؤهلة بالكامل (FQDNs) أو تطبيق لاحقة DNS المناسبة يدويا على الأجهزة الظاهرية الخاصة بك.

السيناريو	حل	لاحقة DNS
تحليل الاسم بين الأجهزة الظاهرية الموجودة في نفس الشبكة الظاهرية أو مثيلات دور Azure Cloud Services في نفس الخدمة السحابية.	مناطق Azure Private DNS أو تحليل الاسم المقدم من Azure	اسم المضيف أو FQDN
تحليل الاسم بين الأجهزة الظاهرية في الشبكات الظاهرية المختلفة أو مثيلات الدور في خدمات سحابية مختلفة.	مناطق Azure Private DNS أو محلل Azure DNS الخاص أو خوادم DNS المدارة من قبل العميل التي تقوم بإعادة توجيه الاستعلامات بين الشبكات الظاهرية للتحليل بواسطة Azure (وكيل DNS). راجع تحليل الاسم باستخدام خادم DNS الخاص بك.	FQDN فقط
تحليل الاسم من Azure App Service (تطبيق ويب أو وظيفة أو روبوت) باستخدام تكامل الشبكة الظاهرية لمثيلات الأدوار أو الأجهزة الظاهرية في نفس الشبكة الظاهرية.	المحلل الخاص لـ Azure DNS أو خوادم DNS المدارة من قبل العميل تعيد توجيه الاستعلامات بين الشبكات الظاهرية للحل بواسطة Azure (وكيل DNS). راجع تحليل الاسم باستخدام خادم DNS الخاص بك.	FQDN فقط
تحليل الاسم من تطبيقات ويب App Service إلى الأجهزة الظاهرية في نفس الشبكة الظاهرية.	المحلل الخاص لـ Azure DNS أو خوادم DNS المدارة من قبل العميل تعيد توجيه الاستعلامات بين الشبكات الظاهرية للحل بواسطة Azure (وكيل DNS). راجع تحليل الاسم باستخدام خادم DNS الخاص بك.	FQDN فقط
تحليل الاسم من تطبيقات ويب App Service في شبكة ظاهرية واحدة إلى أجهزة ظاهرية في شبكة ظاهرية مختلفة.	المحلل الخاص لـ Azure DNS أو خوادم DNS المدارة من قبل العميل تعيد توجيه الاستعلامات بين الشبكات الظاهرية للحل بواسطة Azure (وكيل DNS). راجع تحليل الاسم باستخدام خادم DNS الخاص بك.	FQDN فقط
دقة الكمبيوتر المحلي وأسماء الخدمة من الأجهزة الظاهرية أو مثيلات الدور في Azure.	محلل Azure DNS الخاص أو خوادم DNS المدارة من قبل العميل (وحدة تحكم المجال المحلية أو وحدة التحكم بالمجال للقراءة فقط المحلية أو DNS الثانوية التي تمت مزامنتها باستخدام عمليات نقل المنطقة، على سبيل المثال). راجع تحليل الاسم باستخدام خادم DNS الخاص بك.	FQDN فقط
تحليل أسماء مضيفي Azure من أجهزة الكمبيوتر المحلية.	أعد توجيه الاستعلامات إلى خادم وكيل DNS الذي يديره العميل في الشبكة الظاهرية المقابلة. ثم يقوم الخادم الوكيل بإعادة توجيه الاستعلامات إلى Azure للحصول على التحليل. راجع تحليل الاسم باستخدام خادم DNS الخاص بك.	FQDN فقط
عكس DNS لعناوين IP الداخلية.	مناطق Azure Private DNS أو تحليل الاسم المقدم من Azure أو محلل Azure DNS الخاص أو تحليل الاسم باستخدام خادم DNS الخاص بك.	غير قابل للتطبيق
تحليل الاسم بين الأجهزة الظاهرية أو مثيلات الدور الموجودة في خدمات سحابية مختلفة، وليس في شبكة ظاهرية.	غير قابل للتطبيق. الاتصال بين الأجهزة الظاهرية ومثيلات الأدوار في خدمات سحابية مختلفة غير مدعوم خارج شبكة ظاهرية.	غير قابل للتطبيق

تحليل الاسم الموفر من Azure

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

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

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

إشعار

عند استخدام أدوار الويب والعاملين في Azure Cloud Services، يمكنك أيضا الوصول إلى عناوين IP الداخلية لمثيلات الأدوار باستخدام واجهة برمجة تطبيقات REST لإدارة خدمة Azure. لمزيد من المعلومات، راجع مرجع واجهة برمجة تطبيقات REST لإدارة الخدمة. يستند العنوان إلى اسم الدور ورقم المثيل.

الميزات

يتضمن تحليل الاسم المتوفر في Azure الميزات التالية:

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

الاعتبارات

عند استخدام تحليل الاسم المقدم من Azure، ضع في اعتبارك النقاط التالية:

• لا يمكن تعديل لاحقة DNS التي تم إنشاؤها بواسطة Azure.
• يتم تحديد نطاق بحث DNS إلى شبكة ظاهرية. لا يمكن حل أسماء DNS التي تم إنشاؤها لشبكة ظاهرية واحدة من الشبكات الظاهرية الأخرى.
• التسجيل اليدوي للسجلات الخاصة بك غير مسموح به.
• WINS وNetBIOS غير مدعومين. لا يمكنك رؤية الأجهزة الظاهرية في مستكشف Windows.
• يجب أن تكون أسماء المضيفين متوافقة مع DNS. يجب أن تستخدم الأسماء من 0 إلى 9 فقط، من أ إلى ي، والواصلة (-). لا يمكن أن تبدأ الأسماء أو تنتهي بواصلة.
• يتم تقييد حركة مرور استعلام DNS لكل جهاز ظاهري. يجب ألا يؤثر التقييد على معظم التطبيقات. إذا لاحظت تقييد الطلب، فتأكد من تمكين التخزين المؤقت من جانب العميل. لمزيد من المعلومات، راجع تكوين عميل DNS.
• يجب استخدام اسم مختلف لكل جهاز ظاهري في شبكة ظاهرية لتجنب مشكلات حل DNS.
• يتم تسجيل الأجهزة الظاهرية فقط في أول 180 خدمة سحابية لكل شبكة ظاهرية في نموذج توزيع كلاسيكي. لا ينطبق هذا الحد على الشبكات الظاهرية في Resource Manager.
• عنوان IP لنظام Azure DNS هو 168.63.129.16. هذا العنوان هو عنوان IP ثابت ولا يتغير.

اعتبارات DNS العكسية

يتم دعم DNS العكسي للأجهزة الظاهرية في جميع الشبكات الظاهرية استنادا إلى Resource Manager. DNS العكسي المدار من Azure، والمعروف أيضا باسم المؤشر (PTR)، تتم إضافة سجلات النموذج \[vmname\].internal.cloudapp.net تلقائيا إلى DNS عند بدء تشغيل جهاز ظاهري. تتم إزالتها عند إيقاف الجهاز الظاهري (إلغاء تخصيصه). راجع المثال التالي:

C:\>nslookup -type=ptr 10.11.0.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.0.11.10.in-addr.arpa  name = myeastspokevm1.internal.cloudapp.net

internal.cloudapp.net منطقة DNS العكسية هي Azure المدارة ولا يمكن عرضها أو تحريرها مباشرة. يتم حل البحث للأمام على FQDN الخاص بالنموذج \[vmname\].internal.cloudapp.net إلى عنوان IP المعين للجهاز الظاهري.

إذا كانت منطقة Azure Private DNS مرتبطة بالشبكة الظاهرية بارتباط شبكة ظاهرية وتم تمكين التسجيل التلقائي على هذا الارتباط، فإن استعلامات DNS العكسية ترجع سجلين. أحد السجلات هو من النموذج \[vmname\].[privatednszonename] والآخر من النموذج \[vmname\].internal.cloudapp.net. راجع المثال التالي:

C:\>nslookup -type=ptr 10.20.2.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.2.20.10.in-addr.arpa  name = mywestvm1.internal.cloudapp.net
4.2.20.10.in-addr.arpa  name = mywestvm1.azure.contoso.com

عند إرجاع سجلي PTR كما هو موضح سابقا، يقوم البحث للأمام لأي من FQDN بإرجاع عنوان IP للجهاز الظاهري.

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

لا يتم تخزين سجلات DNS العكسية (PTR) في منطقة DNS خاصة للأمام. يتم تخزين سجلات DNS العكسية في منطقة DNS عكسية (in-addr.arpa). منطقة DNS العكسية الافتراضية المقترنة بشبكة ظاهرية غير قابلة للعرض أو التحرير.

يمكنك تعطيل دالة DNS العكسية في شبكة ظاهرية. إنشاء منطقة البحث العكسي الخاصة بك باستخدام مناطق Azure Private DNS. ثم اربط هذه المنطقة بشبكتك الظاهرية. على سبيل المثال، إذا كانت مساحة عنوان IP للشبكة الظاهرية هي 10.20.0.0/16، يمكنك إنشاء منطقة 20.10.in-addr.arpa DNS خاصة فارغة وربطها بالشبكة الظاهرية. تتجاوز هذه المنطقة مناطق البحث العكسي الافتراضية للشبكة الظاهرية. هذه المنطقة فارغة. ترجع NXDOMAIN DNS العكسية ما لم تقم بإنشاء هذه الإدخالات يدويا.

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

إشعار

نظرا لأن مناطق Azure DNS الخاصة عمومية، يمكنك إنشاء بحث DNS عكسي للامتداد عبر شبكات ظاهرية متعددة. تحتاج إلى إنشاء منطقة Azure Private DNS للبحث العكسي (منطقة in-addr.arpa )، ثم ربطها بالشبكات الظاهرية. يجب عليك إدارة سجلات DNS العكسية يدويا للأجهزة الظاهرية.

تكوين عميل DNS

يغطي هذا القسم التخزين المؤقت من جانب العميل وإعادة المحاولة من جانب العميل.

التخزين المؤقت من جانب العميل

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

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

تتوفر العديد من حزم التخزين المؤقت DNS المختلفة (مثل dnsmasq). فيما يلي كيفية التثبيت dnsmasq على التوزيعات الأكثر شيوعا:

RHEL

RHEL (يستخدم NetworkManager)

1. تثبيت الحزمة dnsmasq باستخدام الأمر التالي:

   sudo yum install dnsmasq
   

2. dnsmasq تمكين الخدمة باستخدام الأمر التالي:

   systemctl enable dnsmasq.service
   

3. dnsmasq ابدأ الخدمة بالأمر التالي:

   systemctl start dnsmasq.service
   

4. استخدم محرر نص لإضافته prepend domain-name-servers 127.0.0.1; إلى /etc/dhclient-eth0.conf:

5. استخدم الأمر التالي لإعادة تشغيل خدمة الشبكة:

   service network restart
   

openSUSE, SLES

openSUSE/SLES (يستخدم netconf)

1. تثبيت الحزمة dnsmasq باستخدام الأمر التالي:

   sudo zypper install dnsmasq
   

2. dnsmasq تمكين الخدمة باستخدام الأمر التالي:

   systemctl enable dnsmasq.service
   

3. dnsmasq ابدأ الخدمة بالأمر التالي:

   systemctl start dnsmasq.service
   

4. استخدم محرر نص لتحرير /etc/sysconfig/network/config. قم بتغيير NETCONFIG_DNS_FORWARDER="" إلى dnsmasq

5. استخدم الأمر التالي للتحديث resolv.conf لتعيين ذاكرة التخزين المؤقت كمحلل DNS المحلي:

   netconfig update
   

أوبونتو، ديبيان

Ubuntu/Debian (يستخدم resolvconf)

استخدم الأمر التالي لتثبيت الحزمة dnsmasq :

sudo apt-get install dnsmasq

إشعار

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

عمليات إعادة المحاولة من جانب العميل

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

• أنظمة تشغيل Windows تقوم بإعادة المحاولة بعد ثانية واحدة، ثم مرة أخرى بعد ثانيتين أخريين، وأربع ثوانٍ، وأربع ثوانٍ أخرى.
• يعيد إعداد Linux الافتراضي المحاولة بعد خمس ثوانٍ. نوصي بتغيير مواصفات إعادة المحاولة إلى خمس مرات، على فترات ثانية واحدة.

تحقق من الإعدادات الحالية على جهاز Linux الظاهري باستخدام cat /etc/resolv.conf. انظر إلى options السطر، على سبيل المثال:

options timeout:1 attempts:5

يتم resolv.conf إنشاء الملف تلقائيا ولا يجب تحريره. تختلف الخطوات المحددة لإضافة options السطر حسب التوزيع.

RHEL

RHEL (يستخدم NetworkManager)

1. استخدم محرر نص لإضافة السطر RES_OPTIONS="options timeout:1 attempts:5" إلى الملف /etc/sysconfig/network-scripts/ifcfg-eth0.

2. استخدم الأمر التالي لإعادة تشغيل NetworkManager الخدمة:

   systemctl restart NetworkManager.service
   

openSUSE, SLES

openSUSE/SLES (يستخدم netconf)

1. استخدم محرر نص لإضافته **timeout:1 attempts:5** إلى المعلمة NETCONFIG_DNS_RESOLVER_OPTIONS="" في /etc/sysconfig/network/config.

2. استخدم الأمر التالي لتحديث netconfig:

   netconfig update
   

أوبونتو، ديبيان

Ubuntu/Debian (يستخدم resolvconf)

1. استخدم محرر نص لإضافة options السطر إلى /etc/resolvconf/resolv.conf.d/tail.

2. استخدم الأمر التالي لتحديث resolvconf:

   resolvconf -u
   

تحليل الاسم الذي يستخدم خادم DNS الخاص بك

يغطي هذا القسم الأجهزة الظاهرية، ومثيلات الأدوار، وتطبيقات الويب.

إشعار

يحل مُحلل Azure DNS الخاص الحاجة إلى استخدام خوادم DNS المستندة إلى الجهاز الظاهري في شبكة ظاهرية. يتم توفير القسم التالي إذا كنت تريد استخدام حل DNS المستند إلى الجهاز الظاهري. تتضمن الفوائد العديدة لاستخدام Azure DNS Private Resolver تقليل التكلفة والتوافر العالي المضمن وقابلية التوسع والمرونة.

الأجهزة الظاهرية ومثيلات الأدوار

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

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

هام

إذا تم استخدام بوابة Azure VPN في هذا الإعداد جنبا إلى جنب مع عناوين IP المخصصة لخادم DNS على شبكة ظاهرية، يجب إضافة عنوان IP ل Azure DNS (168.63.129.16) في القائمة للحفاظ على الخدمة غير الممزقة.

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

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

إشعار

يمكن لمثيل الدور تنفيذ تحليل الاسم للأجهزة الظاهرية داخل نفس الشبكة الظاهرية. يستخدم FQDN، الذي يتكون من اسم مضيف الجهاز الظاهري ولاحقة internal.cloudapp.net DNS. في هذه الحالة، يكون تحليل الاسم ناجحا فقط إذا كان لمثيل الدور اسم الجهاز الظاهري المحدد في مخطط الدور (ملف .cscfg): <Role name="<role-name>" vmName="<vm-name>">.

يجب على مثيلات الدور التي تحتاج إلى تنفيذ تحليل الاسم للأجهزة الظاهرية في شبكة ظاهرية أخرى (FQDN باستخدام internal.cloudapp.net اللاحقة) استخدام الأسلوب الموضح في هذا القسم (إعادة توجيه خوادم DNS المخصصة بين الشبكتين الظاهريتين).

.

عند استخدام تحليل الاسم المقدم من Azure، يوفر بروتوكول تكوين المضيف الديناميكي Azure (DHCP) لاحقة DNS داخلية (.internal.cloudapp.net) لكل جهاز ظاهري. تمكن هذه اللاحقة دقة اسم المضيف لأن سجلات اسم المضيف موجودة في internal.cloudapp.net المنطقة. عند استخدام حل تحليل الاسم الخاص بك، لا يتم توفير هذه اللاحقة للأجهزة الظاهرية لأنها تتداخل مع بنيات DNS الأخرى (مثل السيناريوهات المرتبطة بالمجال). بدلا من ذلك، يوفر Azure عنصر نائب غير وظيفي (reddog.microsoft.com).

إذا لزم الأمر، يمكنك تحديد لاحقة DNS الداخلية باستخدام PowerShell أو واجهة برمجة التطبيقات.

بالنسبة للشبكات الظاهرية في نماذج نشر Resource Manager، تتوفر اللاحقة عبر واجهة الشبكة REST API، والحصول على AzNetworkInterface PowerShell cmdlet، والأمر az network nic show Azure CLI.

إذا كانت إعادة توجيه الاستعلامات إلى Azure لا تناسب احتياجاتك، فوفر حل DNS الخاص بك أو انشر Azure DNS Private Resolver.

إذا قمت بتوفير حل DNS الخاص بك، فإنه يحتاج إلى:

• توفير دقة اسم المضيف المناسبة، عبر DNS الديناميكي (DDNS)، على سبيل المثال. إذا كنت تستخدم DDNS، فقد تحتاج إلى تعطيل مسح سجلات DNS. عقود إيجار Azure DHCP طويلة، وقد يؤدي البحث إلى إزالة سجلات DNS قبل الأوان.
• قم بتوفير التحليل التكراري المناسب للسماح بحل أسماء المجالات الخارجية.
• يمكن الوصول إليه (TCP وUDP على المنفذ 53) من العملاء الذين تخدمهم ويكون قادراً على الوصول إلى الإنترنت.
• تأمين ضد الوصول من الإنترنت للتخفيف من التهديدات التي يشكلها وكلاء خارجيون.

للحصول على أفضل أداء، عند استخدام أجهزة Azure الظاهرية كخوادم DNS، يجب تعطيل IPv6.

تعمل مجموعات أمان الشبكة (NSGs) كجدران حماية لنقاط نهاية محلل DNS. تعديل قواعد أمان NSG أو تجاوزها للسماح بالوصول إلى منفذ UDP 53 (واختياريا، منفذ TCP 53) إلى نقاط نهاية وحدة استماع DNS. بعد تعيين خوادم DNS المخصصة على شبكة، تتجاوز نسبة استخدام الشبكة عبر المنفذ 53 مجموعات أمان الشبكة للشبكة الفرعية.

هام

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

لمزيد من المعلومات حول هذه المشكلة، راجع معاد التوجيه ومهلات حل معاد التوجيه الشرطي.

قد تنطبق هذه التوصية أيضا على الأنظمة الأساسية الأخرى لخادم DNS مع إعادة توجيه قيم المهلة من ثلاث ثوان أو أقل.

قد يؤدي عدم القيام بذلك إلى حل سجلات منطقة DNS الخاصة بعناوين IP العامة.

تطبيقات الويب

لنفترض أنك بحاجة إلى إجراء تحليل الاسم من تطبيق الويب لديك الذي تم إنشاؤه باستخدام App Service، المرتبط بشبكة ظاهرية، إلى الأجهزة الظاهرية في نفس الشبكة الظاهرية. بالإضافة إلى إعداد خادم DNS مخصص به معيد توجيه DNS يقوم بإعادة توجيه الاستعلامات إلى Azure (عنوان IP الظاهري 168.63.129.16)، قم بتنفيذ الخطوات التالية:

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

لاستخدام خوادم DNS المخصصة:

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

لاستخدام محلل Azure DNS الخاص، راجع ارتباطات مجموعة القواعد.

قم بتحديد خوادم DNS

عند استخدام خوادم DNS الخاصة بك، يمكنك تحديد خوادم DNS متعددة لكل شبكة ظاهرية. يمكنك أيضا تحديد خوادم DNS متعددة لكل واجهة شبكة (ل Resource Manager) أو لكل خدمة سحابية (لنموذج النشر الكلاسيكي). تتمتع خوادم DNS المحددة لواجهة الشبكة أو الخدمة السحابية بالأسبقية على خوادم DNS المحددة للشبكة الظاهرية.

إشعار

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

عند استخدام نموذج توزيع Resource Manager، يمكنك تحديد خوادم DNS لشبكة ظاهرية وواجهة شبكة اتصال. لمزيد من المعلومات، راجع إدارة شبكة ظاهرية وإدارة واجهة شبكة.

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

إشعار

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

المحتوى ذو الصلة

نموذج توزيع Azure Resource Manager:

• إدارة شبكة ظاهرية
• إدارة واجهة شبكة