لماذا لا يصل إدخال /etc/hosts لديك إلى DNS الخاص بشبكة VPN
لا يؤدي الاتصال بـ VPN إلى رفع /etc/hosts. افصل بحث النظام عن استعلام DNS مباشر، ثم انشر الأسماء الخاصة عبر منطقة مُدارة.
أضفت اسمًا إلى /etc/hosts، واتصلت بـ VPN، وتوقعت أن يظهر السجل للجميع. لكن ذلك لا يحدث، وغالبًا ما تأتي المفاجأة مع عرض ثانٍ: الاسم يُحلّ على جهازك ويفشل على جهاز زميل، وهذا يبدو كخدمة DNS معطلة في VPN، والحقيقة أن ملف hosts يفعل بالضبط ما صُمم لفعله. ملف hosts هو إعداد محلي لتحليل الأسماء، وليس تحديثًا لمنطقة، ولا شيء في اتصال VPN عادي يرفعه.
ملف hosts تجاوز محلي وليس تحديثًا لمنطقة
الملف قائمة تعيينات تستشيرها مكتبات خدمة الأسماء قبل أن تسأل خادم DNS أو بدلًا من ذلك. سطر مثل 10.40.0.20 build.corp.example يغيّر ما تستنتجه التطبيقات على ذلك الجهاز وحده. وهو لا ينشئ سجلًا، ولا يعبر النفق، وخادم DNS الذي يشير إليه النفق لا يعلم بوجوده أصلًا.
لهذا يكون الفشل غير متماثل. عميلك يحصل على إجابة من الملف. عميل آخر يسأل خادم DNS الخاص بـ VPN، فيعيد لا شيء، ويبلغ التطبيق بأن الاسم غير موجود. كلا الجهازين يتصرفان بشكل صحيح؛ لكن واحدًا فقط منهما لديه تجاوز لم يره الآخر قط.
أمران، مكوّنان مختلفان
أسرع طريقة لإنهاء الجدل هي إظهار الفرق في أمرين، كلاهما يُنفَّذ على العميل الذي يحمل إدخال hosts:
getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A
الأمر الأول يسأل مسار البحث الخاص بالنظام، والذي يقرأ على نظام glibc نموذجي الملفات المحلية قبل DNS. الأمر الثاني يرسل استعلام DNS مباشرة إلى الخادم على ذلك العنوان ولا يستشير الملفات المحلية إطلاقًا. عندما يعيد الأول إدخالك ويعيد الثاني NXDOMAIN، تكون قد أثبتت أن السجل غير موجود في DNS وأن جهازك يجيب من تجاوز محلي.
الترتيب قابل للتهيئة، ويستحق التحقق منه قبل أن تستنتج أي شيء عن توزيعة معينة. انظر إلى سطر hosts: في /etc/nsswitch.conf؛ فـ hosts: files dns يستشير الملفات أولًا. لا تنسخ ذلك المثال فوق تهيئة عاملة لمجرد تغيير الترتيب، لأن الأنظمة الحقيقية كثيرًا ما تسرد مصادر إضافية وإدخالات خدمة شرطية لا يحملها المثال.
systemd-resolved يطمس الاختبار
على نظام يستخدم systemd-resolved، يقدّم المكوّن المحلي أيضًا أسماء من قاعدة بيانات hosts. لذلك فإن الاستعلام عن 127.0.0.53 ليس اختبارًا مستقلًا للخادم البعيد، رغم أنه يبدو كاستعلام DNS ويتصرف مثله. يمكنك تأكيد ما يعرفه المُحلِّل وأي الخوادم سيسألها باستخدام:
resolvectl query build.corp.example
resolvectl status
يسمّي مخرجات الحالة خوادم DNS لكل ارتباط، وهكذا تعرف ما إذا كان ارتباط VPN قد تلقى مُحلِّلًا أصلًا. هذا السؤال منفصل عن إدخال hosts، وهو السؤال الجدير بالطرح عندما يفشل اسم خاص لدى كل المستخدمين وليس لدى واحد فقط.
يمكن للتطبيقات أن تضيف طبقة أخرى. متصفح بإعداد DNS-over-HTTPS خاص به، أو حاوية بتهيئة مُحلِّل خاصة بها، أو بيئة تشغيل تخزّن نتائج البحث طوال عمر العملية، قد يجيب كل منها بشكل مختلف عن النظام. اختبر التطبيق الذي يهمك بدلًا من افتراض أن أمرًا واحدًا يصف كل برنامج على الجهاز.
ما الذي يشارك اسمًا فعليًا عبر VPN
إذا كان على اسم خاص أن يعمل للجميع، فهو يحتاج إلى مالك يستطيع مُحلِّل الجميع الوصول إليه. الجواب النظيف هو نشر السجل في منطقة مُدارة وجعل تلك المنطقة قابلة للحل عبر مسار DNS المقصود في VPN. عندئذ يصبح للسجل مصدر حقيقة واحد وسجل تدقيق ودورة حياة، ولا يحتاج أحد إلى تذكر أي حاسوب محمول يحمل تجاوزًا محليًا.
توزيع ملفات hosts بديل مشروع، وهو إدارة أجهزة طرفية وليس خدمة أسماء. إذا اخترته، فيجب نشر الملف وإصداره وإزالته بواسطة ما يدير الأسطول، وينبغي وصفه بهذه الطريقة في التصميم. عبارة «VPN يتولى ذلك» ليست وصفًا لتلك العملية.
تسجيل DNS الديناميكي آلية ثالثة، لها أذوناتها ومصادقة التحديث وعمر السجل الخاص بها. وهو لا ينتج عن إدخال hosts، ولا ينتج عن مجرد اتصال عميل، ما لم يكن الخادم والعميل مكوَّنين كلاهما للقيام بذلك. السجل الذي يظهر من تلقاء نفسه إشارة إلى أن أحدهم فعّل التحديثات الآمنة وعميلًا يسجّل نفسه، وذلك التكوين ينتمي إلى سجل التصميم وليس إلى خيط استكشاف أخطاء. إذا لم يستطع أحد تسمية من يملك ذلك الإعداد، فتعامل مع السجل التلقائي على أنه غير موثّق وأبقِ المنطقة المُدارة مصدر الحقيقة.
الاسم الذي يُحلّ ليس مسارًا
تحليل الأسماء وقابلية الوصول منفصلان، والتعيين المحلي القديم هو الطريقة الكلاسيكية لخلطهما. إدخال hosts يشير إلى عنوان انتقل سيبقى يختار المضيف القديم وقتًا طويلًا بعد تصحيح DNS، وتبدو الأعراض كفشل توجيه على اسم يُحلّ جيدًا.
لذلك عندما يكون التقرير «الاسم يُحلّ لكن الخدمة غير قابلة للوصول»، قارن بحث النظام باستعلام صريح إلى خادم DNS الخاص بـ VPN، ثم تحقق من العنوان الذي حصلت عليه مقابل العنوان الذي تستخدمه الخدمة فعليًا. إن مرجع systemd-resolved يوثّق المصادر المحلية التي يستشيرها، وهي الخريطة التي تحتاجها لتلك المقارنة.
ثم أصلح التجاوز عبر مالكه. إزالة سطر من ملف hosts الخاص بك لا تفعل شيئًا لأجهزة الحاسوب المحمولة الاثني عشر التي تلقت السطر نفسه من سكربت نشر، وهذه هي نسخة هذه المشكلة التي يواجهها الناس فعلًا.