AnyConnect se coupe à la fermeture d'un terminal : vérifications de session

Le tunnel est actif, vous fermez un terminal inutilisé, et le VPN tombe sans la moindre frappe dans le client. Sur le client AnyConnect sous Linux, la cause signalée est la comptabilité des sessions et non le routage : le client enregistre quelles sessions de connexion existaient au moment où le tunnel est monté et considère la fin de n'importe laquelle comme une raison de le démonter. Les vérifications ci-dessous s'exécutent dans l'ordre, et la première qui échoue vous dit si vous êtes bien face à ce comportement. Rien dans la sortie habituelle du client ne mentionne un terminal, ce qui explique pourquoi le premier réflexe, accuser le concentrateur, est généralement du temps perdu.

Ne commencez pas par modifier des fichiers système. Chaque étape explique soit la coupure, soit élimine un candidat, et les étapes les moins coûteuses viennent en premier.

Distinguer une coupure de session d'une coupure du réseau sous-jacent

Reconnectez-vous immédiatement après la déconnexion. Un tunnel qui revient en quelques secondes, sur le même réseau, sans nouveaux identifiants, indique un déclencheur local comme une session fermée, et non un lien montant mort, une itinérance Wi-Fi ou un délai d'inactivité sur le concentrateur. Un tunnel qui reste bloqué sur Connecting, ou qui échoue jusqu'à ce que vous changiez de réseau, relève d'un autre article.

Notez ce qui était ouvert au moment où le tunnel est monté : le terminal depuis lequel vous avez lancé le client, tout second shell, la session graphique et toute session SSH venue d'une autre machine. Vous aurez besoin de cette liste dans un instant, et la reconstituer de mémoire après la coupure suivante n'est pas fiable.

Vérifier ce que le client a enregistré au moment de la connexion

Le client n'inspecte pas les processus parents ni la propriété du terminal. Il prend un instantané de l'ensemble des sessions de connexion présentes au moment de la connexion et compare cet ensemble plus tard ; quand un membre disparaît, la comparaison échoue et le tunnel part avec lui. C'est pourquoi fermer la fenêtre depuis laquelle vous vous êtes connecté peut être sans effet alors que fermer un terminal inutilisé sans rapport tue la connexion : ce qui compte, c'est de savoir si cette session figurait dans l'ensemble d'origine. La vérification est une comparaison d'ensembles et non un comptage, ce qui explique qu'un remplacement de session puisse être aussi fatal qu'une perte.

Énumérez ce que le client pouvait voir avant de changer quoi que ce soit :

who
w
last -n 10
sudo ls -l /run/utmp

Chaque ligne de who est une entrée de processus utilisateur dans utmp. Si votre session apparaît deux fois, une fois pour la session graphique et une fois pour le terminal, les deux entrées existaient au moment de la connexion et toutes deux sont candidates.

Ne retirer que votre propre entrée d'utmp

Le contournement publié rend invisible dans utmp la session que vous êtes sur le point d'utiliser avant le démarrage du client. Un petit programme en C parcourt getutent(), trouve l'enregistrement dont le ut_line correspond au TTY de l'entrée standard, puis réécrit cet enregistrement. L'ordre est délibéré : setutent(), lire l'entrée, copier son ut_id, passer ut_type à DEAD_PROCESS, vider les champs utilisateur et ligne, la réécrire avec pututline(), puis endutent().

Compilez-le, puis exécutez-le en root depuis le shell qui lancera le client :

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

Deux modes d'échec expliquent la plupart des rapports selon lesquels l'outil ne fait rien. Il agit sur le TTY attaché à l'entrée standard, donc l'exécuter depuis un script ou une tâche cron sans terminal ne lui laisse rien à comparer. Et /run/utmp n'est pas accessible en écriture aux utilisateurs ordinaires, donc une exécution sans root échoue silencieusement si vous ne vérifiez pas le code de sortie.

Vérifier que le tunnel survit à la fermeture

Testez le mécanisme au lieu de le supposer. Connectez-vous depuis une session que vous comptez garder, ouvrez un second terminal, fermez le second, puis confirmez que le tunnel tient toujours avec vpn state et un coup d'œil à la liste des interfaces. S'il survit, le déclencheur était un type de session particulier et non toutes les sessions, et vous avez trouvé la session qui doit rester ouverte.

S'il tombe encore, la session surveillée se trouvait ailleurs, le plus souvent la session graphique qui a engendré votre terminal, et retirer une seule entrée TTY n'y changera rien. Répétez l'observation avec la liste complète de la première étape au lieu d'ajouter de la chirurgie.

Quand réécrire utmp est la mauvaise réponse

utmp est une comptabilité partagée, pas une table privée. Réécrire l'entrée d'une session encore vivante fait que who, w et certains outils d'audit la sous-déclarent, et un programme qui ferme ensuite la même entrée peut échouer complètement. Gardez l'outil limité à votre propre session, conservez une copie du fichier d'origine et ne le transformez pas en service de démarrage qui supprime chaque enregistrement.

Si votre site collecte la comptabilité des sessions pour la conformité, le contournement entre en conflit avec cette exigence et la réponse prise en charge est une autre version du client ou une autre méthode d'accès, pas un utmp corrigé. Pour la plupart des gens, la correction la moins invasive consiste simplement à lancer le client depuis une session qui restera ouverte toute la journée et à ne plus toucher à cette fenêtre.

Avant de clôturer le ticket, notez quelle session le client surveillait au moment où le tunnel est monté. C'est cette seule ligne qui transforme une déconnexion mystérieuse en condition reproductible pour la personne suivante sur la machine.