Deux VPN sur une seule machine Linux : tester chacun sans mélanger les résultats

Deux icônes de connexion vertes ressemblent à une comparaison et ne sont le plus souvent qu’une coïncidence. Si la requête de test pouvait emprunter l’un ou l’autre tunnel, le résultat décrit au mieux l’un des deux et au pire aucun. Donnez à chaque observation un contexte réseau, une destination visée et une attente écrite avant que le test ne s’exécute. Sur une machine Linux que vous administrez vous-même, les espaces de noms réseau nommés sont le moyen le moins coûteux d’acheter cette séparation.

Deux voyants verts ne font pas une comparaison

Un espace de noms sépare les tables de routage, les interfaces et l’état de la pile réseau, si bien qu’une requête lancée dans l’un ne peut pas emprunter discrètement le tunnel d’un autre. Ce qu’il ne sépare pas, c’est un processeur, une liaison montante physique ou le démon résolveur qui tourne sur l’hôte. C’est précisément dans ce dernier vide que la plupart de ces tests échouent sans que personne ne le remarque. Une résolution qui quitte l’espace de noms et interroge le résolveur de l’hôte renvoie une réponse sans aucun rapport avec le tunnel testé.

Cette procédure suppose deux espaces de noms de test déjà préparés et approuvés, avec une connectivité extérieure fonctionnelle et des clients pris en charge. Elle ne crée rien, n’enregistre rien et ne remplace aucune configuration. Les machines virtuelles séparées restent le choix honnête lorsqu’un client a besoin d’une session de bureau complète ou refuse de s’exécuter en dehors.

Fixez l’attente avant la première exécution

Décidez pour chaque contexte à quoi ressemble le succès : le résolveur, le nom du service, l’adresse attendue et le comportement exigé lorsque le tunnel tombe. Gardez ces valeurs planifiées dans leur propre colonne, car un relevé qui mélange plan et observation est une fiction horodatée. La liste ci-dessous est la forme dont le relevé a besoin, et chaque ligne doit pouvoir être remplie avant la première connexion.

Le câblage du résolveur mérite sa propre ligne dans ce relevé, car c’est le champ le plus susceptible de mentir. Les fichiers liés à l’espace de noms, comme /etc/netns/vpn-a/resolv.conf apparaissent à leurs chemins habituels lorsqu’une commande s’exécute à l’intérieur de l’espace de noms, comme le décrit la référence iproute2 sur les espaces de noms, mais la configuration du basculement du service de noms et tout résolveur local qu’elle lance peuvent encore ramener une résolution vers l’hôte.

Un tunnel à la fois, l’autre déconnecté

Connectez A via son propriétaire existant pendant que B reste hors ligne, puis examinez la politique, les routes et le chemin retenu depuis le contexte d’administration. Trois des commandes ci-dessous lisent l’état ; seule la dernière contacte un service de noms, et aucune n’envoie de requête applicative.

sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internal

Une recherche de route répond à une question hypothétique sur une destination, elle ne peut donc pas montrer que le service accepte du trafic. Gardez ces deux types de preuves dans des colonnes séparées, car une route saine à côté d’une connexion refusée est un résultat réel et fréquent. Envoyez ensuite une requête autorisée et inoffensive avec la véritable application, lancée dans le contexte de A comme son utilisateur normal non privilégié, la validation des certificats et l’authentification applicative intactes, et consignez le résultat avec l’adresse source observée par le service. Déconnectez A via son propriétaire et répétez toute la ligne de base pour B, en notant chaque changement de configuration que vous faites, sinon les deux lignes de base cessent d’être comparables.

Les deux en haut, puis un en bas à la fois

L’état stable est la partie facile. Les deux tunnels connectés, répétez la résolution et la requête applicative de chaque contexte, puis coupez un tunnel et vérifiez l’autre. Reconnectez dans l’ordre inverse lorsque l’ordre de connexion est lui-même la question.

sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20

La capture tranche des débats qu’un résultat applicatif ne peut pas trancher : elle montre si la requête est sortie par l’interface attendue ou par tout autre chose. Pour chaque transition, consignez l’action du propriétaire, l’horodatage, le résultat de la route, le résultat du nom et l’issue applicative. Vérifiez ensuite l’exigence de fermeture sûre dans l’espace de noms concerné, car l’isolation n’est pas un interrupteur d’urgence. Un espace de noms garde deux tunnels séparés ; il n’empêche aucun des deux de porter du trafic lorsque son profil dit que le trafic doit s’arrêter.

Ce que ce relevé peut affirmer et ce qu’il ne peut pas

Une réussite prouve ces observations pour cette disposition, sur cet hôte, à ce moment-là. Elle ne dit rien de deux clients qui partagent une table de routage de bureau, ni du débit pendant que les deux tunnels portent une charge. Ce sont des questions distinctes avec des tests distincts, et une comparaison ne vaut que par le contexte attaché à chaque ligne.

Gardez les échecs dans le relevé à côté des réussites, étiquetés selon le tunnel qui était actif à ce moment-là. Une page propre qui cache l’état au moment de la mesure est pire qu’une page laide qui le montre. Ce qui rend le relevé réutilisable plus tard, c’est le contexte, pas le score.

Deux tunnels sur une machine peuvent être comparés honnêtement, mais seulement dans autant de contextes que vous en avez réellement contrôlés. Tout ce qui va au-delà est un souhait avec une icône verte à côté.