SSH cai na VPN a cada minuto? Não é o keepalive

O SSH conecta, funciona cerca de um minuto e depois congela no mesmo intervalo aproximado todas as vezes. A explicação comum é um timeout de inatividade, então as pessoas baixam a MTU e configuram keepalives no cliente. O link WireGuard em que trabalhei já tinha passado por tudo isso: uma MTU de túnel menor, ajustes de client-alive e um keepalive de túnel configurado. As quedas continuavam iguais. A causa acabou sendo uma rota LAN assimétrica, e vale reconhecer o padrão porque ele derrota qualquer correção baseada em temporizadores.

Um keepalive prova que o seu host ainda está disposto a enviar. Ele não consegue fazer um dispositivo com estado ver uma resposta que nunca o atravessa.

O mito: keepalives corrigem uma queda silenciosa

Os keepalives do SSH existem para uma única tarefa: impedir que algo que conta o silêncio descarte uma sessão inativa. Isso eles fazem bem. Eles não resolvem o caso de um dispositivo com estado que viu o primeiro pacote numa direção e depois nunca viu a resposta, porque nada do que o cliente envia muda qual interface a resposta usa.

Mudar a MTU é a outra correção popular, e tem o mesmo modo de falha. Reduzir a MTU ajuda com fragmentação e problemas de MTU de caminho, e não faz nada a uma rota. Se os seus temporizadores e a MTU já são razoáveis e a queda continua num intervalo repetível, o intervalo está falando de um timeout em algum lugar, não do tamanho dos pacotes. Anote o intervalo e compare-o com os timeouts de estado em cada dispositivo do caminho.

A pista é a regularidade combinada com uma sessão que continua utilizável dentro desse intervalo. Timeouts de inatividade atacam quando nada acontece; este ataca enquanto você digita.

O que o gateway extra realmente faz

Coloque o portátil e o gateway VPN na mesma LAN, com um firewall LAN separado como gateway padrão. O portátil envia o tráfego destinado à VPN ao firewall, o firewall encaminha-o ao gateway, e as respostas do gateway voltam direto pela LAN ao portátil. Esse segundo trecho nunca passa pelo firewall, então a sua tabela de estado mantém meia conexão.

Os endereços abaixo refletem essa disposição:

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

Redirecionamentos e tratamento de estado transformam então um handshake funcional numa conexão que morre mais tarde em vez de imediatamente. O atraso é a entrada de estado a expirar ou uma verificação mais rígida a falhar, e é por isso que o intervalo parece tão mecânico.

Nada disso aparece na configuração do cliente, e é por isso que a busca por ele costuma começar no ficheiro errado.

Escolha um caminho deliberado

Para a disposição acima, encaminhar a sub-rede remota diretamente para o gateway VPN elimina a meia conexão:

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

São endereços de exemplo. O próximo salto tem de ser alcançável na sua LAN, o prefixo tem de ser a rede remota pretendida, e o segundo comando mostra-lhe o resultado antes de confiar nele. Se o gateway não está na sua sub-rede, esta rota não é a correção que você quer.

Se o firewall deve vigiar o tráfego entre esses sistemas, encaminhar por fora é o desenho errado. Faça as duas direções atravessarem a fronteira e configure as rotas de cada lado para que o caminho de volta coincida. O objetivo é um único caminho deliberado, não menos verificação de estado.

As notas sobre encaminhamento assimétrico da Netgate descrevem a mesma assimetria ao nível da interface e os problemas de estado que ela cria, por isso leia-as antes de afrouxar o tratamento de estado globalmente. Desconexões temporizadas semelhantes a este caso não são prova por si só. Trate o artigo como a descrição de um modo de falha e depois prove que a sua própria rede se encaixa nele antes de mudar a política global de estado.

Teste pelas duas pontas

Leia a rota do portátil até ao destino e a rota do destino de volta até ao portátil; são duas decisões separadas e provavelmente apenas uma delas está errada. Um ping que tem sucesso a partir do próprio gateway pode esconder o problema por completo, porque nasce na máquina cujo caminho já está correto. Precisa das duas direções como as veem as duas pontas da sessão real.

Depois da correção, reabra o SSH e mantenha a sessão aberta muito além do intervalo que falhava. Depois torne a rota persistente na configuração de rede aprovada, porque um comando pontual não é um plano de reinício e o problema voltará no próximo reinício com um mistério novo.

Quando a assimetria está bem

O encaminhamento assimétrico é normal em muitas redes e não está quebrado por definição. Torna-se um problema quando o rastreio de estado, a tradução ou a política dependem de ver um caminho que não veem, e cada um deles tem um remédio diferente. Verifique o que o dispositivo intermédio exige realmente antes de redesenhar em torno dele.

A resposta duradoura nomeia os dois caminhos, o dispositivo que precisa de ver ambos e a rota que torna isso possível. Se não consegue nomear o dispositivo, ainda não encontrou a causa.