vpnc, OpenConnect ou enveloppe AnyConnect : laquelle choisir ?

Installer un greffon après l’autre jusqu’à ce que quelque chose se connecte peut coûter un après-midi entier, car « Cisco VPN » décrit au moins trois dispositions différentes. Un profil ancien à secret de groupe avec XAuth n’est pas le même service qu’une passerelle compatible AnyConnect, même lorsque la même organisation exploite les deux. Le greffon doit correspondre au protocole et au flux d’authentification, pas au logo du fournisseur. Une entrée de menu indique seulement quelle intégration est présente, jamais laquelle la passerelle acceptera.

Posez deux questions à l’administrateur de la passerelle : quel protocole, et quel client est approuvé pour celui-ci.

Trois intégrations, trois cibles différentes

NetworkManager les répertorie comme des intégrations distinctes. NetworkManager-vpnc couvre l’ancien IPsec compatible Cisco. NetworkManager-openconnect fournit une interface fondée sur OpenConnect pour les protocoles pris en charge, y compris AnyConnect. L’enveloppe AnyConnect répertoriée séparément dépend de l’installation et de la configuration préalables du client propriétaire.

Ce ne sont pas des graphies du même exécutable. En installer une ne fait pas fonctionner les autres, et une entrée qui apparaît dans un menu est un fait d’interface, non une garantie de compatibilité.

L’authentification décide de plus que le transport

Un transport correspondant n’est que le début. La connexion peut exiger un certificat, un transfert vers le navigateur, un second facteur ou un contrôle de posture du poste qu’une interface tierce n’implémente pas. OpenConnect documente plusieurs mécanismes d’authentification, mais une liste de fonctions n’est pas la promesse que chaque passerelle accepte chaque interface. Un secret de groupe issu d’un profil ancien ne doit jamais être collé dans un champ d’authentification sans rapport simplement parce que la case du mot de passe y ressemblait.

Obtenez un profil et le transfert des identifiants pour le client approuvé. Traduire selon la position visuelle est la façon dont les identifiants finissent au mauvais endroit.

La maintenance fait partie du choix

La documentation de NetworkManager lui-même marque le greffon vpnc comme non maintenu et suggère NetworkManager-libreswan comme remplacement possible pour la même famille de protocoles IKEv1. Elle avertit aussi que les profils doivent être recréés et que la parité option par option n’a pas été vérifiée. C’est une direction, pas un outil de conversion.

IKEv1 lui-même est obsolète. Pour une connexion ancienne approuvée, séparez la question à court terme du client à exécuter de la question à long terme du moment où la passerelle changera de protocole.

Les paquets séparent le service de l’éditeur

Un greffon NetworkManager est généralement livré en deux pièces : un composant côté service qui établit le tunnel et une intégration d’éditeur qui permet au bureau de le configurer. Les distributions découpent et nomment ces paquets différemment, et installer seulement le client en ligne de commande peut laisser l’éditeur sans formulaire. Vérifiez les deux moitiés dans la liste de paquets de votre distribution et gardez la version d’exécution compatible avec la version de NetworkManager dans laquelle elle s’insère.

Un client autonome qui fonctionne prouve que le protocole fonctionne. Il ne prouve pas que l’intégration au bureau est installée.

Écrivez le contrat

La réponse de l’administrateur devrait produire cinq lignes : protocole, client ou greffon approuvé, flux de connexion, paquets requis et propriétaire qui maintient la passerelle. Une fois cela écrit, la prochaine panne a un point de départ au lieu d’une liste de greffons à essayer.

Si la réponse est « celui qui se connecte », l’environnement a un problème de documentation qui survivra à ce ticket. Demandez à nouveau avec les entrées de menu précises sous les yeux.