Votre ancienne route par défaut survit délibérément à OpenVPN

Vous connectez le tunnel, exécutez ip route, et la passerelle par défaut d’origine est toujours là. La pensée suivante est que le client n’a pas pris la route, alors vous supprimez la route par défaut à la main et perdez complètement la connectivité. Cette entrée est censée rester. Avec redirect-gateway def1, OpenVPN installe deux routes plus spécifiques qui priment sur la route par défaut ordinaire au lieu de la remplacer. L’ancienne passerelle reste et cesse de porter le trafic que vous testiez.

Ce que fait réellement def1

L’option ajoute 0.0.0.0/1 et 128.0.0.0/1, toutes deux pointant vers le tunnel. 0.0.0.0/1 couvre toute adresse dont le premier octet va de 0 à 127, et 128.0.0.0/1 couvre 128 à 255, donc chaque destination IPv4 a une correspondance plus spécifique que l’ancienne route par défaut. La longueur du préfixe, et non la métrique, décide quelle route gagne.

Laisser la route par défaut d’origine en place est délibéré. Le client n’a pas à se souvenir de ce qu’il a remplacé et ne réécrit pas la route qui porte sa propre connexion au serveur VPN. À la déconnexion, il retire les deux demi-routes et la table revient à ce qu’elle était.

Pourquoi /1 et non /0

Le routage choisit le préfixe correspondant le plus long, pas la métrique la plus basse, donc une /1 bat une /0 quoi que dise la métrique de la route par défaut. Les deux moitiés existent parce qu’une /1 ne couvre que la moitié de l’espace ; avec seulement 0.0.0.0/1 présent, tout ce qui part de 128.0.0.0 suit encore l’ancienne route par défaut, ce qui produit le symptôme déroutant où certains sites fonctionnent et d’autres non.

Augmenter ou baisser la métrique de l’ancienne route par défaut ne change rien, et une route par défaut de métrique plus basse sur une autre interface ne vole pas non plus le trafic. La longueur du préfixe décide d’abord, et seuls les préfixes égaux se rabattent sur la métrique.

Lire une vraie table de routage

Un hôte connecté peut afficher les trois entrées à la fois, le tunnel portant les moitiés et la passerelle d’origine toujours listée. Les adresses sont des exemples et non une configuration à copier, car les noms d’interface, la topologie du tunnel et les routes supplémentaires varient selon la plateforme et le client.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

L’important est la relation : deux moitiés précises au-dessus d’une route par défaut générale. La ligne de l’ancienne passerelle reste parce que rien ne l’a remplacée.

Vérifier quelle route le paquet emprunte réellement

Des routes plus spécifiques peuvent encore gagner : une route pour une plage privée, un sous-réseau local ou l’adresse du serveur VPN lui-même est plus longue qu’une /1. Le tunnel a besoin d’un chemin extérieur vers son serveur, et renvoyer cette connexion dans le tunnel le casserait immédiatement. Sous Linux, interrogez le noyau au lieu de lire la table à l’œil : ip route get avec la destination qui vous intéresse imprime la route choisie, l’interface et la source. Si un routage par politiques est configuré, inspectez aussi les règles, car une règle peut sélectionner une autre table avant que la principale ne soit consultée.

Si seule une partie d’IPv4 se comporte mal, confirmez que les deux moitiés sont installées, puis cherchez une exception correspondant à la destination qui échoue. Supprimer l’ancienne route par défaut n’est pas une solution, et cela retire la route dont le client a besoin pour démonter proprement le tunnel.

Ce que def1 ne couvre pas

Deux entrées IPv4 ne disent rien d’IPv6 : un hôte doté d’une connectivité IPv6 continue d’utiliser sa propre route par défaut jusqu’à ce que quelque chose redirige cette famille séparément, ce qui explique pourquoi, sur un réseau double pile, une partie du trafic semble contourner le tunnel. D’autres clients et gestionnaires réseau implémentent le routage de tunnel complet différemment, et leurs tables ne correspondront pas. Le comportement de def1 décrit ici appartient à l’option documentée d’OpenVPN, pas à chaque VPN de la machine.

Un kill switch répond à une autre question : ce que fait la machine quand le tunnel tombe. La priorité des routes décide où va le trafic tant que le tunnel est actif ; elle ne décide pas de ce que fait un pare-feu ensuite. Ordre de travail : lisez la table, confirmez que les deux moitiés existent, exécutez ip route get pour la destination qui échoue, vérifiez les règles de politique, puis regardez IPv6 séparément. Laissez l’ancienne route par défaut là où elle est.