Le script se termine avec zéro, le tunnel apparaît, et l’exécution suivante est refusée avant même qu’il demande un mot de passe. Ou la même commande fonctionne dans un terminal et échoue depuis une tâche planifiée avec une erreur « événement introuvable » qui ne nomme rien d’utile. Les deux sont la conversation sur l’entrée standard du client AnyConnect qui tourne mal, pas une panne réseau. Traitez la connexion comme une question-réponse écrite et les échecs deviennent prévisibles et petits.

Pourquoi la même commande échoue dans un script

Le client lit ses réponses sur l’entrée standard, une ligne par invite, dans l’ordre où la passerelle les demande. Tout ce qui change le nombre d’invites, comme une nouvelle bannière, un sélecteur de groupe ou un défi de second facteur, décale chaque réponse suivante d’une ligne. Le client lit alors un nom d’utilisateur là où il attendait un mot de passe et signale un échec qui ne pointe vers ni l’un ni l’autre.

Un mot de passe contenant un point d’exclamation ajoute un second échec plus discret. Entre guillemets doubles, le shell l’étend bien avant que le client ne voie quoi que ce soit.

Mettez la charge utile entre guillemets simples et le caractère voyage intact. C’est toute la correction, et elle explique toute une classe de rapports où le même identifiant fonctionne à la saisie et échoue à l’enregistrement. Vérifiez ce que le shell a fait avant de vérifier la passerelle : imprimez la charge utile via un enrobage qui montre les octets exacts et comptez les lignes. La plupart de ces enquêtes s’arrêtent là.

Écrivez les réponses dans l’ordre où le client les demande

Exécutez le client une fois en interactif et notez chaque invite dans l’ordre. Un sélecteur de groupe n’apparaît que lorsque la passerelle publie plusieurs profils, et une invite de bannière n’apparaît que lorsqu’une est configurée. Le fichier de réponses doit correspondre à la passerelle vers laquelle vous pointez réellement, pas à celle de la documentation.

Construisez ensuite le fichier avec cette séquence exacte, une réponse par ligne. L’index de groupe est le numéro que le client liste, pas la position d’un profil dans un document. N’acceptez la bannière que si votre passerelle en envoie une, et ajoutez une ligne pour chaque question supplémentaire que cette passerelle est connue pour poser. Lancez le client avec l’option non interactive pour qu’il consomme le fichier au lieu d’attendre un terminal.

connect vpn.lab.example
0
username
password
y
exit
/opt/cisco/anyconnect/bin/vpn -s < anyconnect.txt

La même séquence peut arriver par un tube lorsque vous préférez ne pas garder de fichier sur le disque. Les règles de citation décident toujours si elle survit.

Gardez l’identifiant hors de la liste des processus

Un argument sur la ligne de commande est lisible par tout utilisateur local pendant toute la vie du processus, donc le mot de passe appartient à un fichier ou à un tube et jamais à la liste des arguments. Rendez ce fichier lisible uniquement par le compte qui exécute le script, et supprimez-le à la fin de la tâche. Sous macOS, le binaire se trouve généralement au même chemin que sous Linux, mais confirmez l’emplacement installé au lieu de le supposer. Un enrobage qui teste les deux chemins est plus court que le rapport d’incident.

printf 'username\npassword\ny\n' | /opt/cisco/anyconnect/bin/vpn -s connect vpn.lab.example

Ne laissez pas non plus le script réessayer sans fin. Une bannière modifiée ou un mot de passe expiré pendant la nuit transforment un fichier de réponses fixe en boucle de réessai, et c’est cette boucle qui verrouille le compte.

Échouez une fois, imprimez le texte d’erreur propre au client et quittez. Une tâche planifiée a besoin du même examen d’identité et de disponibilité des identifiants que toute autre tâche non surveillée, car un identifiant qui expire en silence est indiscernable d’une panne à trois heures du matin.

Confirmez la session avant de faire confiance au code de sortie

Un état connecté prouve que le tunnel existe et rien de plus. Testez une ressource qui doit être joignable à travers lui avant que le script ne commence le vrai travail, et traitez un échec là comme une panne différente d’une connexion ratée. Sinon vous réessaierez une connexion parfaitement bonne qui ne peut simplement pas atteindre sa destination.

Demandez au client son état avant et après la déconnexion, car une session périmée peut refuser la connexion suivante pendant que votre script signale un succès.

/opt/cisco/anyconnect/bin/vpn state
/opt/cisco/anyconnect/bin/vpn disconnect

Enregistrez la sortie d’état à côté du code de sortie, car un code seul ne peut pas séparer une connexion refusée d’une session qui ne s’est jamais fermée. Lorsque la passerelle exige un second facteur ou une approbation interactive, arrêtez de scripter cette étape et utilisez plutôt le mécanisme pris en charge par le client. Un fichier de réponses fixe est une commodité pour un identifiant que vous contrôlez, pas un moyen de contourner une étape d’authentification que vous ne contrôlez pas. Gardez le périmètre aussi étroit et cela reste un script court.

Quand un fichier de réponses fixe est le mauvais outil

Un second facteur ou une invite d’approbation déjouent entièrement le schéma, et c’est une limite de conception, pas une énigme de script. Utilisez le mécanisme que le client prend en charge pour cette étape au lieu de deviner la réponse à l’avance. Un fichier fixe ne fonctionne que pour des identifiants qui restent les mêmes entre les exécutions.

Deux styles d’identifiants plus anciens sont aussi confondus avec AnyConnect. Un profil vpnc parle un autre protocole, et il veut le nom du groupe comme identifiant IPSec, puis un secret de groupe partagé, puis les détails de votre propre compte.

Comme les protocoles diffèrent, vpnc ne peut pas atteindre une passerelle qui ne publie que des profils AnyConnect, et l’alternative ouverte habituelle pour ce service est openconnect avec son protocole anyconnect sélectionné. Un fichier pcf appartient au client Cisco hérité et, bien que son hôte, son nom de groupe et son mot de passe de groupe puissent être ressaisis dans un client qui parle encore Cisco IPsec, le fichier ne se transpose pas d’un client à l’autre. Un port inhabituel ou un mode de tunnelisation non standard se perd généralement dans ce transfert. Décidez quel protocole la passerelle propose avant de choisir un outil.

Articles similaires