PowerShell वापरून Windows VPN अडॅप्टरवर DNS सेट करा, नंतर तपासा

Windows VPN कनेक्शन तुम्ही सेटिंग्जमध्ये संपादित करता त्या प्रोफाइलमध्ये DNS सर्व्हर साठवत नाही। टनेल वर आल्यावर क्लायंट गेटवेबरोबर IP कॉन्फिगरेशनवर वाटाघाटी करतो, गेटवे रिझोल्व्हरची यादी पाठवतो, आणि Windows ती टनेल अडॅप्टरवर लागू करतो। तो अडॅप्टर तुमच्या Wi-Fi किंवा Ethernet पेक्षा वेगळा इंटरफेस आहे, आणि यादी इंटरफेसची आहे, प्रोफाइलची नाही। कोणती वस्तू हे मूल्य धारण करते हे कळल्यावर PowerShell मध्ये ते ओव्हरराइड करणे एकच आदेश आहे; ओव्हरराइड पुन्हा कनेक्ट होण्यापर्यंत टिकवणे हा निर्णय लागणारा भाग आहे।

पत्ता कोणत्या वस्तूकडे आहे

RAS कनेक्शन यशस्वी झाल्यावर टनेल अडॅप्टर तयार करतो आणि कनेक्शन तुटल्यावर तो काढून टाकतो। ipconfig /all मध्ये तुम्हाला दिसणारे DNS सर्व्हर त्या कॉन्फिगरेशनच्या देवघेवीदरम्यान, IPv4 आणि IPv6 पत्ते व मार्गांच्या शेजारी येतात। मूल्य इंटरफेसशी जोडलेले असल्याने, Set-DnsClientServerAddress कनेक्शन असेपर्यंतच अस्तित्वात असणाऱ्या गोष्टीत लिहितो।

हे एकच सत्य VPN DNS भोवतीचा बहुतेक गोंधळ स्पष्ट करते। प्रोफाइल डिस्कनेक्ट असतानाही पाहता येते, पण दाखवण्यासाठी इंटरफेस नाही, त्यामुळे VPN अलियासवर cmdlet कॉल करणारी लॉगिन स्क्रिप्ट कोणी कनेक्ट होण्यापूर्वीच अयशस्वी होते। मागे फिरल्यासारखे वाटणारे बदलही हेच स्पष्ट करते: काहीच मागे फिरले नाही, इंटरफेस नष्ट झाला आणि गेटवेने पाठवलेल्या मूल्यांसह पुन्हा बांधला गेला।

DNS ला स्पर्श करण्यापूर्वी अलियास शोधा

प्रोफाइलचे नाव आणि इंटरफेस अलियास सहसा एकच स्ट्रिंग असतात, पण त्या एकच वस्तू नाहीत। Get-VpnConnection प्रोफाइलची यादी दाखवते; Get-NetAdapter Windows कडे खरोखर असलेल्या इंटरफेसची यादी दाखवते। DNS cmdlet ला दुसरे हवे असते, आणि हे दोन लोक अपेक्षा करतात त्यापेक्षा जास्त वेळा वेगळे होतात, विशेषतः क्लायंटने अडॅप्टरच्या नावाला "(RAS)" सारखे वर्णन जोडले तेव्हा।

