Comment tester un second client VPN sur un Mac sans perdre le premier

Vous installez le second client pour le comparer, et le premier cesse de fonctionner. Rien n'a été supprimé, et les deux applications sont toujours installées. Ce qui a changé se trouve en dessous : une extension système, un réglage DNS ou une route par défaut, et les deux clients ne s'accordent plus sur qui en est propriétaire. L'installation n'est pas la partie risquée ; la partie risquée est de faire tourner les deux sans référence consignée à laquelle revenir.

Le symptôme : la configuration qui fonctionnait s'arrête après la seconde installation

Les clients VPN modernes de macOS fournissent souvent une extension réseau plutôt qu'une interface à l'ancienne. L'installation de l'une peut demander une approbation, ajouter un profil de configuration ou enregistrer une extension système qui influence le trafic avant même qu'une connexion soit établie. L'extension se charge avant l'apparition de la fenêtre de l'application, ce qui explique pourquoi le client d'origine peut échouer pendant que le nouveau reste inactif.

Si ensuite le client d'origine ne parvient pas à se connecter, ou se connecte sans rien résoudre, la nouvelle extension est le premier suspect. Ce n'est pas la preuve d'un conflit, mais c'est là que l'enquête commence. Vérifiez ensuite la liste des extensions et les profils de configuration installés, pas seulement le dossier des applications.

Consignez la référence avant d'installer quoi que ce soit

Notez ce qui fonctionne actuellement : le résultat de l'application, la version du client, le point de terminaison auquel il se connecte et toute exclusion par application ou de tunnel divisé. Enregistrez le profil d'origine via le processus protégé pris en charge par le client, et non en copiant des fichiers depuis un paquet d'application.

scutil --dns | head -40
netstat -rn | head -30
ifconfig | grep -E "^(utun|ipsec)"

Capturez ces trois sorties pendant que le client qui fonctionne est connecté. Elles vous donnent l'état du résolveur, la table de routage et la liste des interfaces que produit une configuration fonctionnelle, et c'est exactement ce qu'il faut pour comparer plus tard. Si le Mac est géré par un employeur, confirmez avant de commencer que la comparaison est autorisée, car une connexion professionnelle automatique peut se réactiver pendant le test et le résultat ne représente alors aucun des deux clients à lui seul. Conservez les trois sorties à côté de la note de profil pour que la comparaison ultérieure ait une référence.

Changez un chemin actif à la fois

Arrêtez la connexion d'origine avec sa commande habituelle, puis démarrez l'alternative. Deux clients connectés en même temps produisent un résultat qui décrit la combinaison, et non l'un des produits. Gardez le point de terminaison et la tâche comparables si les services le permettent, car un téléchargement plus rapide via un autre serveur compare deux options de connexion et non deux applications.

Si le nouveau client échoue, conservez sa première erreur avant de changer quoi que ce soit d'autre. La première erreur nomme généralement l'étape, et une seconde tentative après un changement de réglages signale souvent quelque chose de moins utile.

Comparez le DNS, les routes et l'application, pas seulement le débit

Exécutez les trois mêmes commandes avec le nouveau client connecté et comparez-les ligne par ligne. Un résolveur qui pointe ailleurs, ou une table de routage sans le sous-réseau privé, explique la plupart des différences de comportement avant même d'examiner le débit. Testez ensuite l'application réelle avec la même tâche, car un client qui se connecte vite et échoue à résoudre un nom interne n'a pas gagné la comparaison, même si la fenêtre d'état semble meilleure.

Notez quelle interface le trafic a utilisée. Sur macOS, le nom de l'interface de tunnel n'est pas un indicateur fiable du client qui possède la route, alors associez la liste des interfaces à la table de routage plutôt que de n'en lire qu'une. Si deux interfaces utun existent, celle qui transporte votre trafic est celle qui a une route correspondante et une entrée de résolveur. Deviner à partir du nom est la façon dont la mauvaise interface est mise en cause, car l'interface qui existe n'est pas toujours celle qui transporte le trafic.

Lisez les trois sorties au lieu de les parcourir. Dans le vidage du résolveur, un serveur de noms rattaché à une interface utun indique quel client l'a installé ; dans la table de routage, la route par défaut nomme l'interface qui transporte le trafic ; dans la liste des interfaces, un second périphérique utun signifie qu'un second tunnel a été créé. Ces trois lignes, comparées à la référence, séparent une configuration rétablie d'une configuration où les deux clients se disputent encore.

Rétablissez, puis retirez proprement

Revenez par le flux de travail propre au client d'origine et confirmez que les sorties de référence correspondent à ce que vous avez consigné. Si le résolveur ou la table de routage ne se rétablit pas, arrêtez-vous et corrigez cela avant de retirer quoi que ce soit d'autre. Retirez la configuration inutilisée via le composant qui la possède : le désinstalleur du client, le profil ou les réglages de l'extension système.

Terminez en mettant à jour vos notes avec la version testée, le point de terminaison utilisé et le résultat pour chacun. Six mois plus tard, cette consignation fait la différence entre une décision et une rumeur.