duplicate-cn donne à deux appareils une seule identité, pas deux

Copiez le profil sur la tablette, connectez-vous, et l'ordinateur portable tombe. Ajoutez duplicate-cn, les deux restent connectés, et le problème semble résolu jusqu'à ce que les deux appareils se disputent la même adresse de tunnel ou qu'une tablette perdue mette tout le compte hors ligne. L'option change une chose et une seule : si le serveur autorise une seconde session sous un nom qu'il a déjà vu. Tout ce que les gens attendent qu'elle corrige, de l'indépendance des appareils à l'adressage par appareil et à la révocation sélective, se fait toujours par identité, et l'identité ici, c'est le certificat.

Le mythe : une seconde session est une seconde identité

L'intuition veut que deux connexions soient deux clients, et que deux clients soient deux appareils avec leurs propres droits. Le serveur ne le modélise pas ainsi. Il voit un nom commun et, duplicate-cn activé, accepte plus d'une session vivante portant ce nom, chacune obtenant son propre état de session dans le démon.

Rien dans cette acceptation ne touche à la vérification du certificat. Le même certificat reste l'identifiant, la même clé reste la clé privée, et toute politique fondée sur le sujet du certificat se résout encore deux fois à la même valeur. Une seconde session est une seconde socket, pas une seconde identité.

Cette distinction est invisible tant que tout fonctionne. Elle devient très visible au moment où il faut distinguer les deux appareils, ce qui est généralement le jour où l'un d'eux est perdu.

Ce qui change vraiment quand deux sessions partagent un nom

Sans l'option, une nouvelle connexion sous un nom commun déjà connecté déplace la session précédente. C'est pourquoi l'ordinateur portable tombe quand la tablette se connecte, et c'est une garde délibérée contre l'ambiguïté, pas un bug. Avec l'option, les deux sessions restent vivantes et le serveur les suit séparément par session, pas par appareil.

Chaque session garde sa propre connexion externe et ses propres clés négociées, donc le débit simultané est réellement simultané. Ce qu'elles partagent, c'est tout ce qui dérive de l'identifiant : recherches de politique, configuration propre au client, identité dans les journaux et révocation. L'état de session appartient à la connexion et meurt avec elle, tandis que les faits au niveau de l'identifiant persistent pour les deux. C'est pourquoi la sortie d'état peut lister deux fois le même nom alors que les compteurs restent séparés.

Vérifiez ce que fait réellement votre build avant de concevoir autour, car l'effet de l'option est défini par l'option elle-même et non par la tradition orale :

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

L'adresse statique que vous croyiez avoir attribuée

La configuration par client est recherchée par nom, et c'est là le piège. Un fichier client-config-dir nommé d'après le nom commun s'applique à chaque appareil utilisant ce nom, si bien qu'un ifconfig-push à l'intérieur donne aux deux appareils la même adresse de tunnel. La seconde session soit ne s'établit pas, soit entre en collision d'une manière qui ressemble à une panne de routage.

Un pool dynamique se comporte mieux par accident, car chaque session reçoit indépendamment une adresse du pool. Cela ne vous donne toujours pas d'adresse stable par appareil, et certainement pas de politique par appareil attachée à cette adresse.

Si le déploiement utilise username-as-common-name, la clé de recherche devient le nom d'utilisateur authentifié au lieu du sujet du certificat, et la même collision se reproduit pour quiconque se connecte deux fois. Le nom qui pilote la configuration doit être unique par appareil pour que la configuration par appareil signifie quelque chose.

Ce qu'une identité partagée ne peut pas faire au moment du retrait

La révocation agit sur le certificat, pas sur le nom affiché ni sur la session. Révoquez ce certificat et chaque appareil qui en détient une copie perd l'accès d'un coup, y compris celui du bureau que personne ne veut déranger. Conservez-le et l'appareil perdu continue de fonctionner, car rien dans le protocole ne le distingue de la copie approuvée.

Les journaux héritent de la même ambiguïté. La sortie d'état affiche un nom commun et une adresse réelle, et les deux peuvent appartenir à l'un ou l'autre appareil. Une revue d'incident qui doit savoir quelle machine a fait quoi ne peut pas répondre à la question à partir des propres enregistrements du VPN, quel que soit le niveau de détail du journal.

Il n'existe aucun contournement cryptographique. Deux appareils qui présentent le même certificat sont, pour le serveur, le même participant deux fois, et tout schéma qui prétend le contraire est une convention de nommage et non un contrôle.

Quand le partage est justifié, et comment le borner

Le partage a des usages légitimes : un compte de laboratoire utilisé par plusieurs machines de test, ou un foyer où les appareils sont gérés ensemble et où la granularité de révocation n'importe pas. Dans ces cas, activez l'option délibérément, gardez l'identifiant partagé hors de la politique par appareil et laissez de la marge au pool pour que les sessions ne puissent pas entrer en collision sur une adresse.

Pour tout ce qui exige des adresses séparées, des journaux séparés ou un retrait séparé, délivrez des certificats séparés par le chemin d'enregistrement habituel. Cela donne à chaque système en aval un objet distinct sur lequel s'appuyer, et l'option cesse d'avoir de l'importance parce que les noms sont déjà uniques.

Quel que soit le chemin choisi, testez le modèle de gestion et non la connexion. Connectez les deux appareils, confirmez qu'ils ont des adresses différentes, puis simulez une perte et vérifiez que vous pouvez en retirer exactement un. Le manuel openvpn(8) définit la portée de l'option ; votre procédure de retrait définit si le partage est réellement acceptable.