خادمان DNS على محوّل واحد لا يقسمان النطاقات

إدراج مُحلِّلين اثنين على محوّل واحد يبدو وسيلة لإرسال نطاق إلى خادم وإرسال نطاق آخر إلى الخادم الثاني، ولا شيء في قائمة المُحلِّلات يعمل بهذه الطريقة. يعمل Windows على تحليل الأسماء، وقرار أي خادم يُسأل يأتي من كائنات سياسة لا من قائمة عناوين مرتَّبة. النموذج الذهني الذي يجب استبداله هو الطابور: لا وجود لخادم أول لنطاق A وخادم ثانٍ لنطاق B. هناك مجموعة قواعد لكل نطاق تسمّي الخوادم صراحةً، وبمجرّد وجود تلك القواعد تتوقف قائمة المحوّل عن أن تكون مثيرة للاهتمام.

الأسطورة: عنوانان لا يقسمان نطاقين

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

لا تعرف القائمة المرتَّبة مفهوم النطاق، فلا تستطيع التعبير عن القصد. ما تتحكم فيه القائمة فعلاً هو أي خادم يُسأل أولاً وأيّهما يُجرَّب ثانيًا، وكلا الجوابين ينطبق على كل اسم بالتساوي.

ما يستخدمه Windows فعلاً للاختيار

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

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

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

قاعدة واحدة لكل نطاق، واحفظ الكائن

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

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

النقطة البادئة تدلّ على مطابقة لاحقة، فالقاعدة تغطي app.svc.internal.example وأي شيء آخر تحته. العنوانان هنا ينتميان إلى خطة التوجيه الخاصة بهذا المختبر؛ والقاعدة لا تُنشئ منطقة ولا تثبّت مسارًا ولا تُصرّح للتطبيق الذي يتصل في النهاية، و مرجع Add-DnsClientNrptRule يوضّح بالضبط أي المعاملات يفعل ماذا.

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

أثبت أن العميل اختار الخادم

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

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

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

احذف بالضبط ما أنشأته

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

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

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