/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 कमांड से वही टकराव फिर से खोजने से रोकता है।