VPN ने DNS पर कब्ज़ा किया और स्थानीय नाम तोड़ दिए: सूची ठीक करें

टनल ऊपर आता है, इंट्रानेट लोड होता है, और प्रिंटर का नाम हल होना बंद हो जाता है। या उलटा: स्थानीय नाम अब भी काम करते हैं जबकि कॉर्पोरेट नेटवर्क के अंदर सब कुछ समय-सीमा पार कर जाता है। दोनों लक्षण एक ही जगह से आते हैं, रिज़ॉल्वर की एक सूची जिसे VPN क्लाइंट ने कनेक्ट होते समय फिर से लिखा था।

सूची को जानबूझकर ठीक करें, फिर पुश तंत्र को अलग से निपटाएँ। रूट तीसरा विषय हैं और यहाँ जो ठीक किया जा रहा है वह वह नहीं है।

ऐप्लिकेशन असल में कौन-सी सूची इस्तेमाल करते हैं

Windows इंटरफ़ेस-स्तर की सेटिंग्स से हल करता है, किसी डायलॉग के दिखाने से नहीं, इसलिए हर इंटरफ़ेस की प्रभावी सूचियों से शुरू करें। एलियास दिखाए गए नाम से ज़्यादा मायने रखता है, क्योंकि नीचे का हर कमांड किसी इंटरफ़ेस को संबोधित करता है। एलियास ग़लत हुआ तो मरम्मत ग़लत अडैप्टर पर पड़ेगी। यह काम करता दिखेगा अगली बार दोबारा कनेक्ट होने तक, जब टनल की अपनी प्रविष्टि लौट आएगी।

सवाल यह है कि कौन-से सर्वर आगे आए और क्या वे स्थिर प्रविष्टियों के रूप में आए या DHCP लीज़ के रूप में। दोनों तथ्य तय करते हैं कि आपके पास कौन-सी मरम्मत उपलब्ध है।

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

टनल अडैप्टर और भौतिक अडैप्टर के लिए आउटपुट पढ़ें, और दोनों पर हर पता नोट करें। स्थिर प्रविष्टि को नीति या स्क्रिप्ट से हटाया जा सकता है; DHCP से मिली प्रविष्टि लीज़ से बँधी है और लौटेगी, जिससे आपको चुनने वाली मरम्मत बदल जाती है। दूर के नेटवर्क के नाम विज्ञापित रिज़ॉल्वर से हल होते हैं, स्थानीय LAN के नाम भौतिक अडैप्टर से, और क्वेरी उस सूची के पास जाती है जिसे पहले देखा जाता है।

धकेले गए सर्वर हटाएँ, या उन्हें नीचे रखें

धकेले गए सर्वर तब मिटाएँ जब टनल के अंदर किसी को उनकी ज़रूरत न हो, क्योंकि भौतिक अडैप्टर के अपने रिज़ॉल्वर फिर से संभाल लेते हैं। उन्हें तभी रखें जब दूर के नेटवर्क के पास ऐसे ज़ोन हों जिनका जवाब सिर्फ़ उसके सर्वर ही दे सकें, और उस स्थिति में उनके आगे कोई स्थानीय रिज़ॉल्वर रखें। नीचे के दो कमांड दोनों विकल्प कवर करते हैं, इसलिए दोनों चलाने के बजाय स्थिति से मेल खाने वाला चुनें।

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

इंडेक्स 1 पहले देखा जाता है, इसलिए धकेले गए पते उपलब्ध रहते हैं पर हर क्वेरी का डिफ़ॉल्ट जवाब बनना बंद कर देते हैं। validate=no फ़्लैग एक पहुँच-परीक्षण छोड़ देता है जो अक्सर विफल होता है जब टनल अभी स्थिर हो रहा हो, इसलिए एग्ज़िट कोड पर भरोसा करने के बजाय show कमांड से नतीजा पुष्ट करें।

