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

هل هذه الصفحة مفيدة؟

هل لديك ملاحظات إضافية؟

سيتم إرسال الملاحظات إلى Microsoft: بالضغط على الزر «إرسال»، سيتم استخدام ملاحظاتك لتحسين منتجات Microsoft وخدماتها. نهج الخصوصية.

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

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

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

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

ملاحظة

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

ملاحظة

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

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

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

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

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

ملاحظة

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

الميزات

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

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

الاعتبارات

النقاط التي يجب مراعاتها عند استخدام دقة الاسم المقدمة من Azure:

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

عكس اعتبارات DNS

يتم دعم عكس DNS في جميع الشبكات الظاهرية المستندة إلى ARM. يمكنك إصدار استعلامات DNS عكسية (استعلامات PTR) لتعيين عناوين IP للأجهزة الظاهرية إلى أسماء مجالات مؤهلة بالكامل للأجهزة الظاهرية.

• ستقوم جميع استعلامات PTR لعناوين IP للأجهزة الظاهرية بإرجاع أسماء مجالات مؤهلة بالكامل من النموذج [vmname].internal.cloudapp.net
• سيؤدي إعادة توجيه البحث على أسماء المجالات المؤهلة بالكامل من النموذج [vmname].internal.cloudapp.net إلى تحليل عنوان IP المعين للجهاز الظاهري.
• إذا كانت الشبكة الظاهرية مرتبطة بمناطق Azure DNS خاصة كشبكة ظاهرية للتسجيل، فستعرض استعلامات DNS العكسية سجلين. سيكون أحد السجلات من النموذج [vmname].[privatednszonename]، بينما سيكون السجل الآخر من النموذج [vmname].internal.cloudapp.net
• يتم تحديد نطاق بحث DNS العكسي على شبكة ظاهرية معينة حتى إذا تم عرضه على شبكات ظاهرية أخرى. ستؤدي استعلامات DNS العكسية (استعلامات PTR) لعناوين IP للأجهزة الظاهرية الموجودة في الشبكات الظاهرية النظيرة إلى إرجاع NXDOMAIN.
• إذا كنت ترغب في إيقاف تشغيل دالة DNS العكسية في شبكة ظاهرية، يمكنك القيام بذلك عن طريق إنشاء منطقة بحث عكسي باستخدام مناطق Azure DNS الخاصة وربط هذه المنطقة بشبكتك الظاهرية. على سبيل المثال، إذا كانت مساحة عنوان IP لشبكتك الظاهرية هي 10.20.0.0/16، يمكنك إنشاء منطقة DNS خاصة فارغة 20.10.in-addr.arpa وربطها بالشبكة الظاهرية. أثناء ربط المنطقة بشبكتك الظاهرية، يجب عليك تعطيل التسجيل التلقائي على الرابط. ستتجاوز هذه المنطقة مناطق البحث العكسي الافتراضية للشبكة الظاهرية وبما أن هذه المنطقة فارغة، فستحصل على NXDOMAIN لاستعلامات DNS العكسية. راجع دليل التشغيل السريع للحصول على تفاصيل حول كيفية إنشاء منطقة DNS خاصة وربطها بشبكة ظاهرية.

ملاحظة

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

تكوين عميل DNS

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

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

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

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

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

• Ubuntu (يستخدم resolvconf)
  • قم بتثبيت حزمة dnsmasq باستخدام sudo apt-get install dnsmasq.
• SUSE (يستخدم netconf):
  • قم بتثبيت حزمة dnsmasq باستخدام sudo zypper install dnsmasq.
  • قم بتمكين خدمة dnsmasq باستخدام systemctl enable dnsmasq.service.
  • ابدأ تشغيل خدمة dnsmasq باستخدام systemctl start dnsmasq.service.
  • حرر /etc/sysconfig/network/config، وقم بتغيير NETCONFIG_DNS_FORWARDER="" إلى dnsmasq.
  • قم بتحديث resolv.conf باستخدام netconfig update، لتعيين ذاكرة التخزين المؤقت كمحلل DNS المحلي.
• CentOS (يستخدم NetworkManager):
  • قم بتثبيت حزمة dnsmasq باستخدام sudo yum install dnsmasq.
  • قم بتمكين خدمة dnsmasq باستخدام systemctl enable dnsmasq.service.
  • ابدأ تشغيل خدمة dnsmasq باستخدام systemctl start dnsmasq.service.
  • أضف prepend domain-name-servers 127.0.0.1; إلى /etc/dhclient-eth0.conf.
  • أعد تشغيل خدمة الشبكة باستخدام service network restart، لتعيين ذاكرة التخزين المؤقت كمحلل DNS المحلي.

ملاحظة

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

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

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

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

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

options timeout:1 attempts:5

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

• Ubuntu (يستخدم resolvconf):
  1. أضف سطر الخيارات إلى /etc/resolvconf/resolv.conf.d/tail.
  2. شغِّل resolvconf -u للتحديث.
• SUSE (يستخدم netconf):
  1. أضف المهلة:1 محاولات:5 إلى المعلمة NETCONFIG_DNS_RESOLVER_OPTIONS="" في /etc/sysconfig/network/config.
  2. شغِّل netconfig update للتحديث.
• CentOS (يستخدم NetworkManager):
  1. أضف السطر RES_OPTIONS="options المهلة:1 محاولات:5" إلى الملف /etc/sysconfig/network-scripts/ifcfg-eth0.
  2. تحديث باستخدام systemctl restart NetworkManager.service.

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

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

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

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

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

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

ملاحظة

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

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

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

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

• بالنسبة للشبكات الظاهرية في نماذج توزيع Azure Resource Manager، تتوفر اللاحقة عبر واجهة برمجة تطبيقات REST لواجهة الشبكة، وPowerShell cmdlet المسمى Get-AzNetworkInterface، وأمر Azure CLI المسمى az network nic show.
• في نماذج التوزيع الكلاسيكية، تتوفر اللاحقة عبر استدعاء واجهة برمجة تطبيقات توزيع Get أو أوامر cmdlet المسماة Get-AzureVM -Debug.

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

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

ملاحظة

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

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

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

1. قم بتمكين تكامل الشبكة الظاهرية لتطبيق الويب، إذا لم يكن قد تم ذلك بالفعل، كما هو موضح في دمج تطبيقك مع شبكة ظاهرية.

2. في مدخل Azure، بالنسبة لخطة App Service التي تستضيف تطبيق الويب، حدد مزامنة الشبكة ضمن الشبكات، تكامل الشبكة الظاهرية.

   

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

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

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

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

ملاحظة

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

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

ملاحظة

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

عند استخدام نموذج التوزيع الكلاسيكي، يمكنك تحديد خوادم DNS للشبكة الظاهرية في مدخل Azure، أو ملف تكوين الشبكة. بالنسبة للخدمات السحابية، يمكنك تحديد خوادم DNS عبر ملف تكوين الخدمة أو باستخدام PowerShell، مع New-AzureVM.

ملاحظة

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

الخطوات التالية

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

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

نموذج التوزيع الكلاسيكي:

• مخطط تكوين Azure Service
• مخطط تكوين الشبكة الظاهرية
• تكوين شبكة ظاهرية باستخدام ملف تكوين شبكة