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 मार्गमा होइन।