Deux tunnels OpenVPN sur un hôte Linux : à qui appartient la route ?

Deux profils sont connectés, et l’un d’eux transporte discrètement du trafic destiné à l’autre. Un hôte Linux peut exécuter les deux clients OpenVPN en même temps sans difficulté. Ce qu’il ne peut pas faire, c’est décider à votre place quel processus peut revendiquer quel préfixe. Cette décision doit être prise avant que le second tunnel ne monte, pas après qu’une ressource a cessé de répondre.

Partez du travail que la seconde liaison doit accomplir

Un bureau joignable par un profil et un laboratoire joignable par un autre ont besoin des deux tunnels actifs et d’aucun des deux qui revendique tout. Une seule application têtue qui doit sortir par le second profil a besoin d’une règle de stratégie plutôt que d’une seconde route par défaut. Une liaison de secours n’a besoin que d’un tunnel actif à la fois, donc la réserve ne devrait pas démarrer avec la machine.

Ce sont trois configurations différentes, et elles se confondent parce que toutes trois commencent de la même façon : un second profil et une connexion réussie. Écrivez d’abord la disposition voulue, puis configurez en conséquence. Une phrase d’intention épargne une heure de captures de paquets.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

La première commande liste les instances en cours, y compris celles démarrées à la main hors du gestionnaire. La seconde affiche la revendication de route par défaut actuelle, c’est-à-dire l’état qu’il vous faudra expliquer plus tard.

Les pools qui se chevauchent cassent avant le routage

Deux serveurs distribueront volontiers des adresses issues du même 10.8.0.0/24. Le client tient alors deux interfaces dans un même préfixe sans rien qui dise quelle destination appartient à laquelle, et le comportement obtenu ressemble à une panne de routage mais est en réalité une panne de numérotation. Renuméroter un pool coûte une modification de configuration ; chaque contournement de routage ultérieur coûte un week-end. Vérifiez le pool avant d’y ajouter une route.

Regardez aussi le LAN local. Un LAN domestique numéroté 192.168.1.0/24 qu’un tunnel expose également produit la même ambiguïté, et le symptôme est un nom d’hôte qui se résout alors que la connexion ne s’établit jamais. Cela ressemble à une panne de résolution de noms jusqu’à ce que vous affichiez les routes.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Comparez les deux sorties aux deux configurations de serveur avant de toucher au client. Si les préfixes se chevauchent, arrêtez-vous et renumérotez, car aucun redémarrage ne les séparera.

Donnez à chaque profil son unité et à chaque préfixe un propriétaire

Chaque profil possède son propre nom d’instance et son propre fichier de configuration, donc l’instance nommée office charge office.conf tandis que celle nommée lab charge lab.conf. Confirmez cette correspondance via le gestionnaire de services plutôt qu’en faisant confiance à un listing de répertoire, car un drop-in peut changer le fichier chargé. Se tromper de correspondance signifie que vous réglez le profil qui ne tourne pas.

Décidez ensuite qui installe les routes. Quand les serveurs poussent des ensembles incompatibles, soit vous refusez la poussée et listez les préfixes vous-même, soit vous laissez un profil conserver la route par défaut et pilotez l’autre avec des règles de stratégie. Deux processus qui installent tous deux une route par défaut finissent avec un gagnant silencieux et sans trace écrite de la décision.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

La première montre l’unité avec toute surcharge qui change ses arguments. La seconde montre si le profil accepte du tout les routes poussées, et c’est l’interrupteur qui décide de tout le reste.

Les marques gardent les réponses sur l’interface d’où elles viennent

Quand chaque tunnel sert des sources différentes, une réponse peut sortir par la mauvaise liaison et la connexion meurt après le premier paquet. Le modèle qui tient consiste à marquer les paquets entrants selon l’interface d’entrée, à restaurer cette marque sur la réponse et à donner à chaque marque une table avec sa propre passerelle par défaut.

Le filtrage laxiste du chemin inverse doit généralement être assoupli pour les interfaces concernées, car une réponse arrive légitimement par une liaison que la table principale ne choisirait jamais. Gardez les marques étroites pour qu’elles ne capturent jamais le trafic chiffré des tunnels eux-mêmes, ce qui enverrait le tunnel à travers lui-même.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Lisez les règles existantes avant d’en ajouter une autre. Les priorités en double et les tables oubliées sont la raison habituelle pour laquelle une stratégie de marques semble n’avoir aucun effet.

Prouvez l’isolation en arrêtant une liaison

Les deux tunnels actifs, notez l’adresse de chaque interface, la route vers un hôte derrière chaque tunnel et le chemin que prend une destination sans rapport. Demandez la recherche au noyau plutôt que de lire une seule table, car une table ne montre jamais la décision finale.

Arrêtez ensuite une instance et observez son interface et ses routes disparaître pendant que l’autre continue. Une rupture chez la survivante signifie que les deux partagent encore un nom de périphérique, une route ou une règle de pare-feu que personne n’a séparés.

Remettez le profil arrêté en marche et répétez les mêmes contrôles. Quand un tunnel ne survit qu’au premier démarrage après un redémarrage, vous voyez un défaut de cycle de vie et non une conception de routage.