किन resolv.conf ले तपाईंको VPN DNS देखाउँछ तर खोजहरूले यसलाई बेवास्ता गर्छन्

लगहरूमा केही पनि गलत देखिँदैन: इन्टरफेस चालु छ, रिजोल्भरले VPN को DNS सर्भर रिपोर्ट गर्छ, र डिस्कको फाइलले त्यसलाई सूचीबद्ध गर्छ। तैपनि आन्तरिक होस्टनाम स्थानीय राउटरमार्फत नै हल हुन्छ। यी तीन भनाइहरू एकअर्कासँग विरोधाभासी छैनन्, किनकि फाइल, प्रत्येक लिङ्कको अवस्था र खोजको मार्ग फरक वस्तुहरू हुन् जसको संयोगवश एउटै नाम छ। तल systemd-resolved भएको होस्टमा क्वेरीले वास्तवमा लिने मार्ग वर्णन गरिएको छ।

resolv.conf नामका तीन वस्तुहरू

resolved भएको होस्टमा /etc/resolv.conf सामान्यतया /run/systemd/resolve/stub-resolv.conf मा जाने साङ्केतिक लिङ्क हो। त्यो लक्ष्यमा स्थानीय stub श्रोताको ठेगाना, 127.0.0.53, र resolved ले गणना गरेका खोज डोमेनहरू हुन्छन्। यो अवस्थाको दृश्य हो, अवस्था आफैं होइन।

अवस्था resolved को प्रत्येक लिङ्कको कन्फिगरेसनमा बस्छ, त्यसैले resolvectl status फाइलसँग असहमत हुँदै पनि सही हुन सक्छ। प्रत्येक लिङ्कले आफ्नै सर्भर र आफ्नै राउटिङ डोमेन बोक्छ, र क्वेरी आउँदा stub ले त्यो डाटा हेर्छ। systemd-resolved को निर्देशिका ले सिर्जना गरिएका फाइल र प्रत्येक लिङ्कको मोडेल वर्णन गर्छ; दृश्य र अवस्थाबीचको विभाजन नै सम्झन लायक भाग हो। साङ्केतिक लिङ्कको लक्ष्य बदल्दा परम्परागत क्लाइन्टले पढ्ने कुरा बदलिन्छ, रिजोल्भरले जान्ने कुरा होइन।

तेस्रो वस्तु, /run/systemd/resolve/resolv.conf, प्रत्येक लिङ्कलाई एउटै सर्भर सूचीमा समतल बनाउँछ। त्यो फाइलतर्फ देखाइएको प्रोग्रामले क्वेरीहरू सिधै सूचीबद्ध सर्भरहरूमा पठाउँछ र stub छोड्छ, त्यसैले प्रत्येक लिङ्कको नीति अब यसमा लागू हुँदैन। त्यसैले एउटै मेसिनका दुई प्रोग्रामले एउटै नामको फरक जवाफ दिन सक्छन्, र दुवैमध्ये कुनै पनि बिग्रिएको छैन।

NSS मार्फत एउटा खोज पछ्याउनुहोस्

glibc नामको जवाफ कसले दिने भनेर निर्णय गर्न /etc/nsswitch.conf पढ्छ। resolve भएको hosts लाइनले प्रश्न nss-resolve मा पठाउँछ, जसले D-Bus मार्फत resolved लाई सोध्छ र प्रत्येक लिङ्कको जवाफ पाउँछ। केवल files dns भएको लाइनले क्वेरी /etc/resolv.conf सँग भएको ठेगानामा पठाउँछ।

त्यो एउटै लाइनले ब्राउजर र dig बीचका अधिकांश मतभेद व्याख्या गर्छ। dig सिधै resolv.conf पढ्छ र NSS लाई कहिल्यै छुँदैन, त्यसैले यसले एप्लिकेसनले प्रयोग गर्ने मार्गको सट्टा stub वा माथिल्लो सर्भर परीक्षण गर्छ। getent hosts internal.example NSS बाट जान्छ, र यसको जवाफलाई dig को जवाफसँग तुलना गर्नु पहिलो उपयोगी मापन हो।

आफ्नै रिजोल्भर बोकेका वा निश्चित एन्डपोइन्टमा HTTPS मा DNS बोल्ने एप्लिकेसनहरूले दुवै मार्ग छोड्छन्। resolv.conf मा वा resolved को अवस्थामा केहीले पनि तिनलाई सीमित गर्दैन।

फाइल कसको हो र कता देखाउँछ जाँच्नुहोस्

