Comment envoyer une destination IPv4 hors d’un tunnel OpenVPN

La plupart des configurations en tunnel complet font passer chaque paquet par le VPN, et la directive redirect-gateway est ce qui le permet. Une destination unique peut néanmoins être exemptée. Ajouter une route d’hôte pour cette adresse avec l’espace réservé net_gateway indique au client de l’atteindre via la passerelle d’origine de la machine, tandis que tout le reste continue d’utiliser le tunnel.

La ligne semble inoffensive et l’est souvent, mais elle ne tranche qu’une question : où vont les paquets destinés à cette adresse IPv4 précise. Elle ne change ni le DNS, ni l’IPv6, ni la politique du pare-feu, ni le processus qui a ouvert la connexion, et chacun de ces éléments peut réduire l’exception à néant en silence.

Ce que net_gateway désigne réellement

L’entrée de profil pour cette exception tient en une ligne : route 198.51.100.77 255.255.255.255 net_gateway. La première adresse est un espace réservé documentaire pour la destination, le masque en fait une route d’hôte unique, et le dernier jeton nomme l’espace réservé de passerelle. OpenVPN résout les espaces réservés de passerelle lorsqu’il installe des routes. vpn_gateway désigne la passerelle propre au tunnel, l’extrémité distante de la liaison VPN. net_gateway désigne la passerelle par défaut que l’hôte avait avant que le VPN ne change quoi que ce soit, généralement le routeur local du réseau physique.

Un troisième espace réservé, remote_host, renvoie à l’adresse du serveur VPN, et il existe pour que le tunnel puisse atteindre le serveur par le chemin physique. Confondre ces trois-là est la raison la plus fréquente pour qu’une exception aille au mauvais endroit ou ne s’installe pas du tout.

La valeur est lue au moment de la connexion, pas écrite dans le fichier. Si la machine passe sur un autre réseau, la passerelle d’avant le VPN change et la route suit la nouvelle. C’est généralement ce que vous voulez, mais cela signifie aussi que le comportement de l’exception dépend du réseau depuis lequel le client a démarré.

Pourquoi une route d’hôte l’emporte sur la route par défaut du tunnel

Le routage est décidé par le préfixe correspondant le plus spécifique. redirect-gateway def1 ne remplace normalement pas la route par défaut ; il ajoute deux moitiés, une route pour la moitié basse de l’espace d’adressage et une pour la moitié haute, de sorte que la route par défaut d’origine est préservée pour d’autres usages. Ces moitiés sont plus larges qu’une seule adresse.

Une route pour une adresse avec le masque 255.255.255.255 est une /32, soit le maximum de spécificité qu’IPv4 permette. Lorsqu’un paquet destiné à cette adresse est évalué, la /32 correspond et gagne, quelle que soit la route installée en premier. C’est le mécanisme derrière l’exception, et il fonctionne de la même façon sous Linux, macOS et Windows tant que la route est réellement présente.

Windows ajoute une seconde dimension. Quand deux routes sont également spécifiques, celle qui a la métrique la plus basse l’emporte, et une carte VPN peut porter une métrique d’interface qui change le résultat. Une /32 reste plus spécifique que les moitiés, l’exception tient donc normalement, mais une route obsolète d’une session précédente peut produire un résultat déroutant si elle est aussi spécifique.

Ce que l’exception ne couvre pas

Le DNS est la première faille. Le client peut pousser des réglages de résolveur internes, et le système d’exploitation continuera de les utiliser pour les recherches. Une application qui résout un nom avant de se connecter peut recevoir une adresse interne pour un service censé passer en direct, ou une adresse externe qui se résout correctement mais bute ensuite sur la faille suivante.

L’IPv6 est la deuxième. La directive de route ne gère que l’IPv4. Une destination à double pile peut préférer l’IPv6, qui suit le tunnel ou la route par défaut IPv6 de l’hôte selon la politique, si bien que l’exception IPv4 n’entre jamais en jeu. Il vous faut une route IPv6 correspondante, ou une décision délibérée de désactiver l’IPv6 pour ce client.

La portée des applications est la troisième. La règle est fondée sur la destination, donc tout processus qui se connecte à cette adresse emprunte le chemin direct, que ce soit celui que vous aviez en tête ou non. À l’inverse, un site web peut répondre depuis plusieurs adresses, donc exempter une /32 n’exempte pas le site. Si le besoin réel est le routage par application, la table de routes du client Community est le mauvais outil.

Vérifier l’exception sans se tromper soi-même

Commencez par la route installée, pas par un navigateur. Sous Linux, demandez au noyau quelle route et quel saut suivant il utilisera pour l’adresse concernée ; sous Windows, lisez la table de routes pour cette /32. Confirmez que la passerelle est bien la physique et non le tunnel. Si l’entrée manque, le profil n’a pas été appliqué ou le client n’avait pas le privilège de modifier les routes.

Testez ensuite deux destinations. Une requête vers l’adresse exemptée devrait sortir par l’interface physique, et une requête vers une adresse interne de contrôle devrait continuer d’utiliser le tunnel. Tester seulement l’adresse exemptée ne prouve rien sur le reste du tunnel, et tester un site web public teste l’adresse vers laquelle ce site a été résolu, qui n’est peut-être pas celle de la règle.

Enfin, vérifiez les contrôles qui peuvent passer outre la route. Un kill switch côté client ou un réglage block-outside-dns de Windows peut interdire le trafic direct, ce qui se manifeste par une connexion qui échoue alors que la route est correcte. Ne désactivez pas ces contrôles pour faire semblant que l’exception fonctionne ; si la politique interdit le chemin direct, l’exception est un problème de conception pour le propriétaire du service VPN.

Revérifiez après une reconnexion ou un changement de réseau, car la passerelle d’avant le VPN et le chemin disponible sont des propriétés du moment, pas du profil.