Le Mac affiche Cisco VPN : lequel des trois utilisez-vous vraiment ?
Une entrée IPsec native, le Cisco VPN Client abandonné et Secure Client portent tous le même nom. Identifiez le propriétaire avant d’appliquer d’anciens correctifs.
Quelqu’un vous dit que le Cisco VPN est en panne sur son Mac, et cette formule recouvre au moins trois objets différents. Elle peut désigner un profil intégré à macOS, une application d’une époque révolue ou le client que votre organisation déploie aujourd’hui. Chacun a ses propres modes de défaillance, et un correctif écrit pour l’un est généralement sans rapport avec les deux autres.
Le premier travail n’est donc pas un correctif. C’est une identification, et elle prend environ une minute si vous demandez les bons détails.
| What the user has | What actually needs identifying |
|---|---|
| An entry under System Settings with a Cisco IPsec type | The native profile's protocol and the authentication settings the administrator supplied |
| The old Cisco VPN Client application | Whether that product is supported at all on the installed macOS release |
| Cisco Secure Client, formerly AnyConnect | The installed release, the managed profile and the gateway service in use |
Une étiquette native n’est pas un pilote Cisco installé
Apple fournit un type de VPN nommé Cisco IPsec, et il est utile, mais c’est l’implémentation par Apple d’un montage IPsec, pas l’ancienne application tierce ni ce que votre équipe sécurité déploie ailleurs. L’étiquette vous indique quel panneau de configuration ouvrir et rien sur le support de l’éditeur.
L’erreur inverse coûte plus cher. Supposer qu’une entrée native peut remplacer Secure Client saute l’enrôlement, la gestion des certificats, les contrôles de posture et la politique qu’attend la passerelle. Un profil poussé par l’organisation n’équivaut pas à une connexion saisie à la main, même lorsque les deux finissent par établir un tunnel IPsec. Cette différence est invisible dans le panneau des réglages et évidente dans les journaux de la passerelle elle-même.
Demandez au propriétaire de la passerelle trois choses : le client Mac qu’il prend en charge, le nom exact du profil et la version minimale du client. Ajoutez la version de macOS que l’utilisateur exécute. Un nom d’hôte de serveur seul ne décrit rien de tout cela, et c’est pourquoi les tickets qui ne contiennent qu’un nom d’hôte ont tendance à revenir.
Les vieux conseils sur le noyau appartiennent à leur propre décennie
Les résultats de recherche sur les problèmes de VPN sur Mac regorgent d’instructions pour maintenir des touches enfoncées au démarrage, démarrer sur une autre architecture de noyau ou exécuter un utilitaire plus ancien que les protections actuelles d’intégrité du système. Ces étapes proviennent de combinaisons anciennes précises de matériel Mac et de versions du client. Les répéter aujourd’hui n’est pas une migration, et sur une version actuelle certaines ne peuvent pas être exécutées du tout.
Il existe une limite connexe qu’il vaut la peine de connaître, car elle est citée hors contexte. Apple documente que les applications 32 bits ont cessé d’être compatibles avec macOS à partir de Catalina 10.15, donc un client aussi ancien ne peut tout simplement pas y fonctionner, quels que soient les pilotes ou les autorisations. C’est une limite de compatibilité applicative, pas un problème de mode noyau, et mélanger les deux explications produit des conseils qui n’aident personne.
S’il ne reste qu’un client obsolète, traitez son profil comme un matériau de migration sensible et demandez le remplacement approuvé. Ne désactivez pas les protections du système, n’installez pas de pilote non signé et ne renommez pas un fichier portant l’extension .pcf en espérant qu’un client moderne l’importera : un PCF appartient au format de l’ancien client, Secure Client utilise son propre mécanisme de profils, et les deux ne sont pas interchangeables par extension.
Séparez le client du réseau
Lorsque le client pris en charge est déjà installé et fonctionne globalement, la question intéressante change. Échoue-t-il partout, ou seulement sur un réseau d’accès ? Un client qui se connecte depuis une connexion domestique et échoue dans un hôtel décrit une atteignabilité, pas une architecture, et réinstaller l’application ne changera pas le filtrage de l’hôtel. Testez le même ordinateur portable sur un réseau de confiance avant de toucher à l’installation.
Capturez la défaillance avant de changer quoi que ce soit. Le journal du client nomme généralement la phase qui a échoué : sélection du profil, authentification, établissement du tunnel ou politique. Comparez-le à une tentative réussie depuis un autre réseau sur la même machine, car la variable testée est le réseau, et le client est la constante.
Notez la réponse pour le prochain ticket
Une fois que vous savez lequel des trois vous concerne, consignez-le dans le ticket avec la version installée et la version de macOS. Cette seule ligne évite au prochain ingénieur de repartir de zéro et rend possible une escalade vers l’éditeur sans deuxième série de questions.
Vérifiez ensuite la seule chose dont l’utilisateur a réellement besoin : si le client actuel peut atteindre la ressource, et pas seulement si l’indicateur de tunnel est devenu vert. Pour la limite de compatibilité qui revient sans cesse dans ces fils, la note d’Apple sur la fin du support des applications 32 bits avec macOS Catalina est la référence à citer plutôt que le folklore.