Les niveaux script-security d’OpenVPN, de 0 à 3, et ce que chacun débloque
Chaque niveau script-security élargit ce qu’un profil peut exécuter : d’abord les auxiliaires d’administration, puis les scripts utilisateur, enfin les mots de passe dans l’environnement. Lisez les directives.
Importez un profil dans un client de bureau et le premier échec est souvent une ligne que le client refuse d’honorer : un hook de script qu’il n’exécutera pas, ou une valeur script-security qu’il juge trop permissive. Augmenter le nombre fait disparaître la boîte de dialogue. Cela élargit aussi ce que ce profil est autorisé à exécuter sur votre machine, ce qui est étrange à accorder juste pour fermer un avertissement. Suivez l’import jusqu’à la directive et la décision devient concrète.
De la boîte d’import à la directive
Le profil est un fichier texte avec des directives, et le client les lit avant qu’un tunnel existe. Une directive comme up, down ou tls-verify nomme un programme externe que OpenVPN doit exécuter à un moment défini. Que OpenVPN soit prêt à l’exécuter est un réglage distinct nommé script-security, et le profil le fixe généralement aussi.
L’avertissement ne porte donc pas sur la cryptographie ni les certificats. Il porte sur un fichier de configuration qui demande au client d’exécuter quelque chose sur l’hôte, et sur le client qui vérifie si son niveau d’autorisation actuel permet cette demande.
Deux échecs différents se ressemblent à ce stade. Un profil qui demande un niveau que le client n’accordera pas produit un refus. Un profil qui demande un niveau que le client accorde mais dont le script est absent produit plutôt une erreur à l’exécution, et les deux sont confondus dans les fils de support. L’un est une question d’autorisation, l’autre une question de conditionnement.
Ce que chaque niveau ouvre réellement
Le niveau 0 interdit totalement les appels à des programmes externes, ce qui est cohérent pour un client qui configure lui-même son interface sans aide et incohérent pour un client qui sollicite le système d’exploitation. Le niveau 1, par défaut, autorise les exécutables intégrés dont la configuration de l’interface et des routes a besoin. Aucun des deux n’exécute quoi que ce soit fourni par l’utilisateur.
| Level | What OpenVPN may execute | What it exposes |
|---|---|---|
| 0 | No external programs at all | Interface and route setup must not depend on helpers |
| 1 (default) | Built-in helpers such as ip, ifconfig, route or netsh | Privileged commands the platform already ships |
| 2 | Built-in helpers plus user-defined scripts | Whatever the named script does with the client's privileges |
| 3 | Everything above, plus passwords in environment variables | Credentials visible to child processes and their logs |
Le niveau 2 est la frontière intéressante, car il admet des scripts définis par l’utilisateur. À partir de là, les privilèges du client s’appliquent à du code que vous n’avez peut-être jamais lu, invoqué à des moments que vous n’avez pas choisis, avec un environnement qui contient les détails de connexion. Le niveau 3 va plus loin et permet de transmettre des mots de passe par variables d’environnement, ce qui explique pourquoi le manuel le décrit comme potentiellement dangereux.
Aucun de ces nombres n’est un réglage de force. Un profil au niveau 3 n’a pas un meilleur chiffrement qu’un profil au niveau 1 ; il a simplement une surface d’exécution plus large, et le tunnel est identique.
Décidez ce que le profil mérite
Demandez à quoi sert le script avant de demander quel niveau il lui faut. Un hook qui pousse les réglages DNS ou répare une route après la connexion est une raison légitime d’exécuter quelque chose. Un hook qui appelle un binaire inconnu dans un répertoire temporaire est une raison de s’arrêter.
Le chemin du script compte autant que le script. Un chemin relatif se résout par rapport au répertoire que le client utilise, et un répertoire inscriptible transforme un import ponctuel en emplacement d’exécution permanent. Les chemins absolus dans un répertoire que l’utilisateur ne peut pas modifier sont la forme à préférer.
Les scripts héritent aussi de l’environnement du client, où vivent les identifiants et les métadonnées de connexion. C’est précisément cet héritage qui rend le niveau 3 dangereux associé à un script qui journalise son environnement, et c’est pourquoi un vidage de diagnostic d’un client avec scripts mérite un second regard avant d’être collé dans un ticket. Retirez l’environnement avant de le partager.
grep -nE 'script-security|^up |^down |tls-verify' client.ovpnChangez une chose, puis surveillez aussi le démontage
Si le profil a vraiment besoin d’un script, ne changez que le niveau et seulement pour ce profil. Lancez le client au premier plan avec une sortie détaillée pour que les erreurs du script soient visibles au lieu d’être avalées par un gestionnaire de services.
openvpn --config client.ovpn --script-security 2 --verb 3
ip route show defaultTestez tout le cycle de vie, pas seulement la connexion. Un hook de descente qui échoue laisse des routes pointant vers un tunnel mort, ce qui produit une machine qui semble connectée et n’atteint rien. Reconnectez une fois et déconnectez une fois avant de déclarer le changement terminé, et vérifiez la table de routage après chacun.
Gardez une copie du profil d’origine. Si un client de plateforme n’implémente pas le même modèle de scripts, supprimer des directives jusqu’à ce que l’import réussisse peut retirer l’intégration DNS ou de routes dont le tunnel avait besoin, et la connexion obtenue s’authentifiera parfaitement sans rien résoudre.
La décision à consigner est étroite : quel script, sur quel chemin, accordé à quel niveau, pour quel profil. Tout le reste du profil est inchangé, et c’est une phrase qu’un relecteur peut vérifier.