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 പാത്തിലല്ല.