കണക്ട് അമർത്തുന്നത് സ്വതന്ത്രമായി വിജയിക്കുന്നതോ പരാജയപ്പെടുന്നതോ ആയ നാല് വേറിട്ട ജോലികൾ ആരംഭിക്കുന്നു. ക്ലയന്റ് ഒരു ശ്രോതാവിനെ എത്തിച്ചേരണം, പങ്കാളി ആരാണെന്ന് യോജിക്കണം, കീകൾ ഉരുത്തിരിയണം, തുടർന്ന് പ്രവർത്തിക്കുന്ന ഒരു ടണൽ സിസ്റ്റത്തിന്റെ ബാക്കി ഭാഗത്തിന് കൈമാറണം. പരാജയപ്പെടുന്ന ഭൂരിഭാഗം കണക്ഷനുകളും തെറ്റായ ജോലിയിൽ രോഗനിർണയം ചെയ്യുന്നു. അതുകൊണ്ടാണ് ആദ്യത്തെ പിശക് മൂന്നാം ശ്രമത്തേക്കാൾ പ്രധാനമാകുന്നത്.

ആദ്യം ശ്രോതാവിനെ എത്തിച്ചേരുക

ഏതെങ്കിലും ഐഡന്റിറ്റി കൈമാറുന്നതിന് മുമ്പ്, ക്ലയന്റ് ഒരു പേര് പരിഹരിക്കുന്നു, ഒരു റൂട്ട് തിരഞ്ഞെടുക്കുന്നു, ഒരു പോർട്ടിലേക്ക് ട്രാൻസ്പോർട്ട് തുറക്കുന്നു. എല്ലാത്തിനും ഉത്തരം നൽകുന്ന ക്യാപ്റ്റീവ് പോർട്ടൽ, അടച്ച പോർട്ട്, തെറ്റായ ഹോസ്റ്റ്നെയിം എന്നിവയെല്ലാം ഇവിടെ പരാജയപ്പെടുന്നു, അവയൊന്നും പ്രമാണീകരണ പ്രശ്നമല്ല. പാസ്‌വേഡ് മാറ്റുന്നത് മൂന്നിൽ ഒന്നും പരിഹരിക്കുന്നില്ല. ക്രെഡൻഷ്യലുകൾ തൊടുന്നതിന് മുമ്പ് പിശകിന്റെ ആദ്യ വരി വായിക്കുക.

സമയപരിധി, സർട്ടിഫിക്കറ്റ് നിരസിക്കൽ, നിരസിക്കപ്പെട്ട അക്കൗണ്ട് എന്നിവ മൂന്ന് വ്യത്യസ്ത പരിശോധനകളുള്ള മൂന്ന് വ്യത്യസ്ത തകരാറുകളാണ്. അവയെ ആദ്യം തരംതിരിക്കുന്നതാണ് ഒരു നെറ്റ്‌വർക്ക് പ്രശ്നം ക്രെഡൻഷ്യൽ പ്രശ്നമായി ഡീബഗ് ചെയ്യുന്നത് തടയുന്നത്.

പങ്കാളിയെ തെളിയിക്കുക, തുടർന്ന് കീകൾ ഉരുത്തിരിയുക

ഓരോ പ്രോട്ടോക്കോളിനും ഉദ്ദേശിച്ച സെർവറിനെ തിരിച്ചറിയാനുള്ള ഒരു മാർഗം വേണം, അത് കോൺഫിഗർ ചെയ്ത പൊതു കീയോ സർട്ടിഫിക്കറ്റ് ശൃംഖലയോ ആകട്ടെ. ഉപയോക്തൃ ലോഗിൻ ആ പരിശോധനയ്ക്കുള്ള കൂട്ടിച്ചേർക്കലാണ്, അതിന്റെ പകരമല്ല. നിങ്ങളുടെ പാസ്‌വേഡ് സ്വീകരിക്കുന്ന സെർവർ തന്റെ സ്വന്തം ഐഡന്റിറ്റിയെക്കുറിച്ച് ഒന്നും തെളിയിച്ചിട്ടില്ല. അതുകൊണ്ടാണ് ക്ലയന്റിൽ ടൈപ്പ് ചെയ്ത പങ്കിട്ട രഹസ്യം ആരാണ് ഉത്തരം നൽകിയതെന്ന് പരിശോധിക്കുന്നതിന് പകരമാകാത്തത്.

തുടർന്ന് കൈമാറ്റം പ്രോട്ടോക്കോളിന്റെ സ്വന്തം ഇൻപുട്ടുകളിൽ നിന്ന് ട്രാഫിക് കീകൾ ഉരുത്തിരിയുന്നു, ലോഗിൻ പാസ്‌വേഡ് സാധാരണയായി ഓരോ പാക്കറ്റിലും പതിപ്പിക്കുന്ന കീയല്ല. ദീർഘകാല ഐഡന്റിറ്റി മെറ്റീരിയലിനും ഹ്രസ്വകാല സെഷൻ കീകൾക്കും വ്യത്യസ്ത ആയുസ്സും വ്യത്യസ്ത ജോലികളുമുണ്ട്. മുന്നോട്ടുള്ള രഹസ്യത പറയുന്നത് ഈ വേർതിരിവിനെക്കുറിച്ചാണ്.

