لماذا يرسل Windows أسماء شبكتك الخاصة إلى خادم DNS لم تُعدّه أنت

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

ما الذي غيّرته، وما الذي يقرّر فعلاً

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

لهذا السبب يمكن لاسمين على الحاسوب نفسه أن يسلكا مسارين مختلفين في اللحظة ذاتها. المضيف تحت اللاحقة المؤسسية يتبع قاعدته، والاسم العام يتبع المسار الافتراضي، وهو عادةً المحوّل الذي يردّ أولاً.

كيف يطابق الجدول الاسم

تُفهرَس القواعد حسب النطاق، وأدقّ تطابق هو الذي يفوز. قاعدة من أجل corp.example تنطبق على vpn.corp.example ولا تنطبق على example.net. والقاعدة ذات النطاق . تغطي كل ما لا تغطيه القواعد الأخرى، ما يجعلها أخطر مدخل في القائمة وأول ما يستحق الفحص عندما يُحلّ موقع غير ذي صلة عبر النفق.

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

اقرأ الجدول الفعّال، لا قائمة الأمنيات

القواعد المهيّأة والقواعد الفعّالة سؤالان مختلفان. يسرد Get-DnsClientNrptRule ما هو موجود على الجهاز. ويعرض Get-DnsClientNrptPolicy -Effective ما سيطبّقه العميل فعلاً، بالقيم المدمجة من السياسة والإعدادات المحلية.

قارن اللاحقة في ذلك الناتج بالاسم الذي تختبره، حرفاً بحرف. قاعدة من أجل corp.example لا تلتقط اسماً ينتهي بـ corp.example.com، ونقطة زائدة في موضع واحد دون الآخر تكفي لتغيير التطابق.

بلا قاعدة، يسأل Windows أكثر من محوّل

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

هناك مخرجان. أضف قاعدة للنطاق حتى يتوقف القرار عن أن يكون سباقاً، أو أوقف السلوك المتوازي عبر سياسة عميل DNS واقبل التحليل الأبطأ الحتمي. والأول أنسب عادةً لـ VPN ذي نفق منقسم، لأنه يوثّق النية بدل الاعتماد على الترتيب.

مسارات تتجاوز المحلّل كلياً

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

تحقّق أيضاً مما إذا كان التطبيق يتصل بعنوان مخزّن مؤقتاً من جلسة سابقة. Clear-DnsClientCache ثم إعادة البحث نفسه يعطي إجابة أنظف من الاستنتاج من نتيجة قديمة.

اختبر بالاسم الذي فشل

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

إن حُلّ الاسم وما زالت الخدمة ترفض، فتوقف عن تعديل DNS. الخطوة المفيدة التالية هي العنوان والمسار إليه، لأن تحليل الأسماء أدّى مهمته بالفعل.