Vai iniciar um cliente VPN por SSH? Fixe primeiro a sua própria rota

Você entra por SSH num host de compilação, inicia ali o cliente VPN, e a sessão deixa de responder. Nada falhou, e nada parece mal configurado no sentido óbvio. O cliente instalou uma rota padrão, então as respostas para a sua estação de trabalho agora saem pelo túnel, onde o endereço da sua estação de trabalho não é roteável. A parte interessante é que esse resultado era previsível, e a correção é uma rota escrita antes de o cliente arrancar. Suponha um servidor com uma única placa de rede, um gateway 192.0.2.254 e um administrador que se liga a partir de 203.0.113.9.

Registe o caminho antes de começar

ip route show default nomeia o gateway e a interface atuais, enquanto ip route get 203.0.113.9 mostra que interface e que endereço de origem o núcleo usaria para a sua sessão. Guarde as duas saídas. Depois de o túnel subir, esses dois comandos devem continuar a descrever o caminho físico, e se descreverem o túnel, a sessão já vive de tempo emprestado.

A ligação já estabelecida é a que importa, por isso não valide apenas com um novo início de sessão. Uma nova sessão pode ter êxito brevemente graças a um estado que a antiga já não tem.

Fixe o endereço na própria configuração do cliente

Uma rota adicionada à mão desaparece ao reiniciar e compete com as atualizações da tabela do próprio cliente, por isso coloque a exceção onde a tabela é gerida. No OpenVPN a palavra-chave net_gateway resolve-se para o gateway que existia antes do túnel, então route 203.0.113.9 255.255.255.255 net_gateway mantém exatamente um endereço fora dele. O WireGuard precisa de outra abordagem porque o wg-quick gere as rotas sozinho: defina Table = off e acrescente a exceção em PostUp, com um PostDown correspondente que a remove. As duas formas exprimem a mesma intenção, e ambas limitam a exceção a um endereço em vez de enfraquecer o túnel para tudo.

Para IPv6 a mesma ideia toma um prefixo de um único host, e o caso do transporte encapsulado merece ser lembrado: se a ligação exterior do próprio túnel viver num endereço fixo, esse endereço tem de ficar fora do túnel que transporta, ou o cliente encaminha o seu próprio transporte para dentro de si.

Ou tire a tabela principal da equação

Quando vários serviços no host têm de manter o seu caminho normal, pare de editar a tabela principal e dê ao cliente a sua. Um espaço de nomes de rede com um par veth faz isso de forma limpa: a rota padrão do cliente vive noutra pilha e só os processos iniciados lá dentro usam o túnel. O encaminhamento por políticas chega a um lugar semelhante para um destino, enviando o tráfego correspondente para uma tabela dedicada cuja rota padrão continua a apontar para o gateway físico. Qualquer das abordagens deixa a tabela principal do host sem uma nova rota padrão, e é essa propriedade que mantém o SSH a responder.

Ambas são mais maquinaria do que uma única rota de host, e ambas valem a pena quando mais do que uma coisa na máquina tem de sobreviver ao túnel.

Assuma que a fixação pode falhar

Uma rota ligada ao seu endereço público atual quebra no momento em que o seu fornecedor o reatribui. Um servidor remoto precisa então de um caminho que não dependa desse endereço: uma consola, uma segunda interface de gestão ou um host de salto que fique fora do túnel.

Duas salvaguardas custam dez minutos. Um vigilante que para o cliente se um início de sessão de confirmação não aparecer em alguns minutos transforma um bloqueio num atraso, e uma segunda sessão SSH mantida aberta durante a mudança prova que a exceção funciona enquanto o túnel está de pé. Os keepalives sozinhos não ajudam aqui, porque o caminho desapareceu em vez de estar inativo; apenas tornam a morte mais fácil de notar.

Verifique na ordem que importa

Ligue o túnel, confirme que a rota para o seu endereço continua a sair pelo gateway físico e depois abra uma nova sessão. Se a nova sessão funcionar e a antiga morrer mesmo assim, a causa é o seguimento de ligações ou um firewall com estado e não o encaminhamento, o que é uma correção diferente.

Escreva o endereço fixado e o comando que o provou no registo de alterações. A próxima pessoa que iniciar um cliente nesse host precisará dos dois, e o endereço pode já ter mudado até lá.