इस पर भरोसा करने से पहले दो सीमाएँ जान लेना ठीक है। Windows उन सर्वरों को नहीं मिटाएगा जो DHCP के ज़रिए netsh से आए हैं, और वे मान इंटरफ़ेस की रजिस्ट्री कुंजी के नीचे DhcpNameServer के रूप में बने रहते हैं, इसलिए रजिस्ट्री संपादन आख़िरी उपाय है जिसे अगली लीज़ के बाद फिर जाँचना पड़ता है। अडैप्टर बाइंडिंग क्रम भी भरोसेमंद रैंकिंग तंत्र नहीं है, क्योंकि VPN क्लाइंट अपनी प्रविष्टि सूची के सबसे ऊपर डाल सकता है।

पुश कहाँ फ़िल्टर किया जा सकता है

बेहतर मरम्मत विकल्प को लागू होने से पहले हटा देती है। Community OpenVPN क्लाइंट किसी धकेले गए निर्देश को नाम से फ़िल्टर कर सकता है, जिससे सर्वर का कॉन्फ़िगरेशन अछूता रहता है।

pull-filter ignore "dhcp-option DNS "

अंत की जगह मिलान का हिस्सा है और फ़िल्टर सर्वर पते के बजाय विकल्प का नाम लेता है। अगर प्रोफ़ाइल में block-outside-dns निर्देश भी है, तो उसे हटाना लीक सुरक्षा बदलता है, नाम हल करना नहीं, इसलिए दो संपादन जोड़ने के बजाय उसे अलग से तय करें।

एक ज़िद्दी होस्टनाम के लिए Windows hosts फ़ाइल में एक पंक्ति पूरी मशीन के लिए रिज़ॉल्वर फिर से क्रम में लगाने से ज़्यादा टिकाऊ है। यह अगले व्यक्ति के लिए अदृश्य भी है, इसलिए इसे वहाँ दर्ज करें जहाँ मशीन का कॉन्फ़िगरेशन प्रलेखित होता है।

मरम्मत को दोबारा कनेक्ट होने तक टिकाएँ

हल करने की जाँच दो बार करनी होती है, एक बार चुने गए सर्वर के सामने और एक बार उस रूप में जो ऐप्लिकेशन इस्तेमाल करता है। यह जोड़ी रिज़ॉल्वर क्रम की समस्या को ऐसे सर्वर से अलग करती है जो बिलकुल जवाब नहीं देता। पहली जाँच छोड़ने से दोनों कारण उलझे रह जाते हैं।

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

टनल दोबारा कनेक्ट करें और दोनों कमांड दोहराएँ। हाथ से जो बदला वह अगले कनेक्शन तक ही टिकता है, क्योंकि क्लाइंट अडैप्टर उठाते समय अपनी रिज़ॉल्वर स्थिति फिर से बनाता है। netsh पंक्तियाँ अपने क्लाइंट की समर्थित कनेक्शन स्क्रिप्ट में डालें, उस स्क्रिप्ट को सफलतापूर्वक ख़त्म होने दें, और उसके चलने से पहले थोड़ी देर का इंतज़ार जोड़ें। स्क्रिप्ट के बाद DNS लागू करने वाला क्लाइंट नतीजे को किसी भी हाल में ऊपर लिख देगा।

अगर सार्वजनिक नाम हल होते हैं और मरम्मत के बाद भी आंतरिक नाम विफल रहते हैं, तो रिज़ॉल्वर सूची अब संदिग्ध नहीं है। क्वेरी शायद सर्वर तक पहुँचती ही नहीं, जो रूटिंग या फ़ायरवॉल नियम की ओर इशारा करता है, किसी और DNS सेटिंग की ओर नहीं। इंटरफ़ेस एलियास और जिन पतों पर आप टिके, उन्हें दर्ज करें, क्योंकि दोनों मशीनों के बीच अलग होते हैं और कोई भी अकेले पुनर्निर्माण में नहीं टिकता।