sudo, &, -b ou --daemon : comment passer un client OpenVPN en arrière-plan

La formule « lancez-le en arrière-plan » cache deux questions. La première est de savoir si cet utilisateur peut seulement démarrer un processus privilégié ; la seconde, si la session peut continuer sans que personne ne tape dans un terminal. Un ampersand de shell ne répond à aucune des deux, et un script qui stocke un mot de passe sudo dans une variable répond mal à la première tout en laissant la seconde intacte. Séparez-les et les options deviennent faciles à comparer.

Comparez les trois candidats sur la propriété, pas sur la commodité.

Trois façons de quitter le terminal, trois propriétaires différents

Ajouter un ampersand à une commande demande au shell de l’exécuter comme tâche d’arrière-plan, et la tâche appartient toujours à ce shell. sudo peut demander avant même que le programme démarre, et OpenVPN peut demander ensuite une phrase de passe de clé ou une connexion. Mettre en arrière-plan une commande qui attend une entrée produit un processus qui attend un terminal que personne ne surveille. Le terminal est libéré ; l’interaction ne l’est pas.

C’est l’option la moins chère et celle qui échoue le plus confusément, parce que l’invite apparaît à un endroit que l’opérateur a déjà quitté.

sudo -b n’est pas un gestionnaire d’identifiants

sudo -b exécute la commande en arrière-plan du point de vue de sudo lui-même, ce qui ressemble à la fonctionnalité manquante et ne l’est pas. Selon le manuel de sudo, les commandes interactives se comportent généralement mal dans ce mode, et le contrôle des tâches du shell ne peut pas gérer les processus qu’il crée. Il déplace le processus sans lui donner le moyen de répondre aux questions. Rien en lui ne fournit de phrase de passe de clé privée ni de connexion à la passerelle.

Si la connexion exige une interaction, la solution est un dispositif d’authentification non interactif pris en charge, pas une autre façon de lancer la même invite.

--daemon change le programme, pas la connexion

--daemon demande à OpenVPN lui-même de se détacher après l’initialisation. Le manuel de la version 2.6 note que la redirection de syslog a lieu lors de l’analyse de l’option, bien que le détachement survienne plus tard, si bien que les messages peuvent cesser d’apparaître dans le terminal plus tôt que prévu. Le silence après ce point ne prouve rien sur le tunnel. Ajoutez un --log ou --log-append explicite pour que la sortie arrive là où vous pouvez la lire.

Le mode démon supprime aussi la console définitivement. Une clé privée protégée a besoin de askpass dans ce mode, et les identifiants saisis sur la console combinés à des options de mise en cache peuvent laisser une réauthentification ultérieure sans endroit où demander. Vérifiez le modèle d’authentification par rapport à la version installée avant de supposer qu’un démarrage en arrière-plan survivra à sa première rotation de clé.

Ce que la validation sudo apporte et ce qu’elle n’apporte pas

sudo -v valide ou rafraîchit l’identifiant local mis en cache, en s’authentifiant si la politique l’exige. Il ne démarre pas OpenVPN, ne s’authentifie pas auprès de la passerelle et ne garantit pas qu’une commande ultérieure du script soit autorisée. sudo -n signifie l’inverse : ne demandez pas, échouez plutôt. Cela rend explicite un échec d’autorisation local, ce qui est utile, et cela ne dit rien de ce qu’OpenVPN demandera plus tard.

Aucune des deux options n’est une raison d’accorder des commandes sans mot de passe à tout va ou de faire passer un mot de passe administrateur dans un script.

Préférez un propriétaire observable

Pour un tunnel possédé par la machine, utilisez l’instance de service prise en charge par la distribution. Ce propriétaire fournit démarrage, arrêt, état et journaux, et il survit à la fin de votre session. Assembler l’arrière-plan du shell, la démonisation et une boucle de redémarrage les uns autour des autres crée trois propriétaires pour un seul tunnel et aucune réponse claire sur celui qui tourne.

Quoi que vous choisissiez, vérifiez la ressource pour laquelle le tunnel existe. Une demande de démarrage réussie est un événement de processus, pas la preuve d’une connexion qui fonctionne.