ServerAliveInterval de SSH por VPN: ¿qué extremo envía la sonda?

La mayoría de los consejos para mantener viva una sesión SSH se detienen en «añada ServerAliveInterval 30» y dejan fuera las partes útiles. La palabra clave es un temporizador del lado del cliente que solo se activa cuando el canal ha estado en silencio, cuenta sondas sin respuesta en lugar de segundos, y vive en un archivo donde gana el primer valor que coincide. Equivoque esas tres propiedades y una sesión VPN sana caerá igualmente, mientras que una muerta quedará colgada.

Las dos direcciones pertenecen a demonios distintos

ServerAliveInterval lo lee su cliente ssh. ClientAliveInterval lo lee sshd en el extremo opuesto y sondea en la otra dirección, del servidor al cliente. No son alias ni cooperan, así que configurar uno no tiene efecto en el comportamiento del otro extremo. Confundirlos es la razón habitual de que una corrección parezca funcionar en un host y no en el siguiente.

Ambos aceptan cero. Con cero el cliente no envía absolutamente nada, y en el lado del servidor un ClientAliveCountMax de cero desactiva la desconexión que de otro modo seguiría a las comprobaciones sin respuesta.

Qué demuestra una sonda y qué no

Cuando pasa el intervalo configurado sin que lleguen datos del servidor, el cliente envía una petición pequeña por el canal cifrado existente y espera una respuesta. ServerAliveCountMax fija cuántas de ellas pueden quedar sin respuesta antes de que se derribe la sesión. Con un intervalo de 60 y un recuento de 3 el cliente se rinde tras unos tres minutos de silencio, y esa cifra es una propiedad de su configuración, no un estándar de red. Deje el intervalo en su valor predeterminado 0 y nunca se envía sonda alguna, por eso un cliente estándar puede quedarse indefinidamente en una conexión muerta.

Como el intercambio ocurre dentro del transporte SSH, una respuesta demuestra que el proceso SSH del otro extremo sigue leyendo y escribiendo. No dice nada sobre el programa que inició dentro de esa sesión: un cliente de base de datos, un puerto reenviado o un script de larga duración pueden estar bloqueados mientras el transporte responde las sondas tan campante.

TCPKeepAlive es un mecanismo aparte una capa más abajo. Lo gestiona el núcleo, no va cifrado, y un extremo cuyo demonio SSH esté atascado aún puede satisfacerlo. Por eso la sonda a nivel SSH es la señal más significativa cuando le importa la sesión y no el socket.

El orden decide qué valor sobrevive

OpenSSH aplica el primer valor que obtiene para cada parámetro, así que un bloque Host concreto debe aparecer antes de cualquier bloque más amplio que también coincida. Ponga los valores predeterminados con comodines al final del archivo, no al principio, y recuerde que un bloque Match más abajo no puede anular un valor ya establecido. La referencia de configuración del cliente OpenSSH enuncia la regla del primer valor directamente, y vale la pena leerla una vez antes de reorganizar una configuración compartida.

Las opciones de línea de comandos ganan al archivo, lo que abarata un experimento temporal:

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

Para ver qué resolvió realmente el cliente en lugar de lo que cree que escribió, pídale que vuelque la configuración efectiva. La salida contiene los valores fusionados para ese nombre de host y es la forma más rápida de atrapar un bloque anterior extraviado:

ssh -G office-shell | grep -i alive

Qué hacen los keepalives por un túnel

El tráfico periódico evita que caduque una asignación NAT o de cortafuegos con estado, lo que es un beneficio real en una VPN cuyo gateway descarta los flujos inactivos al cabo de unos minutos. Las sondas que llegan cada 60 segundos refrescan esa asignación sin transportar datos de aplicación.

No pueden reconstruir un camino que ha desaparecido. Cuando la interfaz del túnel desaparece, las sondas fallan como todo lo demás, y la sesión termina en cuanto se agota el recuento. La detección de vida y la recuperación del camino son problemas distintos, y solo el primero es configurable en ssh_config. Lo que el intervalo y el recuento realmente le compran es la rapidez con que el cliente se da cuenta, y esa es la parte que el usuario vive como un cuelgue.

Las conexiones multiplexadas añaden un pliegue. Con ControlMaster en juego, las sondas pertenecen a la conexión maestra, y una sesión nueva sobre una maestra existente hereda lo que esa maestra negoció. Si la maestra del mux está atascada, abrir otra ventana no volverá a probar el camino.

Confirmar la configuración de extremo a extremo

En el servidor, vuelque la configuración efectiva del demonio en lugar de leer el archivo y adivinar qué include ganó:

sshd -T | grep -i clientalive

Luego observe una sesión real con la salida de depuración activada. El cliente imprime una línea de tiempo de espera cuando se agota el recuento, y las marcas de tiempo a su alrededor muestran si el silencio fue continuo o si las sondas nunca se enviaron. Una sesión que muere sin tráfico de sondas normalmente tiene la palabra clave en un bloque que nunca coincidió.

Vale la pena añadir dos comprobaciones para cualquier host al que solo llegue por un túnel: confirme que el intervalo resuelto es el que pretendía, y confirme que ese intervalo multiplicado por el recuento es más corto que el tiempo de inactividad en el gateway de la VPN. Cuando el segundo número es mayor, el gateway descarta primero el flujo en silencio y la sonda SSH nunca llega a tener ocasión de informar de nada.