Comment mettre OpenConnect en arrière-plan après une connexion interactive

Vous terminez l’invite MFA, le tunnel monte, et la fermeture du terminal emporte la connexion. C’est un problème de supervision, pas d’authentification, et OpenConnect fournit déjà l’option qui le règle. La solution consiste à laisser le client passer en arrière-plan une fois le démarrage terminé, quand la partie interactive est vraiment finie. Voici une suite de vérifications : faites-les dans l’ordre et arrêtez-vous à la première qui ne tient pas pour votre passerelle.

Confirmez ce que la passerelle exige à la connexion

Avant de taper une commande, notez le chemin d’authentification imposé par le déploiement. Certificat seul, mot de passe plus jeton, et un aller-retour navigateur via un fournisseur SAML se comportent différemment, et le mode arrière-plan ne peut en sauter aucun. L’option change ce qui se passe après le démarrage, jamais pendant.

La solution tentante est d’automatiser l’invite. Un script qui tape une réponse fixe dès qu’il reconnaît une invite de mot de passe casse dès que la passerelle demande un code à usage unique, et il laisse un identifiant dans un fichier lisible par d’autres comptes. Si une personne doit approuver la session, gardez-la dans la boucle.

Lancez la première session au premier plan et lisez la sortie

Connectez-vous une fois normalement et laissez toute la poignée de main s’afficher. Notez le protocole utilisé, le chemin du certificat ou du jeton, l’adresse du tunnel attribuée par le serveur et chaque avertissement avant l’acceptation. Cette trace est votre référence et le seul moyen bon marché de distinguer plus tard un problème client d’un changement de passerelle. Enregistrez-la hors du tampon du terminal.

Répétez ensuite l’appel avec le mode arrière-plan et un fichier PID ajouté, par exemple openconnect --background --pid-file /run/openconnect.pid vpn.example.net, en gardant le protocole et les options d’authentification exigés par votre passerelle sur la même ligne. Le manuel OpenConnect décrit cette option comme une poursuite en arrière-plan après le démarrage, d’où la nécessité de terminer d’abord la phase interactive.

Rendez le processus en cours repérable et arrêtable

Un fichier PID ne prouve quelque chose que tant qu’il correspond à un processus vivant. Placez-le dans un répertoire appartenant au compte de service et comparez le numéro enregistré à la table des processus avant d’envoyer un signal. Les redémarrages et les plantages laissent le fichier, et un fichier périmé explique souvent qu’un script d’arrêt signale un succès alors que le tunnel tourne encore. Traitez la vérification comme faisant partie de l’arrêt, pas comme une étape facultative.

Envoyez le signal au PID vérifié, puis confirmez que l’interface du tunnel a réellement disparu plutôt que de vous fier au code de sortie. Si le client a besoin de privilèges élevés pour configurer l’interface, le signal doit venir d’un compte autorisé à l’envoyer.

N’empilez pas le mode arrière-plan sous un superviseur

systemd et les superviseurs similaires attendent de posséder le processus qu’ils ont lancé, d’où la confusion d’un client qui se détache. Le superviseur voit un lanceur se terminer alors que la connexion réelle continue, donc la logique de redémarrage, l’état et les délais d’arrêt décrivent quelque chose qui n’est plus vrai. Écrivez l’unité dans la disposition au premier plan prise en charge et laissez le superviseur faire le travail de démon.

Réservez --background aux sessions qu’une personne lance puis abandonne. Si le besoin est un tunnel présent avant toute connexion, il manque une identité non interactive approuvée et un plan pour la renouveler, et aucun indicateur de ligne de commande ne fournit l’un ou l’autre. Ajouter l’indicateur à un script de démarrage produit un tunnel qui échoue silencieusement à la première authentification expirée.

Traitez le cookie de session comme un identifiant

OpenConnect documente une phase d’authentification distincte via --authenticate, et le matériel obtenu peut être rendu avec --cookie-on-stdin. Ce couple sert au travail d’intégration, et ce qu’il produit est aussi sensible que le mot de passe qui l’a créé.

Gardez la valeur hors de l’historique du shell, des journaux et de tout ticket que vous ouvrez. Un script de remise doit aussi préserver les informations d’extrémité vérifiées reçues avec le cookie ; si elles sont perdues, une exécution ultérieure peut se connecter à un hôte jamais authentifié, ce qui est pire qu’une connexion qui échoue simplement.

Parcourez la liste avant de fermer le terminal

Quatre choses doivent être vraies : la connexion interactive s’est terminée au premier plan, le fichier PID pointe vers un processus vérifié, la question du superviseur est tranchée dans un sens ou dans l’autre et le cookie a un plan de stockage qui n’est pas un fichier en clair. Quand les quatre tiennent, quitter le terminal est sûr et le tunnel continue.

Si l’une échoue, corrigez-la avant de toucher aux autres, car les vérifications restantes ne peuvent pas la compenser. Conservez aussi la trace du premier plan de votre premier lancement : la prochaine fois que le tunnel tombe sans prévenir, cette référence sépare un changement côté passerelle d’un changement côté client.