resolv.conf संपादित करने से VPN डिस्कनेक्ट के बाद DNS ठीक नहीं होता

आप VPN डिस्कनेक्ट करते हैं, ping 1.1.1.1 अब भी जवाब देता है, और हर नाम लुकअप पेज के आखिर में हार मानने से पहले अटक जाता है। फिर cat /etc/resolv.conf ऐसा नेमसर्वर दिखाता है जो कभी सिर्फ़ टनल के अंदर ही मौजूद था, आम तौर पर सूची में पहला। उस पंक्ति को हटाना लगभग दस मिनट के लिए ठीक करता दिखता है, जब तक सस्पेंड, Wi-Fi रोमिंग या रीस्टार्ट उसे वापस न ले आए। आपने जो फ़ाइल संपादित की वह सेटिंग नहीं है; वह लिंक स्थिति का एक रेंडरिंग है जिसका मालिक कोई दूसरा घटक है।

एक पुरानी प्रविष्टि हर लुकअप पर सेकंड क्यों खर्च करती है

glibc रिज़ॉल्वर नेमसर्वर सूची को क्रम से चलता है और अगला आज़माने से पहले एक टाइमआउट पूरा होने का इंतज़ार करता है, और resolv.conf(5) उस सूची को तीन प्रविष्टियों तक सीमित करता है। टनल जाने के बाद 10.8.0.1 जैसा टनल-तरफ़ा रिज़ॉल्वर सूची के शीर्ष पर रखें, और हर लुकअप जवाब देने वाले सर्वर तक पहुँचने से पहले टाइमआउट की कीमत चुकाता है। इसी वजह से लक्षण DNS त्रुटि के बजाय मृत कनेक्शन जैसा दिखता है: ब्राउज़र अटक जाते हैं, समय खत्म हो जाता है और कभी-कभी कैश किया हुआ पता परोस देते हैं जो बाद में पुराना हो जाता है।

यह भी समझाता है कि शिकायत «इंटरनेट टूट गया है» के रूप में क्यों आती है। किसी IP पते पर ping साबित करता है कि लिंक ठीक है, जिससे गड़बड़ी ऐप की लगती है। रिज़ॉल्वर सूची पहली चीज़ है जो पढ़नी चाहिए और आखिरी जिसे संपादित करना चाहिए।

मिथक: resolv.conf एक सेटिंग्स फ़ाइल है

बदलने से पहले पूछें कि यह पथ असल में क्या है:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

systemd-resolved वाले होस्ट पर यह 127.0.0.53 की ओर इशारा करने वाली स्टब फ़ाइल का सिमलिंक है, और असली सर्वर resolvectl जो छापता है उस प्रति-लिंक स्थिति में रहते हैं। NetworkManager वाले होस्ट पर यह ऐसी फ़ाइल हो सकती है जिसे NetworkManager सक्रिय कनेक्शन से लिखता है। कुछ विक्रेता क्लाइंट में यह सादी फ़ाइल है जो कनेक्ट होते समय वहीं फिर से लिखी जाती है और, अगर आप बदकिस्मत हैं, डिस्कनेक्ट पर कभी बहाल नहीं होती। ये तीन अलग मालिक हैं, और पहले दो को हाथ से संपादित करना या तो कुछ नहीं करता या अगली नेटवर्क घटना तक टिकता है।

resolvectl status वह दृश्य है जो सच बताता है: प्रति-लिंक DNS सर्वर, रूटिंग डोमेन, और क्या टनल लिंक अब भी मौजूद है। resolvectl query example.com आगे जाता है और दिखाता है कि किस इंटरफ़ेस ने जवाब दिया। किसी फ़ाइल को छूने से पहले दोनों इस्तेमाल करें, और ध्यान रखें कि अपना सुरक्षित DNS रखने वाला ब्राउज़र इन सबको नज़रअंदाज़ करता है।

कुछ भी संपादित करने से पहले मालिक खोजें

आम तौर पर तीन घटक एक ही सेटिंग के लिए होड़ करते हैं: systemd-resolved, NetworkManager और जो कुछ VPN क्लाइंट ने इंस्टॉल किया। पहले जीवित वाले की पहचान करें:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

अगर resolved सक्रिय है और सिमलिंक उसके स्टब की ओर इशारा करता है, तो वैश्विक फ़ाइल जनरेट किया गया आउटपुट है और आपका संपादन दिखावटी है। अगर NetworkManager कनेक्शन का मालिक है, तो सर्वर कनेक्शन प्रोफ़ाइल के हैं, इसलिए सुधार फ़ाइल संपादन नहीं बल्कि nmcli प्रॉपर्टी बदलाव है। अगर विक्रेता का डेमॉन चल रहा है, तो सिर्फ़ उसका अपना रिस्टोर पथ अगले कनेक्शन तक बचता है।

क्लाइंट द्वारा छोड़ी गई लिंक स्थिति साफ़ करें

