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 अद्यावधिकपछि यसलाई फेरि जाँच्नुहोस्, किनकि यीमध्ये जुनसुकैले भौतिक एडाप्टर फेरि अगाडि ल्याउन सक्छ।