Métrique de route OpenVPN : pourquoi la route choisie perd encore

Vous avez ajouté une métrique à une route dans le profil, vous vous êtes reconnecté, et le trafic sort toujours par la mauvaise interface. Le nombre est rarement le problème. Une métrique ne fait qu’ordonner les candidats que le système d’exploitation compare déjà, et un préfixe plus spécifique ou une table de politiques antérieure décide avant qu’aucune métrique ne soit lue.

Parcourez d’abord le profil, puis la table installée, puis les règles de sélection. Cet ordre correspond à la façon dont le client construit la route et vous empêche de régler une valeur qui n’entre jamais dans la comparaison.

Lisez la ligne de route dans l’ordre des champs

Un client communautaire OpenVPN 2.6 accepte quatre champs sur une ligne route IPv4 : réseau, masque de réseau, passerelle et une métrique facultative. La position de la passerelle est là où va le mot-clé spécial vpn_gateway. Il désigne le saut suivant côté VPN pour cette connexion, pas un numéro de table de routage et pas votre routeur physique. Si vous le manquez, le reste de la ligne est lu avec une idée fausse de ce qu’il fait. référence des options réseau documente les quatre champs.

Pour une destination privée, la ligne peut se lire ainsi :

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Le 30 explicite s’applique à cette route, et le 50 reste la valeur par défaut pour toute autre route du profil qui omet un nombre. Lire la ligne de gauche à droite suffit pour savoir quelle valeur s’applique et où.

route-metric est une valeur par défaut, pas un rang

route-metric définit la valeur de repli pour les routes qui ne portent pas leur propre nombre. Il ne place aucune route au-dessus d’une autre et ne réordonne pas les routes installées avec des métriques explicites.

Cette distinction compte lorsqu’un profil mélange les deux formes. Une seule ligne route-metric près du haut semble faire autorité et il est facile de la blâmer, alors que la route qui porte réellement le trafic peut porter sa propre métrique trois lignes plus bas.

Si vous voulez qu’une route préfère un chemin, mettez le nombre sur cette route. Si vous voulez une valeur par défaut cohérente sur un profil généré, utilisez route-metric et laissez les lignes individuelles tranquilles. Mélanger les deux sans raison est la façon dont un profil finit avec une route que personne ne peut expliquer.

Inspectez ce que le client a installé

Une fois la reconnexion terminée, interrogez le noyau plutôt que le profil.

ip route show liste les routes que le client a ajoutées, et ip route get 172.20.5.10 répond à la question plus utile : quelle route cette destination utiliserait réellement, et avec quelle adresse source. Si la destination est absente de la table, le client ne l’a pas installée.

Une directive locale, un push du serveur ou un autre gestionnaire de réseau peuvent ajouter ou retirer le même préfixe, et le dernier qui écrit gagne. Gardez la route du point de terminaison sous les yeux pendant que vous travaillez, car la connexion a besoin d’un chemin vers le serveur distant qui ne passe pas par le tunnel qu’elle construit.

Pourquoi une métrique plus petite perd encore

Les métriques comparent des routes vers la même destination. Elles ne rendent pas un préfixe large plus spécifique. Quand redirect-gateway def1 est en jeu, le client installe 0.0.0.0/1 et 128.0.0.0/1, et ces deux préfixes couvrent tout l’espace IPv4 de façon plus spécifique que 0.0.0.0/0. Une métrique de 1 sur la route par défaut ne les surclasse pas.

La même logique s’applique à toute paire qui se chevauche. Un /24 bat un /16 pour une adresse à l’intérieur, quels que soient les nombres attachés, parce que la recherche choisit d’abord la correspondance la plus spécifique et ne compare les métriques entre égales qu’ensuite.

C’est la partie qui ressemble à un bogue de métrique et n’en est pas un. Vérifiez la longueur du préfixe sur les deux candidats avant de changer le moindre nombre.

Les règles de politique s’exécutent avant la table

Sous Linux, ip rule décide quelle table de routage est consultée. Les règles sont évaluées par ordre de priorité, donc une table antérieure peut renvoyer une route avant même que la table principale ne soit lue. Une métrique dans main ne peut pas surclasser une correspondance dans une table consultée en premier.

Utilisez ip rule show puis interrogez la table concernée, par exemple ip route show table 100, pour voir ce que cette règle renverrait. Si un client VPN ou un environnement de conteneurs a ajouté une règle, la réponse peut être là plutôt que dans la table que vous lisiez. L’adresse source compte aussi, car une règle peut correspondre à la source et résoudre la même destination différemment pour le trafic du tunnel et le trafic LAN.

Vérifiez la destination, pas le classement

Le test qui met fin au débat est une seule requête vers un hôte dans le sous-réseau visé, plus une vérification de l’adresse source choisie par le noyau. Si cette paire correspond à la conception, la métrique fait son travail même quand la liste ne ressemble pas à un classement propre.

Laissez IPv6 et DNS hors de cette vérification. Ils sont configurés par des directives différentes et résolus par des mécanismes différents, et une route IPv4 qui fonctionne ne dit rien de l’un ni de l’autre. Changez une couche à la fois et relancez la requête.