Por qué una ruta VPN eliminada vuelve tras reconectar

Una ruta que eliminaste a mano vuelve tras la siguiente reconexión, y la tabla queda exactamente como estaba. No es un fallo de enrutamiento: algo recrea la entrada desde la configuración o desde una acción del ciclo de vida de la conexión. La mayoría de los runbooks se detienen en la tabla activa, por eso la eliminación parece funcionar un minuto y luego falla. Identifica al propietario, cámbialo y demuéstralo en una reconexión.

Quién instaló la ruta

Empieza por una lista de candidatos en lugar de por una corrección. Un perfil de VPN puede llevar sus propias rutas, un servidor puede enviarlas al conectar, un perfil del gestor de red puede declararlas, una unidad de arranque o un script puede añadirlas, y las implementaciones de IPsec instalan rutas para los selectores de tráfico que negocian. Las reglas de enrutamiento por política también pueden redirigir el tráfico por completo a otra tabla.

El momento en que aparecen las separa más rápido que la arqueología de configuración. Una entrada que aparece en el instante en que sube la interfaz pertenece al cliente; una que llega un segundo después suele venir de un push del servidor; una que existe al arrancar pertenece a la configuración guardada. Registra la tabla antes y después de una conexión, una desconexión y un reinicio, y el patrón nombrará al propietario. Una ruta que solo vuelve cuando se reinicia el servicio apunta a una unidad y no a la VPN.

Lee la tabla antes de editarla

Mira la visión del propio núcleo en lugar de un archivo guardado. La columna de protocolo muestra qué instaló cada entrada:

ip route show
ip route show table all
ip rule show

El campo de protocolo, la métrica y el número de tabla te dicen si estás viendo una entrada estática, una creada por el núcleo o algo que añadió un demonio. La lista de reglas importa porque una búsqueda puede abandonar la tabla principal por completo, lo que hace que una edición allí sea invisible para la aplicación que estás depurando. Lee la línea de izquierda a derecha: destino, puerta de enlace, dispositivo, protocolo y métrica.

Después pregunta al núcleo qué ruta usaría realmente. Una dirección protegida es una sonda mejor que una pública:

ip route get 10.20.5.7

Cambia al propietario, no el síntoma

Una vez conocido el propietario, el cambio pertenece a ese propietario. Quita la ruta del perfil del cliente, corrige la ruta enviada en el servidor o edita la conexión del gestor de red en lugar de añadir una ruta persistente competidora que gane por métrica. Dos reglas que se pelean entre sí producen una tabla que nadie podrá explicar después.

Mantén la exclusión del extremo. Una ruta de host que envía la dirección pública propia del servidor VPN a través de la puerta de enlace física es lo que mantiene fluyendo los paquetes exteriores del túnel; si la eliminas, el túnel intenta llevarse a sí mismo. En un perfil de túnel dividido, el mismo cuidado se aplica a las subredes locales que deben evitar el túnel.

Reconecta y verifica ambos caminos

Reconecta y luego comprueba ambos destinos en una sola pasada. La dirección protegida y el extremo excluido responden a preguntas distintas:

ip route get 10.20.5.7
ip route get 198.51.100.20

La primera debería resolverse por la interfaz del túnel y la segunda por la puerta de enlace física. Si ambas se resuelven por el túnel, falta la exclusión; si ninguna lo hace, el cambio de perfil no ha surtido efecto y estás viendo a un propietario distinto del que pensabas.

Anota el propósito de la ruta, su propietario y cuánto tiempo debe vivir. Esa nota es lo que impide que la siguiente persona repita el mismo ciclo de eliminar y reconectar.