VPN ले DNS कब्जा गर्‍यो र स्थानीय नामहरू भत्कायो: सूची सुधार्नुहोस्

टनेल माथि आउँछ, इन्ट्रानेट लोड हुन्छ, र प्रिन्टरको नाम समाधान हुन छाड्छ। वा उल्टो: स्थानीय नामहरू अझै काम गर्छन् जबकि कर्पोरेट नेटवर्कभित्र सबै समय सकिन्छ। दुवै लक्षण एउटै ठाउँबाट आउँछन्, रिजोल्भरहरूको सूचीबाट जुन VPN क्लाइन्टले जडान गर्दा पुनः लेखेको थियो।

सूची जानाजान सुधार्नुहोस्, त्यसपछि पुश संयन्त्र अलग्गै हेर्नुहोस्। मार्गहरू तेस्रो विषय हुन् र यहाँ सुधारिएको कुरा त्यो होइन।

एप्लिकेसनहरूले वास्तवमा कुन सूची प्रयोग गर्छन्

Windows डायलगले देखाउने कुराबाट होइन, इन्टरफेस-स्तरको सेटिङबाट समाधान गर्छ, त्यसैले प्रत्येक इन्टरफेसको प्रभावकारी सूचीबाट सुरु गर्नुहोस्। एलियास देखाइएको नामभन्दा बढी महत्त्वपूर्ण हुन्छ, किनकि तलको हरेक आदेशले इन्टरफेसलाई सम्बोधन गर्छ। एलियास गलत भयो भने सुधार गलत एडाप्टरमा पर्छ। अर्को पुनः जडानसम्म काम गरेको जस्तो देखिन्छ, त्यतिबेला टनेलको आफ्नै प्रविष्टि फर्केर आउँछ।

प्रश्न यो हो कि कुन सर्भरहरू अगाडि आए, र तिनीहरू स्थिर प्रविष्टिका रूपमा आए वा DHCP भाडाका रूपमा। दुवै तथ्यले तपाईंलाई कुन सुधार उपलब्ध छ भन्ने निर्धारण गर्छ।

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

टनेल एडाप्टर र भौतिक एडाप्टरका लागि आउटपुट पढ्नुहोस्, र प्रत्येकमा भएको हरेक ठेगाना नोट गर्नुहोस्। स्थिर प्रविष्टि नीति वा स्क्रिप्टले हटाउन सकिन्छ; DHCP ले दिएको प्रविष्टि भाडामा बाँधिएको हुन्छ र फर्केर आउँछ, जसले तपाईंले छान्नुपर्ने सुधार बदल्छ। टाढाको नेटवर्कका नामहरू घोषित रिजोल्भरले समाधान गर्छ, स्थानीय LAN का नामहरू भौतिक एडाप्टरले, र क्वेरी पहिले हेरिने सूचीतिर जान्छ।

धकेलिएका सर्भरहरू हटाउनुहोस्, वा तिनीहरूलाई तल राख्नुहोस्

टनेलभित्र कसैलाई तिनीहरूको आवश्यकता नभए धकेलिएका सर्भरहरू मेट्नुहोस्, किनकि भौतिक एडाप्टरका आफ्नै रिजोल्भरहरूले फेरि काम लिन्छन्। टाढाको नेटवर्कसँग तिनका सर्भरले मात्र जवाफ दिन सक्ने क्षेत्रहरू छन् भने मात्र तिनीहरूलाई राख्नुहोस्, र त्यस अवस्थामा तिनीहरूअगाडि स्थानीय रिजोल्भर राख्नुहोस्। तलका दुई आदेशले दुवै विकल्प समेट्छन्, त्यसैले दुवै चलाउनुको सट्टा अवस्थासँग मिल्ने छान्नुहोस्।

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

सूचक 1 पहिले हेरिन्छ, त्यसैले धकेलिएका ठेगानाहरू उपलब्ध रहन्छन् तर हरेक क्वेरीको पूर्वनिर्धारित जवाफ बन्न छाड्छन्। validate=no झन्डाले टनेल अझै स्थिर हुँदै गर्दा प्रायः असफल हुने पहुँच परीक्षण छोड्छ, त्यसैले निकास कोडमा भरोसा गर्नुको सट्टा show आदेशले नतिजा पुष्टि गर्नुहोस्।

