Métrica de ruta de OpenVPN: por que a ruta escollida segue perdendo

Engadiu unha métrica a unha ruta no perfil, reconectouse e o tráfico segue saíndo pola interface incorrecta. O número raramente é o problema. Unha métrica só ordena os candidatos que o sistema operativo xa compara, e un prefixo máis específico ou unha táboa de políticas anterior decide antes de que se lea calquera métrica.

Revise primeiro o perfil, logo a táboa instalada e despois as regras de selección. Esa orde coincide coa forma en que o cliente constrúe a ruta e evítalle axustar un valor que nunca entra na comparación.

Lea a liña de ruta por orde de campos

Un cliente da comunidade OpenVPN 2.6 acepta catro campos nunha liña route de IPv4: rede, máscara de rede, pasarela e unha métrica opcional. A posición da pasarela é onde vai a palabra clave especial vpn_gateway. Significa o seguinte salto do lado VPN para esta conexión, non un número de táboa de encamiñamento nin o seu router físico. Se o pasa por alto, o resto da liña lese cunha idea equivocada do que fai. referencia de opcións de rede documenta os catro campos.

Para un destino privado, a liña pode lerse así:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

O 30 explícito aplícase a esa ruta, e o 50 segue sendo o valor predeterminado para calquera outra ruta do perfil que omita un número. Ler a liña de esquerda a dereita abonda para saber que valor se aplica e onde.

route-metric é un valor predeterminado, non un rango

route-metric establece o valor de reserva para as rutas que non levan o seu propio número. Non eleva unha ruta por riba de nada nin reordena as rutas instaladas con métricas explícitas.

Esa distinción importa cando un perfil mestura ambas formas. Unha soa liña route-metric preto da parte superior parece autoritaria e é doado culpar dela, mentres que a ruta que realmente transporta tráfico pode levar a súa propia métrica tres liñas máis abaixo.

Se quere que unha ruta prefira un camiño, poña o número nesa ruta. Se quere un valor predeterminado coherente nun perfil xerado, use route-metric e deixe as liñas individuais en paz. Mesturar as dúas sen motivo é como un perfil acaba cunha ruta que ninguén pode explicar.

Inspeccione o que instalou o cliente

Cando remate a reconexión, pregunte ao núcleo, non ao perfil.

ip route show enumera as rutas que engadiu o cliente, e ip route get 172.20.5.10 responde á pregunta máis útil: que ruta usaría realmente este destino e con que enderezo de orixe. Se o destino falta na táboa, o cliente non o instalou.

Unha directiva local, un envío desde o servidor ou outro xestor de rede poden engadir ou quitar o mesmo prefixo, e gaña o último que escribe. Manteña a ruta do extremo á vista mentres traballa, porque a conexión necesita un camiño cara ao servidor remoto que non pase polo túnel que está a construír.

Por que unha métrica menor segue perdendo

As métricas comparan rutas cara ao mesmo destino. Non fan que un prefixo amplo sexa máis específico. Cando redirect-gateway def1 está en xogo, o cliente instala 0.0.0.0/1 e 128.0.0.0/1, e eses dous prefixos cobren todo o espazo IPv4 de forma máis específica que 0.0.0.0/0. Unha métrica de 1 na ruta predeterminada non os supera.

A mesma lóxica aplícase a calquera par solapado. Unha /24 gaña a unha /16 para un enderezo dentro dela, independentemente dos números adxuntos, porque a busca escolle primeiro a coincidencia máis específica e só despois compara métricas entre iguais.

Esta é a parte que parece un erro de métrica e non o é. Comprobe a lonxitude do prefixo nos dous candidatos antes de cambiar calquera número.

As regras de política execútanse antes da táboa

En Linux, ip rule decide que táboa de encamiñamento se consulta. As regras avalíanse por orde de prioridade, así que unha táboa anterior pode devolver unha ruta antes de que se lea a táboa principal. Unha métrica dentro de main non pode superar unha coincidencia nunha táboa que se consultou primeiro.

Use ip rule show e despois consulte a táboa concreta, por exemplo ip route show table 100, para ver que devolvería esa regra. Se un cliente VPN ou un contorno de contedores engadiu unha regra, a resposta pode estar alí en lugar de na táboa que estivo lendo. O enderezo de orixe tamén importa, porque unha regra pode coincidir coa orixe e resolver o mesmo destino de forma distinta para o tráfico do túnel e o tráfico de LAN.

Verifique o destino, non a clasificación

A proba que pecha a discusión é unha soa consulta a un host dentro da subrede prevista, máis unha comprobación do enderezo de orixe que escolleu o núcleo. Se ese par coincide co deseño, a métrica fai o seu traballo mesmo cando a listaxe non parece unha clasificación limpa.

Deixe IPv6 e DNS fóra desta comprobación. Configúranse con directivas distintas e resólvense con mecanismos distintos, e unha ruta IPv4 que funciona non di nada sobre ningún dos dous. Cambie unha capa á vez e volva executar a consulta.