तुमचा 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 वर उत्तर देणारे काहीही.