/etc/resolv.conf साठी स्पर्धा करणाऱ्या दोन Linux सेवा थांबवा

DNS वारंवार जुन्या स्थितीत परत येते, VPN पुन्हा कनेक्ट होणे तुमची दुरुस्ती रद्द करते, आणि शेवटी संघातील कोणीतरी फाइल लॉक करण्याचा सल्ला देते. हा क्रम लक्षण आहे, उपाय नाही: दोन्ही घटकांचा असा विश्वास असतो की /etc/resolv.conf त्यांची आहे, आणि शेवटी जो लिहितो तो जिंकतो. फाइल लॉक केल्याने मालकीचा संघर्ष सुटत नाही, तो फक्त लपवला जातो आणि तुम्हाला खरोखर हवा असलेला घटक तुटतो. खालील चार तपासण्या क्रमाने करा आणि फाइलेवर नव्हे, तर तिची मालकी असलेल्या स्तरावर रचना दुरुस्त करा.

तपासणी 1: हे सिमलिंक आहे का, आणि कुठे

फाइलपासूनच सुरुवात करा, कारण तुम्ही संपादित करत असलेला मार्ग फाइलच नसू शकतो. रिझॉल्व्हरच्या रनटाइम डिरेक्टरीकडे जाणारी सिमलिंक, क्लायंट स्क्रिप्ट पुन्हा लिहिणाऱ्या साध्या फाइलपेक्षा पूर्णपणे वेगळी वागते:

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

systemd-resolved च्या stub मार्गाकडे जाणाऱ्या लिंकचा अर्थ फाइलचा आशय तयार होतो, आणि हाताने केलेले संपादन पुढील घटनेत अधिलिखित होईल. nameserver ओळींची साधी फाइल सहसा कनेक्ट होताना चालणारा क्लायंट किंवा DHCP हुक लिहितो. दोन्ही वैध आहेत; महत्त्वाचे म्हणजे काहीही बदलण्यापूर्वी तुमच्याकडे कोणती आहे हे जाणून घेणे.

तपासणी 2: कोणता डेमन चालू आहे

काय इंस्टॉल आहे ते नव्हे, तर काय खरोखर सक्रिय आहे ते शोधा. आधुनिक वितरणावर अनेक रिझॉल्व्हर असू शकतात, आणि लूपबॅक इंटरफेसवर पोर्ट 53 धरणारा उत्तर देतो:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

स्थिती आउटपुट प्रत्येक लिंकचे DNS सर्व्हर आणि राउटिंग डोमेन सांगते, जे स्प्लिट DNS साठी आवश्यक नकाशा आहे. जर अंतर्गत नावे अंतर्गत सर्व्हरकडे आणि बाकी सर्व सार्वजनिक सर्व्हरकडे जायला हवीत, तर ते धोरण प्रत्येक लिंकच्या डोमेनमध्ये राहते, आणि ते फाइलमधील स्थिर nameserver यादीत सपाट करणे तो फरक शांतपणे गमावते.

NetworkManager चे स्वतःचे कॉन्फिगरेशन यापैकी कोणता बॅकएंड वापरायचा हे ठरवते. मुख्य कॉन्फिगरेशन फाइलमधील त्याची dns= सेटिंग त्याचा अंतर्गत रिझॉल्व्हर, dnsmasq, systemd-resolved आणि none यांमध्ये निवड करते, आणि वितरणाने तुमच्यासाठी निवडले असेल. या होस्टवर “DNS दुरुस्त करणे” म्हणजे काय हे ठरवण्यापूर्वी ती सेटिंग वाचा.

तपासणी 3: VPN क्लायंटला काय लिहिण्याची परवानगी आहे

संघर्ष सहसा इथेच राहतो. रिझॉल्व्हर फाइल थेट पुन्हा लिहिणारा VPN क्लायंट ती देखील सांभाळणाऱ्या कोणत्याही सेवेशी भांडेल, आणि हरतो तो जो आधी चालतो. अलीकडील OpenVPN आवृत्त्या फाइल पुन्हा लिहिण्याऐवजी DNS सेटिंग्ज systemd-resolved ला देऊ शकतात, जे तुम्हाला हवे असलेले सहकार्याचे वर्तन आहे; जुन्या स्क्रिप्टी आणि हाताने लिहिलेले हुक अनेकदा जुने सहाय्यक साधन बोलावतात किंवा फाइलवर सरळ लिहून देतात.

WireGuard ची स्थिती आकाराने समान आहे: इंटरफेस कॉन्फिगरेशन स्वतः DNS व्यवस्थापित करत नाही, आजूबाजूची साधने करतात, रिझॉल्व्हर सहाय्यक किंवा resolved एकत्रीकरणाद्वारे. असे दोन सहाय्यक स्थापित असतील, तर दोन्ही कनेक्ट होताना आपले जगाचे दर्शन लागू करण्याचा प्रयत्न करतील.

