OpenVPN push-peer-info : étiqueter les clients sans accorder l’accès

Les étiquettes de déploiement sont la raison habituelle pour laquelle on se tourne vers cette fonctionnalité : chaque connexion devrait porter quelque chose comme un site ou un rôle, et le serveur devrait le lire sans inventer un second format d’identifiants. OpenVPN communautaire possède déjà le mécanisme, et il est petit. La partie douloureuse, ce sont les attentes. Définir une variable ordinaire dans le profil client ne fait rien sur le serveur, et une valeur qui arrive réellement prouve seulement que le client l’a envoyée.

Ceci est un guide d’exploitation pour le chemin qui fonctionne, l’étape de vérification qui montre ce qui est vraiment arrivé, et le retour arrière qui ne laisse aucun hook à moitié configuré. Rien ici ne nécessite un nouveau certificat, un nouveau greffon ni une extension de protocole.

Définir la variable et activer le chemin

Deux lignes font le travail dans le profil client, et les deux sont nécessaires. Sans la première, il n’y a rien à envoyer ; sans la seconde, le client ne propose pas du tout d’informations de pair. L’ordre n’a pas d’importance, ce qui vaut la peine d’être su car les deux lignes finissent souvent dans des parties différentes d’un profil généré. L’important est que les deux survivent à toute réécriture du profil avant que le client ne le lise.

setenv UV_DEPLOY field-support
push-peer-info

Le préfixe UV_ n’est pas décoratif. Une variable DEPLOY ordinaire reste locale au processus client et n’est jamais transmise, tandis que la forme préfixée est l’espace de noms que le protocole réserve aux champs définis par l’utilisateur. Laissez le reste du profil approuvé intact et confirmez que la compilation client que vous déployez prend en charge les deux directives avant de la déployer.

Une vérification pratique a sa place ici et non à la fin : assurez-vous que la directive atteint le binaire client et n’est pas avalée par un enrobage. Un client graphique qui génère sa propre ligne de commande, ou une interface de gestion qui recharge un profil enregistré, peut supprimer des lignes qu’il ne reconnaît pas. Si le serveur ne voit rien, c’est le premier endroit où regarder.

Lire le champ depuis un hook serveur

Côté serveur, les informations de pair reçues sont validées et insérées dans l’environnement du flux de connexion, et c’est ce qui les rend lisibles depuis un hook sans aucun travail de protocole de votre part. Le serveur n’a pas besoin d’analyser le canal de contrôle ni de stocker quoi que ce soit pour vous ; la valeur est simplement présente pendant l’établissement de la connexion. Un script client-connect minimal qui enregistre l’étiquette à côté du nom authentifié ressemble à ceci.

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

Lisez la variable via l’environnement plutôt qu’en analysant le journal, et donnez-lui toujours une valeur par défaut. ${UV_DEPLOY:-unset} maintient le script fonctionnel pour les clients qui n’envoient jamais le champ, ce qui est l’état normal lors d’un déploiement progressif. Ne videz pas tout l’environnement dans un journal pour trouver le nom ; il contient bien plus que l’étiquette, y compris des valeurs que vous ne comptiez pas conserver.

Exécutez le script à la main et il signalera unset pour tout, car un shell manuel ne porte pas l’environnement de la connexion. Ce n’est pas un bug du script et ce n’est pas la preuve que le champ manque. Testez-le via une connexion réelle, le seul contexte où la variable existe.

Vérifier ce qui est réellement arrivé

Connectez un client avec l’étiquette et un sans, puis lisez le fichier. La paire est le test : une ligne doit porter la valeur et l’autre la valeur par défaut, et les deux doivent nommer la même identité authentifiée que vous attendez.

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

Ces lignes de commentaire sont la forme de la sortie, pas une transcription de votre serveur ; lisez votre propre fichier. Si le second client affiche aussi une valeur, la variable est définie ailleurs dans l’environnement, et vous lisez un réglage obsolète plutôt que le champ de pair.

Vérifiez aussi le journal du serveur pour la connexion. Les informations de pair peuvent y apparaître, ce qui est pratique pour le débogage et une raison de garder les valeurs ennuyeuses : pas de noms de personnes, pas de numéros de ticket, rien que vous ne voudriez pas qu’un lecteur du journal voie.

Traiter l’étiquette comme une déclaration, pas une identité

Quiconque peut modifier le profil client peut changer l’étiquette, et le fait que le tunnel soit authentifié ne rend pas l’étiquette autoritaire. Le transport protège la valeur en transit ; il ne certifie pas la déclaration. L’autorisation appartient toujours à l’identité authentifiée et à un enregistrement d’inscription que le serveur possède, l’étiquette étant comparée à cet enregistrement quand cela compte.

Cette distinction décide où l’étiquette peut être utilisée. Les bons usages sont d’acheminer une session vers le bon fichier journal, de choisir un groupe d’affichage dans un tableau de bord, ou d’étiqueter une session de support pour qu’un humain la retrouve plus tard. Les mauvais usages sont d’admettre un appareil dans un sous-réseau, de sélectionner une politique de pare-feu, ou de décider quelles données client la session peut lire.

Validez la valeur avant qu’elle n’atteigne un chemin, une requête ou une commande shell. Une liste d’autorisation de chaînes attendues suffit pour une étiquette de déploiement, et elle ne coûte rien. N’interpolez jamais une chaîne fournie par le pair dans une ligne de commande shell, et limitez toute observation stockée à la session plutôt qu’à une adresse de tunnel que le prochain client réutilisera.

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

Revenir en arrière proprement

Retirer la fonctionnalité, c’est deux suppressions et une vérification. Supprimez les lignes setenv et push-peer-info du profil client, puis supprimez ou désactivez le hook et sa cible de journal sur le serveur.

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

Reconnectez un client ensuite et confirmez que la ligne de journal cesse d’apparaître. Un hook qui continue de se déclencher après le changement de profil est généralement un second profil encore déployé sur un appareil de test, et le trouver maintenant coûte moins cher que le trouver lors d’un audit.

Ce qui reste à la fin est un petit morceau borné de métadonnées de session dont l’origine est documentée : le client l’affirme, le serveur l’enregistre, et rien de l’accès n’en dépend. C’est la version utile de la fonctionnalité, et elle ne demande aucun nouvel identifiant pour y arriver.