Um cache de rotas VPN está a esconder a sua alteração? Verifique três coisas

Esvaziar o cache de rotas é o primeiro instinto quando uma alteração não produz efeito, e no Linux moderno é esforço desperdiçado: o cache global de rotas IPv4 foi removido há anos, por isso ip route show cache não imprime nada e não há nada para limpar. O estado que o engana vive uma camada acima: num socket, num mapeamento NAT, num resolvedor ou num gestor de rede que reaplicou o perfil antigo. Três perguntas separam esses casos: se o caminho errado vem de um fluxo novo ou de uma ligação antiga, se a sua plataforma guarda rotas em cache, e se o estado está no encaminhamento ou acima dele. Responda-lhes antes de reiniciar uma interface.

Verificação um: o caminho antigo vem de um fluxo novo?

Uma ligação estabelecida mantém a rota com que foi criada. É por isso que uma sessão SSH pelo túnel sobrevive a uma alteração da tabela de encaminhamento enquanto uma sessão nova toma logo o caminho novo, e é por isso que «a alteração não fez nada» significa muitas vezes «o socket antigo ainda a segura». Teste com um processo novo, não com a janela que já tem aberta.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

O último comando imprime o endereço que a nova ligação realmente alcançou, e é a forma mais barata de ver o caminho real sem confiar numa janela de estado. Compare-o com o endereço de origem que o espaço de nomes ou a interface deviam usar.

Se um fluxo novo toma o caminho correto e o antigo não recupera, deixe de olhar para o encaminhamento. A rota estava certa; a sessão era antiga.

Verificação dois: a sua plataforma chega a guardar um cache de rotas?

No Linux a resposta é não, no sentido que a maioria dos guias quer dizer. Não há um cache global de destinos para descartar, e a entrada por socket que guarda uma rota escolhida é libertada com o socket. A secção de cache do manual do ip-route descreve um comportamento histórico, não algo que possa esvaziar num kernel atual.

Outras plataformas são diferentes, e é aqui que copiar conselhos corre mal. O Windows guarda um cache de destinos que pode limpar com netsh interface ip delete destinationcache. BSD e macOS expõem pesquisas por destino através de route -n get, e os seus caches expiram segundo o próprio calendário. Um comando que funciona numa delas não faz absolutamente nada no Linux, e é por isso que a mesma correção parece falhar para metade das pessoas que a experimentam.

Uma tabela NAT ou conntrack não é um cache de rotas, embora produza o mesmo sintoma. Um fluxo traduzido antes da sua alteração mantém a sua tradução, e conntrack -L mostrá-lo-á muito depois de a política de encaminhamento ter avançado. Isso é estado desatualizado, mas limpar rotas não lhe tocará.

Verificação três: o estado está no encaminhamento ou acima dele?

Leia a pesquisa atual antes de ler qualquer outra coisa: ip route get para o destino, depois o mesmo comando com from e o endereço de origem, depois ip rule show. Se esses três concordarem com o que pretendia, o encaminhamento não é a camada a corrigir, e a observação desatualizada veio de outro sítio.

Três suspeitos habituais sentam-se acima do encaminhamento. Um gestor de rede pode reinstalar uma rota a partir de um perfil guardado segundos depois de a apagar, por isso a sua alteração parece reverter; verifique nmcli connection show --active e o estado da unidade antes de editar a tabela outra vez. O cache de um resolvedor devolve um endereço antigo, o que parece uma falha de encaminhamento até consultar o mesmo nome com uma ferramenta que contorna o cache. O conjunto de ligações de uma aplicação mantém um socket funcional para o destino antigo e nunca pede ao kernel uma decisão nova.

O que as três respostas lhe permitem concluir

Junte as respostas e a reparação costuma enunciar-se sozinha. Um fluxo novo que toma o caminho errado numa plataforma sem cache de rotas significa que a política está realmente errada, por isso leia as regras e a tabela que o túnel instalou. Um fluxo novo que toma o caminho certo enquanto a sessão antiga encrava significa que o problema é a aplicação ou o socket. Rotas corretas com uma observação quebrada nos dois casos significa que o estado está acima do encaminhamento.

Resista à atualização genérica. Reiniciar a pilha de rede ou apagar todas as rotas numa máquina cuja rota predefinida é o túnel pode cortar precisamente a ligação que está a usar para a reparar, e destrói a evidência que lhe teria dito que camada falhou.

Se tiver mesmo de limpar algo, limpe a coisa mais pequena que corresponda ao diagnóstico: os sockets de um processo, uma entrada de conntrack, o cache do resolvedor. Depois repita o mesmo teste de fluxo novo e anote o que mudou.

Mantenha os três estados separados nas suas notas

Configuração guardada, pesquisa atual e fluxo observado são três factos diferentes, e juntá-los em «o cache» é o que torna a falha difícil de reproduzir. Anote o perfil ou a unidade que detém a rota, a saída de ip route get, e a origem e o destino da ligação real.

Anote ao lado a plataforma e a versão do cliente, porque uma correção que limpa um cache de destinos do Windows não é uma correção aplicável a um anfitrião Linux, e um procedimento copiado entre os dois ensina a lição errada. Quando entregar o problema a outra pessoa, essas três linhas permitem-lhe reproduzir o estado falhado em vez de adivinhar.