vpncli -s ou l’interface graphique : se connecter à Cisco Secure Client

Cisco Secure Client offre deux façons de répondre aux mêmes invites de connexion : une personne qui tape dans vpnui.exe, ou un script qui alimente vpncli.exe en réponses via l’entrée standard avec -s. La seconde rend possibles les connexions planifiées sans lire l’écran de l’interface graphique, et elle transforme aussi une connexion en fichier qu’il faut protéger comme un identifiant. Celle que vous voulez dépend de la présence d’un humain devant la machine et de la fréquence de rotation du mot de passe. Aucune option ne change ce que la passerelle demande, seulement qui répond.

Les deux chemins aboutissent au même tunnel, la comparaison porte donc sur l’exploitation, pas sur le protocole.

Deux façons de répondre aux mêmes invites

Le chemin de l’interface graphique est interactif par conception : le client demande, quelqu’un répond, et la session vit tant que cette personne la laisse tranquille. C’est le bon choix sur un portable utilisé par un humain, car les invites s’adaptent à la méthode d’authentification de la passerelle et personne n’a à garder un mot de passe en clair sur le disque.

Le chemin du script convient à un kiosque, une machine de laboratoire ou une tâche planifiée où personne n’est là pour taper. L’échange est explicite : vous acceptez un fichier d’identifiants sur le disque en échange d’une connexion sans surveillance. Si la passerelle propose une authentification par certificat ou SAML, cet échange ne vaut généralement pas la peine, car le fichier n’existe que pour répondre à des invites qu’une méthode plus forte éviterait.

Ne mélangez pas les deux sur une même machine en même temps. La ligne de commande et le client graphique se disputent le même état de session, et c’est le problème de la section suivante.

Ce que le fichier de réponses doit contenir

Le client demande dans l’ordre — passerelle, parfois une sélection de groupe, nom d’utilisateur, mot de passe et toute confirmation de bannière. Un fichier qui répond à tout cela ressemble à ceci, avec les vraies valeurs substituées :

connect vpn.example.com
MyGroup
alice
correct-horse-battery
y

La façon fiable de construire ce fichier est de se connecter une fois à la main, de noter chaque ligne que vous tapez et chaque appui sur Entrée, puis de reproduire exactement cette séquence. Les déploiements qui stockent le groupe et le nom d’utilisateur dans le profil peuvent avoir besoin de lignes vides là où ces invites n’apparaissent plus, et la dernière ligne a toujours besoin de son propre saut de ligne. Un fichier auquel il manque une ligne se bloque généralement à la dernière invite au lieu d’échouer avec une erreur claire, et c’est pourquoi on en accuse le réseau. Comparez le fichier à votre transcription deux fois, une fois pour l’ordre et une fois pour les lignes vides.

Gardez le fichier hors de tout dossier synchronisé et lisible uniquement par le compte qui exécute la tâche. Ce mot de passe est en clair, le fichier est donc un identifiant : pas de dépôt, pas de disque partagé, pas de pièce jointe dans un ticket. Le client ne vous avertira d’aucun de ces points.

Pourquoi l’interface graphique doit partir en premier

Commencez le script en terminant le processus de l’interface graphique, puis lancez la CLI depuis son propre répertoire d’installation, car le répertoire de travail et la version du client comptent tous deux. Un enrobage illustratif :

@echo off
taskkill /IM vpnui.exe /F >nul 2>&1
cd /d "%PROGRAMFILES(x86)%\Cisco\Cisco Secure Client"
vpncli.exe -s < C:\secure\login.txt

Les codes de sortie ne sont pas ici un signal de succès fiable. Le client imprime sa progression et garde le tunnel dans un processus séparé, alors lisez la sortie pour la ligne d’état de connexion et ne commencez qu’ensuite le travail qui dépend du VPN.

Si vous sautez la fermeture de l’interface graphique, le script peut sembler s’exécuter alors que la session existante reste dans l’état où l’utilisateur l’a laissée. Cette panne paraît intermittente, ce qui est exactement le genre de bug qui survit à une semaine de suppositions.

Confirmez une session, ne la supposez pas

Une fois le script revenu, vérifiez quelque chose qui n’existe qu’à l’intérieur du tunnel — un hôte interne ou un suffixe DNS auquel seul le résolveur d’entreprise répond. Lisez aussi la ligne d’état de connexion dans la sortie du client et traitez tout le reste comme un échec plutôt qu’un succès lent. Relancer le fichier alors qu’une session est déjà ouverte peut laisser le client à moitié configuré, alors soit déconnectez d’abord, soit sautez la connexion quand la session est présente.

Décidez ensuite qui est responsable de la reconnexion. Une boucle qui ping une adresse interne et relance la connexion peut maintenir un kiosque en ligne pendant des mois, et elle peut aussi verrouiller un compte la première fois que le mot de passe tourne. Limitez le nombre de tentatives, alertez en cas de dépassement et laissez l’équipe identité faire tourner le fichier au lieu de laisser un mot de passe périmé réessayer jusqu’au verrouillage.

L’ancien vpnclient.exe n’est pas le même outil

La même automatisation apparaît sous un nom plus ancien, et les deux ne sont pas interchangeables. Le client Cisco IPsec retiré utilisait vpnclient.exe avec des arguments en ligne comme un verbe connect, un nom de profil, un utilisateur et un mot de passe sur une seule ligne de commande ; vpncli.exe attend une séquence d’invites sur l’entrée standard avec -s. Copier un ancien script de forum sur une machine actuelle produit donc une commande qui s’exécute, ne fait rien de visible et dont on accuse la passerelle.

Avant de modifier le moindre argument, vérifiez quel client est installé et lequel le script appelle réellement. La différence de nom est assez petite pour passer inaperçue dans une tâche planifiée, et c’est la première chose à vérifier quand un script hérité a cessé de fonctionner après une mise à jour.