resolv.conf आपका VPN DNS क्यों दिखाता है पर लुकअप उसे नज़रअंदाज़ करते हैं

लॉग में कुछ भी गलत नहीं दिखता: इंटरफ़ेस चालू है, रिज़ॉल्वर VPN के DNS सर्वर की सूचना देता है, और डिस्क की फ़ाइल उसे सूचीबद्ध करती है। फिर भी एक आंतरिक होस्टनाम अब भी स्थानीय राउटर से हल होता है। ये तीन कथन एक-दूसरे का खंडन नहीं करते, क्योंकि फ़ाइल, हर लिंक की स्थिति और लुकअप का पथ अलग-अलग वस्तुएँ हैं जो संयोग से एक ही नाम साझा करती हैं। आगे वह पथ है जो systemd-resolved वाले होस्ट पर क्वेरी वास्तव में लेती है।

resolv.conf नाम की तीन वस्तुएँ

resolved वाले होस्ट पर /etc/resolv.conf आमतौर पर /run/systemd/resolve/stub-resolv.conf के लिए एक सांकेतिक लिंक होता है। वह लक्ष्य स्थानीय stub श्रोता का पता, 127.0.0.53, तथा resolved द्वारा गणना किए गए खोज डोमेन रखता है। यह स्थिति का दृश्य है, स्थिति स्वयं नहीं।

स्थिति resolved के प्रति-लिंक कॉन्फ़िगरेशन में रहती है, इसीलिए resolvectl status फ़ाइल से अलग हो सकता है और फिर भी सही हो सकता है। हर लिंक अपने सर्वर और अपने रूटिंग डोमेन ले जाता है, और क्वेरी आने पर stub उस डेटा से परामर्श करता है। systemd-resolved का मैनुअल बनाई गई फ़ाइलों और प्रति-लिंक मॉडल का वर्णन करता है; दृश्य और स्थिति का बँटवारा याद रखने लायक हिस्सा है। सांकेतिक लिंक का लक्ष्य बदलने से पारंपरिक क्लाइंट जो पढ़ते हैं वह बदलता है, रिज़ॉल्वर जो जानता है वह नहीं।

तीसरी वस्तु, /run/systemd/resolve/resolv.conf, हर लिंक को एक ही सर्वर सूची में समतल कर देती है। उस फ़ाइल की ओर इशारा करने वाला प्रोग्राम क्वेरी सीधे सूचीबद्ध सर्वरों को भेजता है और stub को छोड़ देता है, इसलिए प्रति-लिंक नीति अब उस पर लागू नहीं होती। इसलिए एक ही मशीन पर दो प्रोग्राम एक ही नाम का अलग जवाब दे सकते हैं, और कोई भी टूटा नहीं है।

NSS के रास्ते एक लुकअप का पीछा करें

glibc नाम का जवाब कौन देगा यह तय करने के लिए /etc/nsswitch.conf पढ़ता है। जिस hosts पंक्ति में resolve है वह प्रश्न nss-resolve को भेजती है, जो D-Bus से resolved से पूछता है और प्रति-लिंक उत्तर पाता है। केवल files dns वाली पंक्ति क्वेरी उस पते पर भेजती है जो /etc/resolv.conf रखता है।

यही एक पंक्ति ब्राउज़र और dig के बीच ज़्यादातर मतभेद समझाती है। dig सीधे resolv.conf पढ़ता है और NSS को कभी नहीं छूता, इसलिए यह ऐप्लिकेशन के इस्तेमाल वाले पथ के बजाय stub या ऊपरी सर्वर की जाँच करता है। getent hosts internal.example NSS से गुज़रता है, और उसके उत्तर की dig के उत्तर से तुलना पहला उपयोगी मापन है।

जो ऐप्लिकेशन अपना रिज़ॉल्वर साथ लाते हैं, या किसी निश्चित एंडपॉइंट से HTTPS पर DNS बोलते हैं, वे दोनों पथ बचा लेते हैं। 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 पंक्ति बताती है कि stub से परामर्श होता भी है या नहीं, इसलिए फ़ाइल में stub पता होने पर भी वहाँ resolve न हो तो क्वेरी स्थानीय श्रोता तक पहुँचती हैं जबकि बँटवारा कोई प्रबंधित नहीं करता। वह अंतिम सूची भी मायने रखती है, क्योंकि stub-resolv.conf के बिना होस्ट यहाँ वर्णित व्यवस्था नहीं चलाता।

अगर श्रृंखला किसी दूसरे पैकेज द्वारा प्रबंधित फ़ाइल पर खत्म होती है, तो VPN क्लाइंट और वह पैकेज दोनों मालिक हैं जिन्हें मिलाया जाना है। लिंक बदलने से एक मालिक का काम बेकार जाता है और दूसरे का अपनी जगह रहता है।

लिंक के मालिक के पास सुधारें

VPN कनेक्शन को अपने सर्वर और डोमेन अपनी ही लिंक पर दर्ज करने चाहिए, फिर डिस्कनेक्ट पर उन्हें वापस खींच लेना चाहिए। NetworkManager का resolved एकीकरण और क्लाइंट का अपना सहायक दोनों इसी तरह काम करते हैं; केवल resolv.conf फिर से लिखने वाली स्क्रिप्ट ऐसा नहीं करती।

पहले से मौजूद लिंक पर रनटाइम सेटिंग्स तंत्र दिखाती हैं। resolvectl dns tun0 10.40.0.53 एक सर्वर जोड़ता है, और resolvectl domain tun0 '~corp.example' एक रूटिंग डोमेन जोड़ता है। टिल्डा (~) भार उठाने वाला अक्षर है: यह उस प्रत्यय की क्वेरी को इसी लिंक तक सीमित करता है और बाकी सबको अछूता छोड़ता है, जबकि इसके बिना वही मान खोज डोमेन बन जाता है और बँटवारा भाप बन जाता है। वे पते प्रयोगशाला के उदाहरण हैं, स्थायी कॉन्फ़िगरेशन नहीं। resolvectl query host.corp.example से पुष्टि करें और पढ़ें कि कौन-सी लिंक ने उत्तर दिया।

पंजीकृत सर्वर को फिर भी मार्ग चाहिए। जब क्वेरी सही लिंक तक पहुँचकर समय-समाप्त हो जाती है, तो गड़बड़ी रिज़ॉल्वर के स्वामित्व में नहीं, बल्कि सुरंग से पहुँच की क्षमता में है।

कार्यशील स्थिति कैसी दिखती है

स्वस्थ परिणाम तीनों दृश्यों में सुसंगत होता है: हर लिंक के सर्वर VPN द्वारा दिए गए से मेल खाते हैं, रूटिंग डोमेन केवल आंतरिक प्रत्यय ढकते हैं, और मायने रखने वाला ऐप्लिकेशन आंतरिक नाम हल करता है जबकि सार्वजनिक नाम अब भी स्थानीय पथ पर चलता है। एक सफल क्वेरी उस सहमति से कम साबित करती है।

फिर डिस्कनेक्ट करें और दोनों क्वेरी दोहराएँ। जो क्लाइंट टियरडाउन के बाद अपने डोमेन पंजीकृत छोड़ देता है वह ऐसी मशीन बनाता है जो घंटों बाद आंतरिक लुकअप में विफल होती है, बिना खुली सुरंग और बिना स्पष्ट कारण।