VPN വഴി SSH ServerAliveInterval: ഏത് അറ്റമാണ് പ്രോബ് അയക്കുന്നത്?

SSH സെഷൻ ജീവനോടെ നിലനിർത്താനുള്ള ഉപദേശങ്ങളിൽ മിക്കതും «ServerAliveInterval 30 ചേർക്കുക» എന്നതിൽ നിർത്തി ഉപയോഗപ്രദമായ ഭാഗങ്ങൾ ഒഴിവാക്കുന്നു. കീവേഡ് ക്ലൈന്റ് വശത്തെ ടൈമറാണ്, അത് ചാനൽ നിശ്ശബ്ദമായിരുന്നപ്പോൾ മാത്രം പ്രവർത്തിക്കുന്നു, അത് സെക്കൻഡുകൾക്ക് പകരം മറുപടിയില്ലാത്ത പ്രോബുകൾ എണ്ണുന്നു, ആദ്യം ഒത്തുവരുന്ന മൂല്യം ജയിക്കുന്ന ഫയലിലാണ് അത് താമസിക്കുന്നത്. ഈ മൂന്ന് സവിശേഷതകളിൽ പിഴവ് വരുത്തിയാൽ ആരോഗ്യമുള്ള VPN സെഷനും വീഴും, എന്നാൽ മരിച്ച സെഷൻ തൂങ്ങിക്കിടക്കും.

രണ്ട് ദിശകളും വ്യത്യസ്ത ഡീമണുകളുടേതാണ്

ServerAliveInterval നിങ്ങളുടെ ssh ക്ലൈന്റാണ് വായിക്കുന്നത്. ClientAliveInterval വിദൂര വശത്തെ sshd വായിക്കുന്നു, അത് എതിർദിശയിൽ, സർവറിൽ നിന്ന് ക്ലൈന്റിലേക്ക് പ്രോബ് ചെയ്യുന്നു. അവ പര്യായങ്ങളല്ല, ഒരുമിച്ച് പ്രവർത്തിക്കുന്നുമില്ല, അതിനാൽ ഒന്ന് സജ്ജീകരിച്ചാൽ മറ്റേ അറ്റത്തിന്റെ സ്വഭാവത്തിൽ യാതൊരു ഫലവുമില്ല. അവ തമ്മിൽ കൂട്ടിക്കലർത്തുന്നതാണ് ഒരു ഹോസ്റ്റിൽ പരിഹാരം ജോലി ചെയ്യുന്നതായും അടുത്തതിൽ ചെയ്യാത്തതായും തോന്നാനുള്ള സാധാരണ കാരണം.

രണ്ടും പൂജ്യം സ്വീകരിക്കുന്നു. പൂജ്യത്തിൽ ക്ലൈന്റ് ഒന്നും അയക്കുന്നില്ല, സർവർ വശത്ത് പൂജ്യം ClientAliveCountMax മറുപടിയില്ലാത്ത പരിശോധനകൾക്ക് ശേഷം വരേണ്ട വിച്ഛേദനം പ്രവർത്തനരഹിതമാക്കുന്നു.

പ്രോബ് എന്ത് തെളിയിക്കുന്നു, എന്ത് തെളിയിക്കുന്നില്ല

നിശ്ചയിച്ച ഇടവേള കഴിഞ്ഞിട്ടും സർവറിൽ നിന്ന് ഡാറ്റ എത്തിയില്ലെങ്കിൽ, ക്ലൈന്റ് നിലവിലുള്ള എൻക്രിപ്റ്റ് ചെയ്ത ചാനൽ വഴി ഒരു ചെറിയ അഭ്യർത്ഥന അയച്ച് മറുപടിക്കായി കാത്തിരിക്കുന്നു. സെഷൻ വിച്ഛേദിക്കുന്നതിന് മുൻപ് എത്രയെണ്ണം മറുപടിയില്ലാതെ തുടരാം എന്ന് ServerAliveCountMax നിർണ്ണയിക്കുന്നു. ഇടവേള 60 ഉം എണ്ണം 3 ഉം ആണെങ്കിൽ ക്ലൈന്റ് ഏകദേശം മൂന്ന് മിനിറ്റ് നിശ്ശബ്ദതയ്ക്ക് ശേഷം വിട്ടുകൊടുക്കുന്നു, ആ സംഖ്യ നെറ്റ്വർക്ക് മാനദണ്ഡമല്ല, നിങ്ങളുടെ കോൺഫിഗറേഷന്റെ സവിശേഷതയാണ്. ഇടവേള അതിന്റെ സ്വതവേയുള്ള 0-ൽ വിട്ടാൽ ഒരു പ്രോബും ഒരിക്കലും അയക്കപ്പെടുന്നില്ല, അതുകൊണ്ടാണ് ഒരു സാധാരണ ക്ലൈന്റിന് മരിച്ച കണക്ഷനിൽ അനിശ്ചിതമായി ഇരിക്കാൻ കഴിയുന്നത്.

