Windows पर OpenConnect की DNS सेटिंग्स वास्तव में कौन लागू करता है?
Windows रिज़ॉल्वर की स्थिति तीन जगह रखता है। एडाप्टर DNS को हाथ से संपादित करने या नेमस्पेस नियम जोड़ने से पहले वह सहायक खोजें जिसके पास कनेक्शन है।
टनल उठाना उसके DNS मान इंस्टॉल करने के समान नहीं है। OpenConnect बातचीत करता है, और Windows की ओर का एक सहायक लागू करता है। इन दो चरणों के बीच का अंतर इस क्लाइंट पर अधिकांश निजी-नाम विफलताओं की व्याख्या करता है, और सहायक लगभग कभी Windows VPN सेटिंग्स पेज नहीं होता।
गेटवे ने जो पेश किया और Windows ने जो इंस्टॉल किया, उन्हें अलग करें
क्लाइंट कनेक्शन डेटा एक स्क्रिप्ट इंटरफ़ेस को सौंपता है, और Unix तथा Windows संस्करण अलग प्रोग्राम हैं। Windows पर कार्यान्वयन आमतौर पर एक JavaScript सहायक होता है जो किसी भी एडाप्टर को छूने से पहले आंतरिक DNS सर्वर और आंतरिक डोमेन जैसे चर पढ़ता है। टनल में स्वयं कुछ भी रिज़ॉल्वर स्थिति नहीं लिखता।
यह विभाजन मायने रखता है क्योंकि कोई मान बातचीत में मौजूद हो सकता है और कभी एडाप्टर तक न पहुंचे। जो सहायक गायब है, आधे रास्ते विफल हो जाता है, या GUI आवरण के भीतर बंद पुरानी प्रति है, वह Windows को ठीक वैसा ही छोड़ देता है जैसा वह था। सत्र जुड़ा हुआ दिखता है, निजी नाम अब भी स्थानीय प्रदाता से हल होता है, और क्लाइंट विंडो में कुछ भी अंतर की ओर संकेत नहीं करता। सहायक का अपना आउटपुट पढ़ना ही यह जानने का एकमात्र भरोसेमंद तरीका है कि कौन सा चरण टूटा।
| Stage | What exists there | Where you see it |
|---|---|---|
| Negotiated | Internal DNS address and domain pushed by the gateway | Client log or helper input |
| Installed | Adapter DNS entry, connection suffix, or namespace rule | Adapter and policy queries |
| Selected | Resolver Windows uses for one specific query | The failing application |
GUI आवरण क्लाइंट और सहायक की अपनी प्रति ला सकता है, इसलिए डिस्क पर कहीं और दूसरा openconnect.exe कुछ साबित नहीं करता। उसका कॉन्फ़िगरेशन आंकने से पहले वह निष्पादन योग्य खोजें जिसने सत्र शुरू किया।
रिज़ॉल्वर स्थिति बदले बिना पढ़ें
तीन केवल-पढ़ने वाली क्वेरी सामान्य उलझन को कवर करती हैं, और हर एक अलग प्रश्न का उत्तर देती है:
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effectiveएडाप्टर स्तर का सर्वर वही है जिसे अधिकांश लोग VPN DNS समझते हैं। कनेक्शन-विशिष्ट प्रत्यय तय करता है कि छोटा नाम बिल्कुल भी विस्तारित होगा या नहीं। नेमस्पेस नीति सूची एडाप्टर क्रम की परवाह किए बिना मेल खाने वाले नामों पर लागू होती है, और वहां खाली परिणाम खराबी नहीं है जब सहायक ने कभी एक बनाने का इरादा नहीं किया। संपादन से पहले तीनों पढ़ना ही ऐसा सुधार रोकता है जो केवल लक्षण को कहीं और खिसका देता है।
पूर्ण योग्य नाम से शुरू करें। यदि FQDN हल होता है और छोटा नाम नहीं, तो अंतर प्रत्यय या खोज सूची है, सर्वर पता नहीं।
दूसरे चरण के रूप में इच्छित सर्वर से सीधे पूछें, जो भी रिज़ॉल्वर उपकरण पहले से इंस्टॉल है। सीधा उत्तर साबित करता है कि सर्वर पहुंच योग्य और ज़ोन के लिए आधिकारिक है। यह इस बारे में कुछ साबित नहीं करता कि कोई एप्लिकेशन डिफ़ॉल्ट रूप से किस सर्वर से पूछता है।
उस घटक का नाम बताएं जिसके पास कनेक्शन है
दो व्यवस्थाएं आम हैं। टर्मिनल से शुरू किया गया क्लाइंट अपना स्क्रिप्ट पथ स्पष्ट रूप से भेजता है, इसलिए स्वामी चलाए गए कमांड में दिखता है। पैकेज्ड एप्लिकेशन आपके लिए क्लाइंट शुरू करता है और सहायक को अपनी ही निर्देशिका में रखता है, यानी विक्रेता तय करता है कि यह कब बदलेगा।
कुछ भी बदलने से पहले इंस्टॉल के बीच सहायक संस्करणों की तुलना करें। फ़ाइल का नाम परिचित लगने के कारण मिरर से लाए सहायक को बढ़े हुए अधिकारों से चलाना DNS के अंतर को सुरक्षा घटना में बदल देता है।
स्वामी ज्ञात होने पर मरम्मत का लक्ष्य स्पष्ट हो जाता है: लॉन्चर में समर्थित स्क्रिप्ट पथ, पैकेज अपडेट, या गेटवे पर सुधारित प्रोफ़ाइल। इनमें से किसी के लिए एडाप्टर गुण हाथ से संपादित करने की ज़रूरत नहीं।
स्वामी ठीक करें, एडाप्टर नहीं
एडाप्टर पर हाथ से सेट किया गया DNS अक्सर डिस्कनेक्ट के बाद भी टिका रहता है, इसलिए वह काम करता दिखता है और फिर अगले नेटवर्क पर परेशानी पैदा करता है। हर इंटरफ़ेस पर जड़ा सार्वजनिक रिज़ॉल्वर निजी नेमस्पेस की समस्या को हल करने के बजाय छिपा देता है। जब सहायक को कभी DNS मान नहीं मिला, तो गेटवे प्रोफ़ाइल देखने की जगह है। जब उसे एक मिला और एडाप्टर अब भी पुराना सर्वर दिखाता है, तो सहायक कनेक्ट के दौरान विफल हुआ और क्लाइंट लॉग आमतौर पर इसे टनल सेटअप पंक्तियों के पास दर्ज करता है।
समर्थित पथ से स्थिति फिर बनाएं, फिर पूरा चक्र सत्यापित करें: कनेक्ट करें, निजी FQDN हल करें, सेवा खोलें, डिस्कनेक्ट करें, और पुष्टि करें कि एडाप्टर अपने पिछले सर्वरों के साथ लौटा है।
उस एप्लिकेशन की जांच करें जो वास्तव में विफल होता है
अपनी एन्क्रिप्टेड-DNS सेटिंग वाला ब्राउज़र ऊपर की सब बातों को अनदेखा करता है और सार्वजनिक रिज़ॉल्वर से उत्तर देता रहता है। टनल उठने से पहले का कैश किया हुआ नकारात्मक उत्तर रखने वाला एप्लिकेशन भी वैसा ही व्यवहार करता है। रिज़ॉल्वर पते फिर बदलने से पहले इसे उसी मशीन पर सादे सिस्टम क्वेरी से तुलना करें।
यदि सिस्टम क्वेरी सही है और एप्लिकेशन गलत, तो बाकी खराबी उस एप्लिकेशन के DNS कॉन्फ़िगरेशन में है, VPN पथ में नहीं।