प्रोफाइल नसेल तर PowerShell मूळ नोंद तयार करू शकते। टनेलचा प्रकार आणि प्रमाणीकरण गेटवे जे देते त्याशी जुळले पाहिजे, कारण विसंगती तयार करताना नाही तर कनेक्ट करताना दिसते:

Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
  -TunnelType Ikev2 -EncryptionLevel Required `
  -AuthenticationMethod Eap -AllUserConnection

एकदा कनेक्ट करा, नंतर कोणताही DNS आदेश लिहिण्यापूर्वी खरा अलियास वाचा:

rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"

ओव्हरराइड योग्य क्रमाने लागू करा

क्रम संकेतापेक्षा महत्त्वाचा आहे। अडॅप्टर सुरू असणे, अलियास सुटणे आणि खात्याला इंटरफेस सेटिंग्ज बदलण्याची परवानगी असणे आवश्यक आहे। प्रत्येक वापरकर्त्याचे कनेक्शन सहसा लॉग इन केलेल्या वापरकर्त्याकडून बदल स्वीकारते; -AllUserConnection ने तयार केलेल्या सर्व-वापरकर्ता कनेक्शनला सहसा उन्नत shell लागतो।

cmdlet स्वतः एकच ओळ आहे, Microsoft च्या Set-DnsClientServerAddress संदर्भात नोंदवलेला:

Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4

अपयशाच्या दोन पद्धती एका दृष्टीक्षेपात ओळखल्या पाहिजेत। चुकीचा अलियास cmdlet कडून त्रुटी देतो, आणि तो चांगला परिणाम आहे, कारण शांतता त्यापेक्षा वाईट ठरेल। बरोबर cmdlet दिसणारा परिणाम न देता आला तर सहसा तुम्ही चुकीचा अडॅप्टर पाहत आहात: दुसऱ्या क्लायंटकडून राहिलेला टनेल अडॅप्टर, सारखे वर्णन असलेला भौतिक नेटवर्क कार्ड, किंवा वेगळ्या वातावरणातील नेटवर्क साधनाने तयार केलेला दुसरा व्हर्च्युअल अडॅप्टर।

पुन्हा कनेक्ट केल्यावर बदल का रद्द होऊ शकतो

ओव्हरराइड इंटरफेसच्या एकाच प्रतिकृतीचा असतो। क्लायंट अडॅप्टर तोडून पुढच्या कनेक्शनला पुन्हा बांधतो तेव्हा पाठवलेली मूल्ये पुन्हा लागू होतात आणि तुमची यादी जाते। काही क्लायंट प्रत्येक कनेक्शनला इंटरफेस पुन्हा तयार करतात; इतर तो सत्रभर पुन्हा वापरतात। Get-NetAdapter मधील इंटरफेस इंडेक्स दोन कनेक्शनांमध्ये तुलना करा आणि तुमच्याकडे कोणते वर्तन आहे ते कळेल।

तीन टिकाऊ उत्तरे आहेत, आणि ती एकावर एक ठेवल्यास स्वतःचे दोष तयार होतात। कनेक्शन-विशिष्ट DNS प्रत्यय आणि NRPT नियम फक्त आंतरिक नामस्थान आंतरिक रिझोल्व्हरकडे पाठवते आणि सार्वजनिक नावे शांत ठेवते। VPN कनेक्शनवर लागू केलेली गट धोरण किंवा MDM सेटिंग कोणत्याही स्क्रिप्टशिवाय कनेक्शनच्या वेळी DNS सेट करते। कनेक्शन घटनेला प्रतिसाद देऊन cmdlet पुन्हा चालवणारे नियोजित कार्य हा ओरबाडलेला पर्याय आहे, पण तो चालतो आणि लॉग सोडतो। DNS साठी एकच मालक निवडा आणि कोणता ते लिहा।

एका लेबलच्या आंतरिक नावांनाही प्रत्यय शोध यादी लागते। Set-DnsClientGlobalSetting -SuffixSearchList संपूर्ण मशीनवर लागू होते, त्यामुळे संगणकावरील प्रत्येक अडॅप्टरसाठी, Ethernet सह, निराकरण बदलते। प्रतिमेत जाण्यापूर्वी प्रयोगशाळेच्या मशीनवर ते तपासा।

फक्त सेटिंग नाही, निराकरणही तपासा

अडॅप्टरवर सूचीबद्ध रिझोल्व्हर फक्त मूल्य लिहिले गेले याचा पुरावा देतो। इच्छित सर्व्हरला थेट विचारा, नंतर नेहमीच्या मार्गाने विचारा:

Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example

ही फूट त्रुटी कुठे आहे ते सांगते। थेट क्वेरी उत्तर देते आणि सामान्य क्वेरी अयशस्वी होते: अडॅप्टर सेटिंग किंवा प्रत्यय यादी अमलात नाही। दोन्ही अयशस्वी होतात: रिझोल्व्हर टनेलमधून पोहोचत नाही, म्हणून DNS पुन्हा स्पर्श करण्यापूर्वी मार्ग आणि फायरवॉल नियम पाहा। थेट क्वेरी अयशस्वी होते आणि सामान्य क्वेरी दुसरीकडून उत्तर देते: विभाजित DNS चुकीचे संरचित आहे आणि आंतरिक नावाला सार्वजनिक रिझोल्व्हर उत्तर देत आहे, ही कनेक्टिव्हिटीच्या आधी धोरणाची समस्या आहे।

चाचणी दोनदा चालवा, एकदा कनेक्ट झाल्यावर लगेच आणि एकदा डिस्कनेक्ट व पुन्हा कनेक्ट केल्यावर, आणि दोन्ही वेळांचे Get-DnsClientServerAddress आउटपुट तुलना करा। जर पाठवलेले मूल्य दुसऱ्या कनेक्शनवर परत आले, तर ओव्हरराइड अडॅप्टरसोबत जगले आणि मरण पावले, आणि मागील विभागातील NRPT किंवा धोरण मार्गच टिकेल। दोन्ही नोंदी आणि कनेक्शनचे वेळचिन्ह जपून ठेवा; ते टिकते का या प्रश्नाचा निकाल आणखी एका संपादन फेरीपेक्षा लवकर लावतात।