ServerAliveInterval de SSH per VPN: quin extrem envia la sonda?

La majoria de consells per mantenir viva una sessió SSH s'aturen a «afegiu ServerAliveInterval 30» i deixen fora les parts útils. La paraula clau és un temporitzador del costat del client que només s'activa quan el canal ha estat en silenci, compta sondes sense resposta en lloc de segons, i viu en un fitxer on guanya el primer valor que coincideix. Equivoqueu-vos en aquestes tres propietats i una sessió VPN sana igualment caurà, mentre que una de morta quedarà penjada.

Les dues direccions pertanyen a dimonis diferents

ServerAliveInterval el llegeix el vostre client ssh. ClientAliveInterval el llegeix sshd a l'altre costat i sondeja en sentit contrari, del servidor al client. No són àlies ni cooperen, així que configurar-ne un no té cap efecte en el comportament de l'altre extrem. Confondre'ls és la raó habitual que una correcció sembli funcionar en un amfitrió i no en el següent.

Tots dos accepten zero. Amb zero el client no envia res de res, i al costat del servidor un ClientAliveCountMax de zero desactiva la desconnexió que altrament seguiria les comprovacions sense resposta.

Què demostra una sonda i què no

Quan passa l'interval configurat sense que arribi cap dada del servidor, el client envia una petició petita pel canal xifrat existent i espera una resposta. ServerAliveCountMax fixa quantes d'aquestes poden quedar sense resposta abans que es trenqui la sessió. Amb un interval de 60 i un recompte de 3 el client es rendeix al cap d'uns tres minuts de silenci, i aquesta xifra és una propietat de la vostra configuració, no un estàndard de xarxa. Deixeu l'interval al seu valor per defecte 0 i no s'enviarà mai cap sonda, i per això un client estàndard pot quedar-se indefinidament en una connexió morta.

Com que l'intercanvi va dins del transport SSH, una resposta demostra que el procés SSH de l'altre extrem encara llegeix i escriu. No diu res del programa que vau engegar dins d'aquella sessió: un client de base de dades, un port redirigit o un script de llarga durada poden estar encallats mentre el transport respon les sondes ben content.

TCPKeepAlive és un mecanisme separat una capa més avall. El nucli se n'encarrega, no va xifrat, i un extrem amb el dimoni SSH encallat encara el pot satisfer. Per això la sonda a nivell SSH és el senyal més significatiu quan us importa la sessió i no el sòcol.

L'ordre decideix quin valor sobreviu

OpenSSH aplica el primer valor que obté per a cada paràmetre, així que un bloc Host concret ha d'aparèixer abans de qualsevol bloc més ampli que també hi encaixi. Posa els valors per defecte amb comodins al final del fitxer, no al principi, i recorda que un bloc Match més avall no pot anul·lar un valor que ja s'ha establert. La referència de configuració del client OpenSSH diu la regla del primer valor directament, i val la pena llegir-la un cop abans de reorganitzar una configuració compartida.

Les opcions de línia d'ordres guanyen el fitxer, cosa que fa barat un experiment temporal:

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

Per veure què ha resolt realment el client i no què creieu que heu escrit, demaneu-li que bolqui la configuració efectiva. La sortida conté els valors fusionats per a aquell nom d'amfitrió i és la manera més ràpida d'atrapar un bloc anterior esgarriat:

ssh -G office-shell | grep -i alive

Què fan els keepalives per un túnel

El trànsit periòdic evita que caduqui una assignació NAT o de tallafoc amb estat, cosa que és un benefici real en una VPN el gateway de la qual descarta els fluxos inactius al cap d'uns minuts. Les sondes que arriben cada 60 segons refresquen aquesta assignació sense portar cap dada d'aplicació.

No poden reconstruir un camí que ha desaparegut. Quan la interfície del túnel desapareix, les sondes fallen com tota la resta, i la sessió acaba quan s'esgota el recompte. La detecció de vida i la recuperació del camí són problemes diferents, i només el primer es pot configurar a ssh_config. El que l'interval i el recompte us compren de veritat és com de ràpid se n'adona el client, i aquesta és la part que l'usuari viu com una penjada.

Les connexions multiplexades hi afegeixen un plec. Amb ControlMaster en joc, les sondes pertanyen a la connexió mestra, i una sessió nova sobre una mestra existent hereta el que aquella mestra va negociar. Si la mestra del mux està encallada, obrir una altra finestra no tornarà a provar el camí.

Confirmar la configuració d'extrem a extrem

Al servidor, bolqueu la configuració efectiva del dimoni en lloc de llegir el fitxer i endevinar quin include ha guanyat:

sshd -T | grep -i clientalive

Després observeu una sessió real amb la sortida de depuració activada. El client imprimeix una línia de temps d'espera quan el recompte s'esgota, i les marques de temps al voltant mostren si el silenci era continu o si les sondes no es van enviar mai. Una sessió que mor sense cap trànsit de sonda normalment té la paraula clau en un bloc que no va coincidir mai.

Val la pena afegir dues comprovacions per a qualsevol amfitrió al qual només arribeu per un túnel: confirmeu que l'interval resolt és el que volíeu, i confirmeu que aquest interval multiplicat pel recompte és més curt que el temps d'inactivitat del gateway de la VPN. Quan el segon número és més gran, el gateway descarta el flux abans en silenci i la sonda SSH no arriba a tenir cap oportunitat d'informar de res.