SSH cae na VPN cada minuto? Non é o keepalive

SSH conecta, funciona aproximadamente un minuto e despois conxélase no mesmo intervalo aproximado cada vez. A explicación habitual é un tempo de espera por inactividade, así que a xente baixa a MTU e configura keepalives no cliente. A ligazón WireGuard na que traballei xa pasara por todo iso: unha MTU de túnel máis pequena, axustes de client-alive e un keepalive de túnel configurado. As caídas continuaban sen cambios. A causa resultou ser unha ruta LAN asimétrica, e paga a pena recoñecer o patrón porque derrota calquera arranxo baseado en temporizadores.

Un keepalive demostra que o teu host segue disposto a enviar. Non pode facer que un dispositivo con estado vexa unha resposta que nunca o atravesa.

O mito: os keepalives arranxan unha caída silenciosa

Os keepalives de SSH existen para unha soa tarefa: evitar que algo que conta o silencio desbote unha sesión inactiva. Iso fan o ben. Non resolven o caso dun dispositivo con estado que viu o primeiro paquete nunha dirección e logo nunca viu a resposta, porque nada do que envía o cliente cambia que interface usa a resposta.

Cambiar a MTU é o outro arranxo popular, e ten o mesmo modo de fallo. Reducir a MTU axuda coa fragmentación e os problemas de MTU de ruta, e non fai nada por unha ruta. Se os teus temporizadores e a MTU xa son razoables e a caída segue nun intervalo repetible, o intervalo fálache dun tempo de espera nalgún sitio, non do tamaño dos paquetes. Anota o intervalo e compárao cos tempos de espera de estado de cada dispositivo da ruta.

A pista é a regularidade combinada cunha sesión que segue sendo utilizábel dentro dese intervalo. Os tempos de espera por inactividade golpean cando non pasa nada; este golpea mentres escribes.

Que fai realmente a devasa adicional

Pon o portátil e a pasarela VPN na mesma LAN, cunha devasa LAN separada como pasarela predeterminada. O portátil envía o tráfico dirixido á VPN á devasa, a devasa reenvíao á pasarela, e as respostas da pasarela volven directamente pola LAN ao portátil. Ese segundo tramo nunca pasa pola devasa, así que a súa táboa de estado mantén media conexión.

Os enderezos de abaixo reflicten 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

As redireccións e o manexo de estado converten entón un handshake funcional nunha conexión que morre máis tarde en lugar de inmediatamente. O atraso é a entrada de estado que caduca ou unha comprobación máis estrita que falla, e por iso o intervalo parece tan mecánico.

Nada disto aparece na configuración do cliente, e por iso a súa busca adoita comezar no ficheiro equivocado.

Escolle un camiño deliberado

Para a disposición de arriba, encamiñar a subrede remota directamente á pasarela VPN elimina a 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 enderezos de exemplo. O seguinte salto ten que ser alcanzable na túa LAN, o prefixo ten que ser a rede remota prevista, e o segundo comando amósache o resultado antes de que confíes nel. Se a pasarela non está na túa subrede, esta ruta non é o arranxo que queres.

Se a devasa debe vixiar o tráfico entre eses sistemas, encamiñar por fóra é un deseño equivocado. Fai que ambas as direccións crucen a fronteira e configura as rutas a cada lado para que o camiño de volta coincida. O obxectivo é un único camiño deliberado, non menos comprobación de estado.

As notas sobre encamiñamento asimétrico de Netgate describen a mesma asimetría a nivel de interface e os problemas de estado que crea, así que leas antes de afrouxar o manexo de estado globalmente. As desconexións temporizadas semellantes a este caso non son proba por si soas. Trata o artigo como a descrición dun modo de fallo e logo demostra que a túa propia rede encaixa con el antes de cambiar a política global de estado.

Proba desde ambos os extremos

Le a ruta do portátil cara ao destino e a ruta do destino de volta cara ao portátil; son dúas decisións separadas e probablemente só unha delas é incorrecta. Un ping que ten éxito desde a propia pasarela pode ocultar o problema por completo, porque se orixina na máquina cuxo camiño xa é correcto. Necesitas ambas as direccións tal como as ven os dous extremos da sesión real.

Despois do arranxo, volve abrir SSH e mantén a sesión aberta moito máis alá do intervalo que antes fallaba. Logo fai a ruta persistente na configuración de rede aprobada, porque un comando puntual non é un plan de reinicio e o problema volverá no próximo reinicio cun novo misterio.

Cando a asimetría está ben

O encamiñamento asimétrico é normal en moitas redes e non está roto por definición. Convértese nun problema cando o seguimento de estado, a tradución ou a política dependen de ver un camiño que non ven, e cada un deses ten un remedio distinto. Comproba que require realmente o dispositivo intermedio antes de redeseñar ao seu redor.

A resposta duradeira nomea os dous camiños, o dispositivo que necesita ver ambos e a ruta que o fai posible. Se non podes nomear o dispositivo, aínda non atopaches a causa.