പ്രശ്നപരിഹാരത്തിനിടയിൽ സ്ഥിരീകരണം ഓണായി സൂക്ഷിക്കുക, കാരണം ഒരു പരിശോധന പ്രവർത്തനരഹിതമാക്കിയതിന് ശേഷം കണക്ട് ചെയ്യുന്ന ടണൽ ആ പരിശോധന എന്തോ ചെയ്യുന്നുണ്ടായിരുന്നു എന്നല്ലാതെ മറ്റൊന്നും തെളിയിച്ചിട്ടില്ല. എന്താണ് മാറ്റിയതെന്ന് എഴുതിവയ്ക്കുക, അടുത്ത പരിശോധനയ്ക്ക് മുമ്പ് അത് പഴയപടിയാക്കുക.

മൂന്ന് പ്രോട്ടോക്കോളുകൾ, മൂന്ന് സംഭാഷണങ്ങൾ

TLS അടിസ്ഥാനമാക്കിയ OpenVPN വിന്യാസത്തിൽ നിയന്ത്രണ ചാനൽ സുരക്ഷാ പാരാമീറ്ററുകൾ ചർച്ച ചെയ്യുമ്പോൾ ഡാറ്റ ചാനൽ ടണലിന്റെ ട്രാഫിക് വഹിക്കുന്നു, അതിനാൽ ഡാറ്റ ചാനൽ ഓപ്ഷനും സർട്ടിഫിക്കറ്റ് പ്രശ്നവും വെവ്വേറെ സ്ഥലങ്ങളിലാണ്. IKEv2 രണ്ട് പങ്കാളികളെയും പ്രമാണീകരിച്ച് സ്വന്തം ആയുസ്സുള്ള IPsec സുരക്ഷാ അസോസിയേഷനുകൾ സ്ഥാപിക്കുന്നു. WireGuard Noise അടിസ്ഥാനമാക്കിയ കൈമാറ്റത്തിലൂടെ കീകൾ ഉരുത്തിരിയുന്നു, അവസ്ഥാ യന്ത്രം ബോധപൂർവം ചെറുതായി നിലനിർത്തുന്നു. മൂന്നിൽ ഏതാണ് നിങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നതെന്ന് അറിയുന്നത് ഏത് ലോഗ് വായിക്കേണ്ടതാണെന്ന് തീരുമാനിക്കുന്നു.

സമാനമായി കാണപ്പെടുന്ന ക്ലയന്റുകൾ താഴെയുള്ള സന്ദേശങ്ങൾ പരസ്പരം മാറ്റാവുന്നതാണെന്ന് അർത്ഥമാക്കുന്നില്ല, ഒരു ഉൽപ്പന്നത്തിലുള്ള കോൺഫിഗറേഷൻ ഫീൽഡിന് മറ്റൊന്നിൽ തുല്യമായ ഒന്ന് ഇല്ലായിരിക്കാം. അവയ്ക്കിടയിൽ പ്രൊഫൈൽ പകർത്തുന്നത് മാറ്റംവരുത്തലല്ല, ഊഹമാണ്.

ഹാൻഡ്ഷേക്ക് ചെയ്യാത്തത്

റൂട്ടുകൾ, പേര് പരിഹരിക്കൽ, ലക്ഷ്യ നയം എന്നിവയെല്ലാം അതിന് ശേഷവും നിലനിൽക്കുന്നു. പങ്കാളി ശരിയായി പ്രമാണീകരിക്കപ്പെടുകയും ടണൽ പ്രവർത്തിക്കുകയും ചെയ്താലും സബ്‌നെറ്റ് റൂട്ട് ഇല്ലാത്തതിനാൽ ഒരു ആന്തരിക സൈറ്റ് എത്തിച്ചേരാനാകാത്തതായി തുടരാം. അതിനെ ദുർബല എൻക്രിപ്ഷനായി കാണുന്നത് തെറ്റായ പാളിയിൽ തിരയാൻ അയയ്ക്കുന്നു, ഒടുവിൽ ഒന്നും ശരിയാക്കാത്ത ഒരു സൈഫർ മാറ്റത്തിൽ അവസാനിക്കുന്നു.

കീ പുതുക്കലും വീണ്ടും കണക്ട് ചെയ്യലും മിക്ക സ്റ്റാറ്റസ് ഡിസ്പ്ലേകളിലും സമാനമായി കാണപ്പെടുന്നു, തടസ്സത്തിനിടയിൽ സാധാരണ ട്രാഫിക് തടഞ്ഞിരുന്നോ എന്ന് രണ്ടും പറയുന്നില്ല. ആ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നത് ക്ലയന്റിന്റെ പരാജയ നയം മാത്രമാണ്, അതിനാൽ ഐക്കണല്ല, നയം വായിക്കുക.

മുകളിലെ ക്രമത്തിൽ ഘട്ടങ്ങൾ പ്രവർത്തിപ്പിച്ച് ആദ്യം പിശക് ഉണ്ടാക്കുന്ന ഘട്ടത്തിൽ നിർത്തുക. തുടർന്നുള്ള ഓരോ ഘട്ടവും മുൻ ഘട്ടങ്ങളുടെ അവസ്ഥ പിന്തുടരുന്നു, അതിനാൽ മൂന്നാം ഘട്ടത്തിലെ പരാജയം നാലാമിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal

അനുബന്ധ ലേഖനങ്ങൾ