OpenVPN client-config-dir : nom de fichier ou CN du certificat

Deux noms entrent en jeu avant même que le client se connecte : le nom du fichier sur l’ordinateur portable (nuc.ovpn) et l’identité que le serveur dérive du justificatif. Une recherche client-config-dir utilise le second. Renommer le profil côté client, ou ajouter .conf au fichier du serveur, ne change rien au fichier que le serveur ouvre.

La comparaison utile n’est pas « quel nom ai-je utilisé » mais « quelle règle le serveur applique », car l’authentification par certificat et l’authentification par nom d’utilisateur/mot de passe peuvent produire des noms effectifs différents à partir de la même connexion.

Nom du profil contre nom commun du certificat

Dans la configuration par défaut basée sur certificat, le serveur prend le nom commun X.509 et cherche un fichier portant exactement ce nom dans client-config-dir. Un profil nommé nuc.ovpn dont le certificat indique tester se résout en /etc/openvpn/server/ccd/tester. Le nom du fichier client n’entre jamais dans le calcul. C’est le premier endroit où une incohérence se cache.

Un répertoire rempli de profils soigneusement nommés peut donc échouer à chaque fois. Le fichier n’est pas mis en correspondance par sujet, par adresse électronique ni par le nom affiché dans une interface graphique ; il l’est par la chaîne du nom commun.

Sur un système de fichiers sensible à la casse, Tester et tester sont deux fichiers différents, et un seul est jamais ouvert. Vérifiez le nom commun du certificat que le client présente réellement, pas celui d’une copie dans vos notes.

username-as-common-name inverse la règle

Lorsque le serveur exécute une authentification par nom d’utilisateur/mot de passe avec username-as-common-name, le nom d’utilisateur authentifié remplace le nom commun du certificat pour cette recherche.

Comparez les deux cas directement : avec l’identité du certificat, le fichier suit le certificat et un changement de mot de passe est sans effet ; avec l’identité du nom d’utilisateur, le fichier suit le nom de connexion et une réémission du certificat est sans effet. Le champ que le serveur substitue est celui sur lequel il faut aligner le nom. Un certificat réémis avec un nouveau CN change silencieusement la cible de la recherche, et l’ancien fichier CCD reste sur le disque en paraissant correct.

Il existe des configurations mixtes, et c’est là que commence l’essentiel de la confusion. Si un bloc de service active la substitution et qu’un autre ne le fait pas, le nom effectif dépend de l’instance qui a traité la connexion. Confirmez la configuration active au lieu de supposer que le fichier global s’applique. La référence des options serveur d’origine documente la recherche par fichier nommé et le repli facultatif.

Ce que le serveur lit et ce qu’il ignore silencieusement

Deux petites différences décident si un fichier est sélectionné. La première est une extension ajoutée. La seconde est un caractère parasite dans le nom.

OpenVPN n’ajoute pas .conf au nom qu’il cherche, donc tester.conf ne correspond pas à tester. Un éditeur qui masque les extensions peut laisser un fichier qui semble correct dans une liste et ne correspond jamais.

Quand aucun fichier correspondant n’existe, le serveur peut se rabattre sur un fichier nommé DEFAULT. La réception de certains réglages ne prouve donc pas que le fichier propre au client a été utilisé. Comparez l’adresse attribuée ou les routes poussées avec ce que produirait le fichier propre au client. Les permissions sont le troisième filtre, car le serveur ouvre le fichier après avoir abandonné ses privilèges ; un shell root capable de le lire ne prouve rien.

Un nom de fichier correct ne valide pas le contenu

La sélection et le contenu sont deux défaillances distinctes. Une fois le bon fichier ouvert, ses directives doivent encore être valides pour ce client.

ifconfig-push doit attribuer une adresse que la topologie peut réellement utiliser, et iroute n’a de sens que pour un sous-réseau routé derrière ce client.

Une identité, plusieurs appareils

Deux ordinateurs portables qui présentent le même nom commun sélectionnent le même fichier et reçoivent les mêmes réglages propres au client. Si vous avez besoin d’adresses distinctes ou d’une révocation distincte, il vous faut des identités distinctes, pas deux copies d’un fichier.

La comparaison oppose le partage d’une identité et l’émission d’un certificat par appareil. Le partage est plus simple à administrer et plus grossier à révoquer, tandis que les certificats par appareil coûtent plus de préparation et vous donnent une unité propre à désactiver.