तपाईंको Mac ले VPN मा प्रयोग गर्ने DNS रिजोल्भरहरू कसरी जाँच्ने

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

ठेगानाभन्दा पहिले ब्लकको क्रम पढ्नुहोस्

हरेक प्रविष्टि resolver #N बाट सुरु हुन्छ र nameserver[0], कहिलेकाहीं if_index, flags लाइन, reach र ब्लक साधारण डिफल्ट नभए domain तथा search domain सूची देखाउँछ। डोमेन नभएको 1 नम्बर रिजोल्भर सार्वजनिक नाम सम्हाल्ने डिफल्ट हो। आफ्ना फ्ल्यागमा Scoped बोक्ने जुनसुकै if_index ले नाम दिने इन्टरफेसमा बाँधिएको हुन्छ, र Supplemental ले चिन्ह लगाइएको जुनसुकै कुरा त्यसको तल सूचीबद्ध डोमेनमा मात्र लागू हुन्छ।

छनोट प्रत्यय मिलान हो। intranet.corp.example जस्तो नामका लागि, domain प्रविष्टि सबैभन्दा लामो मिल्ने प्रत्यय भएको रिजोल्भरलाई macOS प्राथमिकता दिन्छ, त्यसैले domain : corp.example भएको ब्लक आउटपुटमा धेरै तल भए पनि डिफल्टलाई हराउँछ। समान लम्बाइका डोमेनबीचको बराबरी order ले टुंग्याउँछ। पहिलो नजरलाई यसभन्दा बढी विरलै चाहिन्छ: एउटा ब्लक सुरुदेखि अन्त्यसम्म पढ्न चाहँदा पूरै आउटपुट, ब्लक क्रम जान्न सुरुका लाइनहरू, र फिल्ड लाइनको छेउमा ब्लक शीर्षक छाप्ने फिल्टर गरिएको एक चक्कर। स्कोप गरिएका ब्लक आफ्नै शीर्षकमुनि देखिन्छन् र माथिको सूचीको निरन्तरता जस्तो पढिन्छन्, त्यसैले आउटपुट उद्धृत गर्दा शीर्षक आँखाबाट ओझेल नगर्नुहोस्।

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

if_index लाई टनेल इन्टरफेससँग मिलाउनुहोस्

इन्डेक्स त्यसको पछाडिको इन्टरफेस नाम दिन सके मात्र उपयोगी हुन्छ। scutil --nwi प्रणालीसँग रहेको नेटवर्क जानकारी सूचीबद्ध गर्छ, जसमा प्राथमिक इन्टरफेस र पहुँच समावेश छ, जबकि ifconfig -l तपाईंलाई नामहरू दिन्छ, जहाँ utun0 देखि utun9 सम्म क्लाइन्टले सामान्यतया बनाउने टनेल उम्मेदवार हुन्। Apple ले आफ्नै जाँच उदाहरणका रूपमा scutil --dns लाई परिनियोजन गाइडमा प्रयोग गर्छ, र Network Extension ले छानिएका डोमेनलाई छानिएका रिजोल्भरमा कसरी मार्गनिर्देशन गर्न सक्छ भन्ने दस्तावेजीकरण गर्छ; ती स्कोप गरिएका ब्लकहरूले देखाउने संयन्त्र त्यही हो।

प्रश्न टुंग्याउने जाँच भनेको रिजोल्भर टनेलले स्थापित गरेको मार्गमा छ कि छैन भन्ने हो:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

route -n get ले रिजोल्भर प्रविष्टिसँग नमिल्ने गेटवे र इन्टरफेस फर्काएमा, ठेगाना पूर्ण रूपमा सही हुँदै पनि पुग्न नसकिने हुन सक्छ। कर्पोरेट सबनेट मात्र बोक्ने स्प्लिट टनेलले तिनका बाहिरको DNS सर्भरतर्फ जाने क्वेरी फालिदिन्छ, र असफलता समय सकिने रूपमा देखिन्छ, त्यसैले कन्फिगरेसन आउटपुट सधैं सफा देखिन्छ।

सिस्टम रिजोल्भरलाई सोध्नुहोस्, त्यसपछि सर्भरलाई

तीन औजारले तीन फरक प्रश्नको जवाफ दिन्छन्, र तिनलाई छेउछाउ मिलाउँदा यस क्षेत्रका अधिकांश गलत निष्कर्ष उत्पन्न हुन्छन्। dscacheutil -q host -a name साधारण एपहरूले प्रयोग गर्ने त्यही सिस्टम रिजोल्भरबाट जान्छ, त्यसैले स्कोप गरिएका र पूरक ब्लक लागू हुन्छन्। सर्भर आर्गुमेन्ट नभएको dig ले /etc/resolv.conf पढ्छ, जो macOS मा स्कोप गरिएको रिजोल्युसनका लागि सत्यको स्रोत होइन, र यसले प्रत्येक डोमेनका नियम पूरै छोडिदिन्छ। dig @address ठ्याक्कै एउटा सर्भरमा पुग्छ र छनोटबारे केही भन्दैन।

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

