client-config-dir ignoré après qu'OpenVPN est devenu un service

Votre tunnel monte et le client se connecte, mais l'adresse fixe et les routes poussées que vous avez définies pour cet utilisateur précis manquent. Rien dans le journal ne dit “file not found”, et c'est justement ce qui pousse les gens à régénérer des certificats. Dans la plupart de ces cas, le démon s'exécute depuis un autre répertoire que le shell dans lequel vous avez testé, et client-config-dir n'a jamais été résolu comme vous le supposiez. Le correctif est une correction de chemin, pas une réinitialisation des identifiants.

Lisez l'unité avant de toucher à la configuration

Partez du processus qui tourne réellement, pas du fichier que vous avez modifié. Demandez à systemd la ligne d'exécution, le répertoire de travail et le compte auquel il passe. Ces trois réponses expliquent la plupart des échecs de cette catégorie :

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

Un WorkingDirectory vide signifie que l'unité démarre dans /, donc un client-config-dir ccd relatif est cherché dans /ccd. Ce répertoire n'existe presque jamais, et le démon ne considère pas son absence comme fatale.

Comparez avec le lancement interactif que vous avez utilisé pendant les tests, où le répertoire courant de votre shell était probablement celui de la configuration. Même fichier, mêmes mots-clés, deux résultats différents.

Par rapport à quoi un chemin relatif est résolu

Le mot-clé est résolu par rapport au répertoire de travail du processus au moment où l'option est utilisée. Cela ne veut pas dire “à côté du fichier de configuration que j'ai passé avec --config”. OpenVPN lira volontiers une configuration depuis un chemin absolu et résoudra quand même les valeurs relatives ailleurs, et c'est exactement le piège ici. Le manuel d'OpenVPN 2.6 énonce la règle sous --client-config-dir et de nouveau sous --cd.

Le mot-clé cd change ce contexte avant que d'autres fichiers soient lus, donc une unité qui définit cd /etc/openvpn/server puis client-config-dir ccd se résout en /etc/openvpn/server/ccd. Si vous ajoutez cd, vérifiez l'ordre des directives et rappelez-vous qu'il affecte toute autre référence relative du même fichier.

Parcourez le chemin en tant que compte du démon

Un chemin peut être correct et pourtant illisible. Après l'abandon des privilèges, le démon n'est plus root, donc chaque répertoire parent a besoin du droit de traversée pour ce compte, et le fichier client lui-même du droit de lecture. Un seul bit d'exécution manquant sur un parent suffit à cacher le fichier, et l'erreur ne se manifeste que par un client qui reçoit silencieusement le pool par défaut.

namei affiche les permissions de chaque composant dans l'ordre, ce qui est plus rapide que de vérifier les répertoires un par un :

namei -l /etc/openvpn/server/ccd/client1

Testez ensuite la lecture en tant que compte du service plutôt que vous-même :

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

Si l'unité utilise chroot, le répertoire doit exister à l'intérieur de la prison, et le chemin de la configuration est interprété après l'application du chroot. Un fichier présent sur l'hôte hors de la prison est invisible de l'intérieur.

Confirmez la recherche au lieu de deviner

Augmentez le niveau de journal pour un redémarrage et lisez ce que le serveur dit des options propres au client. À verb 4 le démon signale la configuration par client qu'il a importée, donc une ligne absente est la preuve directe qu'aucun fichier n'a été lu pour cette connexion.

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

Lancez cela au premier plan sur un port libre et connectez un client. Cela retire complètement systemd de l'équation : si les surcharges apparaissent ici et pas sous le service, la différence vient du contexte de l'unité, pas du fichier.

Décidez ce qui doit arriver quand aucun fichier ne correspond. Sans ccd-exclusive le client est admis avec seulement les réglages globaux du pool, et c'est l'échec silencieux décrit plus haut. Avec elle, un fichier manquant devient une connexion refusée, et ce refus est plus facile à remarquer mais plus difficile à déboguer sous charge.

Corrigez, redémarrez, vérifiez

Rendez le répertoire absolu dans la configuration et laissez-le ainsi. Les chemins relatifs ne sont sûrs que lorsque l'unité fixe le répertoire de travail, et le fixer est une pièce mobile supplémentaire que quelqu'un retirera plus tard.

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

Redémarrez l'instance, reconnectez un client connu et lisez l'adresse qu'il a reçue ainsi que les routes poussées vers lui. Si l'adresse correspond à la ligne ifconfig-push du fichier de ce client, la recherche a fonctionné. Si le client atterrit encore dans le pool général, revenez au nombre de lignes du journal : zéro import signifie que le chemin ou l'identité est faux, un import au contenu erroné signifie que vous éditez un autre fichier que celui que lit le démon.

Revenez en arrière en restaurant l'unité et la configuration précédentes ensemble, puis redémarrez. Les certificats n'ont pas besoin d'être réémis pour cela, et traiter un problème de répertoire comme un problème d'identifiants, c'est ainsi qu'un correctif de cinq minutes devient une fenêtre de maintenance.