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 मध्ये दिसतात।