अंदाज लावण्याऐवजी क्लायंटचे up आणि down हुक वाचा. /etc/openvpn/up.sh किंवा समतुल्य डिरेक्टरीतील काही ओळी shell अन्यथा यादृच्छिक वाटणारे वर्तन स्पष्ट करतात, आणि क्लायंटला स्पर्धा करण्याऐवजी सहकार्य करायला लावण्याची जागा देखील तीच आहे.

तपासणी 4: मालकाकडे दुरुस्त करा, फाइलमध्ये नाही

मालक कोण आहे हे कळल्यावर त्या मालकाच्या समर्थित इंटरफेसद्वारे DNS कॉन्फिगर करा. systemd-resolved साठी याचा अर्थ स्थिर फाइलऐवजी प्रत्येक लिंकच्या सेटिंग्ज आणि राउटिंग डोमेन; NetworkManager साठी कनेक्शन प्रोफाइलच्या DNS सेटिंग्ज आणि निवडलेला बॅकएंड; resolvconf एकत्रीकरण वापरणाऱ्या वितरणासाठी त्या सहाय्यकाद्वारे लिहिणे.

फाइल अपरिवर्तनीय करू नका. अपरिवर्तनीय गुणधर्म वैध DHCP नूतनीकरणे आणि VPN अपडेट्स तुम्ही ज्यांच्याशी भांडत होता त्यांच्यासह थांबवतो, आणि पुढील पॅकेज अपग्रेड किंवा पुन्हा कनेक्शन कॉन्फिगरेशनमधून कोणीही स्पष्ट करू शकत नाही अशी अयशस्वीता निर्माण करणाऱ्या स्थितीत प्रणाली सोडतो. तो मालकीचा संघर्ष लपवतो, जो तुम्ही सोडवण्याचा प्रयत्न करत होता तोच.

जिथे दोन घटकांना खरोखर एकत्र राहावे लागते, तिथे त्यांना वेगवेगळी कामे द्या. नेटवर्क मॅनेजरकडे इंटरफेस-स्तरीय कॉन्फिगरेशन ठेवा, VPN क्लायंटने त्याच एकत्रीकरणाद्वारे प्रत्येक लिंकचे DNS आणि डोमेन योगदान द्यावे, आणि फाइल थेट लिहिणारी तिसरी स्क्रिप्ट काढून टाका. systemd-resolved चे दस्तऐवज त्याला समर्थन असलेल्या मोड्स आणि प्रत्येक /etc/resolv.conf मध्ये काय दाखवते ते सांगते. तुम्हाला किती धोरण ठेवायचे आहे त्याला जुळणारा मोड निवडा. स्प्लिट DNS महत्त्वाचे असल्यास, प्रत्येक लिंकच्या डोमेनसह stub रचना ते जपते, तर upstream सर्व्हर फाइलमध्ये कॉपी करणारा मोड ते शांतपणे सपाट करतो.

पुन्हा कनेक्शननंतर पडताळा, संपादनानंतर नाही

तुमच्या बदलानंतर लगेच बरोबर दिसणारी फाइल काहीही सिद्ध करत नाही, कारण पुढील घटना अजून घडलेली नाही. जो क्रम पूर्वी ती तोडत असे तो चालवा: टनेल खाली आणि पुन्हा वर करा, DHCP लीजचे नूतनीकरण करा किंवा इंटरफेस टॉगल करा, नंतर तीच मूल्ये पुन्हा वाचा.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

मग महत्त्वाचा फरक पुष्ट करा: अंतर्गत नाव अंतर्गत सर्व्हरद्वारे सोडवले जाते आणि सार्वजनिक नाव अजूनही काम करते. सर्व काही अंतर्गत सर्व्हरकडे पाठवणारे कॉन्फिगरेशन कोणी टनेलमधून इंटरनेट गाठण्याचा प्रयत्न करेपर्यंत ठीक दिसते, आणि सर्व काही सार्वजनिककडे पाठवणारे कॉन्फिगरेशन अंतर्गत नावे गळकी करते.

डिप्लॉयमेंट नोट्समध्ये मालक, बॅकएंड आणि सिमलिंक मोड नोंदवा. तो एकच परिच्छेद भविष्यातील पॅकेज अपग्रेडला घटनेऐवजी पुनरावलोकन बिंदू बनवतो, आणि पुढच्या व्यक्तीला chattr कमांडने तोच संघर्ष पुन्हा शोधण्यापासून थांबवतो.