मारा गया क्लाइंट अपना क्लीनअप हुक नहीं चला सकता। SIGKILL बिल्कुल पकड़ा नहीं जा सकता, जबकि SIGINT और SIGTERM पकड़े जा सकते हैं, इसलिए ज़बरदस्ती मारने के बाद «बस रुक गई» टनल अक्सर इंटरफ़ेस पंजीकरण और रिज़ॉल्वर प्रविष्टि दोनों जगह पर छोड़ देती है। सटीक PID खोजें और सिग्नल सिर्फ़ उसी को भेजें:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

पूरी मैच सूची पढ़ने से पहले pkill -f vpn या killall vpn की ओर हाथ न बढ़ाएँ। -f पूरी कमांड लाइन से मेल खाता है, इसलिए यह रैपर स्क्रिप्ट, एडिटर सत्र या ऐसी असंबंधित प्रक्रिया खत्म कर सकता है जिसके पथ में वह स्ट्रिंग हो। काम के बीच गलत प्रक्रिया खत्म करना ही वह तरीका है जिससे रिज़ॉल्वर समस्या खोई हुई फ़ाइल बन जाती है।

resolvectl revert उस लिंक की रनटाइम DNS कॉन्फ़िगरेशन रीसेट करता है, जो रिज़ॉल्वर रीस्टार्ट करने से संकीर्ण है और वैश्विक फ़ाइल संपादित करने से बहुत संकीर्ण है। अगर टनल लिंक पूरी तरह चला गया है, तो systemctl restart NetworkManager कनेक्शन स्थिति फिर से बनाता है और स्रोत थ्रेड बार-बार इसी चरण पर लौटते हैं। Restart=always वाले सर्विस मैनेजर से सावधान रहें, क्योंकि वह मारे गए क्लाइंट और उसकी DNS सेटिंग्स को सीधे वापस ला सकता है।

दूसरी दिशा: धकेला गया DNS जो कभी पहुँचा ही नहीं

पुरानी प्रविष्टि की दर्पण छवि ऐसी टनल है जिसमें कोई भी उपयोगी रिज़ॉल्वर नहीं है। प्रोफ़ाइल में DNS विकल्प एक अनुरोध है; कनेक्शन प्रबंधित करने वाले घटक को उसे रिज़ॉल्वर तक पहुँचाना होता है। अगर लॉग दिखाता है कि सर्वर मिल गया पर टनल लिंक कोई DNS सेटिंग नहीं ले जाता, तो कमी इंटीग्रेशन की है, सर्वर की नहीं।

हैंडऑफ़ को हाथ से करके जाँचें, जो «सर्वर गलत है» को «किसी ने लागू ही नहीं किया» से अलग करता है:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

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

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

ऐसी कंपनी टनल के लिए जिसे सिर्फ़ आंतरिक नामों का जवाब देना चाहिए, उन ज़ोनों को सब कुछ पकड़ने के बजाय शुरुआती टिल्ड के साथ सूचीबद्ध करें, ताकि सार्वजनिक नाम स्थानीय रिज़ॉल्वर का इस्तेमाल करते रहें।

वर्कअराउंड जो अगली बड़ी गड़बड़ी बन जाते हैं

कनेक्ट करने से पहले resolv.conf की नकल करना और बाद में उसे बहाल करना runbook में एक वैध पंक्ति है, और यह मरम्मत नहीं बल्कि वर्कअराउंड है। यह ठीक तभी विफल होता है जब इसकी ज़रूरत होती है, क्योंकि क्रैश या ज़बरदस्ती रीबूट बहाली छोड़ देता है। इसे वर्कअराउंड के रूप में लिख लें ताकि अगला व्यक्ति इस पर न बनाए।

systemd-resolved बंद करना और सार्वजनिक सर्वर हार्डकोड करना दूसरा लोकप्रिय कदम है। यह कनेक्ट और डिस्कनेक्ट को अनुमानित बनाता है और हर दूसरे नेटवर्क के लिए प्रति-लिंक DNS हटा देता है, जो आंतरिक नामों के लिए स्प्लिट DNS तोड़ता है और ऐसी टनल का उद्देश्य विफल करता है जो क्वेरी को उसके अंदर रखने के लिए बनी है। resolvconf इंस्टॉल करना और सार्वजनिक सर्वर पिन करना एक अतिरिक्त परत के साथ उतना ही महंगा है। दोनों में से किसी को निदान मानें: अगर यह ब्राउज़िंग लौटाता है, तो आपने सीखा कि रिज़ॉल्वर इंटीग्रेशन दोषी है, यह नहीं कि सार्वजनिक सर्वर सही हैं।

टिकाऊ सुधार हर परत के लिए एक मालिक है: तय करें कि टनल लिंक का DNS किस घटक के पास है और वैश्विक डिफ़ॉल्ट किसके पास, उसे लिख लें, और बाकियों को रास्ते से हटा दें। फिर डिस्कनेक्ट के बाद ऐसे नाम से जाँचें जिसे सिर्फ़ VPN हल करता है। अगर निजी नाम अब भी जवाब देता है, तो पंजीकरण हटाया नहीं गया; अगर कुछ भी हल नहीं होता, तो फ़ाइल ऐसे सर्वर की ओर इशारा करती है जो अब नहीं है। दोनों ब्राउज़र खोलने से पहले resolvectl में दिखते हैं।