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

ഇടവേളയെ സംഖ്യയാക്കുക

അഞ്ചോ ആറോ സംഭവങ്ങൾ ശേഖരിച്ച് അവയ്ക്കിടയിലുള്ള വിടവ് കണക്കാക്കുക, ദിവസത്തിന്റെ തുടക്കത്തിൽ നിന്നല്ല. 09:12, 10:12, 11:12 എന്നിവയിലെ വിച്ഛേദം മണിക്കൂർ അതിർത്തിയാണ്; 09:12, 09:27, 09:42 എന്നിവയിലെ വിച്ഛേദം അവസാന വിജയകരമായ കണക്ഷനിൽ നിന്ന് പതിനഞ്ച് മിനിറ്റാണ്. ഫലം അടുത്തുള്ള മിനിറ്റിലേക്കല്ല, ഏറ്റവും സാധ്യതയുള്ള ടൈമറിലേക്ക് റൗണ്ട് ചെയ്യുക.

ഓരോ സംഭവത്തിനും രണ്ട് നിമിഷങ്ങൾ രേഖപ്പെടുത്തുക: ട്രാഫിക് അവസാനമായി നീങ്ങിയത് എപ്പോൾ, ക്ലയന്റ് വിച്ഛേദം റിപ്പോർട്ട് ചെയ്തത് എപ്പോൾ. ടണൽ നിശബ്ദമായി മരിക്കുമ്പോഴും ക്ലയന്റ് അടുത്ത അയയ്ക്കലിൽ മാത്രം അത് ശ്രദ്ധിക്കുമ്പോഴും ഇവ വ്യത്യാസപ്പെടുന്നു, ആ വ്യത്യാസമാണ് ഐഡിൽ ടൈമൗട്ടിനെ കഠിന തകരാറിൽ നിന്ന് വേർതിരിക്കുന്നത്. വൈകി ശ്രദ്ധിക്കുന്ന ക്ലയന്റ് നിങ്ങൾ അളക്കുന്ന ഐഡിൽ വിൻഡോ വലുതാക്കി കാണിക്കുന്നു.

വീണ്ടും കണക്ട് ചെയ്യൽ യാന്ത്രികമാണോ എന്ന് ശ്രദ്ധിക്കുക. സെക്കൻഡുകൾക്കുള്ളിൽ വീണ്ടും ബന്ധിപ്പിക്കുന്ന ക്ലയന്റ് ഇടവേള ലോഗിൽ കാണുന്നതും ഉപയോക്തൃ റിപ്പോർട്ടിന് പുറത്തും നിലനിർത്തുന്നു, അതുകൊണ്ടാണ് ഈ തകരാറുകൾ ആനുകാലികമല്ലാതെ ഇടയ്ക്കിടെയുള്ളതായി വിവരിക്കുന്നത്. ലാപ്ടോപ്പ് ഉപയോഗിക്കുന്ന വ്യക്തിയിൽ നിന്ന് സംഭവം മറയ്ക്കുകയും ചെയ്യുന്നു.

ഒരുപോലെ തോന്നുന്ന നാല് ടൈമറുകൾ

ഏതാണ്ട് എല്ലാ ആവർത്തിച്ചുള്ള ടണൽ വീഴ്ചയും ഇവയിലൊന്നിൽ നിന്നാണ് വരുന്നത്: പ്രോട്ടോക്കോൾ കീ പുതുക്കൽ, നിഷ്ക്രിയ മാപ്പിംഗിന്റെ കാലഹരണം, DHCP അല്ലെങ്കിൽ ഇന്റർഫേസ് സംഭവം, അല്ലെങ്കിൽ അക്കൗണ്ട് നയം. ട്രാഫിക് ഒഴുകിയിരുന്നോ എന്നതിലും അതിർത്തിയിൽ ലോഗ് എന്ത് പറയുന്നു എന്നതിലും അവ വ്യത്യാസപ്പെടുന്നു.

താഴെയുള്ള അടയാളങ്ങൾ പഠിക്കാൻ യോഗ്യമാണ്, കാരണം ഒരു ലോഗ് വരിയിൽ നിന്ന് മൂന്ന് വിശദീകരണങ്ങൾ തള്ളാൻ അവ അനുവദിക്കുന്നു:

TimerTypical triggerWhat the log shows at the boundary
Protocol rekeyTraffic present, fixed intervalNegotiation lines, sometimes a failure
NAT or firewall idleNo traffic for minutesSilence, then a timeout on send
DHCP lease or link changeHalf the lease, or a radio eventAddress or interface churn
Account session limitWall-clock hours since loginClean disconnect, server-side reason

ആദ്യ വരി തന്റെ ജോലി ചെയ്യുന്ന സുരക്ഷാ സംവിധാനമാണ്, രണ്ടാമത്തേത് അവസ്ഥ മറക്കുന്ന ഇടനില ഉപകരണമാണ്. ഇവ കൂട്ടിക്കുഴയ്ക്കുന്നത് കീ പുതുക്കൽ ദുർബലമാക്കാനോ ഒരിക്കലും ഉൾപ്പെടാത്ത ഫയർവാൾ നിയമത്തിന് പിന്നാലെ പോകാനോ കാരണമാകുന്നു.

തിരക്കിലാണോ നിഷ്ക്രിയമാണോ എന്നത് ഏത് പകുതിയെന്ന് പറയുന്നു

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

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

പരിശോധനയ്ക്കിടയിൽ ആക്സസ് നെറ്റ്വർക്ക് മാറ്റാതെ നിർത്തുക. താരതമ്യത്തിനിടയിൽ Wi-Fi-നും Ethernet-നും ഇടയിൽ മാറുന്നത് ടൈമറിൽ നിന്ന് വേർതിരിക്കാൻ ശ്രമിക്കുന്ന ഇന്റർഫേസ് സംഭവം കൃത്യമായി കൊണ്ടുവരുന്നു.

ലോഗ് വരി അതിർത്തിയുമായി ഒത്തുനോക്കുക

രേഖപ്പെടുത്തിയ നിമിഷത്തിന് ചുറ്റുമുള്ള ക്ലയന്റ്, സെർവർ ലോഗുകൾ വായിക്കുക, മുഴുവൻ ഫയലല്ല. കീ പുതുക്കൽ ചർച്ചകൾ കാണിക്കുന്നു; ഐഡിൽ കാലഹരണം അടുത്ത പാക്കറ്റ് വരെ ഒന്നും കാണിക്കുന്നില്ല; ലീസ് മാറ്റം വിലാസപ്രവർത്തനം കാണിക്കുന്നു; നയ പരിധി സാധാരണയായി വ്യക്തമായ ഭരണപരമായ വിച്ഛേദം കാണിക്കുന്നു.

ഈ കമാൻഡുകൾ ഓരോ ഉറവിടത്തിൽ നിന്നും പ്രസക്തമായ വിൻഡോ വലിച്ചെടുക്കുന്നു:

grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg show

മൂന്ന് ഉറവിടങ്ങളും സമയമുദ്രയിൽ യോജിക്കുന്നുവെങ്കിൽ ടൈമറിന്റെ ഉടമ നിങ്ങൾക്കറിയാം. ക്ലയന്റ് ലോഗിൽ മാത്രം എന്തെങ്കിലും ഉണ്ടെങ്കിൽ, സെഷൻ അവസാനിപ്പിക്കുന്നത് സെർവർ ആയിരിക്കില്ല.

ഘട്ടം ശരിയാക്കുക, ഐക്കൺ അല്ല

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

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

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