La métrique de route VPN change après la connexion : ce que cela signifie
Une métrique plus basse ne départage que des routes également spécifiques. Lisez la règle de politique, le préfixe et la route d’hôte du point de terminaison avant de modifier un numéro de route VPN.
Vous connectez le VPN, lancez route print, et la route par défaut porte maintenant une métrique bien plus basse qu’avant. La conclusion naturelle est que le VPN a pris la route par défaut parce que son numéro est plus petit. Parfois c’est exactement ce qui s’est produit. Souvent la métrique n’est pas du tout le facteur décisif, et la modifier ne change rien parce que le choix a été fait plus tôt, par la longueur du préfixe ou par une règle de politique.
Le symptôme est réel : le trafic qui sortait par l’adaptateur Wi-Fi sort maintenant par le tunnel, ou l’inverse. La métrique est une entrée d’une recherche qui s’exécute dans un ordre fixe, et c’est cet ordre qu’il faut lire avant de toucher un nombre.
Ce à quoi le nombre se mesure réellement
La première comparaison est la spécificité, pas la préférence. Une route pour 10.20.0.0/16 bat 10.0.0.0/8, et les deux battent 0.0.0.0/0, quoi qu’en disent leurs métriques. Un VPN qui installe une route par défaut avec la métrique la plus basse de la machine perd encore face à toute route plus spécifique qui correspond à la destination, y compris la route d’hôte que le client installe pour son propre serveur.
C’est pourquoi abaisser la métrique d’une route par défaut ne peut pas forcer un sous-réseau directement connecté à entrer dans le tunnel. Si vous voulez ce sous-réseau dans le VPN, ajoutez une route pour le préfixe ou sélectionnez la table du tunnel avec une règle de politique. La métrique est le mauvais levier pour ce travail.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
Linux choisit la table avant la métrique
Sous Linux, le noyau consulte d’abord la base de politiques. ip rule liste les règles et les tables qu’elles sélectionnent, et ip route get 203.0.113.10 rapporte la table, la route et l’adresse source que le noyau utiliserait réellement pour cette destination. Une métrique à l’intérieur de la table 100 ne concurrence jamais une route de la table principale, car la règle a choisi la table avant qu’aucune métrique ne soit comparée.
C’est pourquoi une route peut sembler correcte dans ip route show table all et ne pas transporter de trafic. Lisez la règle qui a correspondu, puis la table qu’elle a sélectionnée, puis comparez les routes à l’intérieur. Si la mauvaise table est sélectionnée, aucune modification de métrique dans l’autre table n’aidera.
Windows combine deux métriques
Windows n’a pas de base de politiques par défaut, mais il combine une métrique de route avec une métrique d’interface, et la métrique d’interface automatique peut changer avec la vitesse du lien et l’état de l’adaptateur. C’est pourquoi la même route peut se comporter différemment après l’apparition d’une station d’accueil ou d’un adaptateur virtuel. Find-NetRoute -RemoteIPAddress 203.0.113.10 rapporte l’adresse source, le saut suivant et l’interface choisis, ce qui est plus proche de la décision réelle que la table brute.
Lisez les valeurs de route et d’interface ensemble. Augmenter la métrique d’une interface peut déplacer le trafic sans qu’aucune entrée de route change, et un client VPN qui possède ses routes les réinstallera à la reconnexion et écartera votre modification.
Gardez le point de terminaison du tunnel hors du tunnel
Chaque tunnel a besoin d’un chemin vers son propre serveur qui ne passe pas par le tunnel. Les clients installent une route d’hôte pour le point de terminaison via la passerelle physique, et cette route doit rester plus spécifique que la route par défaut que le client ajoute. Supprimez-la, ou laissez le tunnel gagner la recherche pour cette adresse, et les paquets encapsulés tenteront d’entrer dans le tunnel qu’ils sont censés construire. La connexion échoue ou boucle.
Vérifiez cette route d’hôte avant et après toute modification de métrique : elle doit pointer vers le saut suivant physique et survivre à une reconnexion. Si c’est le client qui la possède, modifiez le profil ou la configuration gérée plutôt qu’une valeur d’exécution qui sera écrasée.
Vérifiez les deux familles d’adresses et le contexte de l’application
IPv4 et IPv6 sont des décisions séparées avec des tables séparées. Un VPN peut transporter IPv4 pendant qu’IPv6 continue d’utiliser le routeur local, et un changement de métrique dans une famille ne dit rien de l’autre. Vérifiez les deux, puis vérifiez le contexte de l’application. Un processus lié à une interface, un namespace de conteneur ou un VPN par application peut voir une table différente de votre shell.
Vérifiez avec l’outil qui rapporte la décision pour la destination réelle, pas avec la liste complète de la table. Si la route choisie est celle que le design prévoit, arrêtez-vous. Une métrique qui n’est pas le plus petit nombre à l’écran n’est pas un défaut, et la forcer à l’être peut casser le chemin du point de terminaison dont dépend le tunnel.