കൈമാറ്റം SSH ട്രാൻസ്പോർട്ടിനുള്ളിൽ നടക്കുന്നതിനാൽ, ഒരു മറുപടി എതിർവശത്തെ SSH പ്രോസസ് ഇപ്പോഴും വായിക്കുന്നുവെന്നും എഴുതുന്നുവെന്നും തെളിയിക്കുന്നു. ആ സെഷനുള്ളിൽ നിങ്ങൾ ആരംഭിച്ച പ്രോഗ്രാമിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല: ഡാറ്റാബേസ് ക്ലൈന്റ്, ഫോർവേഡ് ചെയ്ത പോർട്ട്, അല്ലെങ്കിൽ ദീർഘനേരം പ്രവർത്തിക്കുന്ന സ്ക്രിപ്റ്റ് എന്നിവ ട്രാൻസ്പോർട്ട് സന്തോഷത്തോടെ പ്രോബുകൾക്ക് മറുപടി നൽകുമ്പോൾ കുടുങ്ങിക്കിടക്കാം.

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

ഏത് മൂല്യം അവശേഷിക്കുമെന്ന് ക്രമം തീരുമാനിക്കുന്നു

ഓരോ പാരാമീറ്ററിനും ലഭിക്കുന്ന ആദ്യ മൂല്യം OpenSSH പ്രയോഗിക്കുന്നു, അതിനാൽ ഒരു നിർദ്ദിഷ്ട Host ബ്ലോക്ക് ഒത്തുവരുന്ന ഏത് വിശാല ബ്ലോക്കിനും മുൻപ് വരണം. വൈൽഡ്കാർഡ് സ്വതവേ മൂല്യങ്ങൾ ഫയലിന്റെ അടിയിൽ വയ്ക്കുക, മുകളിലല്ല, താഴെയുള്ള Match ബ്ലോക്കിന് ഇതിനകം സജ്ജീകരിച്ച മൂല്യം മറികടക്കാനാവില്ലെന്ന് ഓർക്കുക. OpenSSH ക്ലൈന്റ് കോൺഫിഗറേഷൻ റഫറൻസ് ആദ്യ-മൂല്യ നിയമം നേരിട്ട് പറയുന്നു, പങ്കിട്ട കോൺഫിഗറേഷൻ പുനഃക്രമീകരിക്കുന്നതിന് മുൻപ് അത് ഒരിക്കൽ വായിക്കാൻ യോഗ്യമാണ്.

കമാൻഡ് ലൈൻ ഓപ്ഷനുകൾ ഫയലിനെ തോൽപ്പിക്കുന്നു, അത് താൽക്കാലിക പരീക്ഷണത്തെ വിലകുറഞ്ഞതാക്കുന്നു:

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

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

ssh -G office-shell | grep -i alive

ടണലിലൂടെ keepalive എന്ത് ചെയ്യുന്നു

സ്ഥിതിയുള്ള NAT അല്ലെങ്കിൽ ഫയർവാൾ മാപ്പിംഗ് കാലഹരണപ്പെടുന്നത് ആനുകാലിക ട്രാഫിക് തടയുന്നു, നിഷ്ക്രിയ ഫ്ലോകൾ കുറച്ച് മിനിറ്റുകൾക്ക് ശേഷം ഉപേക്ഷിക്കുന്ന ഗേറ്റ്വേയുള്ള VPN-ൽ ഇത് യഥാർത്ഥ നേട്ടമാണ്. ഓരോ 60 സെക്കൻഡിലും എത്തുന്ന പ്രോബുകൾ ഒരു ആപ്ലിക്കേഷൻ ഡാറ്റയും വഹിക്കാതെ ആ മാപ്പിംഗ് പുതുക്കുന്നു.

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

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

ക്രമീകരണം ആദ്യം മുതൽ അവസാനം വരെ സ്ഥിരീകരിക്കൽ

സർവറിൽ ഫയൽ വായിച്ച് ഏത് include ജയിച്ചു എന്ന് ഊഹിക്കുന്നതിന് പകരം ഫലപ്രദമായ ഡീമൺ കോൺഫിഗറേഷൻ ഡംപ് ചെയ്യുക:

sshd -T | grep -i clientalive

തുടർന്ന് ഡീബഗ് output ഓൺ ചെയ്ത് ഒരു യഥാർത്ഥ സെഷൻ നിരീക്ഷിക്കുക. എണ്ണം തീരുമ്പോൾ ക്ലൈന്റ് ഒരു ടൈംഔട്ട് വരി അച്ചടിക്കുന്നു, അതിന് ചുറ്റുമുള്ള ടൈംസ്റ്റാമ്പുകൾ നിശ്ശബ്ദത തുടർച്ചയായിരുന്നോ അതോ പ്രോബുകൾ ഒട്ടും അയച്ചിട്ടില്ലേ എന്ന് കാണിക്കുന്നു. പ്രോബ് ട്രാഫിക്കില്ലാതെ മരിക്കുന്ന സെഷന്റെ കീവേഡ് സാധാരണയായി ഒരിക്കലും ഒത്തുവരാത്ത ബ്ലോക്കിലായിരിക്കും.

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