VPN का DNS हर लुकअप ले लेता है: NetworkManager में dns-priority ठीक करें

ऑफ़िस VPN से जुड़िए और अचानक हर नाम लुकअप कॉर्पोरेट रिज़ॉल्वर पर जाता है। सार्वजनिक नाम अब भी हल होते हैं, इसलिए तब तक कुछ टूटा नहीं दिखता जब तक किसी स्थानीय प्रिंटर का नाम विफल न हो या कोई split-horizon रिकॉर्ड ऑफ़िस का पता न लौटाए। कुछ Fedora सेटअप में उलटा होता है: टनल ऊपर आने के बाद भी ISP रिज़ॉल्वर जवाब देता रहता है। दोनों एक ही सवाल हैं — कौन सा रिज़ॉल्वर इस क्वेरी का मालिक है — और 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 डिज़ाइन को टनल प्रकार से मिलाएँ

जो गोपनीयता डिज़ाइन सब कुछ टनल से भेजते हैं उन्हें विभाजन सूची नहीं रखनी चाहिए, क्योंकि वह सार्वजनिक नाम स्थानीय रिज़ॉल्वर को लौटा देगी और मंशा रद्द कर देगी। स्प्लिट-टनल डिज़ाइन को एक चाहिए: उसके बिना कॉर्पोरेट रिज़ॉल्वर हर सार्वजनिक क्वेरी देखता है, और टनल गिरते ही सेटअप टूट जाता है।

फिर वह kill switch है जो टनल के बाहर DNS रोकता है। नाम टनल के ज़ोन के लिए हल होते हैं और बाकी हर जगह विफल होते हैं जबकि कनेक्शन पूरी तरह स्वस्थ है। व्यावहारिक जवाब LAN रिज़ॉल्वर के लिए स्पष्ट अनुमति या ऐसा स्थानीय कैश है जो सिर्फ़ कॉर्पोरेट ज़ोन फ़ॉरवर्ड करे, और इनमें से कोई भी टनल में खराबी नहीं बल्कि मालिक वाला अपवाद है।

जो प्रोफ़ाइल इंटरफ़ेस शुरू होने पर रिज़ॉल्वर कॉन्फ़िगरेशन फिर से लिखती है वह लगभग वैसा ही व्यवहार करती है: स्थानीय रिज़ॉल्वर पहुँच से बाहर होते ही सिर्फ़ वे नाम हल होंगे जिन्हें टनल जानता है। कोई भी तंत्र लागू हो, लिख लें कि हर स्थिति में कौन से नाम काम करने चाहिए, और वह सूची रिपोर्ट संभालने वाले को दें।

हर लिंक पर जाँचें, फिर दोबारा कनेक्ट होने के बाद फिर जाँचें

एक आंतरिक और एक सार्वजनिक नाम पूछें, और देखें कि क्वेरी असल में कहाँ जाती है। लीक-जाँच पृष्ठ बताता है कि किस रिज़ॉल्वर ने जवाब दिया, यह नहीं कि सिस्टम ने कौन सा लिंक चुना, इसलिए यह उस क्रम के बारे में कुछ नहीं कहता जो आपने अभी सेट किया।

डिस्कनेक्ट और दोबारा कनेक्ट के बाद दोनों क्वेरी फिर चलाएँ। कनेक्शन सक्रिय होने पर प्राथमिकताएँ फिर लागू होती हैं, और पुराना सिमलिंक ऐसा अपग्रेड भी झेल सकता है जो किसी को याद नहीं। अंत में आप लिखकर रखना चाहते हैं कि कौन सा रिज़ॉल्वर किस प्रत्यय का मालिक है, साथ में एक जाँच जो कल भी मान्य रहे।