Le deuxième client VPN a cassé le premier : trouvez la ressource partagée

Hier, le client d’origine fonctionnait. Aujourd’hui, le nouveau venu réclame une connexion tandis que l’ancien profil s’arrête à une étape qu’il franchissait sans se plaindre. Les identifiants sont rarement en cause, et la passerelle est généralement innocente. Ce qui a changé, c’est que deux piles VPN veulent désormais la même ressource exclusive, et la réparation dépend de sa désignation. Parcourez les couches au lieu de réinstaller les deux.

Parcourez les quatre couches dans l’ordre

Un produit VPN a besoin de quatre ressources qui peuvent entrer en collision : un service d’arrière-plan qui refuse souvent de tourner deux fois, un port fixe, une carte virtuelle ou un filtre noyau qui voit le trafic avant la table de routage, et le droit d’installer des routes avant celle par défaut. Savoir laquelle a cédé transforme un conflit vague en une seule question dont la réponse est testable.

Associez le symptôme à une couche avant de toucher à quoi que ce soit. Un client qui ne démarre pas pointe le service ; celui qui démarre sans jamais négocier pointe le port ; celui qui se connecte alors que l’autre perd toute connectivité pointe le filtre ou la route par défaut. Notez cette correspondance, car elle épargne une heure de réinstallation d’applications dans l’espoir.

Commencez par le service qui ne tourne pas deux fois

Sous Windows, un client d’entreprise est généralement plus qu’un tunnel, car il installe un service, un pilote de filtre et parfois un fournisseur d’identifiants à côté du profil. Notez quels services tournent avant le changement et de nouveau après, puis comparez les deux listes au lieu de redémarrer jusqu’à ce que quelque chose marche. Les services peuvent aussi s’exclure par des dépendances, où le démarrage de l’un arrête l’autre, et le même schéma apparaît sous macOS avec des tâches launchd et un démon partagé. Un client qui démarre et s’arrête en quelques secondes signale une propriété, pas une configuration.

Lisez l’état du service et son journal avant de lire le profil. Un service qui a démarré et s’est arrêté dans la même minute est le schéma à rechercher, et son propre journal d’événements nomme la dépendance qui l’a délogé. Un profil ne peut pas réparer un processus qui ne tourne pas, et le temps passé à le modifier est du temps non consacré au conflit réel.

Demandez ensuite qui possède le port

La propriété du port est la preuve la plus claire que vous obtiendrez, car un échec de liaison nomme le conflit d’emblée. Deux implémentations IKE ne peuvent pas répondre toutes les deux sur la même adresse locale et le même port UDP, et aucun nombre de tentatives ne change cela.

Get-NetUDPEndpoint -LocalPort 500,4500 | Select-Object LocalAddress,LocalPort,OwningProcess
netstat -ano | findstr :500
sudo lsof -nP -iUDP:500
ss -lunp | grep -E ':500|:4500'

Quelle que soit la ligne qui correspond à votre plateforme, la réponse que vous voulez est un processus et le service qui l’a engendré. Si l’écouteur est le service IKE intégré, le deuxième client est l’intrus ; si c’est un agent de fournisseur, le client intégré l’est. Décidez lequel peut démarrer à l’ouverture de session et désactivez le démarrage automatique de l’autre plutôt que de le tuer à chaque session.

Le pilote de filtre se trouve sous vos routes

Un pilote de filtre réseau intercepte le trafic entre la carte et la pile de protocoles, il peut donc réécrire ou bloquer des paquets quoi que dise la table de routage. C’est ainsi qu’une route qui semble correcte est ignorée, et pourquoi un ping réussi peut cohabiter avec un navigateur qui ne charge rien.

Les composants du fournisseur se lient aussi à des connexions précises. Un filtre hérité lié à une carte peut empêcher un profil par ailleurs correct de terminer sa poignée de main, et détacher ce composant des propriétés de la carte est plus étroit et plus réversible que de retirer complètement le produit. Comme la liaison est par connexion, comparez les cartes plutôt que toute la pile.

Décidez quel produit possède le démarrage, puis consignez-le

La coexistence n’est réaliste que lorsque les deux clients occupent par conception des couches différentes, comme une pile IPsec à côté d’un proxy qui ne traite que le trafic applicatif. Là où les deux veulent le même port, la même couche de filtre ou le droit de publier une route par défaut, ils continueront à alterner et chaque échec ressemblera à une nouvelle panne.

Choisissez le propriétaire délibérément. Les formes qui survivent à un redémarrage incluent l’exécution du second client dans une machine virtuelle, son maintien sur du matériel dédié, ou la standardisation sur un seul client qui parle les deux protocoles. Désactiver le démarrage automatique et le service du perdant est un changement plus petit que de reconstruire la table de routage après chaque démarrage, et cela s’annule d’une seule modification de réglage.