OpenVPN Access Server ou Community : ce qui migre vraiment
Community Edition et Access Server partagent le protocole OpenVPN mais pas la couche de gestion. Comparez ce qui se déplace, ce qu’il faut reconstruire et qui en assure le support.
Les profils migrent ; les listes d’utilisateurs restent derrière. Une équipe qui bascule entre Access Server et Community Edition bute sur cet écart une heure après la bascule, quand son premier client s’authentifie et n’a ensuite ni politique de groupe, ni route par utilisateur, ni réinitialisation de mot de passe en libre-service. Les deux produits parlent le même protocole et acceptent le même client, et c’est précisément pour cela que l’écart reste invisible pendant la planification. Ce que vous choisissez réellement, c’est la couche de gestion et les personnes qui en sont responsables.
Traitez la décision comme une question d’inventaire plutôt que comme une grille de fonctionnalités. Demandez qui crée les utilisateurs, qui révoque les certificats et qui répond à l’appel à 02:00.
Pourquoi le fichier .ovpn ne transporte pas la configuration
Un profil .ovpn décrit la relation d’un client avec un serveur : l’hôte distant, le protocole, l’AC, un certificat et une clé client, et tout matériel tls-crypt en ligne. Déposez ce fichier dans une installation neuve et le client termine quand même la poignée de main, si bien que la migration semble terminée. Rien n’y liste les utilisateurs, leurs groupes, leurs routes statiques ni la politique qui décidait qui avait le droit de se connecter. Ces enregistrements vivent dans le stockage propre du serveur, et les deux produits les conservent sous des formes différentes.
Dans Community Edition, les équivalents sont des fichiers que vous tenez vous-même : des entrées client-config-dir contenant des options par client comme ifconfig-push et iroute, une CRL pour les révocations et la clé tls-crypt. Access Server conserve les mêmes concepts dans sa propre base de données et les expose via une console web et l’outil en ligne de commande sacli. Les concepts se correspondent un à un ; les artefacts ne bougent pas du tout.
Les profils font aussi entrer en contrebande des comportements que personne ne remarque avant qu’ils ne changent. Un client avec redirect-gateway def1 envoie toute la navigation via le serveur ; déplacez-le vers une installation sans cette ligne et la plainte sera que l’internet est cassé. Une incohérence d’AC ou un mauvais réglage de remote-cert-tls échoue bruyamment, ce qui est le bon résultat. Une clé tls-crypt manquante échoue en expiration silencieuse, ce qui ne l’est pas.
Ce que possède la couche de gestion
Comptez ce qui n’est pas du protocole : création de comptes, réinitialisation de mots de passe, affectation aux groupes, enrôlement MFA, droits de connexion et la piste d’audit qui répond qui s’est connecté et quand. Community Edition n’en fournit aucun directement. Vous choisissez un backend d’authentification, branchez PAM, LDAP ou RADIUS via un greffon ou auth-user-pass-verify, et maintenez le reste vous-même. Access Server livre un portail utilisateur, une console d’administration et des intégrations avec les fournisseurs d’identité courants. Aucune des deux dispositions n’est plus sûre par défaut, car la politique doit encore être écrite par quelqu’un qui connaît le réseau.
Les droits de connexion sont la différence opérationnelle la plus nette. Access Server est licencié selon un nombre de connexions simultanées et applique ce nombre par logiciel. Sur Community Edition, un plafond global est une seule ligne max-clients, tandis que tout ce qui est par utilisateur ou par groupe demande plus de travail client-config-dir et votre propre application. Une équipe sans goût pour cette maintenance achète exactement cela lorsqu’elle paie le produit commercial.
Licences et support : la ligne que personne ne budgète
Community Edition est gratuit et open source. Access Server est commercial, et son niveau gratuit a historiquement couvert un petit nombre de connexions simultanées, avec une licence payante au-delà. Tout chiffre cité dans une ancienne réponse de forum est désormais périmé, alors vérifiez les conditions actuelles de l’éditeur avant de chiffrer le projet. La comparaison honnête ajoute les heures consacrées à la gestion des utilisateurs, au MFA et à la supervision côté communautaire à la ligne de licence côté commercial.
La responsabilité du support suit la même répartition. Avec Community Edition, vous êtes la voie d’escalade pour chaque client bizarre et chaque mise à jour du noyau. Avec Access Server, vous avez un éditeur à appeler et vous héritez de son rythme de publication, qu’il convienne ou non à votre fenêtre de changement.
Contrôles à faire avant la bascule
Inventoriez ce que le serveur en production contient réellement avant la bascule, dans un sens comme dans l’autre. Côté Access Server, exportez la liste des utilisateurs et les affectations de groupe et notez quels comptes dépendent du MFA. Côté Community Edition, listez les certificats émis, la CRL et chaque fichier sous client-config-dir. Comparez les deux listes ligne par ligne, car la différence entre elles constitue le travail de migration.
Testez des clients représentatifs pendant que l’ancien service tourne encore. openvpn --config client.ovpn --verb 4 au premier plan affiche la poignée de main, les routes poussées et les options DNS, et openssl x509 -in client.crt -noout -subject -enddate montre quel certificat le client présente réellement. Un client qui se connecte mais n’atteint pas un hôte interne a un trou de route ou d’iroute, pas un échec d’authentification.
Maintenez l’ancien chemin de secours en vie jusqu’à ce que le remplaçant réussisse un test d’accès refusé ainsi qu’un test réussi. Écrivez la carte finale sur une seule page : chaque exigence, l’artefact qui la satisfait aujourd’hui et l’artefact qui la satisfera ensuite.