Mètrica de ruta d’OpenVPN: per què la ruta triada encara perd

Heu afegit una mètrica a una ruta del perfil, us heu tornat a connectar i el trànsit encara surt per la interfície incorrecta. El número poques vegades és el problema. Una mètrica només ordena els candidats que el sistema operatiu ja compara, i un prefix més específic o una taula de polítiques anterior decideix abans que es llegeixi cap mètrica.

Primer reviseu el perfil, després la taula instal·lada i després les regles de selecció. Aquest ordre coincideix amb la manera com el client construeix la ruta i us evita ajustar un valor que mai no entra a la comparació.

Llegiu la línia de ruta per ordre de camps

Un client de la comunitat OpenVPN 2.6 accepta quatre camps en una línia route IPv4: xarxa, màscara de xarxa, passarel·la i una mètrica opcional. La posició de la passarel·la és on va la paraula clau especial vpn_gateway. Significa el següent salt del costat VPN per a aquesta connexió, no un número de taula d’encaminament ni el vostre router físic. Si us ho salteu, la resta de la línia es llegeix amb una idea equivocada del que fa. referència d’opcions de xarxa documenta tots quatre camps.

Per a una destinació privada, la línia pot ser així:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

El 30 explícit s’aplica a aquesta ruta, i el 50 continua sent el valor per defecte per a qualsevol altra ruta del perfil que ometi un número. Llegir la línia d’esquerra a dreta ja és prou per saber quin valor s’aplica i on.

route-metric és un valor per defecte, no un rang

route-metric estableix el valor de reserva per a les rutes que no porten el seu propi número. No eleva cap ruta per sobre de res ni reordena les rutes instal·lades amb mètriques explícites.

Aquesta distinció importa quan un perfil barreja les dues formes. Una sola línia route-metric a prop de dalt sembla autoritària i és fàcil de culpar, mentre que la ruta que realment porta trànsit pot portar la seva pròpia mètrica tres línies més avall.

Si voleu que una ruta prefereixi un camí, poseu el número en aquesta ruta. Si voleu un valor per defecte consistent en un perfil generat, useu route-metric i deixeu les línies individuals tranquil·les. Barrejar les dues sense motiu és com un perfil acaba amb una ruta que ningú no pot explicar.

Inspeccioneu què ha instal·lat el client

Quan la reconnexió s’hagi completat, pregunteu al nucli, no al perfil.

ip route show llista les rutes que el client ha afegit, i ip route get 172.20.5.10 respon la pregunta més útil: quina ruta faria servir realment aquesta destinació i amb quina adreça d’origen. Si la destinació no apareix a la taula, el client no l’ha instal·lat.

Una directiva local, un push del servidor o un altre gestor de xarxa poden afegir o treure el mateix prefix, i guanya l’últim que escriu. Tingueu la ruta de punt final a la vista mentre treballeu, perquè la connexió necessita un camí cap al servidor remot que no passi pel túnel que està construint.

Per què una mètrica més petita encara perd

Les mètriques comparen rutes cap a la mateixa destinació. No fan que un prefix ampli sigui més específic. Quan redirect-gateway def1 està en joc, el client instal·la 0.0.0.0/1 i 128.0.0.0/1, i aquests dos prefixos cobreixen tot l’espai IPv4 de manera més específica que 0.0.0.0/0. Una mètrica d’1 a la ruta per defecte no els supera.

La mateixa lògica s’aplica a qualsevol parell solapat. Una /24 guanya una /16 per a una adreça dins seu, independentment dels números adjunts, perquè la consulta tria primer la coincidència més específica i només després compara mètriques entre iguals.

Aquesta és la part que sembla un error de mètrica i no ho és. Comproveu la longitud del prefix en els dos candidats abans de canviar cap número.

Les regles de política s’executen abans de la taula

A Linux, ip rule decideix quina taula d’encaminament es consulta. Les regles s’avaluen per ordre de prioritat, així que una taula anterior pot retornar una ruta abans que la taula principal s’hagi llegit. Una mètrica dins de main no pot superar una coincidència en una taula que s’ha consultat primer.

Useu ip rule show i després consulteu la taula concreta, per exemple ip route show table 100, per veure què retornaria aquesta regla. Si un client VPN o un entorn de contenidors ha afegit una regla, la resposta pot ser allà en lloc de la taula que heu estat llegint. L’adreça d’origen també importa, perquè una regla pot coincidir amb l’origen i resoldre la mateixa destinació de manera diferent per al trànsit del túnel i el trànsit de LAN.

Verifiqueu la destinació, no la classificació

La prova que tanca la discussió és una sola consulta a un amfitrió dins de la subxarxa prevista, més una comprovació de l’adreça d’origen que el nucli ha triat. Si aquest parell coincideix amb el disseny, la mètrica fa la seva feina fins i tot quan el llistat no sembla una classificació neta.

Deixeu IPv6 i DNS fora d’aquesta comprovació. Es configuren amb directrius diferents i es resolen amb mecanismes diferents, i una ruta IPv4 que funciona no diu res sobre cap dels dos. Canvieu una capa alhora i torneu a executar la consulta.