¿Oculta una caché de rutas VPN tu cambio? Comprueba tres cosas

Vaciar la caché de rutas es el primer instinto cuando un cambio no surte efecto, y en Linux moderno es un esfuerzo inútil: la caché global de rutas IPv4 se eliminó hace años, así que ip route show cache no imprime nada y no hay nada que borrar. El estado que te engaña vive una capa más arriba: en un socket, una asignación NAT, un resolutor o un gestor de red que ha vuelto a aplicar el perfil antiguo. Tres preguntas separan esos casos: si el camino equivocado viene de un flujo nuevo o de una conexión antigua, si tu plataforma guarda rutas en caché o no, y si el estado está en el enrutamiento o por encima. Respóndelas antes de reiniciar una interfaz.

Comprobación uno: ¿el camino antiguo viene de un flujo nuevo?

Una conexión establecida conserva la ruta con la que se creó. Por eso una sesión SSH por el túnel sobrevive a un cambio de la tabla de enrutamiento mientras una sesión nueva toma de inmediato el camino nuevo, y por eso «el cambio no hizo nada» a menudo significa «el socket antiguo todavía lo retiene». Prueba con un proceso nuevo, no con la ventana que ya tienes abierta.

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

El último comando imprime la dirección a la que llegó realmente la conexión nueva, que es la forma más barata de ver el camino real sin fiarse de una ventana de estado. Compárala con la dirección de origen que el espacio de nombres o la interfaz debían usar.

Si un flujo nuevo toma el camino correcto y el antiguo no se recupera, deja de mirar el enrutamiento. La ruta era correcta; la sesión era antigua.

Comprobación dos: ¿tu plataforma guarda siquiera una caché de rutas?

En Linux la respuesta es no, en el sentido que quieren decir la mayoría de las guías. No hay una caché global de destinos que descartar, y la entrada por socket que guarda una ruta elegida se libera con el socket. La sección de caché del manual de ip-route describe un comportamiento histórico, no algo que puedas vaciar en un núcleo actual.

Otras plataformas son distintas, y aquí es donde falla copiar consejos. Windows guarda una caché de destinos que puedes limpiar con netsh interface ip delete destinationcache. BSD y macOS exponen búsquedas por destino mediante route -n get, y sus cachés caducan según su propio calendario. Un comando que funciona en una de ellas no hace absolutamente nada en Linux, y por eso el mismo arreglo parece fallar a la mitad de quienes lo prueban.

Una tabla NAT o conntrack no es una caché de rutas, aunque produce el mismo síntoma. Un flujo traducido antes de tu cambio conserva su traducción, y conntrack -L lo mostrará mucho después de que la política de enrutamiento haya avanzado. Eso es estado obsoleto, pero borrar rutas no lo tocará.

Comprobación tres: ¿el estado está en el enrutamiento o por encima?

Lee la consulta actual antes de leer cualquier otra cosa: ip route get para el destino, luego el mismo comando con from y la dirección de origen, luego ip rule show. Si esas tres coinciden con lo que pretendías, el enrutamiento no es la capa que hay que arreglar, y la observación obsoleta vino de otro sitio.

Tres sospechosos habituales se sientan por encima del enrutamiento. Un gestor de red puede reinstalar una ruta desde un perfil guardado segundos después de que la borres, así que tu cambio parece revertirse; comprueba nmcli connection show --active y el estado de la unidad antes de volver a editar la tabla. La caché de un resolutor devuelve una dirección antigua, lo que parece un fallo de enrutamiento hasta que consultas el mismo nombre con una herramienta que rompe la caché. El conjunto de conexiones de una aplicación mantiene un socket funcional hacia el destino antiguo y nunca pide al núcleo una decisión nueva.

Qué te permiten concluir las tres respuestas

Junta las respuestas y la reparación suele enunciarse sola. Un flujo nuevo que toma el camino equivocado en una plataforma sin caché de rutas significa que la política es realmente incorrecta, así que lee las reglas y la tabla que instaló el túnel. Un flujo nuevo que toma el camino correcto mientras la sesión antigua se atasca significa que el problema es la aplicación o el socket. Rutas correctas con una observación rota en ambos casos significa que el estado está por encima del enrutamiento.

Resiste la actualización genérica. Reiniciar la pila de red o borrar todas las rutas en una máquina cuya ruta predeterminada es el túnel puede cortar justo la conexión que usas para arreglarlo, y destruye la evidencia que te habría dicho qué capa falló.

Si de verdad tienes que limpiar algo, limpia lo más pequeño que encaje con el diagnóstico: los sockets de un proceso, una entrada de conntrack, la caché del resolutor. Luego repite la misma prueba de flujo nuevo y anota qué cambió.

Mantén los tres estados separados en tus notas

La configuración guardada, la consulta actual y el flujo observado son tres hechos distintos, y fundirlos en «la caché» es lo que hace difícil reproducir el fallo. Apunta el perfil o la unidad que posee la ruta, la salida de ip route get y el origen y el destino de la conexión real.

Anota al lado la plataforma y la versión del cliente, porque un remedio que limpia una caché de destinos de Windows no es un remedio aplicable a un anfitrión Linux, y un procedimiento copiado entre ambos enseña la lección equivocada. Cuando entregues el problema a otra persona, esas tres líneas le permitirán reproducir el estado fallido en lugar de adivinarlo.