Por que uma rota de host /32 mantém o endpoint da VPN alcançável

Uma rota de host escolhe um endereço, não uma sub-rede. Ela pode manter um endpoint de túnel alcançável ou fixar um recurso, mas fica obsoleta quando os endereços mudam.

Você abre a tabela de rotas após conectar e encontra um único endereço roteado pelo túnel enquanto a sub-rede ao redor continua indo para o gateway local. Essa entrada é uma rota de host: um endereço, casado por um prefixo de todos uns. Isso importa porque as decisões de roteamento usam o prefixo correspondente mais longo, então uma /32 pode sobrepor uma /24 ou uma rota padrão sem alterar nenhuma das duas. Se isso é uma exceção cuidadosa ou uma indisponibilidade futura depende de qual endereço ela nomeia e de quem a mantém.

Um endereço, uma entrada na tabela

Uma rota de host IPv4 carrega um prefixo /32 e uma rota de host IPv6 carrega /128, o que significa que a entrada pode casar exatamente com um endereço de destino. Nada mais na tabela se move: a sub-rede que a cobre e a rota padrão ficam onde estavam. A entrada estreita ganha para esse endereço porque seu prefixo é mais longo, não porque foi adicionada depois.

Essa propriedade faz de uma rota de host uma boa exceção e um mau hábito. Duas entradas /32 que nomeiam a porta de entrada de um serviço não cobrem seu segundo endereço, seu endereço IPv6 nem o endereço para o qual ele se muda no mês que vem. Uma tabela cheia de entradas de endereço único sem explicação geralmente significa que alguém continuou remendando em torno de uma decisão de sub-rede em vez de tomá-la. Leia primeiro o comprimento do prefixo e depois pergunte o que a entrada deve proteger.

Leia a entrada do cliente para fora

Comece pela máquina com o problema, porque o mesmo endereço pode ser roteado de forma diferente em um notebook e no gateway à frente dele. Pergunte ao kernel qual caminho ele escolheria para o endereço exato que a aplicação usa, em vez de ler a tabela de cima. A resposta inclui a interface e o próximo salto, que juntos são a decisão.

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

Repita a consulta para a família de endereços que a aplicação realmente escolhe, já que um cliente pode preferir IPv6 e ignorar silenciosamente uma exceção IPv4. Compare o resultado antes e depois de o túnel subir, e guarde ambas as saídas. Essa comparação mostra se o cliente adicionou a entrada ao conectar ou se ela já estava lá.

Uma entrada persistente e uma entrada de execução falham de forma diferente. A de execução desaparece com a sessão, enquanto a persistente sobrevive a uma reinicialização e continua enviando tráfego para um gateway que não existe mais.

A exceção do endpoint e a armadilha da recursão

Clientes de VPN costumam instalar uma rota de host para o endereço externo do servidor pelo gateway original antes de redirecionar a rota padrão. Sem essa entrada, os pacotes criptografados seriam enviados para dentro do túnel que estão tentando construir, e a conexão entraria em loop até expirar.

A armadilha aparece quando as sub-redes aceitas do túnel incluem por acaso esse endereço do endpoint, ou quando um segundo perfil adiciona depois uma rota mais ampla. A entrada do endpoint então perde para um prefixo mais longo e a sessão desmorona assim que começa a passar tráfego. Escrever o endereço do endpoint ao lado das sub-redes aceitas é a forma mais barata de notar a colisão antes dos usuários. Também explica por que o mesmo perfil funciona a partir de uma rede e falha a partir de outra.

Verifique o caminho que a aplicação realmente usa

Um ping bem-sucedido ao nome do host é evidência fraca quando a aplicação se conecta a outro endereço ou a outra família. Verifique a combinação exata de endereço, família, porta e interface, na máquina que executa o cliente.

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

Se o caminho estiver errado, decida se o requisito é uma rede ou um endereço antes de editar qualquer coisa. Um requisito de endereço único justifica uma rota de host com um comentário e um responsável; um serviço com endereços rotativos precisa de roteamento baseado em domínio ou de uma decisão honesta de sub-rede.

Remova as entradas que não correspondem mais a um destino real e anote as que você mantém. Uma /32 sem explicação é indistinguível de um bug três meses depois, e a próxima pessoa a apagará sem saber do que ela dependia.

Artigos relacionados