अपने 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 जैसे नाम के लिए macOS उस रिज़ॉल्वर को प्राथमिकता देता है जिसकी domain प्रविष्टि सबसे लंबा मिलता प्रत्यय है, इसलिए 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 पर कौन जवाब देता है।