DNS يعمل عبر VPN، لكن أسماء .local تفشل رغم ذلك: من يحلّها؟

جهازان على VPN واحد، واسم المضيف نفسه، ومع ذلك لا يحلّه إلا أحدهما: الفرق عادةً ليس في النفق، بل في أي محلِّل أجاب. على سطح مكتب Linux، يمكن أن يمرّ ذلك الاسم عبر مبدِّل خدمة الأسماء، أو عبر وسيط systemd-resolved، أو عبر محلِّل جاءت به التطبيقة معها، وكل واحد من هذه يطبّق قاعدته الخاصة على اللاحقة نفسها. اللاحقة هي موضع افتراق القواعد، لأن .local ليس تسمية محايدة. اكتشف المسار الذي يسلكه البرنامج الفاشل فعلًا قبل أن تغيّر ترتيب تشغيل أي شيء.

محلِّلان، إجابتان مختلفتان

البحث التقليدي في glibc يمرّ عبر سطر hosts: في nsswitch.conf ويسأل كل وحدة بدورها حتى تجيب إحداها. أما العميل الذي يخاطب systemd-resolved عبر مستمع الوسيط فيسأل عملية واحدة بدلًا من ذلك، وتلك العملية تطبّق سياسة كل وصلة إضافةً إلى حالاتها الخاصة. والتطبيقة التي تأتي بمحلِّلها الخاص، أو تربط مكتبةً تفعل ذلك، يمكنها تجاوز الاثنين. لذلك قد يكون لاسم مضيف واحد ثلاثة مالكين على جهاز واحد، ولا يعرف إلا واحد منهم ما قصده VPN.

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

أي أمر سأل محلِّلك فعليًا

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

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

الأول يسأل عبر الوحدات المهيّأة، وهذا ما يختبره برنامج نمطي. والثاني يسأل systemd-resolved مباشرةً ويبلّغ عن الوصلة والبروتوكول والخادم الذي أجاب. استعلام خادم الشركة بالعنوان يثبت فقط أن الخادم يحتفظ بالسجل، لأنه لا يقول شيئًا عن كون التطبيقة سألته أصلًا. اقرأ الوصلة التي تحمل VPN والنطاقات التي تدّعيها، ثم قارن تلك القائمة باللاحقة في الاسم الفاشل.

لماذا يتجاوز .local منطقة unicast لديك

مرجع systemd-resolved يقول إن الأسماء متعددة التسميات المنتهية بـ .local تذهب عادةً إلى DNS المتعدد البث عندما يكون mDNS مفعّلًا، لا إلى DNS العادي أحادي البث. ويخصّص RFC 6762 تلك المساحة للتعدد البث المحلي للوصلة، لذا قد يحتفظ نطاق شركة بسجل صحيح لا يُستشار أبدًا لتلك اللاحقة. يمكن للنفق أن يوجّه المحلِّل بشكل مثالي ومع ذلك يخسر السباق. ونجاح ping من ذاكرة مؤقتة لا يقول شيئًا عن البحث الذي حدث للتو.

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

الاستثناء الضيق يتغلّب على إعادة الترتيب العامة

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

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

ما الذي يجب إثباته بعد التغيير

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

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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