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 वा नीति मार्ग मात्र टिक्नेछ। दुवै ट्रान्स्क्रिप्ट र जडानका समयचिह्न राख्नुहोस्; तिनले रहन्छ कि भन्ने प्रश्न अर्को चरण सम्पादनभन्दा छिटो टुंग्याउँछन्।