പിശക് 809 ലോഗിനല്ല, പാതയുടെ പ്രശ്നമാണ്
ക്ലയന്റിന് കണക്ഷൻ സ്ഥാപിക്കാനായില്ല, അത് നിരസിക്കപ്പെട്ട പാസ്വേഡല്ല. പ്രോട്ടോക്കോൾ സ്ഥിരീകരിച്ച ശേഷം ക്രെഡൻഷ്യലുകളിൽ തൊടുന്നതിന് മുമ്പ് നെറ്റ്വർക്ക് മാറ്റുക.
പിശക് 809 നിങ്ങളോട് എന്ത് പറയുന്നു എന്ന് മൂന്ന് വ്യവസ്ഥകൾ തീരുമാനിക്കുന്നു: പ്രൊഫൈലിന്റെ പ്രോട്ടോക്കോൾ നിങ്ങൾ കരുതുന്നത് തന്നെയാണോ, പാത ആ പ്രോട്ടോക്കോളിനെ കടത്തിവിടുന്നുണ്ടോ, ഗേറ്റ്വേ ശ്രമം ഒട്ടും കണ്ടിട്ടുണ്ടോ. ഇവയ്ക്ക് ഉത്തരം ലഭിക്കുന്നതുവരെ പിശക് ഒരു സമയപരിധി കവിയലാണ്, സമയപരിധി കവിയൽ ക്രെഡൻഷ്യലുകളെക്കുറിച്ചുള്ള വിധിയല്ല. ക്രമം പ്രധാനമാണ്, കാരണം തെറ്റായ വ്യവസ്ഥ ആദ്യം മാറ്റുന്നത് മറ്റ് രണ്ടിന്റെയും തെളിവ് നശിപ്പിക്കുന്നു.
തടയപ്പെട്ട പോർട്ടും തെറ്റായ പാസ്വേഡും തികച്ചും വ്യത്യസ്ത സന്ദേശങ്ങൾ നൽകുന്നു, 809 അപൂർവ്വമായി മാത്രമേ രണ്ടാമത്തേതാകൂ.
പ്രൊഫൈൽ ഉപയോഗിക്കുന്ന പ്രോട്ടോക്കോൾ സ്ഥിരീകരിക്കുക
സെർവറിന്റെ പേര്, വിലാസം, ടണൽ തരം എന്നിവ ഓപ്പറേറ്ററുടെ നിലവിലെ നിർദ്ദേശങ്ങളുമായി പരിശോധിച്ച ശേഷം ആ തരം ഏത് ഗതാഗതത്തെ ആശ്രയിക്കുന്നു എന്ന് കുറിക്കുക. ഈ മൂന്ന് മൂല്യങ്ങളും ഒരുമിച്ചാണ്; പഴയ ടണൽ തരത്തോടുകൂടിയ ശരിയായ പേര് തെറ്റായ പേര് പോലെ തന്നെ പരാജയപ്പെടുന്നു. IKEv2 UDP 500, 4500 എന്നിവയെ ആശ്രയിക്കുന്നു, തദ്ദേശീയ ESP ട്രാഫിക്കിന് TCP അല്ലെങ്കിൽ UDP ആയല്ല, സ്വന്തം പ്രോട്ടോക്കോളായി അനുമതി നൽകണം. പഴയ ക്രമീകരണത്തിൽ നിന്ന് പകർത്തിയ പ്രൊഫൈൽ സെർവർ ഇനി നൽകാത്ത ടണൽ തരം പറഞ്ഞേക്കാം. ഡയലോഗിലെ ലേബലിൽ നിന്ന് അനുമാനിക്കാതെ ഓപ്പറേറ്ററിൽ നിന്ന് മൂല്യം വാങ്ങുക.
അതേ ഹോസ്റ്റ്നെയിമിലുള്ള ബ്രൗസർ പേജ് തികച്ചും വേറെ ഒരു സേവനം പരിശോധിക്കുന്നു. ഹോസ്റ്റ് ജീവിച്ചിരിക്കുന്നു എന്ന് തെളിയിക്കാം, പരാജയപ്പെട്ട ചർച്ചയെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.
ക്രെഡൻഷ്യലുകളല്ല, നെറ്റ്വർക്ക് മാറ്റുക
നയം അനുവദിക്കുകയാണെങ്കിൽ, അതേ പ്രൊഫൈൽ മറ്റൊരു വിശ്വസ്ത നെറ്റ്വർക്കിൽ നിന്ന് പരീക്ഷിക്കുക, ക്ലയന്റും സെർവറും മാറ്റമില്ലാതെ വച്ച് ആക്സസ് പാത മാത്രം വ്യത്യാസമാക്കുക. മറ്റൊരിടത്ത് വിജയം യഥാർത്ഥ പാതയിലെ ഫിൽട്ടറിംഗിലേക്ക് വിരൽ ചൂണ്ടുന്നു, എല്ലായിടത്തും പരാജയം അന്തിമ പോയിന്റിലേക്കോ പ്രൊഫൈലിലേക്കോ തന്നെ. ഗേറ്റ്വേ ശ്രമം കണ്ടോ എന്ന് ഓപ്പറേറ്ററിനോട് ചോദിക്കുക, കാരണം സെർവറിൽ ബന്ധപ്പെട്ട സംഭവമില്ലാത്ത ക്ലയന്റ് വ്യക്തമായ നിരസിക്കലിൽ നിന്ന് വ്യത്യസ്തമായ അതിർത്തിയാണ്.
ക്രമരഹിതമായ രജിസ്ട്രി മാറ്റങ്ങളും ഫയർവാൾ ഓഫാക്കുന്നതും ഈ കോഡിന് ജനപ്രിയമായ ഉപദേശമാണ്, രണ്ടും സ്ഥിരീകരിച്ച രോഗനിർണ്ണയത്തിൽ നിന്ന് വരുന്നില്ല. ഈ വിന്യാസത്തിന് രേഖപ്പെടുത്തിയ തിരുത്ത് എന്താണെന്ന് ഓപ്പറേറ്ററിനോട് ചോദിക്കുക.
കോഡിനെ അടുത്ത ഘട്ടത്തിലേക്ക് പിന്തുടരുക
പിന്നീടുള്ള ശ്രമം പ്രാമാണീകരണത്തിലെത്തി വേറെ കോഡ് നൽകിയാൽ, ആ പുതിയ ഘട്ടം പിന്തുടരുക, യഥാർത്ഥ സമയപരിധി കവിയൽ രോഗനിർണ്ണയം വിടുക. പാതയുടെ പ്രശ്നം അക്കൗണ്ട് അന്വേഷണത്തിലേക്ക് കൊണ്ടുപോകുന്നത് രണ്ടിലും സമയം പാഴാക്കുന്നു. പ്രോട്ടോക്കോൾ, പരാജയപ്പെട്ട ഘട്ടം, നെറ്റ്വർക്ക് താരതമ്യം നടത്തിയോ എന്നിവ രേഖപ്പെടുത്തുക, അടുത്ത ആൾ ഡയലോഗ് പാഠത്തിൽ നിന്നല്ല, തെളിവിൽ നിന്ന് തുടങ്ങട്ടെ.
കോഡിനെ വിധിയല്ല, ഘട്ടത്തിന്റെ അടയാളമായി കാണുക; ആ വായനയാണ് അഞ്ച് മിനിറ്റ് പരിശോധനയും നഷ്ടപ്പെട്ട ഉച്ചയ്ക്ക് ശേഷവും തമ്മിലുള്ള വ്യത്യാസം.
ആദ്യം എന്ത് മാറ്റരുത്
ക്രെഡൻഷ്യലുകൾ, ലോക്കൗട്ട് അവസ്ഥ, സർട്ടിഫിക്കറ്റ് സംഭരണി എന്നിവയെല്ലാം ഒടുവിൽ ശ്രദ്ധ അർഹിക്കുന്നു. അവയൊന്നും 809 സാധാരണ തുടങ്ങുന്ന സ്ഥലമല്ല, ഒന്ന് ആദ്യം മാറ്റുന്നത് പാത കണ്ടെത്തിയേനെയുള്ള താരതമ്യം നീക്കം ചെയ്യുന്നു. ഈ പരിശോധനകൾ നെറ്റ്വർക്ക് പരീക്ഷണത്തിന് ശേഷത്തേക്ക് മാറ്റിവയ്ക്കുക. നെറ്റ്വർക്ക് മാറ്റുമ്പോൾ ക്ലയന്റ്, പ്രൊഫൈൽ, സെർവർ സ്ഥിരമായി നിർത്തുക, എന്താണ് മാറ്റിയതെന്ന് കുറിപ്പെടുക്കുക.
ഓപ്പറേറ്റർ അടുത്തിടെ അന്തിമ പോയിന്റ് മാറ്റിയിട്ടുണ്ടെങ്കിൽ, ഓർമ്മയിൽ നിന്ന് പുനർനിർമ്മിക്കാതെ നിലവിലെ വിശദാംശങ്ങൾ ആവശ്യപ്പെടുക. ഇനി നിലവിലില്ലാത്ത വിലാസം കൃത്യമായി ഈ തരം പരാജയം ഉണ്ടാക്കുന്നു.
പ്രോട്ടോക്കോൾ, പരീക്ഷിച്ച നെറ്റ്വർക്കുകൾ, ഗേറ്റ്വേയുടെ കാഴ്ച എന്നിവ രേഖപ്പെടുത്തുക. ഈ മൂന്നും മിക്ക 809 റിപ്പോർട്ടുകളും തീർക്കുന്നു.