Métrica de ruta de OpenVPN: por qué la ruta elegida sigue perdiendo

Añadió una métrica a una ruta en el perfil, se reconectó y el tráfico sigue saliendo por la interfaz incorrecta. El número rara vez es el problema. Una métrica solo ordena los candidatos que el sistema operativo ya compara, y un prefijo más específico o una tabla de políticas anterior decide antes de que se lea cualquier métrica.

Revise primero el perfil, luego la tabla instalada y luego las reglas de selección. Ese orden coincide con la forma en que el cliente construye la ruta y le evita ajustar un valor que nunca entra en la comparación.

Lea la línea de ruta por orden de campos

Un cliente de la comunidad OpenVPN 2.6 acepta cuatro campos en una línea route de IPv4: red, máscara de red, puerta de enlace y una métrica opcional. La posición de la puerta de enlace es donde va la palabra clave especial vpn_gateway. Significa el siguiente salto del lado VPN para esta conexión, no un número de tabla de enrutamiento ni su router físico. Si lo pasa por alto, el resto de la línea se lee con una idea equivocada de lo que hace. referencia de opciones de red documenta los cuatro campos.

Para un destino privado, la línea puede leerse así:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

El 30 explícito se aplica a esa ruta, y el 50 sigue siendo el valor predeterminado para cualquier otra ruta del perfil que omita un número. Leer la línea de izquierda a derecha basta para saber qué valor se aplica y dónde.

route-metric es un valor predeterminado, no un rango

route-metric establece el valor de reserva para las rutas que no llevan su propio número. No eleva una ruta por encima de nada ni reordena las rutas instaladas con métricas explícitas.

Esa distinción importa cuando un perfil mezcla ambas formas. Una sola línea route-metric cerca de la parte superior parece autoritativa y es fácil de culpar, mientras que la ruta que realmente transporta tráfico puede llevar su propia métrica tres líneas más abajo.

Si quiere que una ruta prefiera un camino, ponga el número en esa ruta. Si quiere un valor predeterminado coherente en un perfil generado, use route-metric y deje las líneas individuales en paz. Mezclar las dos sin motivo es como un perfil acaba con una ruta que nadie puede explicar.

Inspeccione qué instaló el cliente

Cuando termine la reconexión, pregunte al núcleo, no al perfil.

ip route show enumera las rutas que añadió el cliente, y ip route get 172.20.5.10 responde a la pregunta más útil: qué ruta usaría realmente este destino y con qué dirección de origen. Si el destino falta en la tabla, el cliente no lo instaló.

Una directiva local, un envío desde el servidor u otro gestor de red pueden añadir o quitar el mismo prefijo, y gana el último que escribe. Mantenga la ruta del extremo a la vista mientras trabaja, porque la conexión necesita un camino hacia el servidor remoto que no pase por el túnel que está construyendo.

Por qué una métrica menor sigue perdiendo

Las métricas comparan rutas hacia el mismo destino. No hacen que un prefijo amplio sea más específico. Cuando redirect-gateway def1 está en juego, el cliente instala 0.0.0.0/1 y 128.0.0.0/1, y esos dos prefijos cubren todo el espacio IPv4 de forma más específica que 0.0.0.0/0. Una métrica de 1 en la ruta predeterminada no los supera.

La misma lógica se aplica a cualquier par superpuesto. Una /24 gana a una /16 para una dirección dentro de ella, independientemente de los números adjuntos, porque la búsqueda elige primero la coincidencia más específica y solo después compara métricas entre iguales.

Esta es la parte que parece un error de métrica y no lo es. Compruebe la longitud del prefijo en ambos candidatos antes de cambiar cualquier número.

Las reglas de política se ejecutan antes de la tabla

En Linux, ip rule decide qué tabla de enrutamiento se consulta. Las reglas se evalúan por orden de prioridad, así que una tabla anterior puede devolver una ruta antes de que se lea la tabla principal. Una métrica dentro de main no puede superar una coincidencia en una tabla que se consultó primero.

Use ip rule show y luego consulte la tabla concreta, por ejemplo ip route show table 100, para ver qué devolvería esa regla. Si un cliente VPN o un entorno de contenedores añadió una regla, la respuesta puede estar ahí en lugar de en la tabla que ha estado leyendo. La dirección de origen también importa, porque una regla puede coincidir con el origen y resolver el mismo destino de forma distinta para el tráfico del túnel y el tráfico de LAN.

Verifique el destino, no la clasificación

La prueba que zanja la discusión es una sola consulta a un host dentro de la subred prevista, más una comprobación de la dirección de origen que eligió el núcleo. Si ese par coincide con el diseño, la métrica hace su trabajo incluso cuando el listado no parece una clasificación limpia.

Deje IPv6 y DNS fuera de esta comprobación. Se configuran con directivas distintas y se resuelven con mecanismos distintos, y una ruta IPv4 que funciona no dice nada sobre ninguno de los dos. Cambie una capa a la vez y vuelva a ejecutar la consulta.