لماذا يعرض resolv.conf خادم DNS الخاص بـ VPN بينما تتجاهله عمليات البحث
على مضيف يعمل بـ resolved يكون الملف عرضًا للحالة لا الحالة نفسها. تتبّع الوكيل المحلي stub وخوادم كل ارتباط وسطر nsswitch لتعرف أيّها يستخدمه البحث فعلًا.
لا شيء في السجلات يبدو خطأ: الواجهة قائمة، ويبلّغ المحلّل بخادم DNS الخاص بـ VPN، والملف على القرص يذكره. ومع ذلك لا يزال اسم مضيف داخلي يُحلّ عبر الموجّه المحلي. هذه العبارات الثلاث ليست متناقضة، لأن الملف وحالة كل ارتباط ومسار البحث كائنات مختلفة تصادف أنها تشترك في اسم. ما يلي هو المسار الذي يسلكه الاستعلام فعلًا على مضيف يعمل بـ systemd-resolved.
ثلاثة كائنات تحمل اسم resolv.conf
على مضيف يعمل بـ resolved، يكون /etc/resolv.conf عادةً رابطًا رمزيًا إلى /run/systemd/resolve/stub-resolv.conf. يحتفظ ذلك الهدف بعنوان مستمع محلي من نوع stub، 127.0.0.53، إضافة إلى نطاقات البحث التي حسبها resolved. إنه عرض للحالة لا الحالة نفسها.
تعيش الحالة في إعداد resolved لكل ارتباط، ولهذا يمكن أن يخالف resolvectl status الملف ويظل محقًا. يحمل كل ارتباط خوادمه ونطاقات التوجيه الخاصة به، ويستشير الوكيل المحلي تلك البيانات عند وصول استعلام. يصف دليل systemd-resolved الملفات المولّدة ونموذج كل ارتباط؛ والفصل بين العرض والحالة هو الجزء الذي يستحق التذكّر. تعديل هدف الرابط الرمزي يغيّر ما تقرأه العملاء التقليدية، لا ما يعرفه المحلّل.
الكائن الثالث، /run/systemd/resolve/resolv.conf، يسطّح كل ارتباط في قائمة خوادم واحدة. البرنامج الموجّه إلى ذلك الملف يرسل الاستعلامات مباشرة إلى الخوادم المدرجة ويتجاوز الوكيل المحلي، فلا تنطبق عليه سياسة كل ارتباط بعد الآن. لذلك يمكن لبرنامجين على الجهاز نفسه أن يجيبا عن الاسم ذاته إجابتين مختلفتين، ولا شيء منهما معطوب.
تتبّع بحثًا واحدًا عبر NSS
يقرأ glibc الملف /etc/nsswitch.conf ليقرّر من يجيب عن الاسم. سطر hosts الذي يحتوي على resolve يوجّه السؤال إلى nss-resolve، الذي يسأل resolved عبر D-Bus ويتلقى إجابة كل ارتباط. السطر الذي يحوي files dns فقط يرسل الاستعلام إلى العنوان الذي يحمله /etc/resolv.conf.
هذا السطر وحده يفسّر معظم الخلافات بين المتصفح وبرنامج dig. يقرأ dig الملف resolv.conf مباشرة ولا يمسّ NSS أبدًا، فهو يختبر الوكيل المحلي أو خادمًا أعلى بدلًا من المسار الذي يستخدمه التطبيق. أما getent hosts internal.example فيمرّ عبر NSS، ومقارنة إجابته بإجابة dig هي أول قياس مفيد.
التطبيقات التي تحمل محلّلًا خاصًا بها، أو تتحدث DNS عبر HTTPS إلى نقطة نهاية ثابتة، تتجاوز المسارين معًا. لا شيء في resolv.conf ولا في حالة resolved يقيّدها.
تحقّق من مالك الملف وإلى أين يشير
اقرأ سلسلة الروابط قبل تغيير أي شيء، لأن الملكية تحدّد أي ملف هو المرجع. كل أمر أدناه يقرأ الحالة فقط.
stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/
يطبع السطر الأول الرابط وهدفه معًا، ووجود ملف عادي يملكه نص VPN يعني أن المحلّل لا يعتبر تلك الكتابة مدخلًا أبدًا. يسرد مخرَج الحالة خوادم كل ارتباط إضافة إلى نطاقات التوجيه التي تحدّد أين يذهب كل استعلام. يبيّن سطر nsswitch ما إذا كان الوكيل المحلي مستشارًا أصلًا، لذا فإن عنوانه في الملف دون resolve هناك يعني أن الاستعلامات تصل إلى المستمع المحلي بينما لا يدير شيء التقسيم. ذلك السرد الأخير مهم أيضًا، لأن مضيفًا بلا stub-resolv.conf لا يشغّل الترتيب الموصوف هنا.
إذا انتهت السلسلة عند ملف يديره حزمة أخرى، فالعميل VPN وتلك الحزمة هما المالكان اللذان يجب التوفيق بينهما. استبدال الرابط يهدر عمل أحد المالكين ويترك عمل الآخر في مكانه.
أصلح عند مالك الرابط
ينبغي لاتصال VPN أن يسجّل خوادمه ونطاقاته على ارتباطه الخاص، ثم يسحبها عند قطع الاتصال. تكامل resolved في NetworkManager ومساعد العميل الخاص يعملان بهذه الطريقة؛ أما نص يعيد كتابة resolv.conf فقط فلا يفعل ذلك.
على ارتباط موجود بالفعل، تُظهر الإعدادات اللحظية الآلية. يربط resolvectl dns tun0 10.40.0.53 خادمًا، ويربط resolvectl domain tun0 '~corp.example' نطاق توجيه. المدّة (~) هي المحرف الحامل: فهي تحصر استعلامات ذلك اللاحقة في هذا الارتباط وتترك كل شيء آخر، بينما تتحول القيمة نفسها دونها إلى نطاق بحث ويتبخّر التقسيم. تلك العناوين أمثلة مخبرية، لا إعدادًا دائمًا. تأكّد بواسطة resolvectl query host.corp.example واقرأ أي ارتباط أجاب.
الخادم المسجّل لا يزال يحتاج إلى مسار. عندما يصل الاستعلام إلى الارتباط الصحيح ثم تنتهي مهلته، يكون العيب في الوصول عبر النفق لا في ملكية المحلّل.
كيف تبدو الحالة العاملة
النتيجة السليمة متسقة عبر العروض الثلاثة: خوادم كل ارتباط تطابق ما وزّعه VPN، ونطاقات التوجيه تغطي اللواحق الداخلية فقط، والتطبيق المهم يحلّ اسمًا داخليًا بينما يظل الاسم العام يتبع المسار المحلي. استعلام ناجح واحد يثبت أقل من هذا التوافق.
ثم اقطع الاتصال وكرّر الاستعلامين. العميل الذي يترك نطاقاته مسجّلة بعد الإنهاء ينتج جهازًا يفشل في عمليات البحث الداخلية بعد ساعات، دون نفق مفتوح ودون سبب ظاهر.