Oculta unha caché de rutas VPN o teu cambio? Comproba tres cousas

Baleirar a caché de rutas é o primeiro instinto cando un cambio non surte efecto, e en Linux moderno é un esforzo inútil: a caché global de rutas IPv4 se eliminou hai anos, así que ip route show cache non imprime nada e non hai nada que borrar. O estado que te engana vive unha capa máis arriba: nun socket, unha asignación NAT, un resolvedor ou un xestor de rede que volveu aplicar o perfil antigo. Tres preguntas separan eses casos: se o camiño equivocado vén dun fluxo novo ou dunha conexión antiga, se a túa plataforma garda rutas en caché ou non, e se o estado está no encamiñamento ou por riba. Responde a elas antes de reiniciar unha interface.

Comprobación un: o camiño antigo vén dun fluxo novo?

Unha conexión establecida conserva a ruta coa que se creou. Por iso unha sesión SSH polo túnel sobrevive a un cambio da táboa de encamiñamento mentres unha sesión nova toma de inmediato o camiño novo, e por iso «o cambio non fixo nada» a miúdo significa «o socket antigo aínda o retén». Proba cun proceso novo, non coa xanela que xa tes 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 enderezo ao que chegou realmente a conexión nova, que é a forma máis barata de ver o camiño real sen confiar nunha xanela de estado. Compárao co enderezo de orixe que o espazo de nomes ou a interface debían usar.

Se un fluxo novo toma o camiño correcto e o antigo non se recupera, deixa de mirar o encamiñamento. A ruta era correcta; a sesión era antiga.

Comprobación dous: a túa plataforma garda sequera unha caché de rutas?

En Linux a resposta é non, no sentido que queren dicir a maioría das guías. Non hai unha caché global de destinos que descartar, e a entrada por socket que garda unha ruta escollida libérase co socket. A sección de caché do manual de ip-route describe un comportamento histórico, non algo que poidas baleirar nun núcleo actual.

Outras plataformas son distintas, e aquí é onde falla copiar consellos. Windows garda unha caché de destinos que podes limpar con netsh interface ip delete destinationcache. BSD e macOS expoñen procuras por destino mediante route -n get, e as súas cachés caducan segundo o seu propio calendario. Un comando que funciona nunha delas non fai absolutamente nada en Linux, e por iso o mesmo arranxo parece fallar á metade de quen o proba.

Unha táboa NAT ou conntrack non é unha caché de rutas, aínda que produce o mesmo síntoma. Un fluxo traducido antes do teu cambio conserva a súa tradución, e conntrack -L mostrarao moito despois de que a política de encamiñamento avanzase. Eso é estado obsoleto, pero borrar rutas non o tocará.

Comprobación tres: o estado está no encamiñamento ou por riba?

Le a consulta actual antes de ler calquera outra cousa: ip route get para o destino, despois o mesmo comando con from e o enderezo de orixe, despois ip rule show. Se esas tres coinciden co que pretendías, o encamiñamento non é a capa que hai que arranxar, e a observación obsoleta veu doutro sitio.

Tres sospeitosos habituais sentan por riba do encamiñamento. Un xestor de rede pode reinstalar unha ruta desde un perfil gardado segundos despois de que a borres, así que o teu cambio parece reverter; comproba nmcli connection show --active e o estado da unidade antes de volver editar a táboa. A caché dun resolvedor devolve un enderezo antigo, o que parece un fallo de encamiñamento ata que consultas o mesmo nome cunha ferramenta que rompe a caché. O conxunto de conexións dunha aplicación mantén un socket funcional cara ao destino antigo e nunca lle pide ao núcleo unha decisión nova.

Que che permiten concluír as tres respostas

Xunta as respostas e a reparación adoita enunciarse soa. Un fluxo novo que toma o camiño equivocado nunha plataforma sen caché de rutas significa que a política é realmente incorrecta, así que le as regras e a táboa que instalou o túnel. Un fluxo novo que toma o camiño correcto mentres a sesión antiga se atasca significa que o problema é a aplicación ou o socket. Rutas correctas cunha observación rota en ambos os casos significa que o estado está por riba do encamiñamento.

Resiste a actualización xenérica. Reiniciar a pila de rede ou borrar todas as rutas nunha máquina cuxa ruta predeterminada é o túnel pode cortar xusto a conexión que usas para arranxalo, e destrúe a evidencia que che tería dito que capa fallou.

Se de verdade tes que limpar algo, limpa o máis pequeno que encaixe co diagnóstico: os sockets dun proceso, unha entrada de conntrack, a caché do resolvedor. Logo repite a mesma proba de fluxo novo e anota que cambiou.

Mantén os tres estados separados nas túas notas

A configuración gardada, a consulta actual e o fluxo observado son tres feitos distintos, e fundilos en «a caché» é o que fai difícil reproducir o fallo. Apunta o perfil ou a unidade que posúe a ruta, a saída de ip route get e a orixe e o destino da conexión real.

Anota ao lado a plataforma e a versión do cliente, porque un remedio que limpa unha caché de destinos de Windows non é un remedio aplicable a un anfitrión Linux, e un procedemento copiado entre ambos ensina a lección equivocada. Cando lle entregues o problema a outra persoa, esas tres liñas permitiranlle reproducir o estado fallido en lugar de adiviñalo.