पहिलो आदेशले जवाफ दिएर दोस्रोले NXDOMAIN फर्काएमा, तपाईंले खोज्नुभएको विभाजन भेटियो र केही पनि बिग्रिएको छैन। पहिलोले समय सकिँदा dig @10.20.0.53 ले जवाफ दिइरहेको छ भने, रिजोल्भर काम गर्छ तर टनेलले छानेको मार्गमा पुग्न सकिँदैन, त्यसैले अर्को कदम DNS सेटिङ बदल्नु होइन, route -n get हो। निजी नामहरू टिकट वा साझा नोटमा टाँस्ने कुनै पनि कुराबाट बाहिर राख्नुहोस्।

आउटपुटले तपाईंलाई के देखाउन सक्दैन

रिजोल्भर सूचीको माथि वा छेउमा धेरै तह बस्छन्, र प्रत्येकले आउटपुटले कहिल्यै उल्लेख नगर्ने ठाउँमा क्वेरी पठाउन सक्छ। सुरक्षित DNS सक्रिय भएको ब्राउजरले आफ्नै इन्क्रिप्टेड च्यानलबाट रिजोल्भ गर्न सक्छ, त्यसैले dscacheutil समय सकिँदा पृष्ठ लोड हुनु विरोधाभास होइन। सुरक्षा सफ्टवेयरले राखेको DNS प्रोक्सीले Network Extension प्रदायकका रूपमा चल्छ र आफैं क्वेरी फर्वार्ड गर्छ, र scutil --dns ले के कन्फिगर गरिएको थियो देखाउँछ, प्रोक्सीले अन्तमा प्रयोग गरेको अपस्ट्रिम ठेगाना होइन। खोज डोमेनले तेस्रो मोड थप्छ: अयोग्य नाममा सूचीबद्ध प्रत्येक प्रत्यय क्रमैसँग जोडिन्छ, त्यसैले जवाफ दिने ब्लक तपाईंले कहिल्यै शंका नगरेको हुन सक्छ।

पुराना जवाफ बहिष्कार गर्न सबैभन्दा सस्तो र सबैभन्दा धेरै छुट्ने कुरा हुन्:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

फ्लसपछि आउटपुट बदलियो भने, स्थिति क्यासमा थियो र अघिल्लो आउटपुटले अब नभएको टनेलको वर्णन गरेको थियो। नबदलियो भने, कन्फिगरेसन जस्तो छ त्यस्तै छ, र प्रश्न मार्ग र एप नीतितर्फ सर्छ।

अघि र पछिका लागि छोटो रनबुक

नीतिले अनुमति दिएको ठाउँमा मात्र आधाररेखा लिनुहोस्, र फाइलहरू कुनै पनि सिंक गरिएको फोल्डरबाहिर राख्नुहोस्। तलको क्रम मैले क्लाइन्ट मेसिनमा चलाउने हो: आधाररेखा लिनुहोस्, जोडिनुहोस्, फेरि लिनुहोस्, त्यसपछि तुलना गर्नुहोस् र खोज्नुहोस्।

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

भिन्नता लाइनअनुसार नभई ब्लकअनुसार पढ्नुहोस्। टनेल इन्टरफेस इन्डेक्स र निजी प्रत्ययका लागि domain प्रविष्टि बोक्ने नयाँ स्कोप गरिएको रिजोल्भर नै अपेक्षित आकार हो। सार्वजनिक ठेगानातर्फ देखाउने नयाँ डिफल्ट रिजोल्भर क्लाइन्ट प्रोफाइलको मालिकसामु राख्न लायक फेला हो। त्यसपछि लुकअप साँच्चै असफल भएको एपभित्र दोहोर्याउनुहोस्, शेलमा मात्र होइन, र नतिजाको छेउमा route -n get को इन्टरफेस लेख्नुहोस्।

परिवर्तन फर्काउन डिस्कनेक्ट गर्नुहोस् र आधाररेखा लिने क्रम दोहोर्याउनुहोस्। स्कोप गरिएको ब्लक गयो भने, क्लाइन्टले आफ्नो पछाडि सफा गरेको छ। ब्लक अझै नभएको इन्टरफेसविरुद्ध सूचीबद्ध छ भने, स्थिति पुरानो छ, र कसैले प्रोफाइल छुनुअघि फ्लस र पुनः जडान नै सबैभन्दा नरम समाधान हो।

यस क्रममा चार जाँच: कुनै रिजोल्भर ब्लक नामको सबैभन्दा लामो प्रत्ययसँग मिल्छ कि; त्यो ब्लक टनेलले स्थापित गरेको इन्टरफेसमा बाँधिएको छ कि; त्यसको नेमसर्भरतर्फको मार्गले टनेल प्रयोग गर्छ कि; र dig होइन, सिस्टम रिजोल्भरले जवाफ फर्काउँछ कि। पहिलो असफल जाँचले DNS नीति, टनेल मार्ग वा एप बदल्नुपर्ने बताउँछ। चारै पास भएर नाम अझै असफल भयो भने, समस्या DNS माथि छ, र अर्को जाँच्नुपर्ने कुरा त्यसको अगाडि पोर्ट 53 मा जवाफ दिने जुनसुकै हो।