केही पनि बदल्नुअघि लिङ्क शृंखला पढ्नुहोस्, किनकि स्वामित्वले कुन फाइल प्रामाणिक हो निर्धारण गर्छ। तलको हरेक आदेशले अवस्था मात्र पढ्छ।

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

पहिलो लाइनले लिङ्क र त्यसको लक्ष्य सँगै छाप्छ, र VPN स्क्रिप्टको स्वामित्वमा भएको साधारण फाइलको अर्थ रिजोल्भरले त्यो लेखाइलाई कहिल्यै इनपुट मान्दैन। अवस्थाको आउटपुटले प्रत्येक लिङ्कका सर्भर र प्रत्येक क्वेरी कहाँ जान्छ निर्धारण गर्ने राउटिङ डोमेन सूचीबद्ध गर्छ। nsswitch लाइनले stub को सल्लाह बिल्कुलै लिइन्छ कि भन्ने बताउँछ, त्यसैले फाइलमा stub ठेगाना भए पनि त्यहाँ resolve नभए क्वेरीहरू स्थानीय श्रोतासम्म पुग्छन् तर विभाजन कसैले व्यवस्थापन गर्दैन। त्यो अन्तिम सूची पनि महत्त्वपूर्ण छ, किनकि stub-resolv.conf नभएको होस्टले यहाँ वर्णन गरिएको व्यवस्था चलाउँदैन।

शृंखला अर्को प्याकेजले व्यवस्थापन गर्ने फाइलमा टुंगिएमा, VPN क्लाइन्ट र त्यो प्याकेज मिलाउनुपर्ने दुई मालिक हुन्। लिङ्क प्रतिस्थापन गर्दा एक मालिकको काम फालिन्छ र अर्काको आफ्नै ठाउँमा रहन्छ।

लिङ्कको मालिककहाँ मर्मत गर्नुहोस्

VPN जडानले आफ्ना सर्भर र डोमेन आफ्नै लिङ्कमा दर्ता गर्नुपर्छ, त्यसपछि विच्छेद हुँदा ती फिर्ता लिनुपर्छ। NetworkManager को resolved एकीकरण र क्लाइन्टको आफ्नै सहायक दुवै यसरी काम गर्छन्; केवल resolv.conf पुनःलेखन गर्ने स्क्रिप्टले त्यसो गर्दैन।

पहिले नै अवस्थित लिङ्कमा रनटाइम सेटिङहरूले संयन्त्र देखाउँछन्। resolvectl dns tun0 10.40.0.53 ले सर्भर जोड्छ, र resolvectl domain tun0 '~corp.example' ले राउटिङ डोमेन जोड्छ। टिल्डा (~) भार बोक्ने अक्षर हो: यसले त्यो प्रत्ययका क्वेरीलाई यही लिङ्कमा सीमित गर्छ र बाँकी सबै शान्त छोड्छ, जबकि यसबिना त्यही मान खोज डोमेन बन्छ र विभाजन वाष्प हुन्छ। ती ठेगानाहरू प्रयोगशालाका उदाहरण हुन्, स्थायी कन्फिगरेसन होइन। resolvectl query host.corp.example सँग पुष्टि गर्नुहोस् र कुन लिङ्कले जवाफ दियो पढ्नुहोस्।

दर्ता भएको सर्भरलाई अझै मार्ग चाहिन्छ। क्वेरी ठीक लिङ्कमा पुगेर समय सकिँदा, दोष रिजोल्भरको स्वामित्वमा होइन, सुरुङमार्फत पुग्ने क्षमतामा हुन्छ।

काम गर्ने अवस्था कस्तो देखिन्छ

स्वस्थ नतिजा तीनै दृश्यमा सुसंगत हुन्छ: प्रत्येक लिङ्कका सर्भर VPN ले दिएकोसँग मिल्छन्, राउटिङ डोमेनहरूले आन्तरिक प्रत्यय मात्र ढाक्छन्, र महत्त्वपूर्ण एप्लिकेसनले आन्तरिक नाम हल गर्छ जबकि सार्वजनिक नाम अझै स्थानीय मार्गमै जान्छ। एउटा सफल क्वेरी त्यो सहमतिभन्दा कम प्रमाणित गर्छ।

त्यसपछि विच्छेद गर्नुहोस् र दुवै क्वेरी दोहोर्याउनुहोस्। टियरडाउनपछि आफ्ना डोमेन दर्ता गरिएकै छोड्ने क्लाइन्टले केही घण्टापछि आन्तरिक खोजमा असफल हुने मेसिन बनाउँछ, खुला सुरुङ र स्पष्ट कारण बिना।