¿SSH se cae en la VPN cada minuto? No es el keepalive

SSH se conecta, funciona más o menos un minuto y luego se congela en el mismo intervalo aproximado cada vez. La explicación habitual es un tiempo de espera por inactividad, así que la gente baja la MTU y configura keepalives en el cliente. El enlace WireGuard en el que trabajé ya había pasado por todo eso: una MTU de túnel más pequeña, ajustes de client-alive y un keepalive de túnel configurado. Las caídas continuaban sin cambios. La causa resultó ser una ruta LAN asimétrica, y merece la pena reconocer el patrón porque derrota cualquier arreglo basado en temporizadores.

Un keepalive demuestra que su host sigue dispuesto a enviar. No puede hacer que un dispositivo con estado vea una respuesta que nunca lo atraviesa.

El mito: los keepalives arreglan una caída silenciosa

Los keepalives de SSH existen para una sola tarea: evitar que algo que cuenta el silencio deseche una sesión inactiva. Eso lo hacen bien. No resuelven el caso de un dispositivo con estado que vio el primer paquete en una dirección y luego nunca vio la respuesta, porque nada de lo que envía el cliente cambia qué interfaz usa la respuesta.

Cambiar la MTU es el otro arreglo popular, y tiene el mismo modo de fallo. Reducir la MTU ayuda con la fragmentación y los problemas de MTU de ruta, y no hace nada por una ruta. Si sus temporizadores y su MTU ya son razonables y la caída sigue en un intervalo repetible, el intervalo le habla de un tiempo de espera en algún sitio, no del tamaño de los paquetes. Anote el intervalo y compárelo con los tiempos de espera de estado de cada dispositivo de la ruta.

La pista es la regularidad combinada con una sesión que sigue siendo utilizable dentro de ese intervalo. Los tiempos de espera por inactividad golpean cuando no pasa nada; este golpea mientras usted escribe.

Qué hace realmente la puerta de enlace adicional

Ponga el portátil y la puerta de enlace VPN en la misma LAN, con un cortafuegos LAN aparte como puerta de enlace predeterminada. El portátil envía el tráfico dirigido a la VPN al cortafuegos, el cortafuegos lo reenvía a la puerta de enlace, y las respuestas de la puerta de enlace vuelven directamente por la LAN al portátil. Ese segundo tramo nunca pasa por el cortafuegos, así que su tabla de estado mantiene media conexión.

Las direcciones de abajo reflejan esa disposición:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

Las redirecciones y el manejo de estado convierten entonces un handshake funcional en una conexión que muere más tarde en lugar de inmediatamente. El retraso es la entrada de estado que caduca o una comprobación más estricta que falla, y por eso el intervalo parece tan mecánico.

Nada de esto aparece en la configuración del cliente, y por eso su búsqueda suele empezar en el archivo equivocado.

Elija un camino deliberado

Para la disposición de arriba, enrutar la subred remota directamente hacia la puerta de enlace VPN elimina la media conexión:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

Son direcciones de ejemplo. El siguiente salto tiene que ser alcanzable en su LAN, el prefijo tiene que ser la red remota prevista, y el segundo comando le muestra el resultado antes de que confíe en él. Si la puerta de enlace no está en su subred, esta ruta no es el arreglo que usted quiere.

Si el cortafuegos debe vigilar el tráfico entre esos sistemas, enrutar por fuera es un diseño equivocado. Haga que ambas direcciones crucen la frontera y configure las rutas a cada lado para que el camino de vuelta coincida. El objetivo es un único camino deliberado, no menos comprobación de estado.

Las notas sobre enrutamiento asimétrico de Netgate describen la misma asimetría a nivel de interfaz y los problemas de estado que crea, así que léalas antes de aflojar el manejo de estado de forma global. Las desconexiones temporizadas parecidas a este caso no son prueba por sí solas. Trate el artículo como la descripción de un modo de fallo y luego demuestre que su propia red encaja con él antes de cambiar la política global de estado.

Pruébelo desde ambos extremos

Lea la ruta del portátil hacia el destino y la ruta del destino de vuelta hacia el portátil; son dos decisiones separadas y probablemente solo una de ellas es incorrecta. Un ping que tiene éxito desde la propia puerta de enlace puede ocultar el problema por completo, porque se origina en la máquina cuyo camino ya es correcto. Necesita ambas direcciones tal como las ven los dos extremos de la sesión real.

Después del arreglo, vuelva a abrir SSH y mantenga la sesión abierta mucho más allá del intervalo que antes fallaba. Luego haga la ruta persistente en la configuración de red aprobada, porque un comando puntual no es un plan de reinicio y el problema volverá en el próximo reinicio con un misterio nuevo.

Cuándo la asimetría está bien

El enrutamiento asimétrico es normal en muchas redes y no está roto por definición. Se convierte en problema cuando el seguimiento de estado, la traducción o la política dependen de ver un camino que no ven, y cada uno de esos tiene un remedio distinto. Compruebe qué requiere realmente el dispositivo intermedio antes de rediseñar alrededor de él.

La respuesta duradera nombra los dos caminos, el dispositivo que necesita ver ambos y la ruta que lo hace posible. Si no puede nombrar el dispositivo, todavía no ha encontrado la causa.