तपाईंको VPN ले तीन DNS सर्भर पठाउँछ: कुनले जवाफ दिन्छ?
थप प्रविष्टिहरू फलब्याक, प्रति-डोमेन मार्ग वा भौतिक लिङ्कको अवशेष हुन सक्छन्। सूचीलाई चुहावट भन्नु अघि प्रत्येकलाई एउटा दायरासँग जोड्नुहोस्।
जडान गरेपछि सेटिङ्स पृष्ठ खोल्नुहोस् र तीन DNS ठेगानाहरू सूचीबद्ध देखिन्छन्; अडिटको प्रश्न यो हो कि तपाईंको अन्तिम क्वेरी कसले सम्हाल्यो। केवल संख्याले कुनै जवाफ दिँदैन, किनकि क्लाइन्ट पुश, भौतिक इन्टरफेस र प्रति-डोमेन नीति सबै एउटै दृश्यमा लेख्छन्। यी प्रविष्टिहरूका फरक दायराहरू छन्, र जवाफ कसले दिने भन्ने स्थानले होइन, दायराले निर्धारण गर्छ। स्रोतहरू छुट्याएर सुरु गर्नुहोस्, त्यसपछि तपाईंका लागि महत्त्वपूर्ण नाम भएको स्रोत परीक्षण गर्नुहोस्।
सूची तपाईंको प्रोफाइलभन्दा लामो किन छ
VPN क्लाइन्टले टनेल लिङ्कका लागि रिजोल्भर ठेगानाहरू पुश गर्छ, र अपरेटिङ सिस्टमले तिनीहरूलाई भौतिक इन्टरफेसमा पहिले नै भएको कुराको छेउमा राख्छ। राउटर, कर्पोरेट DHCP लिज, दोस्रो VPN र प्रति-डोमेन नीति प्रत्येकले आफ्नै प्रविष्टि थप्छ। त्यसैले पृष्ठमा तीन ठेगानाले एउटा कामका लागि तीन उम्मेदवार होइन, तीन दायरा जनाउन सक्छ। संख्यालाई चुहावटको प्रमाणका रूपमा पढ्नु यो अडिटको पहिलो गल्ती हो।
एउटा इन्टरफेसभित्र क्लाइन्टले साँच्चै आफ्ना सर्भरहरू क्रममा प्रयास गर्छ, त्यसैले क्रमबद्ध सूची अर्थहीन छैन। जो लाइन होइन त्यो मिलाइएको दृश्य हो, जहाँ प्रोफाइल, भौतिक लिङ्क र प्रति-डोमेन नियमका प्रविष्टिहरू एउटै क्रमबिना छेउछाउ बस्छन्। यही भिन्नताले तपाईं के परीक्षण गर्ने निर्धारण गर्छ: क्रमले एउटा दायराभित्रको व्यवहार व्याख्या गर्छ, र दायराले बाँकी सबै।
इन्क्रिप्टेड DNS ले चित्रलाई एप्लिकेसनभित्रबाट तोड्छ। आफ्नै DNS-over-HTTPS रिजोल्भर भएको ब्राउजर वा च्याट क्लाइन्टले क्वेरीहरू अपरेटिङ सिस्टमको सूची पूरै बाइपास गरेर पठाउँछ, त्यसैले सेटिङ्स पृष्ठका ठेगानाहरूले एपले कहिल्यै नबनाएको ट्राफिक वर्णन गर्छन्। नाम गलत आएकोमा प्रोफाइललाई दोष दिनु अघि एपकै रिजोल्भर सेटिङ जाँच्नुहोस्।
तीन जाँचमध्ये प्रत्येकले के भन्छ
प्रत्येक स्रोतले आफ्नो चिन्ह फरक ठाउँमा छोड्छ, र कुनै एउटा आदेशले सबै देखाउँदैन। सेटिङ्स पृष्ठको छेउमा राख्न लायक म्यापिङ यो हो:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
systemd-resolved प्रयोग गर्ने प्रणालीमा resolvectl status आधिकारिक हो, किनकि यसले राउटिङ डोमेनसहित प्रत्येक लिङ्कको DNS रिपोर्ट गर्छ। macOS scutil --dns मार्फत जवाफ दिन्छ, जसले दायरा भएका रिजोल्भरहरूलाई प्रयासको क्रममा सूचीबद्ध गर्छ। Windows ले दुई आधा भाग गर्छ: प्रति-इन्टरफेस सर्भरका लागि Get-DnsClientServerAddress र सफिक्स नियमका लागि Get-DnsClientNrptPolicy। वास्तवमा प्रयोग भइरहेको रिजोल्भरसँग सम्बन्धित आदेश चलाउनुहोस्, किनकि कन्टेनर रनटाइम र डेस्कटप रिजोल्भर भएको मेसिनमा एकभन्दा बढी स्थापित हुन सक्छ।
तपाईंको जोनको जवाफ दिन नसक्ने ब्याकअप रिजोल्भर
दोस्रो प्रविष्टि सामान्यतया उपलब्धताका लागि हुन्छ, र उपलब्धता ब्याकअपले नामहरू जानेमा मात्र काम गर्छ। सार्वजनिक रिजोल्भरलाई आन्तरिक होस्टनेम सोध्नुहोस्, त्यसले NXDOMAIN फर्काउँछ, वा तपाईंसँग कुनै सम्बन्ध नभएको खोज डोमेनबाट वाइल्डकार्ड जवाफ दिन्छ। कसैले नजाँचेको फेलओभरले त्यसपछि ठ्याक्कै आवश्यक क्षणमा अवरोध उत्पन्न गर्छ।
Split DNS त्यो रोक्नकै लागि छ: कम्पनीका सफिक्सहरू जोन राख्ने रिजोल्भरकहाँ जान्छन्, र सार्वजनिक नामहरू पूर्वनिर्धारित मार्गमा रहन्छन्। डिजाइन बलियो छ, र यो सफिक्स सूची पूर्ण हुनमा निर्भर छ। Microsoft ले प्रति-सफिक्स रिजोल्भर नीति सम्बन्धी दस्तावेजीकरण गर्छ, जसले Windows मा यो चलाउँछ, र त्यही विचार systemd-resolved मा राउटिङ डोमेन र macOS मा दायरा भएका रिजोल्भरका रूपमा देखिन्छ।
ब्याकअपले जवाफ दिन सक्ने जोनहरूको नीतिमा भएका सफिक्सहरूसँग तुलना गर्नुहोस्। यो तुलनाले प्रयोगकर्ताले टनेल परिवर्तनपछि एउटा आन्तरिक साइट समाधान हुन छोड्यो भनी रिपोर्ट गर्नु अघि नै खाडल भेट्टाउँछ।
नीतिभित्रबाट सोध्नुहोस्, वरिपरि होइन
अपरेटिङ सिस्टमको रिजोल्भरमार्फत सोध्नुहोस्, किनकि सर्भरमा सिधा क्वेरीले नीति बाइपास गर्छ र त्यो सर्भरले के भन्थ्यो त्यति मात्र रिपोर्ट गर्छ। दुई जवाफबीचको खाडल नै सम्पूर्ण कुरा हो:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53यदि प्रणाली क्वेरीले निजी ठेगाना फर्काउँछ र सिधा क्वेरीले NXDOMAIN फर्काउँछ भने, नीति काम गरिरहेको छ र कमजोर बिन्दु ब्याकअप हो। यदि दुवैले एउटै सार्वजनिक जवाफ फर्काउँछन् भने, नाम तपाईंले सोचेको दायराबाहिर समाधान भइरहेको छ, र सफिक्स सूची हेर्ने ठाउँ हो। दुवै आउटपुट राख्नुहोस्, किनकि सेटिङ्स पृष्ठको स्क्रिनसटभन्दा दुई लाइनले रिजोल्भर बहस छिटो टुंगिन्छ।
त्यसपछि असफलताको मार्ग अभ्यास गर्नुहोस्, किनकि कसैले नजाँचेको फलब्याक एउटा अनुमान हो। एउटा क्वेरीका लागि मनपर्ने रिजोल्भरलाई ब्ल्याकहोल बनाउनुहोस् र कुन ठेगाना फर्कन्छ हेर्नुहोस्:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32क्वेरी सकिएपछि तुरुन्तै त्यो मार्ग मेट्नुहोस्, नत्र अर्को व्यक्तिले एउटा रहस्य पाउँछ। यदि त्यो अवधिमा आन्तरिक नामहरू अझै समाधान भइरहेका छन् भने, इच्छित दायराबाहिरको कुनै कुराले तिनलाई जवाफ दिएको छ। यदि तिनीहरू समय सकिएर बन्द भए भने, फलब्याक छैन वा राम्ररी सीमित छ, र रिजोल्भरकै लगले दुईमध्ये कुन भएको बताउँछ।
निर्णय गर्नुहोस्: राख्नुहोस्, सीमित गर्नुहोस् वा हटाउनुहोस्
दोस्रो रिजोल्भर तब राख्नुहोस् जब यसले तपाईंलाई आवश्यक नामस्थानको जवाफ दिन्छ र प्रोफाइलमुनि पुग्नयोग्य रहन्छ। यसलाई एउटा सफिक्स मात्र देख्नुपर्ने भए सीमित गर्नुहोस्, र यसको दायरा वा दस्तावेजी उद्देश्य छैन भने हटाउनुहोस्। काम नभएको प्रविष्टि लाभ नभएको भविष्यको चुहावट हो, र विक्रेताको पूर्वनिर्धारण उद्देश्य होइन।
नतिजा चार स्तम्भमा लेख्नुहोस्: सफिक्स, रिजोल्भर, इन्टरफेस र मालिक। त्यो लाइनले कुनै पनि स्क्रिनसटभन्दा छिटो अर्को अडिट प्रश्नको जवाफ दिन्छ, र सूचीलाई चुपचाप पुनर्व्यवस्थित गर्ने क्लाइन्ट अपडेटबाट पनि बाँच्छ।