यसमा भर पर्नुअघि दुई सीमा जान्नु राम्रो हुन्छ। Windows ले DHCP मार्फत netsh बाट आएका सर्भरहरू मेटाउँदैन, र ती मानहरू इन्टरफेसको रजिस्ट्री कुञ्जीमुनि DhcpNameServer का रूपमा रहन्छन्, त्यसैले रजिस्ट्री सम्पादन अन्तिम उपाय हो जुन अर्को भाडापछि फेरि जाँच्नुपर्छ। एडाप्टर बाइन्डिङ क्रम पनि भरपर्दो श्रेणीकरण संयन्त्र होइन, किनकि VPN क्लाइन्टले आफ्नै प्रविष्टि सूचीको सबैभन्दा माथि राख्न सक्छ।

पुश कहाँ फिल्टर गर्न सकिन्छ

राम्रो सुधारले विकल्प लागू हुनुअघि नै हटाउँछ। Community OpenVPN क्लाइन्टले धकेलिएको निर्देशलाई नामले फिल्टर गर्न सक्छ, जसले सर्भरको कन्फिगरेसनलाई अछुतो राख्छ।

pull-filter ignore "dhcp-option DNS "

अन्त्यको खाली ठाउँ मिलानसँग सम्बन्धित छ र फिल्टरले सर्भर ठेगाना होइन, विकल्पको नाम लिन्छ। प्रोफाइलमा block-outside-dns निर्देश पनि छ भने, त्यो हटाउँदा नाम समाधान होइन, चुहावट संरक्षण बदलिन्छ, त्यसैले दुई सम्पादन जोड्नुको सट्टा त्यो अलग्गै निर्णय गर्नुहोस्।

एउटा जिद्दी होस्टनामका लागि Windows hosts फाइलमा एउटा लाइन पूरै मेसिनका लागि रिजोल्भर पुनः क्रममा राख्नुभन्दा बढी स्थिर हुन्छ। त्यो अर्को व्यक्तिलाई अदृश्य पनि हुन्छ, त्यसैले मेसिनको कन्फिगरेसन अभिलेख गरिने ठाउँमा त्यो लेख्नुहोस्।

सुधारलाई पुनः जडानसम्म टिकाउनुहोस्

नाम समाधान दुई पटक परीक्षण गर्नुपर्छ, एक पटक छानिएको सर्भरविरुद्ध र एक पटक एप्लिकेसनले प्रयोग गर्ने रूपमा। त्यो जोडीले रिजोल्भर क्रमको समस्यालाई जवाफै नदिने सर्भरबाट अलग गर्छ। पहिलो परीक्षण छोडियो भने दुवै कारण गाँसिएर रहन्छन्।

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

टनेल फेरि जडान गर्नुहोस् र दुवै आदेश दोहोर्याउनुहोस्। हातले बदलेको कुरा अर्को जडानसम्म मात्र टिक्छ, किनकि क्लाइन्टले एडाप्टर उठाउँदा आफ्नो रिजोल्भर अवस्था फेरि बनाउँछ। netsh लाइनहरू तपाईंको क्लाइन्टको समर्थित जडान स्क्रिप्टमा राख्नुहोस्, त्यो स्क्रिप्ट सफलतापूर्वक सकियोस्, र चल्नुअघि छोटो प्रतीक्षा थप्नुहोस्। स्क्रिप्टपछि DNS लागू गर्ने क्लाइन्टले जसरी पनि नतिजा माथि लेख्छ।

सुधारपछि सार्वजनिक नामहरू समाधान भए र आन्तरिक नामहरू अझै असफल भए, रिजोल्भर सूची अब शंकास्पद छैन। क्वेरी सर्भरसम्म पुग्दै नपुगेको हुन सक्छ, जसले अर्को DNS सेटिङ होइन, राउटिङ वा फायरवाल नियमतिर संकेत गर्छ। इन्टरफेस एलियास र तपाईं अडिएका ठेगानाहरू नोट गर्नुहोस्, किनकि दुवै मेसिनपिच्छे फरक हुन्छन् र कुनै पनि एक्लै पुनर्निर्माणमा टिक्दैन।