DNS الشبكة الافتراضية يستحوذ على كل استعلام: اضبط dns-priority في NetworkManager

اتصل بشبكة VPN الخاصة بالمكتب، وفجأة يذهب كل استعلام اسم إلى خادم المؤسسة. الأسماء العامة ما زالت تُحل، فلا يبدو شيء معطوبًا حتى يفشل اسم طابعة محلية أو يعيد سجل split-horizon عنوان المكتب. في بعض إعدادات Fedora يحدث العكس: خادم مزود الخدمة يستمر في الإجابة بعد أن يصبح النفق جاهزًا. كلتا الحالتين سؤال واحد — أي خادم يملك هذا الاستعلام — وعلى أنظمة NetworkManager يعيش الجواب في خصائص DNS لكل اتصال.

اتصالان، خادم واحد يفوز

كل اتصال يعلن أولوية DNS. الاتصالات العادية تأخذ 50 افتراضيًا واتصالات VPN تأخذ 0، والقيمة الأصغر تفوز. هذا الافتراضي هو سبب تجاوز اتصال VPN للرابط السلكي بصمت لكل نطاق يطالب به: الصفر يهزم الخمسين دون أن يختاره أحد.

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

الأولوية تحدد الترتيب، وقائمة البحث تحدد الملكية

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

قائمة البحث هي بيان الملكية. نطاق مجرد مثل corp.example يصبح لاحقة بحث ونطاق توجيه. الصيغة المخصصة للتوجيه فقط ~corp.example ترسل الاستعلامات تحت تلك اللاحقة إلى هذا الاتصال دون إلحاق النطاق بالأسماء القصيرة. تلك التلدة هي الفرق بين «اسأل هذا الخادم» و«اسأل هذا الخادم وأكمل كتابتي عني».

استخدم الصيغتين عندما يكتب المستخدمون أسماء مضيفين قصيرة وتُعنون السجلات أيضًا بأسماء مؤهلة بالكامل. واستخدم صيغة التوجيه فقط عندما تريد الانقسام دون تغيير طريقة إكمال الخادم لاسم مجرد.

ثم اجعل التفضيل صريحًا وأعد تنشيط الاتصال:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

الأولوية السالبة هي الطريقة الموثقة لقول «فضّل هذا الاتصال»، وتعيين عائلتي العناوين معًا يحفظ السلوك متسقًا على مضيف لديه اتصال IPv6. تغيير الخاصية دون إعادة تنشيط الاتصال لا يغير شيئًا يعمل الآن، ولهذا تنتهي السلسلة بأمر up صريح.

دع systemd-resolved يحتفظ بالانقسام

إضافة dnsmasq الافتراضية تجمع الاستعلامات في خادم محلي واحد، فيبقى الفصل لكل رابط خشنًا. systemd-resolved يعرض الانقسام لكل رابط، و resolvectl query يسمي الرابط الذي أجاب.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

بعد ذلك يحمل رابط المؤسسة corp.example ويخدم خادم عام الباقي. وعندما يصل استعلام إلى الرابط الخطأ، يسمي الأمر الرابط الذي أجاب عنه، ومعرفة ذلك أفضل من معرفة العنوان وحده.

طابق تصميم DNS مع نوع النفق

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

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

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

تحقق لكل رابط، ثم مرة أخرى بعد إعادة الاتصال

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

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