كيف تفحص محلّلات DNS التي يستخدمها جهاز Mac على شبكة VPN

scutil --dns يطبع إعدادات المحلّل التي يقرأها macOS فعلاً، لا خادم DNS الوحيد الذي كتبته في لوحة الإعدادات. المخرجات أطول مما يتوقع معظم الناس، لأن النظام يحتفظ بكتل محلّل منفصلة للمسار الافتراضي، وللواجهات المحدّدة النطاق، وللإعادة التوجيه الخاص بنطاقات معيّنة. الكتلة في أعلى المخرجات ليست بالضرورة التي تجيب عن الاستعلام. إذا كان اسم خاص يُحلّ في المكتب ثم يفشل لحظة اتصال VPN، فعدم التطابق في قواعد المطابقة والمسارات، لا في عنوان الخادم. اقرأ الترتيب أولاً، ثم أثبت الإجابة ببحث حقيقي.

اقرأ ترتيب الكتل قبل العناوين

كل مدخل يبدأ بـ resolver #N ويسرد nameserver[0]، وأحياناً if_index، وسطر flags، وreach، وعندما لا تكون الكتلة افتراضية صرفة، domain وقائمة search domain. المحلّل رقم 1 بلا نطاق هو الافتراضي الذي يتعامل مع الأسماء العامة. أي شيء يحمل Scoped في أعلامه مرتبط بالواجهة التي يسمّيها if_index، وأي شيء موسوم Supplemental ينطبق فقط على النطاقات المدرجة تحته.

الاختيار مطابقة لاحقة. لاسم مثل intranet.corp.example، يفضّل macOS المحلّل الذي يكون فيه مدخل domain أطول لاحقة مطابقة، لذا تفوز كتلة فيها domain : corp.example على الافتراضي حتى لو كانت في أسفل المخرجات. يحسم order التعادل بين نطاقات بالطول نفسه. نادراً ما تحتاج نظرة أولى أكثر من هذا: المخرجات كاملة عندما تريد قراءة كتلة واحدة من أولها إلى آخرها، والأسطر الأولى لمعرفة ترتيب الكتل، وتمريرة مفلترة تطبع رؤوس الكتل بجانب أسطر الحقول. تظهر الكتل المحدّدة النطاق تحت عنوانها الخاص وتُقرأ كتكملة للقائمة فوقها، لذا أبقِ رأساً في مجال النظر كلما اقتبست المخرجات.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

طابِق if_index بواجهة النفق

لا يفيد الفهرس إلا إذا استطعت تسمية الواجهة خلفه. يسرد scutil --nwi معلومات الشبكة التي يحتفظ بها النظام، بما فيها الواجهة الأساسية وإمكانية الوصول، بينما يعطيك ifconfig -l الأسماء، حيث utun0 إلى utun9 هي مرشّحات النفق التي ينشئها العميل عادة. تستخدم Apple scutil --dns كمثال الفحص الخاص بها في دليل النشر, وتوثّق كيف يمكن لـ Network Extension توجيه نطاقات مختارة إلى محلّلات مختارة، وهو الميكانيزم الذي تكشفه تلك الكتل المحدّدة النطاق.

الفحص الذي يحسم المسألة هو ما إذا كان المحلّل يقع على المسار الذي ثبّته النفق:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

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

استعلم من محلّل النظام، ثم من الخادم

ثلاث أدوات تجيب عن ثلاثة أسئلة مختلفة، والخلط بينها ينتج معظم الاستنتاجات الخاطئة في هذا المجال. يمر dscacheutil -q host -a name عبر محلّل النظام نفسه الذي تستخدمه التطبيقات العادية، لذا تنطبق الكتل المحدّدة النطاق والتكميلية. يقرأ dig بلا وسيط خادم /etc/resolv.conf، وهو ليس مصدر الحقيقة للحل المحدّد النطاق على macOS، ويتخطى قواعد كل نطاق تماماً. يصل dig @address إلى خادم واحد بالضبط ولا يخبرك شيئاً عن الاختيار.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

عندما يجيب الأمر الأول ويعيد الثاني NXDOMAIN، فقد وجدت الانقسام الذي تبحث عنه وليس هناك عطل. وعندما ينتهي الأول بالمهلة بينما يرد dig @10.20.0.53، فالمحلّل يعمل لكنه غير قابل للوصول على المسار الذي اختاره النفق، لذا الخطوة التالية هي route -n get لا تعديل إعدادات DNS. أبقِ الأسماء الخاصة خارج أي شيء تلصقه في تذكرة أو ملاحظة مشتركة.

ما لا تستطيع المخرجات إظهاره لك

عدة طبقات تجلس فوق قائمة المحلّلات أو بجانبها، وكل منها قد يرسل استعلاماً إلى مكان لا تذكره المخرجات أبداً. المتصفح المفعّل فيه DNS الآمن قد يحلّ عبر قناته المشفّرة، فصفحة تُحمّل بينما ينتهي dscacheutil بالمهلة ليست تناقضاً. وكيل DNS الذي يثبّته برنامج أمني يعمل كمزوّد Network Extension ويمرّر الاستعلامات بنفسه، ويعرض scutil --dns ما تم إعداده لا عنوان المنبع الذي استخدمه الوكيل في النهاية. نطاقات البحث تضيف ثنية ثالثة: الاسم غير المؤهّل تُلحق به كل لاحقة مدرجة بالترتيب، لذا الكتلة التي أجابت قد تكون واحدة لم تكن تتوقعها.

الإجابات القديمة أرخص شيء يمكن استبعاده وأكثره إغفالاً:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

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

دليل قصير لما قبل وما بعد

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

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

اقرأ الفرق بالكتل لا بالأسطر. محلّل محدّد النطاق جديد يحمل فهرس واجهة النفق ومدخل domain لللاحقة الخاصة هو الشكل المتوقع. محلّل افتراضي جديد يشير إلى عنوان عام هو نتيجة تستحق طرحها على من يملك ملف تعريف العميل. ثم كرّر البحث داخل التطبيق الذي فشل فعلاً، لا في الصدفة فقط، وسجّل الواجهة من route -n get بجانب النتيجة.

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

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