Métrica de rota do OpenVPN: por que a rota escolhida ainda perde

Você adicionou uma métrica a uma rota no perfil, reconectou e o tráfego ainda sai pela interface errada. O número raramente é o problema. Uma métrica apenas ordena os candidatos que o sistema operacional já está comparando, e um prefixo mais específico ou uma tabela de políticas anterior decide antes de qualquer métrica ser lida.

Passe pelo perfil primeiro, depois pela tabela instalada e, por fim, pelas regras de seleção. Essa ordem acompanha a forma como o cliente monta a rota e evita que você ajuste um valor que nunca entra na comparação.

Leia a linha de rota na ordem dos campos

Um cliente Community OpenVPN 2.6 aceita quatro campos em uma linha route de IPv4: rede, máscara, gateway e uma métrica opcional. A posição do gateway é onde vai a palavra-chave especial vpn_gateway. Ela significa o próximo salto do lado da VPN para esta conexão, não um número de tabela de roteamento e não o seu roteador físico. Erre isso e o restante da linha será lido com a ideia errada do que ele faz. A referência de opções de rede documenta os quatro campos.

Para um destino privado, a linha pode ser:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

O 30 explícito se aplica a essa rota, e o 50 continua sendo o padrão para todas as outras rotas do perfil que omitem um número. Ler a linha da esquerda para a direita basta para saber qual valor se aplica onde.

route-metric é um padrão, não uma posição

route-metric define o valor de fallback para rotas que não trazem o próprio número. Ele não coloca uma rota acima de nenhuma outra e não reordena rotas que foram instaladas com métricas explícitas.

Essa distinção importa quando um perfil mistura as duas formas. Uma única linha route-metric perto do topo parece impor autoridade e é fácil de culpar, enquanto a rota que de fato carrega o tráfego pode trazer a própria métrica três linhas abaixo.

Se você quer que uma rota prefira um caminho, coloque o número nessa rota. Se você quer um padrão consistente em um perfil gerado, use route-metric e deixe as linhas individuais em paz. Misturar as duas sem motivo é como um perfil acaba com uma rota que ninguém consegue explicar.

Inspecione o que o cliente instalou

Depois que a reconexão termina, pergunte ao kernel, não ao perfil.

ip route show lista as rotas que o cliente adicionou, e ip route get 172.20.5.10 responde à pergunta mais útil: qual rota este destino realmente usaria, com qual endereço de origem. Se o destino não estiver na tabela, o cliente não o instalou.

Uma diretiva local, um push do servidor ou outro gerenciador de rede pode adicionar ou remover o mesmo prefixo, e o último a escrever vence. Mantenha a rota do endpoint à vista enquanto trabalha, porque a conexão precisa de um caminho até o servidor remoto que não passe pelo túnel que ela está construindo.

Por que uma métrica menor ainda perde

Métricas comparam rotas para o mesmo destino. Elas não tornam um prefixo amplo mais específico. Quando redirect-gateway def1 está em jogo, o cliente instala 0.0.0.0/1 e 128.0.0.0/1, e esses dois prefixos cobrem todo o espaço IPv4 de forma mais específica que 0.0.0.0/0. Uma métrica de 1 na rota padrão não supera esses prefixos.

A mesma lógica vale para qualquer par sobreposto. Um /24 vence um /16 para um endereço dentro dele, independentemente dos números anexados, porque a busca escolhe primeiro a correspondência mais específica e só depois compara métricas entre iguais.

Esta é a parte que parece um bug de métrica e não é. Verifique o comprimento do prefixo nos dois candidatos antes de mudar qualquer número.

Regras de política rodam antes da tabela

No Linux, ip rule decide qual tabela de roteamento é consultada. As regras são avaliadas em ordem de prioridade, então uma tabela anterior pode devolver uma rota antes de a tabela principal ser lida. Uma métrica dentro da main não pode superar uma correspondência em uma tabela consultada primeiro.

Use ip rule show e depois consulte a tabela específica, por exemplo ip route show table 100, para ver o que essa regra retornaria. Se um cliente VPN ou um runtime de contêiner adicionou uma regra, a resposta pode estar lá em vez de na tabela que você vem lendo. O endereço de origem também importa, pois uma regra pode casar com a origem e resolver o mesmo destino de forma diferente para o tráfego do túnel e o tráfego da LAN.

Verifique o destino, não a classificação

O teste que encerra a discussão é uma única consulta a um host dentro da sub-rede pretendida, mais a checagem do endereço de origem que o kernel selecionou. Se esse par corresponde ao projeto, a métrica está fazendo o seu trabalho mesmo quando a listagem não parece uma classificação limpa.

Deixe IPv6 e DNS fora desta checagem. Eles são configurados por diretivas diferentes e resolvidos por mecanismos diferentes, e uma rota IPv4 funcionando não diz nada sobre nenhum dos dois. Mude uma camada de cada vez e repita a consulta.