Deux clients OpenVPN sur un même hôte Linux : à qui appartient la route ?

Les deux profils signalent une connexion et l’un d’eux transporte discrètement du trafic destiné à l’autre. Deux clients sur un même hôte est un agencement pris en charge ; deux clients sans propriétaire pour chaque préfixe ne l’est pas. Le travail consiste moins à monter le second tunnel qu’à décider quel processus peut revendiquer quelle route. Suivez l’ordre ci-dessous et la configuration découle des réponses.

Commencez par demander à quoi sert le second tunnel

Trois situations se ressemblent sur la ligne d’état et exigent des conceptions différentes. Une répartition par destination envoie un préfixe par le profil bureau et un autre par le profil laboratoire, sans qu’aucun ne revendique de route par défaut. Une répartition par application garde généralement un tunnel complet et dirige un trafic précis par des règles de politique. Le basculement de secours maintient exactement un tunnel actif à la fois, ce qui signifie que le second ne doit pas démarrer automatiquement.

Écrivez le cas avant d’ouvrir le moindre fichier de configuration, car cette réponse décide de tout ce qui suit.

L’agencement cassé le plus courant est deux tunnels complets qui ont tous deux poussé une route par défaut, où celui qui s’est connecté en dernier gagne et le premier continue de faire semblant. Cet état paraît intentionnel depuis la ligne d’état et gaspille une journée de la table de routage. Nommer le cas d’abord le rend impossible plutôt que simplement improbable.

Regardez les pools avant les routes

Deux serveurs peuvent facilement distribuer des adresses d’une même plage privée, et lorsqu’ils le font, le client se retrouve avec deux interfaces dans un seul préfixe. Aucune destination ne peut alors être attribuée à une interface par adresse, car les deux semblent également correctes. Renumérotez un pool au lieu d’inventer une règle pour départager.

Vérifiez aussi le réseau local, car un LAN domestique ou de bureau qui chevauche une plage de tunnel crée la même ambiguïté de l’autre côté. Comparez les adresses de l’hôte avec les deux configurations serveur avant de blâmer le client. Un changement de pool sur un serveur de laboratoire est une correction de cinq minutes, tandis qu’un contournement par routage politique pour un préfixe chevauchant est une taxe permanente pour quiconque lira la configuration plus tard. Décidez lequel des deux vous voulez avant de choisir où intervenir.

Deux familles d’adresses signifient deux tours de cette vérification. Les pools IPv6 entrent en collision aussi discrètement que les IPv4.

Donnez à chaque profil un propriétaire

Une instance par profil, un fichier de configuration par instance et un nom qui identifie la paire. Dans l’empaquetage de style Debian, le nom après l’arobase sélectionne le fichier, ce qui explique que deux profils partageant un nom d’instance ne puissent jamais fonctionner tous les deux. Confirmez la correspondance depuis l’unité installée et non depuis un tutoriel.

systemctl cat [email protected]
ip -4 addr show

Décidez ensuite qui installe les routes, ce qui est une question de politique et non de syntaxe.

Quand les deux serveurs poussent des ensembles incompatibles, soit ajoutez route-nopull et ne listez que les préfixes dont chaque profil a besoin, soit laissez l’un conserver sa route par défaut et dirigez le reste par une règle de politique. Deux processus qui installent tous deux une route par défaut finissent avec un seul gagnant et personne ne peut dire pourquoi. Dès que les deux tunnels portent du trafic de sources différentes, une réponse peut sortir par le mauvais, et le schéma qui tient est une marque de connexion restaurée sur les réponses et dirigée vers sa propre table. Limitez les marques pour que les paquets chiffrés propres aux tunnels ne les rencontrent jamais.

Vérifiez par tunnel, puis arrêtez-en un

Une fois les deux actifs, prenez trois relevés : l’adresse de chaque interface de tunnel, la route vers un hôte qui vit derrière chacune et le chemin qu’emprunterait une destination hors des deux. Une liste de routes ordinaire cesse de décrire la recherche finale dès que des règles entrent en jeu, alors demandez au noyau ce qu’il choisirait réellement. Arrêtez ensuite une instance et regardez ce qui disparaît. Si l’arrêt de la première perturbe la seconde, quelque chose est encore partagé entre elles : une route, un nom d’interface ou une règle de pare-feu que personne n’a séparée.

ip rule show
ip route get 203.0.113.9

Remontez le profil arrêté et répétez les mêmes vérifications, car un tunnel qui fonctionne une fois après un redémarrage et plus jamais est un bug de cycle de vie déguisé en routage.

Notez dans les notes de déploiement quel profil possède quel préfixe, à côté des plages de pools. Deux tunnels sont un agencement délibéré, et le prochain lecteur doit voir la frontière avant de toucher l’un ou l’autre profil. Sans cette note, la frontière est redécouverte par la personne d’astreinte quand le préfixe partagé finit par casser.