Deux clients VPN sur un seul poste : ce qui entre en collision et ce qui fonctionne

Votre second client se connecte, les ressources du premier cessent de se résoudre, et le ticket dit que le VPN du travail a cassé celui du personnel. Rien n’est cassé au sens d’une panne : les deux clients ont fait ce pour quoi ils ont été conçus, et la machine n’a qu’une seule table de routage. La collision porte sur quatre ressources que chaque client suppose posséder. Traitez-les dans l’ordre, et le correctif devient généralement un choix de conception plutôt qu’une réparation.

Étape 1 : identifier quel client possède la sortie

Lisez la décision de sortie actuelle avant de changer quoi que ce soit. La recherche de route pour une adresse publique vous indique quelle interface et quel saut suivant un paquet utiliserait à l’instant, et c’est la réponse à qui a gagné. Comparez-la aux noms d’interface créés par les clients, qui portent généralement le nom du produit ou du protocole. Si la recherche pointe vers le tunnel que vous n’attendiez pas, vous avez déjà trouvé la collision.

ip route get 1.1.1.1
ip route show default
route print

Certains clients ne remplacent pas du tout la route par défaut ; ils ajoutent deux moitiés, une pour la moitié basse de l’espace d’adressage et une pour la moitié haute, qui ensemble couvrent tout. Cela laisse la route par défaut d’origine visible et fait paraître une réparation manuelle correcte alors que le trafic sort toujours par le tunnel. Lisez la métrique et la longueur du préfixe, pas seulement la présence d’une entrée par défaut.

Arrêtez-vous si les deux clients revendiquent le même préfixe avec la même métrique. Le noyau en choisira un, et l’autre apparaîtra connecté sans rien transporter.

Étape 2 : vérifier le résolveur et les préfixes qui se chevauchent

Le DNS est la seconde collision, et il produit un symptôme distinctif : les noms échouent alors que les adresses fonctionnent. Chaque client impose son propre résolveur, et le dernier à écrire gagne pour les requêtes suivantes. Demandez au service de résolution ce qu’il utilise par liaison au lieu de lire la page de réglages du client.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Comparez ensuite les préfixes privés qu’utilisent les deux réseaux. Si les deux côtés allouent depuis la même plage, aucun arrangement côté client ne corrigera cela, car la machine ne peut pas dire quelle destination 10.0.0.0/8 appartient à quel tunnel. Un côté doit être renuméroté ou traduit, et c’est une conversation avec les propriétaires du réseau, pas un changement de configuration. Le chevauchement est la seule collision où la réponse honnête est que la conception doit changer.

Arrêtez-vous ici si les préfixes se chevauchent. Tout le reste de cette liste suppose qu’ils ne se chevauchent pas.

Étape 3 : choisir un schéma de séparation qui tient

Les schémas fiables évitent d’exécuter deux clients sur la même table de routage. Un seul client avec une politique de split-tunnel qui atteint les deux réseaux privés est le plus simple, à condition que les destinations ne se chevauchent pas et que le propriétaire de la politique soit d’accord. Une machine virtuelle ou un espace de noms réseau est l’étape suivante, car chacun obtient sa propre table et son propre résolveur.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

Un espace de noms offre la même séparation qu’une machine virtuelle sans le second système d’exploitation, mais il a des angles rugueux : le périphérique du tunnel doit y être déplacé, et l’application doit être lancée à l’intérieur. Un périphérique physique séparé est souvent l’option la moins surprenante pour un VPN personnel à côté d’un client professionnel géré. Empiler un tunnel dans un autre n’est pas un schéma de séparation ; le point de terminaison interne doit rester joignable via le tunnel externe, et l’arrangement ajoute en plus des problèmes de MTU et de latence.

Choisissez un schéma et notez pourquoi. Mélanger un espace de noms pour une application avec un split-tunnel pour le reste recrée la collision d’origine sous une forme plus difficile à déboguer.

Étape 4 : vérifier les deux réseaux depuis la même session

Testez une ressource sur chaque réseau privé depuis l’environnement où l’application s’exécute réellement, pas depuis votre shell si l’application tourne dans un espace de noms. Vérifiez ensemble l’interface de sortie, l’adresse résolue et le code de réponse, car un succès sur l’un des trois peut masquer un échec sur les autres. Répétez après un redémarrage, car l’ordre dans lequel les clients démarrent décide lequel gagne. C’est cet ordre que les gens oublient de consigner.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Consignez les versions des clients, les interfaces, l’état du résolveur et les préfixes de chaque réseau. Lorsqu’un client se met à jour et change son comportement de routage, cette consignation fait la différence entre un correctif de cinq minutes et une reconstruction. La personne suivante ne partagera pas votre souvenir du tunnel qui est monté en premier.

La liste est complète lorsque vous pouvez nommer l’interface qui possède la route par défaut, le résolveur que chaque nom utilise, le schéma qui sépare le second tunnel et le résultat d’une requête par réseau après un redémarrage. Tout ce qui est en dessous est une configuration qui fonctionne par hasard aujourd’hui.