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

النفق ينقل الاستعلامات لا معرفة المناطق

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

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

افترض أن المنطقة هي cloud.corp.example لبقية هذا الشرح، واعتبر كل عنوان توضيحيًا.

الخيار A: نقطة النهاية الواردة المُدارة

يوفّر Azure DNS Private Resolver نقطة نهاية واردة تقبل استعلامات DNS من خارج VNet. تنشره في شبكة فرعية مفوّضة مخصّصة، وتربط المنطقة الخاصة بتلك VNet، وتدوّن عنوان الوارد الذي تخصصه الخدمة.

على خادم DNS المحلي تُنشئ بعد ذلك مُمرِّرًا شرطيًا للنطاق الدقيق نحو ذلك العنوان:

Namespace: cloud.corp.example
Forward to: 10.20.2.4

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

المقابل هو أنك تملك الآن مورد محلّل وتفويض شبكته الفرعية وتكلفته، وهي تكلفة حقيقية حتى عندما يكون حجم الاستعلامات ضئيلاً.

الخيار B: جهاز افتراضي مُمرِّر داخل VNet

يشغّل التصميم الأقدم برنامج DNS على جهاز افتراضي عادي داخل VNet: Windows DNS أو BIND أو dnsmasq، مع استضافة المنطقة الخاصة محليًا أو تمريرها إلى محلّل Azure المدمج على 168.63.129.16. ويشير المُمرِّر الشرطي المحلي إلى العنوان الخاص لذلك الجهاز.

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

مضيف VNet عادي ليس وكيل DNS حتى يُثبَّت البرنامج ويُسمح له بالإجابة عن هؤلاء العملاء، وهي الخطوة التي يتجاوزها الناس عند استنساخ جهاز افتراضي.

أي التصميمين يناسب تشغيلك

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

QuestionManaged inbound endpointForwarder VM
Software to patchNoneThe DNS service on every instance
Address stabilityFixed for the resource lifetimeTied to the VM or its reserved address
Availability workHandled by the serviceSecond instance, health checks, failover
Extra logicLimited to resolver featuresWhatever the DNS software supports

أيًا كان الصف الذي يحسم الأمر، تبدو قاعدة المُمرِّر المحلية نفسها. هذا هو الجزء الذي يجب أن يوجد في كلا التصميمين، وهو الجزء الأكثر غيابًا عندما يبلّغ أحدهم أن التحليل يعمل من داخل Azure ولكن ليس من المكتب.

افحص المسار بالترتيب

تأكد من أن المنطقة مرتبطة بـ VNet التي تضم المحلّل، وتأكد من أن المُمرِّر المحلي يسمّي النطاق لا نطاقًا أب. المُمرِّر الخاص بـ corp.example لن يطابق cloud.corp.example ما لم يكن المحلّل نفسه يفوّض، وعدم التطابق ينتج إجابة سلبية نظيفة تبدو كسجل مفقود.

ثم تحقق من وصول الاستعلام إلى نقطة النهاية: يحتاج المصدر المحلي إلى مسار إلى عنوان المحلّل ومسار عودة، ويجب السماح بمنفذ 53 لكل من UDP وTCP حيث تسمح السياسة. لا يمكن لمجموعة أمان شبكة أن توفّر سجل منطقة مفقودًا، ولا يمكن لمنطقة صحيحة أن تجيب عن استعلام لا يصل أبدًا.

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

مقالات ذات صلة