Socket de gestion OpenVPN : un canal de contrôle, pas des métriques

Demandez un statut à l’interface de gestion une fois, et elle commence à ressembler à un port de statut. Elle n’en est pas un. Dès qu’un client est admis, il peut émettre les commandes de contrôle du protocole, et le compte qui exécute ce client hérite de tout ce que ces commandes peuvent faire au démon. La traiter comme un flux en lecture seule est l’erreur qui transforme une intégration de supervision en console non authentifiée.

La croyance, et ce qu’elle coûte

La croyance est que l’écouteur de gestion équivaut à un point de terminaison de métriques : branchez un collecteur, lisez les compteurs, passez à autre chose. En réalité, le collecteur ouvre une session dotée de capacités de contrôle, et toute autre hypothèse que vous avez faite sur le déploiement dépend désormais du bon comportement de ce collecteur.

Rien dans l’interface ne fait la promotion d’un mode en lecture seule. Il n’y a aucun rôle d’observateur à sélectionner, et un nom d’utilisateur dans la configuration n’en crée pas.

Ce qu’un client admis détient réellement

Le démon communautaire accepte un seul client de gestion actif à la fois. Cet emplacement unique signifie qu’une interface graphique, un script et un agent de supervision ne peuvent pas tous s’y connecter ; le second attend ou échoue pendant que le premier tient la session. Si votre conception suppose des lecteurs simultanés, elle est déjà fausse.

Là où un instantané périodique suffit, la sortie du fichier de statut vous donne les mêmes chiffres sans session active. Écrire ce fichier à intervalles réguliers et le lire avec des permissions de fichier ordinaires maintient le collecteur entièrement hors du plan de contrôle, et c’est là la disposition dont la plupart des supervisions ont réellement besoin.

Un socket possédé, pas un socket ouvert

Un socket de domaine Unix garde le chemin de contrôle hors du réseau, ce qui retire le problème de l’adresse de tunnel changeante. Cela ne retire pas la question des permissions. Le répertoire parent doit être inscriptible par le compte de service et accessible par le compte du contrôleur, et ce sont deux autorisations distinctes :

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

Le fichier de mot de passe porte le secret de gestion sur sa première ligne. Protégez ce fichier comme tout autre identifiant, et gardez son contenu hors des journaux et des tickets de support. Les restrictions d’utilisateur et de groupe sont des vérifications de pair sur le socket Unix, pas des permissions de système de fichiers, donc le processus visé a besoin à la fois de l’accès au fichier et de l’identité correspondante.

Rendre le socket accessible au monde entier pour effacer une erreur de permission est la seule correction à éviter. Elle transforme un canal de contrôle local en quelque chose que n’importe quel processus de l’hôte peut piloter.

Publier via TCP n’est pas la même conception

Déplacer l’écouteur vers un port TCP ne le rend ni plus sûr ni plus pratique. Le mot de passe de gestion est envoyé en clair, donc un écouteur TCP expose à la fois l’identifiant et la session à quiconque peut observer le chemin. L’atteindre depuis un autre hôte exige un canal d’administration autorisé, ou un petit agent local qui n’expose que les observations dont vous avez besoin.

Un mot de passe sur un transport en clair est une authentification sans confidentialité, et cette combinaison est pire qu’elle n’en a l’air parce qu’elle donne une impression de protection.

Des dépendances de démarrage que vous n’avez pas demandées

Plusieurs options de gestion modifient le cycle de vie du démon. Retenir le démarrage jusqu’à ce qu’un contrôleur se connecte, ou terminer lorsque le contrôleur disparaît, transforme un observateur facultatif en dépendance dure. Un agent de supervision qui plante emporterait alors le tunnel avec lui.

Examinez ces options avant d’activer quoi que ce soit au-delà du socket lui-même. L’observation facultative doit rester facultative, et une politique de redémarrage ne devrait pas être couplée à un collecteur ajouté pour les graphiques.

Un fichier de socket laissé après un processus défaillant ne prouve pas qu’un écouteur existe. Identifiez quelle instance possède le chemin avant de le supprimer, et utilisez le propre flux de récupération du service plutôt que de supprimer des fichiers sous un démon en cours d’exécution.

À quoi ressemble l’acceptation

Quatre contrôles couvrent la conception : l’identité prévue du contrôleur se connecte, un processus sans cette identité est refusé, le démon survit à un contrôleur qui se déconnecte sans avertissement, et le tunnel continue de porter du trafic après un redémarrage contrôlé. Une connexion de gestion réussie ne prouve que le plan de contrôle. Elle ne dit rien sur le fonctionnement du trafic des applications privées, alors testez-le séparément. Notez les quatre résultats là où le prochain opérateur pourra les trouver.

La documentation de l’interface de gestion décrit le modèle à client unique et la nature privilégiée du protocole, et c’est la partie qui vaut la peine d’être lue avant d’y pointer un tableau de bord.