¿El cliente VPN borra la ruta que añadió? Use una tabla de políticas

Una /24 para una impresora de laboratorio desaparece entre dos llamadas a ip route show, y el registro del cliente solo dice que la red cambió. No había nada mal con el comando, el prefijo ni sus privilegios. Un cliente corporativo que posee el modelo de enrutamiento del host reafirma ese modelo cada vez que alguien más lo edita, así que la entrada que añadió se elimina como intrusa. Luchar contra él en la misma tabla es una posición perdedora. La solución es dejar de competir por esa tabla por completo y poner la excepción donde el monitor nunca mira.

El monitor explica la ruta desaparecida

Demuéstrelo antes de rediseñar nada: lea la tabla, añada el prefijo, espere unos segundos, vuelva a leer. Si la entrada no está y usted no escribió nada para quitarla, hay un agente vigilando. Encuentre el proceso que posee ese comportamiento y lea su registro alrededor del momento en que la ruta desaparece, porque el mismo servicio suele mantener el túnel, los filtros de paquetes y la configuración del resolutor. Matarlo para que su ruta se mantenga es un intercambio que lamentará en la próxima reconexión.

ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route show

El prefijo y la interfaz de arriba son marcadores de posición. Copiar un nombre de interfaz de un ejemplo que funciona en otra máquina es la razón más común de que esta demostración no produzca absolutamente nada.

Una segunda tabla es invisible para el monitor

El agente solo reconstruye la tabla que posee. Dé a la excepción una tabla propia más una regla que envíe allí los destinos coincidentes, y la tabla principal nunca cambia, así que el agente no tiene nada que corregir. Esa es toda la idea: un espacio de nombres de rutas que mantiene otra persona y otro que solo toca usted.

El intercambio es el mantenimiento. Dos objetos pueden separarse, y la posición de la regla en la lista importa tanto como la ruta dentro de la tabla que selecciona.

Construya la excepción y luego haga que gane

Cree la tabla, instale la ruta y añada una regla que seleccione la tabla para ese destino. La preferencia decide si su regla se consulta antes o después de las que insertó el cliente, y una regla que se ordena más tarde nunca se alcanza, así que el número es parte del diseño y no un adorno. Luego pregunte al núcleo qué haría realmente, que es una pregunta distinta de lo que usted configuró.

ip rule add to 192.168.2.0/24 table 110 pref 30010
ip route add 192.168.2.0/24 dev enp0s31f6 table 110
ip route get 192.168.2.50

ip route get resuelve la ruta que usaría el núcleo, incluidos el dispositivo y la dirección de origen. No imprime el identificador de la tabla, así que combínelo con ip rule show cuando necesite confirmar qué tabla ganó. Juntos responden la única pregunta que importa: ¿el tráfico hacia esa dirección sale donde usted pretendía?

Otras formas de la misma idea

El patrón se generaliza en cuanto deja de pensar en destinos. Una subred local puede seguir siendo accesible mientras el túnel conserva la ruta predeterminada. Las respuestas de un servidor SSH conectado a la LAN pueden salir por la interfaz por la que llegaron en lugar de desaparecer en el túnel. Y una regla basada en interfaz puede empujar todo lo que llega por una interfaz inalámbrica hacia el túnel mientras el tráfico que genera el propio host se queda en Ethernet:

ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10

Ese último caso coincide con la interfaz de entrada en lugar del destino, que es otro tipo de regla y otro modelo mental. El tráfico reenviado también necesita net.ipv4.ip_forward habilitado, y el extremo remoto debe enrutar de vuelta el rango de origen o traducirlo; una regla en una máquina nunca crea la otra mitad del camino.

Trate la regla como desechable

Las reglas y las rutas de tabla viven en la memoria. Tras una reconexión, el dispositivo del túnel puede cambiar de nombre, la dirección asignada puede moverse, y una regla con el valor antiguo deja de coincidir en silencio. Vuelva a aplicar todo el cambio desde un único script que lo posea, y luego vuelva a comprobar ip rule show, el nombre actual del dispositivo y un ip route get nuevo contra un destino real antes de confiar en la excepción.

Dos límites sobreviven a cualquier cuidado. El cliente sigue controlando sus propias reglas de filtrado y la configuración del resolutor, y una excepción de enrutamiento no anula ninguna de las dos. Si el cliente también borra su regla de política, las vías admitidas son su propia política de túnel dividido o un cliente que le permita gestionar rutas, como OpenConnect; parchear un binario de proveedor para silenciar su monitor es un compromiso de mantenimiento con una comprobación de integridad adjunta.

Escriba el número de tabla, la preferencia y el destino en una nota junto al script. De lo contrario, la siguiente persona encuentra una regla que supera al túnel y no tiene forma de saber por qué.