/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 आदेशले त्यही द्वन्द्व फेरि पत्ता लगाउनबाट रोक्छ।