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 के साथ बनाया गया सभी-उपयोगकर्ता कनेक्शन आमतौर पर उन्नत शेल मांगता है।

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 कनेक्शन पर लागू Group Policy या 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 या नीति मार्ग ही टिकेगा। दोनों ट्रांसक्रिप्ट और कनेक्शन के समय-चिह्न सँभालकर रखें; वे यह सवाल कि यह टिकता है या नहीं, संपादनों के अगले दौर से तेज़ी से तय करते हैं।