IP വിലാസത്തോടുള്ള പിശക് 868? Windows ആദ്യം എന്താണ് പരിഹരിക്കുന്നത്

ഡയലോഗ് പറയുന്നത് സെർവറിന്റെ പേര് പരിഹരിക്കാനായില്ല എന്നാണ്, എന്നാൽ നിങ്ങൾ നോക്കുന്ന പ്രൊഫൈൽ ഫീൽഡ് ഒരു വിലാസമാണ്. ഈ സംയോജനം വൈരുദ്ധ്യമല്ല: നിങ്ങൾ വായിക്കുന്നതായി കരുതുന്ന മൂല്യത്തിൽ നിന്ന് വ്യത്യസ്തമായ ഒന്നാണ് ക്ലയന്റ് പരിഹരിക്കുന്നത്. DNS തകർന്നു എന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് അത് യഥാർത്ഥത്തിൽ എന്തിനെ വിളിക്കുന്നു എന്ന് കണ്ടെത്തുക. ക്ലയന്റിന്റെ സ്വന്തം ഘട്ടങ്ങളുടെ ക്രമം എവിടെ നോക്കണം എന്ന് കാണിച്ചുതരുന്നു.

ക്ലയന്റ് വിളിക്കുന്നതിന് മുമ്പ് പേര് പരിഹരിക്കുന്നു

Windows-ന്റെ സ്വാഭാവിക VPN കണക്ഷൻ അതിന്റെ പ്രൊഫൈൽ വായിക്കുന്നു, സെർവർ വിലാസം പരിഹരിക്കുന്നു, ടണൽ ആരംഭിക്കുന്നു, അതിനുശേഷം മാത്രം പ്രാമാണീകരിക്കുന്നു. പിശക് 868 രണ്ടാം ഘട്ടത്തിനുള്ളതാണ്. തുടർന്നുള്ള ഘട്ടങ്ങൾ ഒരിക്കലും പ്രവർത്തിക്കാത്തതിനാൽ, ലുക്കപ്പ് ആദ്യം പരാജയപ്പെട്ടാൽ ഡയലോഗ് ഒരു ക്രെഡൻഷ്യൽ പ്രശ്നം പോലെ തോന്നാം.

ഈ ക്രമം ഉപയോഗപ്രദമാണ്, കാരണം പരിശോധിക്കേണ്ട പാളി ചുരുക്കുന്നു. ഒരേ പ്രൊഫൈൽ ഒരു നെറ്റ്വർക്കിൽ നിന്ന് പ്രവർത്തിക്കുകയും മറ്റൊന്നിൽ നിന്ന് പരാജയപ്പെടുകയും ചെയ്യുമ്പോൾ, വ്യത്യാസം സാധാരണയായി പേര് പരിഹരിക്കലാണ്, ടണൽ തരമോ അക്കൗണ്ടോ അല്ല. പ്രൊഫൈൽ നിർമ്മിച്ചിടത്തല്ല, പരാജയം സംഭവിക്കുന്നിടത്ത് ലുക്കപ്പ് പരിശോധിക്കുക.

ഫീൽഡ് വിലാസം കാണിക്കുമ്പോൾ ഏത് പേര്

കാണിക്കുന്ന പേരിന് പകരം സംഭരിച്ച മൂല്യം വായിക്കുക. ഒരു കണക്ഷന്റെ ലേബൽ അതിന്റെ സെർവർ വിലാസമല്ല, സമാന ലേബലുകളുള്ള രണ്ട് എൻട്രികൾ തെറ്റായതിന് പിന്നാലെ നിങ്ങളെ അയയ്ക്കുന്നു:

Get-VpnConnection -Name "Work VPN" |
    Select-Object Name, ServerAddress, TunnelType

പ്രൊഫൈൽ എല്ലാ ഉപയോക്താക്കൾക്കുമായി തയ്യാറാക്കിയതാണെങ്കിൽ, ആ പരിധിയും ഇതുപയോഗിച്ച് ചോദിക്കുക -AllUserConnection. തുടർന്ന് കമാൻഡ് അച്ചടിച്ച മൂല്യം കൃത്യമായി, പരാജയം സംഭവിക്കുന്ന നെറ്റ്വർക്കിൽ നിന്ന് പരിഹരിക്കുക. ഓപ്പറേറ്ററുടെ രേഖപ്പെടുത്തിയ ഗേറ്റ്വേ ഉപയോഗിക്കുക, ടണൽ ഉയർന്നതിനുശേഷം മാത്രം പരിഹരിക്കുന്ന അപ്ലിക്കേഷന്റെ ആന്തരിക പേരല്ല. ആ രണ്ടാം ക്വറി പ്രതീക്ഷിത കാരണത്താൽ പരാജയപ്പെടുന്നു, വിളിയെക്കുറിച്ച് നിങ്ങളോട് ഒന്നും പറയുന്നുമില്ല:

Resolve-DnsName vpn.example.com

