Cisco Secure Client sur Mac : fenêtre, connexion automatique ou reconnexion ?

Quelque chose lié à Cisco apparaît après votre connexion, et il se peut qu'il connecte quelque chose ou non. La fenêtre, la connexion automatique et la reconnexion après un changement de réseau sont trois comportements distincts avec trois responsables distincts. La plupart des tentatives frustrées de supprimer un élément de démarrage partent de ces trois fondus en une seule plainte. Séparez-les d'abord et la demande de changement s'écrit toute seule.

Nommez le comportement que vous voyez réellement

Observez une connexion sans rien toucher et notez ce qui se passe, dans l'ordre. Une fenêtre qui s'ouvre sans connexion est un cas, une fenêtre qui s'ouvre et se connecte en est un autre, et une connexion qui revient après le changement de réseau en est un troisième. Demandez ce qui établit réellement le tunnel plutôt que ce qui apparaît à l'écran, car la fenêtre et le tunnel ont des propriétaires différents. Deux types de preuves répondent à cela, et une seule voit ce client :

scutil --nc list
ps aux | grep -i [v]pnagentd
ifconfig | grep -A3 utun

Lisez les trois sorties ensemble, car scutil --nc list liste les configurations VPN du système et une liste vide signifie seulement qu'aucun service VPN du système ne possède de tunnel. Cisco Secure Client n'en enregistre pas : il se termine via vpnagentd et une interface utun, donc le processus et l'interface sont les preuves qui le voient. Lorsque vpnagentd s'exécute et qu'une interface utun détient une adresse, le tunnel existe même fenêtre fermée ; quand aucun des deux n'est présent, la connexion automatique est désactivée et la fenêtre est le seul sujet de discussion. Le front end peut aussi s'exécuter pendant qu'un service d'arrière-plan distinct possède le tunnel, donc la question de la propriété relève des sections de profil et non de celle-ci.

La fenêtre à la connexion est une question de démarrage

Une fenêtre de connexion vient d'un agent de lancement ou de la préférence propre à l'application d'ouverture à la connexion, et aucune des deux n'est le même mécanisme que la politique de connexion. Identifiez le produit et la version installés avant de modifier quoi que ce soit, car la documentation des anciennes versions décrit des fichiers qu'une installation actuelle peut ne pas utiliser. Désactiver la connexion automatique n'arrête pas forcément l'ouverture de la fenêtre, et arrêter la fenêtre n'arrête pas une reconnexion. Utilisez le contrôle de démarrage pris en charge du client ou le processus logiciel de votre administrateur, dans cet ordre.

Sur un Mac géré, confirmez si le comportement arrive par un profil de configuration installé avant de le traiter comme une préférence locale. Le système peut lister les profils qu'il possède, et un élément de connexion géré ne vous appartient pas :

profiles show -type configuration

Là où le réglage est contrôlable par l'utilisateur, modifiez-le dans les préférences du client et déconnectez-vous pour tester. Là où il est verrouillé, seul le propriétaire du profil peut le changer. Supprimer des fichiers localement produit une divergence que la mise à jour suivante répare silencieusement, ce qui en fait la correction la moins durable disponible. Une case à cocher grisée n'est pas un client cassé ; c'est une déclaration de politique.

Auto Connect on Start est une préférence distincte

Le guide de connexion de Cisco nomme Auto Connect on Start comme la préférence qui contrôle une tentative de connexion au lancement du client, et la décrit comme désactivée par défaut. Un profil déployé peut l'activer, et c'est pourquoi deux Mac avec le même client se comportent différemment à la connexion. Cherchez cette préférence dans les réglages du client avant de supposer quoi que ce soit sur les éléments de démarrage.

Changez-la via le contrôle pris en charge et testez avec une déconnexion complète plutôt qu'un relancement, car certains composants ne démarrent qu'avec la session de connexion. Confirmez ensuite que la connexion manuelle fonctionne toujours, car une préférence qui supprime la tentative automatique ne devrait pas retirer votre capacité à vous connecter. Si le client se reconnecte tout de suite malgré tout, vous regardez le comportement de reconnexion. C'est la question suivante, et elle a un autre responsable.

Auto Reconnect relève d'un troisième réglage

La reconnexion régit ce qui se passe après qu'une session établie perd son chemin : fermeture du capot, changement de réseau Wi-Fi, chute d'une liaison filaire. Cisco la documente séparément du comportement de démarrage, donc un changement de démarrage n'y touchera pas. Testez-la en déconnectant le réseau un instant et en observant si le tunnel revient sans intervention.

Une reconnexion qui ignore une déconnexion délibérée relève généralement de la politique plutôt que d'un bogue. Certains déploiements exigent une disposition toujours active, qui relève d'une conversation de politique plutôt que d'un contournement. Supprimer le composant qui l'impose peut casser les contrôles de posture et être ensuite restauré par la prochaine poussée de gestion. Si l'exigence est légitime, demandez ce qu'elle est censée garantir et si un réglage plus étroit la satisfait ; sinon, le propriétaire du profil peut la changer à un seul endroit au lieu que vous la changiez sur quarante portables.

Demandez le plus petit changement, puis vérifiez-le

Écrivez la demande avec quatre faits : quelle version du client vous exécutez, quelle version de macOS vous exécutez, ce qui apparaît après une connexion et si un tunnel se forme sans intervention. Énoncez ensuite le résultat souhaité en une phrase qu'un collègue pourrait mettre en œuvre sans vous demander. Garder le client disponible mais fermer sa fenêtre est une demande différente de celle d'empêcher une connexion automatique. Une demande précise obtient un changement de politique, tandis qu'une demande vague obtient un contournement que personne ne possède.

Après le changement, déconnectez-vous et reconnectez-vous, puis exécutez le flux de connexion manuelle dont vous dépendez. Si la reconnexion faisait partie du périmètre, testez-la séparément selon la procédure que votre administrateur autorise.

Vérifiez que les modules de sécurité exigés par l'organisation fonctionnent toujours, car une suppression silencieuse est facile à manquer jusqu'à ce qu'un audit la trouve. Le résultat que vous voulez est le comportement de démarrage demandé avec un client qui fonctionne, pas une icône absente et un mystère. Notez lequel des trois comportements a changé, pour que la personne suivante puisse distinguer une vraie correction d'une coïncidence.