DNS المنقسم وVPN: قواعد النطاقات ليست مسارات IP
يختار DNS المنقسم محللًا حسب الاسم، والجواب ما زال يحتاج مسارًا. اختبر قاعدة النطاق والمسار كلًا على حدة، على المنصة التي تشغلها فعلًا.
يحل حاسوبك المحمول intranet.corp عبر النفق بينما يظل gitlab.com يتجه إلى محلل مزود الخدمة، وهذا هو الترتيب الذي يعمل كما صُمم. نتج ذلك عن قرارين منفصلين: قاعدة مطابقة الاسم اختارت المحلل، ومسار أعاد الجواب. أعطِل أيًّا من القرارين فتظهر في المتصفح مشكلة تبدو نفسها من الخارج. معظم تقارير DNS المنقسم تصف المشكلة الثانية بينما تستشهد بأدلة عن الأولى.
يعيش النصفان في مكانين مختلفين، ويحررهما عادةً أشخاص مختلفون. أحدهما سياسة DNS مرتبطة بملف تعريف VPN، والآخر مسار يثبّته النفق أو يحجبه. يتوقف التشخيص عندما لا يحدد أحد أي النصفين تحرك فعلًا.
قراران مخفيان في طلب واحد
نصف الاسم كائن سياسة وليس مسارًا. على Windows تكون سياسة تحليل أسماء على ملف تعريف VPN؛ وعلى منصات Apple مجموعة نطاقات مطابقة على كائن إعدادات DNS؛ وعلى Linux نطاق توجيه أو سطر محلل منقسم أو ترتيب مبدّل خدمة الأسماء. نصف المسار توجيه عادي يثبّته النفق أو اليد، ولا يعرف شيئًا عن أسماء المضيفين. الملف الذي يسمح بلاحقة يقرر فقط من يجيب؛ ولا يجعل الجواب قابلًا للوصول أبدًا.
اختبار عرضي سريع يفصل بينهما: استبدل الاسم بعنوان. إذا عمل العنوان، فالمسار سليم والقاعدة خاطئة. وإذا فشل العنوان أيضًا، فقد تكون القاعدة صحيحة والمسار مفقودًا.
كيف تعبّر كل منصة عن قاعدة الاسم نفسها
النية واحدة وأسماء الحقول ليست كذلك. مثال يُنسخ من عميل إلى آخر يُحلَّل بنظافة ولا يطابق أبدًا. تبدو الأشكال الثلاثة هكذا:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
نطاق المطابقة أو التوجيه اختبار لاحقة، لذا يغطي intranet.corp النطاق git.intranet.corp ولا يغطي corp.intranet، وقلبه هو الخطأ الأشيع في الإعداد كله. يحمل Windows التعيين كسياسة تحليل أسماء مرتبطة بملف تعريف، مع ترتيب أولوية خاص به مقابل قائمة اللواحق التي كانت الواجهة تحملها أصلًا. تربط منصات Apple نطاقات المطابقة بكائن إعدادات DNS لامتداد الشبكة، ويطبقها النظام لكل محلل محدَّد النطاق. لا شيء من هذه الأشكال مسار، ولا يمكن لأي منها جعل عنوان غير قابل للوصول قابلًا للوصول. مرجع سياسة تحليل الأسماء في Windows يسرد أسماء الحقول وقواعد الأولوية لتلك المنصة، وهي ليست تلك التي تستخدمها وثائق Apple أو systemd.
الجواب الصحيح ما زال يحتاج مسارًا
جواب المحلل ليس إلا عنوانًا، وعلى التطبيق أن يصل إليه. تصميم النفق المنقسم كثيرًا ما يدفع 10.20.0.0/16 ويحجب المسار الافتراضي، فيُحلّ الاسم الداخلي ثم يتوقف الاتصال. والحالة المعاكسة شائعة بالقدر نفسه: المسار موجود، ومحلل عام يجيب عن الاسم الخاص بـ NXDOMAIN، فتُسجَّل المشكلة كمشكلة توجيه. اختبار المسار أولًا يجعلك تحدّق في المسارات لاسم لم يكن ليُحلّ أصلًا.
هناك أيضًا بوابة ثالثة لا يغطيها أي نصف. قائمة تحكم على البوابة أو قاعدة جدار حماية أو سياسة على جانب العميل يمكن أن تُسقط الاتصال بعد أن كان القراران صحيحين. عندما يُحلّ الاسم ويوجد المسار ويظل الاتصال ينتهي مهلته، توقف عن اختبار DNS.
اختبار الأسماء والمسارات بترتيب ثابت
اختر ترتيبًا والتزم به، وإلا ستطارد الخطوة التي فشلت أحدث. حلّل الاسم الداخلي الكامل الموثّق، وتأكد أن الجواب عنوان يستطيع جدول التوجيه حمله، ثم كرر باسم عام لإثبات أن النفق لم يلتقط كل شيء. على مضيف systemd يفصل أمر واحد بين الاستعلام ونطاق توجيه المحلل:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10عميل Windows يسأل السؤالين نفسيهما بأوامر cmdlet مختلفة. الثاني يبلّغ عن الواجهة التي سيستخدمها النظام فعليًا:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10إذا أعاد البحث عنوانًا وسمّى فحص المسار الواجهة الفعلية، فقد نجحت قاعدة الاسم وفشل المسار. وإذا فشل الاسم القصير بينما يُحلّ الاسم الكامل، فقائمة اللواحق خاطئة وليس المحلل.
أين يخطئ المقارنة عادة
الخطأ الأول هو سؤال محلل عام غير ذي صلة عن اسم خاص وقراءة الرفض كدليل على VPN. والثاني افتراض أن بحثًا عامًا ناجحًا يثبت مسار محلل النفق. والثالث معاملة النفق المنقسم وDNS المنقسم كقرار تصميم واحد، بينما يمكن أن يكون النشر صحيحًا في أحدهما ومعطوبًا في الآخر. كل خطأ ينتج استنتاجات واثقة من اختبار لم يمارس الجزء الذي يُلام.
يمكن لمتصفح له DNS آمن خاص به أن يتجاوز قاعدة النظام أيضًا، ولهذا فإن فشل متصفح واحد بينما ينجح آخر ليس تناقضًا. قارن المحلل الذي أجاب، لا المتصفح الذي اشتكى.
عندما يصبح النصفان مرئيين، يصير السؤال المتبقي سؤال سياسة لا سؤالًا تقنيًا: أي فضاءات الأسماء تنتمي إلى المؤسسة، ومن يملك كل جواب، وأيها ينبغي أن يغادر الجهاز أصلًا. اكتب ذلك بجوار ملف التعريف، لأن الشخص التالي الذي يلمس القاعدة سيحتاجه.