OpenVPN redirect-gateway : ce que chaque option fait aux routes

Connectez-vous avec redirect-gateway dans le profil, et la route par défaut de votre machine peut disparaître, se scinder en deux ou rester exactement là où elle était, selon des options que personne ne lit deux fois. L’option ne modifie que l’état de routage et rien d’autre, donc la seule preuve fiable de ce qu’elle a fait est la table que le client a installée ensuite. Ce qui suit est la table après une connexion, la route qui maintient le tunnel lui-même en vie, et le trafic IPv6 que la directive ne prétend jamais couvrir. Chaque étape est une commande que vous pouvez exécuter sur le client pendant que le tunnel est actif.

Ce que chaque option fait à la route par défaut

Sans aucune option, la directive supprime la route par défaut ordinaire et met le tunnel à sa place, si bien que l’ancienne passerelle disparaît de la table tant que la connexion est active. Ajoutez def1 et cette route par défaut reste listée, avec deux routes plus étroites qui font le travail. Ajoutez bypass-dhcp et la route DHCP survit aussi, ce qui compte sur un réseau où le client doit encore joindre le serveur DHCP local. La liste des options de la page de manuel d’OpenVPN 2.6 est assez courte pour être lue une fois, et chaque entrée change quelles routes finissent dans la table.

Une option poussée se comporte de la même façon à son arrivée, si bien que le profil du client peut ne rien contenir alors que la table semble entièrement redirigée. C’est normal : le serveur a envoyé les options, le client les a appliquées, et le fichier local n’a jamais mentionné la directive. Quand un envoi semble ne rien faire, vérifiez le filtre côté client qui accepte ou rejette les options tirées, car une option rejetée ne déclenche d’erreur d’aucun côté.

def1 gagne par spécificité sans toucher à votre route par défaut

Deux demi-routes par défaut couvrent ensemble l’espace IPv4, 0.0.0.0/1 et 128.0.0.0/1. Chacune est plus spécifique que 0.0.0.0/0, donc une recherche les préfère tandis que la vraie route par défaut reste dans la table pour tout ce qui demande la correspondance la moins spécifique.

Lisez la table plutôt que le profil, car seule la table montre dans lequel de ces cas vous êtes. Deux lignes suffisent à les distinguer :

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Notez l’interface et la métrique de chaque ligne, pas seulement la destination. Une route par défaut pointant vers le tunnel et une paire de demi-routes pointant vers le tunnel décrivent la même intention et échouent différemment quand le tunnel tombe, car dans un cas le repli existe encore. Inscrivez les deux champs dans la note de changement. Un repli survivant est parfois ce qui maintient une session distante en vie assez longtemps pour réparer le tunnel, et c’est aussi ce qui fuit du trafic quand l’intention était un tunnel complet.

Gardez l’extrémité du tunnel joignable

Le client a besoin d’une route vers l’extrémité distante du tunnel qui ne passe pas elle-même par le tunnel. OpenVPN installe cette route d’hôte avant de changer quoi que ce soit d’autre, et une modification manuelle des routes ou un second client VPN peuvent la retirer. Le symptôme ensuite est une connexion qui se dit connectée puis ne laisse rien passer.

Demandez au noyau quelle interface il utiliserait pour l’adresse de l’extrémité pendant que le tunnel est actif. La réponse doit nommer l’interface physique et sa passerelle, jamais tun0 :

ip route get 198.51.100.20

Si cette recherche renvoie le périphérique du tunnel, le tunnel porte son propre transport et s’effondrera dès qu’un paquet devra sortir. Les préfixes locaux, un second adaptateur et le routage par politique comptent encore ici, c’est pourquoi une redirection qui fonctionne sur un portable propre peut échouer sur un hôte doté d’une interface de gestion et de deux routes par défaut. On blâme généralement le profil pour ce qu’a fait le plan d’adressage.

Le trafic IPv6 continue d’utiliser sa propre table

Rediriger IPv4 laisse IPv6 tranquille, et les deux familles sont modifiées par des options différentes. Sur un hôte double pile avec une route v6 par défaut qui fonctionne, le trafic v4 peut rester entièrement dans le tunnel tandis que chaque destination compatible v6 sort par le lien physique. Un hôte qui semble correct dans une table fuit dans l’autre.

Vérifiez la table v6 après la connexion au lieu de supposer que le tunnel l’a couverte. La directive porte des options de famille d’adresses précisément pour cela, et un profil qui les omet hérite de ce que la plateforme fait par défaut :

ip -6 route show default
ip -6 route get 2001:db8::10

Prouvez quelle interface une application utilise

Un état connecté n’est pas un blocage, et un changement de route n’est pas un coupe-circuit. Si le trafic direct doit s’arrêter quand le tunnel tombe, cette politique vit dans le pare-feu et exige son propre test.

Testez le chemin qu’une application emprunte réellement plutôt que le chemin que décrit le profil. Demandez d’abord la route, puis liez une requête à chaque interface tour à tour et comparez ce que rapporte le côté distant :

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Si les deux requêtes renvoient la même adresse, l’application n’utilise pas le tunnel alors même que la table de routage dit qu’elle devrait. Si seule la requête liée au tunnel réussit, le chemin physique est filtré pour cette destination et le tunnel fait ce que vous avez demandé. Inscrivez les options, les routes installées, la recherche de l’extrémité et les deux résultats de sortie dans le journal des changements, afin que la personne suivante hérite de faits plutôt que d’une capture d’écran.