Un lien OpenVPN à clé statique peut-il servir plusieurs clients ?

Le mode à clé statique relie exactement deux pairs, et c’est sa conception, pas une limitation que quelqu’un aurait oublié de lever. client-to-client est une option de transfert du mode serveur, donc l’ajouter à une configuration --secret ne change rien au nombre de clients qui peuvent se connecter. La décision ne porte pas sur l’indicateur à ajouter, mais sur la question de savoir si le déploiement a besoin d’une liaison point à point ou d’un service multi-clients. Si plusieurs appareils doivent se connecter indépendamment, le mode de protection change et chaque appareil reçoit une identité.

Deux pairs, une clé et aucun état par client : cette forme est toute l’histoire du mode.

À quoi sert le mode à clé statique

En mode secret, les deux pairs partagent un seul fichier de clé, et cette clé protège directement le trafic. Il n’y a ni poignée de main, ni échange de certificats, ni session par client, car il n’y a pas de clients au sens serveur, seulement deux extrémités.

Le mode reste utile pour une paire fixe de machines avec un processus documenté de rotation des clés, et OpenVPN 2.6 le marque comme obsolète précisément parce que le mode TLS couvre ces cas avec de meilleures propriétés. Ce qu’il ne peut pas faire, c’est distinguer un appareil qui se connecte d’un autre, puisque la possession du fichier est toute l’histoire de l’authentification. Ajouter un troisième appareil signifie partager la même clé avec lui, après quoi les deux premiers ne peuvent plus le distinguer d’eux-mêmes.

C’est pourquoi la limite de deux pairs est structurelle et non un réglage à modifier.

Pourquoi client-to-client n’est pas la pièce manquante

client-to-client contrôle si les clients connectés peuvent échanger du trafic via le serveur. Il n’admet pas de clients, n’attribue pas d’identités et ne crée pas un mode serveur qui n’a pas été configuré, et dans une configuration à clé statique il n’y a aucune liste de clients qu’il pourrait gouverner.

L’autre confusion courante concerne le matériel tls-crypt ou tls-auth. Un serveur TLS peut partager une de ces clés entre tous les clients, car elle protège le canal de contrôle au lieu de prouver qui est chaque client. Une clé de canal de contrôle partagée en mode TLS est un objet différent d’une clé de données statique partagée, même si les deux arrivent sous forme de fichiers qui se ressemblent.

Le choix entre les modes se résume à deux questions. Plus d’un appareil doit-il se connecter indépendamment, et le déploiement a-t-il besoin d’une révocation par appareil ? Un non aux deux maintient le mode à clé statique viable ; un oui à l’une ou l’autre pointe vers TLS. Il n’existe pas de troisième option où un second client serait admis sans sa propre identité.

Construire le serveur multi-clients

Un serveur multi-clients nécessite le mode TLS, un certificat côté serveur et une identité par client. L’assistant serveur met en place le pool d’adresses et le mode multi-clients, mais il ne fournit pas la configuration TLS, l’ancre de confiance ni les certificats clients qui rendent l’admission significative.

Enrôlez chaque appareil via l’autorité de certification existante plutôt que de copier les identifiants d’un client. Des identités distinctes sont ce qui rend possibles la révocation, le routage par client et des journaux utiles, et un seul certificat client partagé fait s’effondrer les trois.

Si le déploiement authentifie les utilisateurs via un annuaire externe ou un second facteur, cette conception reste telle quelle. Le passage au mode serveur TLS décide comment les pairs se prouvent au niveau de la couche tunnel, et il n’impose pas le backend de comptes. Gardez les deux décisions séparées afin qu’un changement dans l’une n’altère pas silencieusement l’autre.

Décidez ensuite la politique de transfert délibérément. client-to-client active le trafic entre clients dans le chemin serveur en espace utilisateur, ce que beaucoup de déploiements veulent et que certains ne doivent pas avoir. C’est un commutateur de politique, non un mécanisme d’identité, et il faut l’activer parce que la conception l’exige, non parce qu’un tutoriel l’a inclus.

Vérifier que les clients sont réellement indépendants

Connectez deux clients et confirmez qu’ils reçoivent des adresses différentes et apparaissent avec des identités différentes dans le journal du serveur. Révoquez ensuite l’un d’eux et confirmez que l’autre continue de fonctionner, ce qui est le test pratique que les identités n’ont pas été partagées.

Testez le service autorisé entre pairs et un autre qui doit rester bloqué. Deux connexions réussies prouvent l’admission, pas l’isolation, et la différence compte lorsque le déploiement est censé séparer des groupes d’utilisateurs.

Enfin, lisez le mode serveur depuis la configuration en cours d’exécution plutôt que de mémoire. Une configuration à clé statique avec des options supplémentaires reste une liaison point à point, et un serveur TLS correct est la seule disposition où plusieurs clients sont réellement des pairs distincts.

Si le journal montre un nom commun pour chaque appareil, le mode n’est pas le problème. Le processus d’enrôlement l’est.