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 अद्ययावतानंतर तो पुन्हा तपासा, कारण यापैकी कोणतेही भौतिक ॲडॉप्टर पुन्हा पुढे आणू शकते।