Cómo distinguir las rutas insertadas por la VPN de las estáticas en Linux

Un prefijo aparece en el portátil cuando el túnel se levanta, así que parece que lo instaló la VPN. Puede que sí, pero el mismo resultado puede venir de un script de cliente que se ejecuta al conectar, de un perfil de conexión que enumera la subred o de una ruta estática que estuvo ahí todo el tiempo y solo empezó a funcionar cuando existió la interfaz. Elegir al propietario equivocado significa que la ruta vuelve tras cada limpieza, y la siguiente persona repite la misma corrección. La secuencia siguiente separa los tres antes de cambiar nada.

Paso 1: nombre el mecanismo que instala prefijos

Distintos protocolos suministran accesibilidad de distintas maneras, y llamar a todo eso anuncio oculta la distinción. Un servidor OpenVPN empuja una directiva de ruta por el canal de control y el cliente la instala salvo que un filtro pull la bloquee. Una configuración de WireGuard enumera localmente los prefijos permitidos, que el cliente usa tanto para el enrutamiento de claves criptográficas como para las rutas que añade. Un túnel IPsec acuerda selectores de tráfico con el par, y el núcleo instala rutas a partir de esos selectores.

Identifique cuál de esos usa su túnel antes de leer cualquier tabla. Una ruta empujada al conectar no es un anuncio de un protocolo de enrutamiento y no promete que el prefijo sea accesible detrás del extremo remoto. Anote el mecanismo junto al prefijo, porque decide dónde corresponde la corrección.

Paso 2: compare la tabla a lo largo de una conexión

Guarde la tabla principal con el túnel bajado, súbalo, guárdela otra vez y compare las dos capturas. Todo lo que apareció pertenece al ciclo de vida de la conexión, y todo lo que se quedó pertenece a la configuración local.

Captúrela con ip route show table main > /tmp/route-down.txt, conéctese y capture de nuevo. Haga lo mismo con ip -6 route si el sitio usa IPv6, porque un prefijo ausente ahí produce fallos que parecen no tener relación con el enrutamiento.

Paso 3: lea la métrica, no solo la presencia

Dos entradas para el mismo prefijo pueden coexistir, y el núcleo elige la métrica más baja. Una ruta estática con métrica 50 seguirá ganando a una ruta empujada con 100 aunque ambas sean visibles, por eso «la ruta está ahí» y «el tráfico la usa» son afirmaciones distintas.

Pregunte al núcleo directamente con ip route get 10.20.5.7 y lea la interfaz que informa. Si el tráfico sale por el adaptador físico mientras una ruta del túnel está en la tabla, lo explica la métrica o la longitud del prefijo, no el cliente VPN. Repita la consulta para un host que sabe que está detrás del túnel y para uno que sabe que no, y la diferencia muestra si la división se comporta como se pretende.

Paso 4: encuentre las entradas que sobreviven al túnel

Las rutas estáticas sobreviven a una desconexión por diseño, y de ahí vienen las entradas obsoletas. Una ruta persistente que apunta a una interfaz que ya no existe puede tragarse una subred en silencio, y una que apunta a un nombre de interfaz reutilizado puede enviar tráfico privado por la puerta equivocada tras un reinicio.

Revise el lado persistente en el lugar que usa su distribución, ya sea una unidad de systemd-networkd, un perfil de NetworkManager o un script en el directorio up del cliente. Corregir la tabla viva con ip route del solo aguanta hasta la próxima conexión. Trate ese borrado como una prueba de la hipótesis y no como la reparación.

Donde el extremo remoto suministra la cobertura equivocada, plantéelo al operador en lugar de filtrarlo todo. Descartar todos los ajustes empujados también descarta el DNS y la política de túnel dividido de los que depende el perfil.

Paso 5: confirme el camino de vuelta antes de culpar al cliente

Para un sitio a sitio o una subred detrás del túnel, el lado remoto necesita una ruta de vuelta a la dirección de su cliente y el reenvío activado en la puerta de enlace. Un camino de ida parece exactamente un fallo de enrutamiento del cliente, salvo que el handshake y el paquete saliente tienen éxito ambos.

El filtrado de ruta inversa añade una segunda trampa en las puertas de enlace Linux. Una respuesta que llega por una interfaz distinta de la que la ruta predice es descartada por el modo estricto, y las rutas asimétricas por dos proveedores lo desencadenan de forma fiable. Los contadores de descarte en la puerta de enlace, no en el cliente, le dicen si el filtrado es la causa.

Paso 6: pruebe el recurso, no el ping

Una vez que la ruta elegida es correcta, abra el recurso real y confirme el tráfico de vuelta. Una respuesta de ping demuestra el camino en una dirección y nada sobre el servicio, y un servicio que responde en una conexión en caché demuestra aún menos.

Después repita toda la comprobación tras reconectar. El valor de la secuencia es que predice qué hará la próxima conexión, por eso tanto la comparación como la métrica pertenecen al ticket.