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 मार्गात नाही.