Hook client ou hook serveur ? Où s’exécute un script OpenVPN

La tâche est claire : quand un portable se connecte, quelque chose sur le portable devrait changer. La configuration qu’on modifie appartient au serveur, et c’est là que l’hypothèse se brise. Un chemin dans un fichier serveur désigne un fichier sur ce serveur, et aucun push ne change quel processus l’exécute. Choisir entre les deux hooks revient surtout à décider quelle machine possède le travail et à accepter les limites qui en découlent.

Deux machines, deux questions à trancher d’abord

Demandez où le changement d’état doit avoir lieu, puis demandez quel événement y correspond. Si le changement est une autorisation par utilisateur ou une décision de configuration par client, il appartient là où l’annuaire des utilisateurs est connu : sur le serveur. Si le changement est une route, un réglage de résolveur ou un assistant local sur un poste, il appartient au poste, et seul le poste peut le faire.

Répondre à ces deux questions dans l’ordre inverse, c’est ainsi que les gens finissent par tenter de pousser un fichier batch vers un portable Windows. Le serveur sait qui s’est connecté ; le portable sait à quoi ressemble sa propre pile réseau. Ni l’un ni l’autre ne possède les informations de l’autre, et la tentative échoue généralement en silence plutôt qu’avec une erreur claire.

Avant les deux, une troisième question mérite d’être posée : la plateforme expose-t-elle seulement le hook que vous voulez ? Un équipement qui génère sa propre configuration n’offre peut-être pas les mêmes noms d’événements, et un client de bureau qui importe un fichier .ovpn n’est pas forcément le client pour lequel le fichier a été écrit. Confirmer la plateforme d’abord vous évite de concevoir autour d’un hook qui n’existe pas là-bas. Cela vous indique aussi quelle documentation s’applique réellement à la machine devant vous.

L’option côté serveur : un événement par connexion

Un script client-connect s’exécute dans le contexte du processus du serveur lorsqu’un client authentifié se connecte, et il reçoit des détails de connexion documentés comme le common name et l’adresse attribuée. C’est le bon endroit pour écrire un fragment de configuration par client, appliquer une décision de politique ou enregistrer un état que le serveur possède.

La distinction que les gens manquent, c’est la différence entre ce hook et un hook up du serveur. Le hook up se déclenche quand le serveur ouvre son périphérique tunnel, ce qui, sur un serveur multi-clients, arrive une fois au démarrage du démon. Ce n’est pas un événement par connexion, et le code placé là s’exécute au démarrage du service plutôt qu’à la connexion des utilisateurs.

Sur un équipement doté d’une interface web, utilisez le mécanisme d’extension pris en charge plutôt que de modifier les fichiers du démon générés. Les fichiers générés sont réécrits à l’enregistrement suivant, et la réécriture supprime silencieusement votre modification au pire moment. Conservez une copie du texte de l’extension hors de l’équipement, afin qu’une mise à jour du firmware ne perde pas aussi l’intention.

L’option côté client : un travail qui doit s’exécuter localement

Un client communautaire peut exécuter un script local lorsque le périphérique tunnel apparaît et de nouveau lorsque les routes sont installées. Ce sont deux moments différents, et choisir le mauvais produit la course classique où un assistant démarre avant que la route dont il dépend existe.

L’assistant doit exister sur ce client, être lisible et exécutable par le compte qui lance le client, et être autorisé par un réglage script-security explicite. Un script qui fonctionne quand vous lancez le client en administrateur ne vous dit rien d’un service avant connexion ni de la session d’un autre utilisateur.

Le nommage compte aussi. Le hook up correspond à la création du périphérique et route-up à l’installation des routes, mais une tâche qui exige qu’un réseau privé soit joignable doit vérifier la joignabilité plutôt que supposer que la création du périphérique implique que chaque route, entrée de résolveur et application sont prêtes.

Pourquoi pousser du code exécutable n’est pas au menu

Les options poussées par push sont volontairement restreintes, et les options qui exécutent des scripts font partie des catégories que le serveur n’est pas autorisé à transmettre. Cette contrainte existe parce que l’alternative permettrait à un serveur compromis ou mal configuré d’exécuter des commandes arbitraires sur chaque client qui se connecte un jour.

Autoriser l’exécution de scripts localement ne change rien à cela. Votre réglage script-security autorise les scripts locaux que vous avez choisis ; il n’autorise pas le serveur à en fournir de nouveaux.

Si l’objectif est simplement d’installer des routes VPN, utilisez la configuration de routes prise en charge au lieu d’inventer un schéma d’exécution à distance. Si l’objectif exige vraiment du code local, distribuez-le via les outils de gestion des postes de l’organisation et examinez-le comme tout autre logiciel qui s’exécute avec les privilèges de l’utilisateur.

Ce qu’il faut vérifier avant de faire confiance à l’un ou l’autre hook

Notez quatre choses pour chaque hook : la machine, le nom de l’événement, le compte sous lequel il s’exécute et le changement d’état qu’il est censé produire. Testez ensuite la connexion, une reconnexion et le chemin de nettoyage, car un hook qui fuit de l’état à la reconnexion est pire qu’un hook qui n’a jamais tourné.

Testez sous le compte qui l’exécutera réellement, au moment où il s’exécutera réellement. Le manuel openvpn(8) documente les deux familles de hooks et les restrictions du push ; la plateforme sur laquelle vous déployez documente si elle les expose ou non. Un script qui réussit dans un terminal administrateur interactif est une hypothèse, pas une vérification.