VPN विच्छेद भएपछि resolv.conf सम्पादन गर्दा 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 मा देखिन्छन्।