टनल वर येतो, इंट्रानेट लोड होते, आणि प्रिंटरचे नाव सोडवले जाणे थांबते। किंवा उलट: स्थानिक नावे अजूनही चालतात, पण कॉर्पोरेट नेटवर्कमधील सर्व काही वेळ संपते। दोन्ही लक्षणे एकाच ठिकाणाहून येतात, 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 सेटिंगकडे नाही तर राउटिंग किंवा फायरवॉल नियमाकडे निर्देश करते। इंटरफेस अलियास आणि तुम्ही थांबलेले पत्ते नोंदवा, कारण दोन्ही मशीनमध्ये वेगळे असतात आणि एकही एकट्याने पुनर्बांधणी टिकत नाही।

संबंधित लेख