IKEv2 മൃത പീയർ കണ്ടെത്തൽ നിങ്ങളുടെ ആപ്പ് പരിശോധിക്കുന്നില്ല

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

ടൈമർ മാറ്റുന്നതിന് മുമ്പ് രണ്ട് തരം തെളിവുകളും വെവ്വേറെ വായിക്കുക.

ജീവനക്ഷമതാ പരിശോധന യഥാർത്ഥത്തിൽ എന്താണ് ചോദിക്കുന്നത്

ജീവനക്ഷമതാ കൈമാറ്റം സ്ഥാപിത IKE സുരക്ഷാ അസോസിയേഷനിൽ ഉള്ളിൽ അയക്കപ്പെടുകയും ക്രമീകരിച്ച വിൻഡോയ്ക്കുള്ളിൽ മറുപടി പ്രതീക്ഷിക്കുകയും ചെയ്യുന്നു. വിജയം എന്നത് പീയറിന്റെ IKE നടപ്പാക്കൽ ഇപ്പോഴും അവിടെ ഉണ്ട്, ഇപ്പോഴും സംസാരിക്കാൻ തയ്യാറാണ്. ട്രാഫിക് വഹിക്കുന്ന ചൈൽഡ് സുരക്ഷാ അസോസിയേഷനുകളെക്കുറിച്ച് ഇത് ഒന്നും പറയുന്നില്ല, ഗേറ്റ്വേയ്ക്ക് അപ്പുറത്തുള്ള റൂട്ടിംഗിനെക്കുറിച്ചും ഒന്നും, ടണൽ തുറന്ന സേവനത്തെക്കുറിച്ചും ഒന്നും പറയുന്നില്ല. ഇവ മൂന്ന് വെവ്വേറെ ചോദ്യങ്ങളാണ്, മൂന്ന് വെവ്വേറെ പരാജയ മാതൃകകളോടെ.

സെഷൻ നിശ്ശബ്ദമാകുമ്പോൾ എവിടെ നോക്കണം എന്ന് ആ വ്യത്യാസമാണ് തീരുമാനിക്കുന്നത്. ഡാറ്റ പാത തകർന്നിരിക്കുമ്പോഴും പ്രതികരിക്കുന്ന പീയർ നയം, റൂട്ടിംഗ് അല്ലെങ്കിൽ താഴെയുള്ള സേവനത്തെ സൂചിപ്പിക്കുന്നു. പ്രതികരിക്കുന്നത് നിർത്തുന്ന പീയർ എത്തിച്ചേരൽ അല്ലെങ്കിൽ ദൂരെ അറ്റത്തിന്റെ സ്വന്തം അവസ്ഥയെ സൂചിപ്പിക്കുന്നു.

ബ്രൗസറിന് മുമ്പ് സുരക്ഷാ അസോസിയേഷനുകൾ വായിക്കുക

ഡെമോണിനോട് ചോദിക്കുമ്പോൾ നിയന്ത്രണ അവസ്ഥയും ഡാറ്റ അവസ്ഥയും വെവ്വേറെ ലിസ്റ്റ് ചെയ്യപ്പെടുന്നു, എന്തെങ്കിലും ശ്രമിച്ചിട്ടുണ്ടോ എന്ന് കൗണ്ടറുകൾ പറയുന്നു. ഒരിക്കലും സ്ഥാപിക്കാത്ത ചൈൽഡ് അസോസിയേഷൻ സ്ഥാപിച്ചതിന് ശേഷം പാക്കറ്റുകൾ കടത്തിവിടുന്നത് നിർത്തിയതിന് സമാനമല്ല, എന്നാൽ രണ്ടും ഒരേ ഉപയോക്തൃ പരാതിയാണ് ഉണ്ടാക്കുന്നത്.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

പരാതിയുടെ നിമിഷത്തിലെ കൗണ്ടറുകളോടൊപ്പം അവസ്ഥകളുടെ പേരുകൾ ടിക്കറ്റിൽ അതേപടി എഴുതുക. ടണൽ താഴെ എന്ന പോലുള്ള വിവരണം രണ്ട് അസോസിയേഷനുകളിൽ ഏതാണ് അവസാനിച്ചതെന്ന് മറയ്ക്കുന്നു, സാധാരണയായി അതാണ് സൂക്ഷിക്കാൻ യോഗ്യമായ ഏക വസ്തുത.

റൂട്ട് പരാജയം മൃത പീയറിനെപ്പോലെ തന്നെ കാണപ്പെടുന്നു

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

ടണൽ സജീവമാണോ എന്ന് പരിശോധിക്കുന്നതിനുപകരം ഉദ്ദേശിച്ച ആപ്ലിക്കേഷൻ നേരിട്ട് പരിശോധിക്കുകയും അത് ശ്രമിച്ച വിലാസം പേരെടുത്ത് പറയുകയും ചെയ്യുക. ഗേറ്റ്വേയിലേക്കുള്ള പിംഗ് ഗേറ്റ്വേ മറുപടി നൽകുന്നു എന്ന് തെളിയിക്കുന്നു; ആപ്ലിക്കേഷൻ മറുപടി നൽകി എന്ന് അത് ഒരിക്കലും തെളിയിച്ചിട്ടില്ല. ആപ്ലിക്കേഷൻ ശ്രമിച്ച കൃത്യമായ വിലാസം രേഖപ്പെടുത്തുക. ആ സ്ട്രിംഗ് പിന്നീട് തിരച്ചിൽ ചുരുക്കുന്നു, ടിക്കറ്റ് സാധാരണയായി വിട്ടുപോകുന്ന ഏക വസ്തുത അതാണ്.

ടൈമറുകളെ രോഗനിർണ്ണയത്തിൽ നിന്ന് അകറ്റി നിർത്തുക

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

NAT മാപ്പിംഗ് പുതുക്കലുകൾ അതേ വിഭാഗത്തിൽ പെടുന്നു. അവ വിവർത്തനം ചെയ്ത പാത ഉപയോഗയോഗ്യമായി നിലനിർത്തുന്നു, ദൂരെയുള്ള ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നു എന്നതിന് അവ തെളിവല്ല.

പൂർണ്ണമായ വീണ്ടെടുപ്പ് നയം പീയർ മൃതമായി പ്രഖ്യാപിക്കുമ്പോൾ ക്ലയന്റ് എന്ത് ചെയ്യണം എന്ന് പറയുന്നു: പുനരാരംഭിക്കുക, അടയ്ക്കുക അല്ലെങ്കിൽ പിടിച്ചുനിർത്തുക, അതിനിടയിൽ മറ്റ് ട്രാഫിക് എന്ത് ചെയ്യാം എന്നും. അതില്ലാതെ അതേ സംഭവം ഓരോ പാദത്തിലും പൂജ്യത്തിൽ നിന്ന് വീണ്ടും രോഗനിർണ്ണയം ചെയ്യപ്പെടുന്നു.