ServerAliveInterval de SSH por VPN: que extremo envía a sonda?

A maioría dos consellos para manter viva unha sesión SSH detéñense en «engada ServerAliveInterval 30» e deixan fóra as partes útiles. A palabra clave é un temporizador do lado do cliente que só se activa cando a canle estivo en silencio, conta sondas sen resposta en lugar de segundos, e vive nun ficheiro onde gaña o primeiro valor que coincide. Equivoque esas tres propiedades e unha sesión VPN san caerá igualmente, mentres que unha morta quedará colgada.

As dúas direccións pertencen a demos distintos

ServerAliveInterval léo o seu cliente ssh. ClientAliveInterval léo sshd no extremo oposto e sonda na outra dirección, do servidor ao cliente. Non son alias nin cooperan, así que configurar un non ten efecto no comportamento do outro extremo. Confundilos é a razón habitual de que unha corrección pareza funcionar nun host e non no seguinte.

Ambos aceptan cero. Con cero o cliente non envía absolutamente nada, e no lado do servidor un ClientAliveCountMax de cero desactiva a desconexión que doutro xeito seguiría ás comprobacións sen resposta.

Que demostra unha sonda e que non

Cando pasa o intervalo configurado sen que cheguen datos do servidor, o cliente envía unha petición pequena pola canle cifrada existente e espera unha resposta. ServerAliveCountMax fixa cantas delas poden quedar sen resposta antes de que se derrube a sesión. Cun intervalo de 60 e un reconto de 3 o cliente réndese tras uns tres minutos de silencio, e esa cifra é unha propiedade da súa configuración, non un estándar de rede. Deixe o intervalo no seu valor predeterminado 0 e nunca se envía sonda algunha, por iso un cliente estándar pode quedar indefinidamente nunha conexión morta.

Como o intercambio ocorre dentro do transporte SSH, unha resposta demostra que o proceso SSH do outro extremo segue lendo e escribindo. Non di nada sobre o programa que iniciou dentro desa sesión: un cliente de base de datos, un porto redirixido ou un script de longa duración poden estar bloqueados mentres o transporte responde as sondas tan contento.

TCPKeepAlive é un mecanismo aparte unha capa máis abaixo. Xestiónao o núcleo, non vai cifrado, e un extremo cuxo demo SSH estea atascado aínda pode satisfacelo. Por iso a sonda a nivel SSH é o sinal máis significativo cando lle importa a sesión e non o socket.

A orde decide que valor sobrevive

OpenSSH aplica o primeiro valor que obtén para cada parámetro, así que un bloque Host concreto debe aparecer antes de calquera bloque máis amplo que tamén coincida. Pona os valores predeterminados con comodíns ao final do ficheiro, non ao principio, e lembre que un bloque Match máis abaixo non pode anular un valor xa establecido. A referencia de configuración do cliente OpenSSH enuncia a regra do primeiro valor directamente, e paga a pena lela unha vez antes de reorganizar unha configuración compartida.

As opcións de liña de ordes gañan ao ficheiro, o que fai barato un experimento temporal:

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

Para ver que resolveu realmente o cliente en lugar do que cree que escribiu, pídalle que volque a configuración efectiva. A saída contén os valores fusionados para ese nome de host e é a forma máis rápida de atrapar un bloque anterior extraviado:

ssh -G office-shell | grep -i alive

Que fan os keepalives por un túnel

O tráfico periódico evita que caduque unha asignación NAT ou de devasado con estado, o que é un beneficio real nunha VPN cuxa pasarela descarta os fluxos inactivos ao cabo duns minutos. As sondas que chegan cada 60 segundos refrescan esa asignación sen transportar datos de aplicación.

Non poden reconstruír un camiño que desapareceu. Cando a interface do túnel desaparece, as sondas fallan como todo o demais, e a sesión remata en canto se esgota o reconto. A detección de vida e a recuperación do camiño son problemas distintos, e só o primeiro é configurable en ssh_config. O que o intervalo e o reconto realmente lle compran é a rapidez con que o cliente se decata, e esa é a parte que o usuario vive como un bloqueo.

As conexións multiplexadas engaden unha dobra. Con ControlMaster en xogo, as sondas pertencen á conexión mestra, e unha sesión nova sobre unha mestra existente herda o que esa mestra negociou. Se a mestra do mux está atascada, abrir outra xanela non volverá probar o camiño.

Confirmar a configuración de extremo a extremo

No servidor, volque a configuración efectiva do demo en lugar de ler o ficheiro e adiviñar que include gañou:

sshd -T | grep -i clientalive

Despois observe unha sesión real coa saída de depuración activada. O cliente imprime unha liña de tempo de espera cando se esgota o reconto, e as marcas de tempo ao seu redor mostran se o silencio foi continuo ou se as sondas nunca se enviaron. Unha sesión que morre sen tráfico de sondas normalmente ten a palabra clave nun bloque que nunca coincidiu.

Paga a pena engadir dúas comprobacións para calquera host ao que só chega por un túnel: confirme que o intervalo resolto é o que pretendía, e confirme que ese intervalo multiplicado polo reconto é máis curto que o tempo de inactividade na pasarela da VPN. Cando o segundo número é maior, a pasarela descarta primeiro o fluxo en silencio e a sonda SSH nunca chega a ter ocasión de informar de nada.