Procédure : intégrer deux clients OpenVPN séparément

Deux clients sur un seul hôte ressemblent à un bloc de serveur de plus et à un second port. Cela devient un autre projet dès que l’on énumère tout ce qu’un client possède réellement : un écouteur, un pool de tunnels, une identité, des fichiers de confiance, des routes et un calendrier de révocation. Omettez l’un de ces éléments et le second client hérite discrètement d’une partie du premier. Construisez une fiche par client et remplissez-la avant que le premier client ne se connecte.

Attribuez une fiche de ressources complète par client

Réservez l’ensemble d’un seul coup : port public, sous-réseau du tunnel, chemin de configuration, destination des journaux, nom de l’instance de service et appareil. C’est le fait de les nommer comme un groupe qui empêche la copie classique d’un fichier opérationnel contenant encore le pool ou l’interface du premier client. Les valeurs sont des exemples, pas des ports réservés, vérifiez donc ce que l’hôte utilise déjà. Un service qui démarre n’est pas la même chose qu’un client complet.

Gardez la fiche à côté de la configuration et mettez-la à jour à chaque changement de valeur. Une documentation qui s’éloigne de la réalité est pire que pas de documentation du tout.

Gardez le matériel de confiance à l’intérieur de chaque client

Une autorité d’émission distincte par client rend la frontière facile à raisonner et garde la clé de signature hors de l’hôte exposé à Internet. Une racine partagée peut aussi fonctionner, mais une ancre commune ne transforme pas deux services en un seul domaine d’appartenance. Décidez quelles chaînes chaque écouteur accepte et quelles identités de client il autorise, puis consignez les deux. Ne retirez pas des certificats d’une chaîne par essais et erreurs jusqu’à ce que quelque chose se connecte.

La clé privée du serveur lui-même appartient à un fichier protégé par client, pas à un répertoire de modèles répliqué avec la configuration.

Séparez les réseaux autant que les processus

Deux processus sur deux ports partagent encore un hôte et une table de routage si vous ne les séparez pas. Confirmez ce qui écoute avant de faire confiance à la conception.

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

La vérification de l’écouteur montre quel processus possède chaque port public, et la validation montre si un certificat client s’enchaîne à l’ancre prévue. Aucune des deux sorties ne prouve que le client de A ne peut pas atteindre le sous-réseau de B, alors définissez la politique de source et de destination, les routes de retour et tout service délibérément partagé. Les espaces de noms réseau ou les conteneurs séparent les contextes de routage et réduisent le mélange accidentel, mais ils ne constituent pas une frontière complète de locataire à eux seuls. Choisissez un mécanisme d’isolation plus fort lorsque le modèle de menace l’exige.

Livrez la révocation avant la remise

Un déploiement de certificats n’est pas complet tant que la révocation n’a pas de chemin de livraison. Vérifiez l’émetteur et la fenêtre de validité de la CRL dans le cadre de l’intégration.

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

L’inspection de la CRL indique quand la liste a été émise et quand elle expire, et l’état du service confirme que l’instance qui la lit fonctionne. Rafraîchissez la liste selon le calendrier de la politique d’émission même quand rien de nouveau n’a été révoqué, car une CRL expirée peut rejeter tous les clients. Publiez un fichier complet au lieu de laisser les lecteurs rencontrer une écriture partielle, et validez la signature avant le déploiement. Consignez qui possède l’émission, l’exploitation du point de terminaison et le retrait, afin que l’arrêt du client A ne perturbe pas B.

Exécutez ensuite la paire d’acceptation : un client autorisé atteint son propre service, et un justificatif de A est refusé par l’écouteur de B. C’est la frontière exprimée sous forme de test.