സംഭരിച്ച മൂല്യം യഥാർത്ഥത്തിൽ സംഖ്യാത്മകമാണെങ്കിൽ, ക്ലയന്റ് പേര് വായിക്കുന്ന രണ്ടാമത്തെ സ്ഥലം തിരയുക. EAP കോൺഫിഗറേഷൻ ഒരു സെർവറിനെ പരാമർശിക്കാം, മറ്റൊരു ടൂളിൽ നിന്ന് ഇറക്കുമതി ചെയ്ത പ്രൊഫൈൽ സ്വന്തം മൂല്യം വഹിക്കാം, മുൻ ഇൻസ്റ്റാളർ ഒരു ആവർത്തിച്ച എൻട്രി വിട്ടേക്കാം. ഡയലോഗിലെ ഫീൽഡ് എപ്പോഴും ഏക ഇൻപുട്ടല്ല.

Windows 7 വീണ്ടും കണക്ട് ചെയ്യുന്ന മാതൃക

ഈ പിശകിന് പിന്നിലെ ത്രെഡ്, ഒരിക്കൽ കണക്ട് ചെയ്ത ശേഷം പ്രൊഫൈലിൽ ഒന്നും മാറ്റാതെ തന്നെ പിന്നീടുള്ള ശ്രമത്തിൽ 868-നൊപ്പം പരാജയപ്പെട്ട യന്ത്രങ്ങളെ വിവരിക്കുന്നു. Remote Access Connection Manager സേവനം പുനരാരംഭിക്കുന്നതോ സൈൻ ഔട്ട് ചെയ്ത് വീണ്ടും സൈൻ ഇൻ ചെയ്യുന്നതോ കണക്ഷൻ താൽക്കാലികമായി പുനഃസ്ഥാപിച്ചുവെന്ന് സംഭാവകർ റിപ്പോർട്ട് ചെയ്തു. ഇവ പരിഹാരമാർഗ്ഗങ്ങളാണ്, തെളിയിക്കപ്പെട്ട അടിസ്ഥാന കാരണമല്ല.

ആ മാതൃകയെ പ്രത്യേക സിദ്ധാന്തമായി കാണുക. പുനരാരംഭം ക്ലയന്റ് അവസ്ഥ പുനഃസജ്ജമാക്കുന്നു, അതിനാൽ പിന്നീടുള്ള താൽക്കാലിക വിജയം DNS റെക്കോർഡ് തെറ്റായിരുന്നു എന്ന് തെളിയിക്കുന്നില്ല:

പട്ടികയെ രോഗനിർണ്ണയമായല്ല, വേർതിരിക്കുന്ന നിരീക്ഷണങ്ങളുടെ കൂട്ടമായി വായിക്കുക. ആദ്യ വരി പേരിലെ പ്രശ്നമാണ്, രണ്ടാമത്തേത് ക്ലയന്റ് അവസ്ഥയാണ്, മൂന്നാമത്തേത് ഒരിക്കലും ശരിയായിരുന്നില്ലാത്ത ഒരു പ്രൊഫൈലാണ്. ഓരോന്നും വ്യത്യസ്ത വ്യക്തിയിലേക്കും വ്യത്യസ്ത പരിഹാരത്തിലേക്കും നയിക്കുന്നു.

അഡ്മിനിസ്ട്രേറ്റർക്കായി എന്ത് ശേഖരിക്കണം

പ്രൊഫൈലിന്റെ പേര്, സംഭരിച്ച വിലാസം, ടണൽ തരം, ക്ലയന്റ് ഉണ്ടായിരുന്ന നെറ്റ്വർക്ക്, പരാജയം വിച്ഛേദനത്തിന് ശേഷമാണോ എന്നത് എന്നിവ എഴുതിവയ്ക്കുക. ആ രേഖ ആരും ഊഹിക്കേണ്ടതില്ലാതെ യഥാർത്ഥ ലുക്കപ്പ് പരാജയത്തെ ചരിത്രപരമായ വീണ്ടും-കണക്ഷൻ സ്വഭാവത്തിൽ നിന്ന് വേർതിരിക്കുന്നു. ശ്രമത്തിന് ചുറ്റുമുള്ള ക്ലയന്റ് ഇവന്റ് ലോഗും സൂക്ഷിക്കുക.

പഴയ ബിൽഡുകളിലെ പരിഹാരം സ്വഭാവം നിലനിന്നിരുന്നു എന്നതിന് തെളിവാണ്, അതേ സേവന പുനരാരംഭം നിലവിലെ യന്ത്രം ശരിയാക്കും എന്ന വാഗ്ദാനമല്ല. രേഖപ്പെടുത്തിയ ഹോസ്റ്റ്നെയിം ഒരു അക്ഷരാർത്ഥ വിലാസം കൊണ്ട് മാറ്റുന്നതും നന്നാക്കലല്ല.

ചില പ്രൊഫൈലുകൾ കോൺഫിഗർ ചെയ്ത പേരുമായി പൊരുത്തപ്പെടുന്ന സെർവർ ഐഡന്റിറ്റി പ്രതീക്ഷിക്കുന്നു, അതിനാൽ സംഖ്യാത്മക പരിഹാരം ഒരു പിശക് മറ്റൊന്നുമായി കൈമാറാം. പേര് നിലനിൽക്കണമെങ്കിൽ, പ്രൊഫൈൽ ടെക്സ്റ്റല്ല, പരിഹാര പാത ശരിയാക്കുക. ഏതായാലും, എന്ത് മാറ്റി, എന്തുകൊണ്ട് എന്ന് രേഖപ്പെടുത്തുക.