Windows VPN में ग़लत DNS सर्वर: मीट्रिक, बाइंडिंग क्रम या प्रत्यय
Windows के तीन तंत्र DNS रिज़ॉल्वर चुनते हैं, और वे अलग-अलग ढंग से विफल होते हैं। नामस्थान के दायरे, वैश्विक क्रम, या सुधार पुनःकनेक्शन के बाद टिकता है या नहीं, इसके आधार पर तय करें।
Windows क्लाइंट के पास काम करने वाला टनल हो सकता है, कॉर्पोरेट रिज़ॉल्वर मौजूद हो और फिर भी आंतरिक नाम घरेलू राउटर पर जाएँ। कौन सा सर्वर उत्तर देगा यह तीन अलग तंत्र तय करते हैं, और वे अलग-अलग तरीक़ों से विफल होते हैं। तीनों को ठीक करना ज़रूरी नहीं: लक्षण बताता है कि कौन खेल में है। नीचे दिया निर्णय-वृक्ष कुछ मिनट लेता है और उस आम नतीजे को रोकता है जहाँ मीट्रिक बदलाव, रजिस्ट्री का पुनर्क्रम और NRPT नियम एक साथ आ जाते हैं और किसी को पता नहीं होता कि किसने क्या किया।
तीन तंत्र निर्णय लेते हैं, और आम तौर पर एक ग़लत होता है
इंटरफ़ेस मीट्रिक किसी दिए गए पता-परिवार के लिए एडाप्टरों को क्रम देता है। Tcpip\Linkage के अंतर्गत बाइंडिंग क्रम मशीन-व्यापी इंटरफ़ेस पहचानकर्ताओं की सूची है जिसे पुराने कोड पथ अब भी देखते हैं। नाम विभेदन नीति तालिका (NRPT) किसी नामस्थान को विशिष्ट सर्वरों से बाँधती है, और प्रत्यय सूची तय करती है कि छोटा नाम आख़िर बढ़ाया जाएगा या नहीं। ये स्वतंत्र हैं, इसीलिए VPN एडाप्टर पर सही रिज़ॉल्वर कहीं और की पुरानी वरीयता से हार जाता है।
| What you see | Mechanism to check | First command |
|---|---|---|
| Every name is slow, public names sometimes wrong | Global adapter order: metric, then Linkage | Get-NetIPInterface |
| Internal names resolve to a public address | The query left through the home resolver, not the tunnel | Resolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10 |
| Only corp.example names fail, public names fine | Namespace binding: NRPT or suffix | Get-DnsClientNrptRule |
| Short name fails, fully qualified name works | Suffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the server | Get-DnsClientGlobalSetting |
| Works, then breaks after a reconnect | Runtime setting that was never persisted | Get-VpnConnection for the stored profile, then Get-NetIPInterface again after a reconnect |
इनमें से कोई तंत्र टनल का दूसरा सिरा नहीं है। अगर VPN जो सर्वर धकेलता है वह नाम विभेदित नहीं कर सकता, तो क्लाइंट पक्ष की हर सेटिंग सिर्फ़ सजावट है, इसलिए पहला निर्णय यह है कि रिज़ॉल्वर स्वयं सीधे पूछे जाने पर उत्तर दे सकता है या नहीं।
निर्णय एक: क्या धकेला गया रिज़ॉल्वर आख़िर उत्तर दे सकता है?
सर्वर से स्पष्ट रूप से पूछें और सामान्य लुकअप से तुलना करें। उत्तरों के बीच का अंतर चयन की समस्या को पहुँच की समस्या से अलग करता है, और यहाँ यही सबसे तेज़ शाखा है:
Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type Aअगर पहला सफल हो और दूसरा विफल, तो रिज़ॉल्वर पहुँच में है और Windows ग़लत चुन रहा है; नीचे नामस्थान और क्रम के निर्णयों पर जाएँ। अगर पहला भी विफल हो, तो क्लाइंट पर कुछ काम नहीं आएगा: जाँचें कि UDP और TCP 53 टनल से सर्वर तक पहुँचते हैं, सर्वर पर कोई होस्ट फ़ायरवॉल पूल को गिराता नहीं, और सर्वर के अपने फ़ॉरवर्डर स्वस्थ हैं।
इसी शाखा पर रुकें। जिस रिज़ॉल्वर तक आप पहुँच नहीं सकते उस पर NRPT नियम लगाना वही विफलता ज़्यादा विन्यास के साथ देता है जिसे हटाना पड़े, और यह असली ख़राबी को ऐसे नियम के पीछे छिपा देता है जो आधिकारिक दिखता है।
निर्णय दो: एक नामस्थान, या हर क्वेरी?
दायरा औज़ार तय करता है। जब केवल कॉर्पोरेट नाम विफल हों, तो मशीन को पुनर्क्रमित करने के बजाय नामस्थान बाँधें: NRPT नियम उस प्रत्यय को टनल रिज़ॉल्वर तक भेजता है और बाक़ी सब अछूता छोड़ देता है। जब हर लुकअप प्रभावित हो, समस्या वैश्विक एडाप्टर वरीयता है, और मीट्रिक शुरू करने की जगह है क्योंकि वह कोई सर्वर सेटिंग नहीं बदलती।
हर पता-परिवार के लिए, दोनों इंटरफ़ेसों पर मीट्रिक सेट करें, और फिर क्रम की पुष्टि करें:
Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6ऊपर की पंक्ति से टनल एडाप्टर के ifIndex से 11 बदलें; अगर 11 LAN एडाप्टर है, तो वही कमांड ग़लत पथ नीचे करती है। इसके बजाय LAN एडाप्टर बढ़ाना दूसरी तरफ़ से वही क्रम देता है: netsh int ip set interface interface="Ethernet" metric=15, और दूसरे परिवार के लिए netsh int ipv6 set interface interface="Ethernet" metric=15, क्योंकि int ip केवल IPv4 को छूता है।
बाइंडिंग क्रम पहला क़दम नहीं बल्कि अंतिम उपाय है। HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage डिवाइस पहचानकर्ताओं की Bind सूची रखता है, और टनल पहचानकर्ता को आगे लाना वास्तव में बदलता है कि कौन सा एडाप्टर पहले पूछा जाए, पर यह मशीन-व्यापी रजिस्ट्री मान है जिसका हर नामस्थान के लिए दायरा नहीं है। संपादन से पहले इसे निर्यात करें और बाद में टनल फिर से जोड़ें ताकि क्रम उसी स्थिति में लागू हो जिसकी क्लाइंट अपेक्षा करता है।
एक ही नामस्थान के लिए, संकीर्ण औज़ार चुनें:
Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServersनिर्णय तीन: क्या सुधार पुनःकनेक्शन के बाद टिकता है?
जो मीट्रिक अगले डायल-अप पुनःकनेक्शन तक चलता है वह कभी सहेजा ही नहीं गया था। L2TP/IPsec और अन्य कनेक्शन प्रोफ़ाइल कनेक्शन शुरू होने पर फिर से बनते हैं, इसलिए सहेजा मान फ़ोन-बुक प्रविष्टि में IpInterfaceMetric के रूप में रहता है, केवल जीवित इंटरफ़ेस पर नहीं। कुछ वातावरण ठीक इसी कारण उस फ़ील्ड को स्क्रिप्ट करते हैं; अन्य प्रबंधन नीति से वरीयता धकेलते हैं और अंतिम बिंदु को अछूता छोड़ देते हैं।
कैश और पंजीकरण अलग परत हैं। टनल उठने के बाद इन्हें चलाना पुरानी प्रविष्टियाँ ठीक करता है और क्लाइंट को फिर से पंजीकृत करता है, पर इनमें से कोई एडाप्टर को पुनर्क्रमित नहीं करता:
ipconfig /registerdns
ipconfig /flushdnsउसी परत में एक बंद स्विच है। भौतिक एडाप्टर पर गतिशील पंजीकरण बंद करने से क्लाइंट अपना VPN-पक्ष का पता ग़लत नाम से घोषित करने से रुक जाता है, और यह ऊपर के रिफ़्रेश से अलग मरम्मत है।
IPv6 निर्णय में अपनी अलग पंक्ति का हक़दार है। अगर भौतिक एडाप्टर के पास वैश्विक IPv6 पता है जबकि टनल केवल IPv4 ढोता है, तो Windows नाम विभेदन के लिए बिना टनल वाला पथ पसंद कर सकता है। उस परिवार को अलग से जाँचें, क्योंकि IPv4 के लिए सेट मीट्रिक उसके बारे में कुछ नहीं कहती:
Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetricLAN एडाप्टर पर IPv6 बंद करना उस पथ और उसके साथ प्रोटोकॉल हटा देता है; IPv6 इंटरफ़ेस पर मीट्रिक बदलाव, या कॉर्पोरेट नामस्थान के लिए NRPT नियम, परिवार बनाए रखता है और वरीयता सुधारता है। संकीर्ण चुनें, जब तक आपने तय न किया हो कि उस लिंक पर IPv6 नहीं होना चाहिए।
नामित स्रोत के साथ सत्यापित करें, और एक ही स्वामी रखें
ऐसे औज़ारों से सत्यापित करें जो बताते हैं कि कौन सा स्रोत प्रभावी है, केवल यह नहीं कि पृष्ठ लोड होता है:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type Aफिर फ़िल्टरिंग को चयन से अलग करें, क्योंकि अनुप्रयोग के भीतर से दोनों एक जैसे दिखते हैं। OpenVPN का block-outside-dns दूसरे एडाप्टरों पर पोर्ट 53 अवरुद्ध करता है; यह रिज़ॉल्वर नहीं चुनता। अगर अब हर क्वेरी विफल हो, तो कोई फ़िल्टर एकमात्र पहुँच-योग्य सर्वर को अवरुद्ध कर रहा हो सकता है; अगर कॉन्फ़िगर किया रिज़ॉल्वर अनदेखा हो रहा है, तो क्रम या नामस्थान नियम ग़लत है। दोनों एक साथ बदलने से अवरुद्ध क्वेरी और अनदेखी क्वेरी अलग-अलग पहचानी नहीं जा सकतीं।
DNS नीति के लिए एक ही स्वामी रखें: VPN प्रोफ़ाइल, प्रबंधन नीति, या NRPT नियम, इनमें से दो नहीं। बंद करने से पहले:
- धकेला गया रिज़ॉल्वर स्पष्ट रूप से नाम लिए जाने पर उत्तर देता है, और सामान्य लुकअप उसका उपयोग करता है।
- आपने जो नियम या मीट्रिक बदला वह उस पता-परिवार को ढकता है जो वास्तव में क्वेरी ढोता है।
- सेटिंग डिस्कनेक्ट और पुनःकनेक्ट के बाद टिकती है, या आपने उसे सहेजे प्रोफ़ाइल में स्थानांतरित कर दिया है।
- ठीक एक तंत्र आधिकारिक है, और बाक़ी जैसे थे वैसे ही छोड़े गए हैं।
क्रम को ख़त्म करने वाली चीज़ नहीं बल्कि पर्यावरणीय स्थिति मानें। पुनःकनेक्शन के बाद और नेटवर्क स्टैक को छूने वाले Windows अद्यतन के बाद उसे फिर जाँचें, क्योंकि इनमें से कोई भी भौतिक एडाप्टर को फिर से आगे ला सकता है।