Deux passerelles, un VPN : pourquoi OpenVPN choisit le mauvais lien montant

Deux liens montants, un tunnel, et le trafic sort par celui que vous n'avez pas choisi. Les sous-réseaux privés sont joignables, le journal signale une connexion réussie, et c'est le lien mesuré qui la transporte. Rien dans la sortie d'OpenVPN ne mentionne de passerelle, car le client n'en a jamais choisi une. Il a ouvert un socket vers une adresse distante et a laissé le noyau décider comment atteindre cette adresse.

L'adresse du tunnel n'est pas le point de terminaison

Il existe deux chemins différents dans chaque session. Le chemin extérieur transporte le trafic chiffré jusqu'à l'adresse publique du serveur. Le chemin intérieur transporte tout ce que le serveur pousse dans le tunnel, et les règles de routage de l'un n'ont aucun effet sur l'autre.

L'entrée remote du profil nomme la destination extérieure, c'est donc l'adresse à fixer. C'est aussi la valeur qui change lorsqu'un nom d'hôte se résout différemment ou que le profil liste plusieurs remote.

Trouvez l'adresse que le client a réellement appelée

Lisez le socket actif plutôt que le fichier de configuration. La table des sockets montre le pair auquel le processus s'est réellement connecté, et c'est la valeur que l'exception doit atteindre. Un profil peut être modifié après le début de la session, et le socket est la seule preuve de ce qui a été appelé :

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

La ligne du journal indique l'adresse et le port du pair au moment de la connexion. Si elle diffère du profil, quelque chose devant le client réécrit la destination avant que la connexion ne commence.

Vérifiez aussi la famille d'adresses. Un profil double pile peut se connecter en IPv6 alors que votre exception ne couvre qu'IPv4, et le trafic suit alors une règle différente de celle que vous avez écrite. Il en va de même pour un proxy qui répond au nom du point de terminaison. Les deux cas produisent un tunnel qui fonctionne pendant que votre route ne fait rien.

Fixez le point de terminaison et lisez l'ordre des politiques

Une route d'hôte est plus spécifique que n'importe quelle route par défaut. Une /32 pour l'adresse du pair l'emporte donc dans la table qui la contient. La forme habituelle nomme explicitement la passerelle et l'interface :

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

Cette route n'aide que si la recherche atteint cette table. Les règles de politique sont évaluées dans l'ordre et la première correspondance décide, donc une règle qui envoie tout vers une seconde table contourne votre route d'hôte dans main. Lisez les règles avant de supposer que la route fait autorité :

ip rule show
ip route get 203.0.113.40

Interrogez la seconde commande avec la même adresse source ou marque que le client utilise lorsque la politique en dépend. Elle indique la route que le noyau choisirait, ce qui est une preuve sur la recherche et non la preuve que le socket actif emprunte ce chemin.

Quand le point de terminaison se déplace

Un nom d'hôte qui se résout en plusieurs adresses invalide une /32 permanente dès que la réponse change. Un profil avec plusieurs lignes remote a le même problème, car le client peut atterrir sur n'importe laquelle. Actualisez la route depuis les propres crochets de cycle de vie du client au lieu de l'ajouter à la main. Un script up qui lit le pair négocié et installe la route d'hôte maintient l'exception alignée sur la réalité, et un script down correspondant la retire.

Consignez l'actualisation au même endroit que le reste de la configuration de routage de l'hôte. Une route qui n'existe que jusqu'au prochain redémarrage est un test, pas un correctif.

Gardez la politique intérieure séparée

Déplacer le chemin extérieur ne donne pas accès à un nouveau sous-réseau privé et ne change pas les destinations que le serveur pousse dans le tunnel. La route de la couche inférieure choisit le câble ; les routes poussées choisissent ce qui entre dans le tunnel. Garder ces deux décisions séparées rend la division prévisible.

Si le but est seulement de garder le trafic chiffré hors d'un lien mesuré, laissez la route par défaut tranquille et ajoutez l'unique exception d'hôte. Remplacer la route par défaut de toute la machine pour déplacer une seule connexion VPN casse toutes les autres applications de l'hôte.

Confirmez le résultat avec deux observations indépendantes : l'adresse locale et l'interface du socket, et la route vers laquelle la destination privée se résout. Quand les deux correspondent à votre intention, la division est réelle. Le manuel OpenVPN 2.6 couvre les options remote et de liaison locale qui décident à quelle adresse le client se connecte.