O cliente VPN borra a ruta que engadiu? Use unha táboa de políticas

Unha /24 para unha impresora de laboratorio desaparece entre dúas chamadas a ip route show, e o rexistro do cliente só di que a rede cambiou. Non había nada mal co comando, o prefixo nin os seus privilexios. Un cliente corporativo que posúe o modelo de enrutamento do host reafirma ese modelo cada vez que alguén máis o edita, así que a entrada que engadiu elimínase como intrusa. Loitar contra el na mesma táboa é unha posición perdida. A solución é deixar de competir por esa táboa por completo e pór a excepción onde o monitor nunca mira.

O monitor explica a ruta desaparecida

Demostre isto antes de redeseñar nada: lea a táboa, engada o prefixo, espere uns segundos, volva ler. Se a entrada non está e non escribiu nada para eliminala, hai un axente vixiando. Atope o proceso que posúe ese comportamento e lea o seu rexistro arredor do momento en que a ruta desaparece, porque o mesmo servizo adoita manter o túnel, os filtros de paquetes e a configuración do resolutor. Matelo para que a súa ruta se manteña é un intercambio que lamentará na próxima reconexión.

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

O prefixo e a interface de arriba son marcadores de posición. Copiar un nome de interface dun exemplo que funciona noutra máquina é a razón máis común de que esta demostración non produza absolutamente nada.

Unha segunda táboa é invisible para o monitor

O axente só reconstrúe a táboa que posúe. Dea á excepción unha táboa propia máis unha regra que envíe alí os destinos coincidentes, e a táboa principal nunca cambia, así que o axente non ten nada que corrixir. Esta é toda a idea: un espazo de nomes de rutas que mantén outra persoa e outro que só toca vostede.

O intercambio é o mantemento. Dous obxectos poden separarse, e a posición da regra na lista importa tanto como a ruta dentro da táboa que selecciona.

Construa a excepción e logo faga que gañe

Cree a táboa, instale a ruta e engada unha regra que seleccione a táboa para ese destino. A preferencia decide se a súa regra se consulta antes ou despois das que inseriu o cliente, e unha regra que se ordena máis tarde nunca se alcanza, así que o número forma parte do deseño e non é decoración. Logo pregunte ao núcleo que faría realmente, que é unha pregunta distinta do que vostede configurou.

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 resolve a ruta que usaría o núcleo, incluídos o dispositivo e o enderezo de orixe. Non imprime o identificador da táboa, así que combínelo con ip rule show cando necesite confirmar que táboa gañou. Xuntos responden a única pregunta que importa: o tráfico cara a ese enderezo sae onde vostede pretendía?

Outras formas da mesma idea

O patrón xeneralízase en canto deixa de pensar en destinos. Unha subrede local pode seguir sendo accesible mentres o túnel conserva a ruta predeterminada. As respostas dun servidor SSH conectado á LAN poden saír pola interface pola que chegaron en lugar de desaparecer no túnel. E unha regra baseada en interface pode empurrar todo o que chega por unha interface sen fíos cara ao túnel mentres o tráfico que xera o propio host queda en Ethernet:

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

Ese último caso coincide coa interface de entrada en lugar do destino, que é outro tipo de regra e outro modelo mental. O tráfico reenviado tamén necesita net.ipv4.ip_forward habilitado, e o extremo remoto debe enrutar de volta o rango de orixe ou traducilo; unha regra nunha máquina nunca crea a outra metade do camiño.

Trate a regra como refugable

As regras e as rutas de táboa viven na memoria. Despois dunha reconexión o dispositivo do túnel pode cambiar de nome, o enderezo asignado pode moverse, e unha regra co valor antigo deixa de coincidir en silencio. Volva aplicar todo o cambio desde un único script que o posúa, e logo volva comprobar ip rule show, o nome actual do dispositivo e un ip route get novo contra un destino real antes de confiar na excepción.

Dous límites sobreviven a calquera coidado. O cliente segue controlando as súas propias regras de filtrado e a configuración do resolutor, e unha excepción de enrutamento non substitúe ningunha das dúas. Se o cliente tamén borra a súa regra de política, as vías admitidas son a súa propia política de túnel dividido ou un cliente que lle permita xestionar rutas, como OpenConnect; parchear un binario de provedor para silenciar o seu monitor é un compromiso de mantemento cunha comprobación de integridade adjunta.

Escriba o número de táboa, a preferencia e o destino nunha nota xunto ao script. Se non, a próxima persoa atopa unha regra que supera o túnel e non ten xeito de saber por que.