Passer d’Access Server à OpenVPN Community : ce qu’il faut reconstruire

Access Server et OpenVPN Community parlent le même protocole et presque rien d’autre de la même manière. La poignée de main, la négociation des chiffrements et le plan de données du tunnel sont compatibles, si bien qu’un client peut souvent se connecter à l’un ou à l’autre sans modifier son profil. Ce qui change, c’est qui possède la configuration : un produit livre une couche de gestion qui écrit et applique la politique, tandis que l’autre vous remet un fichier de configuration et un ensemble de points d’accroche et attend que vous décidiez.

Cette distinction, c’est le plan de migration. Tout ce que l’ancien produit décidait à votre place doit devenir une décision explicite quelque part dans le nouveau déploiement.

Là où les deux déploiements cessent d’être interchangeables

Dans Access Server, l’interface d’administration web possède les utilisateurs, les groupes, les permissions par utilisateur, la délivrance des certificats et le paquet de profil qu’une personne télécharge. Le démon en dessous est configuré par cette couche, si bien que le service en cours d’exécution est le produit d’un état stocké que vous modifiez rarement à la main. Dans OpenVPN Community, le fichier de configuration est l’état : il nomme l’écouteur, l’autorité de certification, le point d’accroche d’authentification et chaque option poussée, et rien ne le réécrit pour vous. La même mécanique TLS repose donc sur deux modèles de propriété très différents.

Une courte table de correspondance rend l’écart concret. Les utilisateurs et les groupes n’existent que dans l’ancienne base de données jusqu’à ce que vous les recréiez. Les paquets de profil deviennent un fichier de configuration plus des certificats que vous distribuez vous-même. Les permissions par utilisateur deviennent des directives dans client-config-dir. L’interface d’administration devient le processus que vous choisissez pour délivrer les certificats et modifier les fichiers.

Écrivez cette table de correspondance avant de toucher à un serveur. Chaque ligne que vous ne pouvez pas remplir est une fonctionnalité que vous êtes sur le point d’abandonner, et l’abandonner en silence est la façon dont une migration devient une panne deux semaines plus tard.

L’identité ne se transfère pas avec les fichiers de certificat

Les certificats de l’ancienne autorité peuvent être analysés correctement par le nouveau service et rester la mauvaise identité, parce que l’ancien produit les associait à un état de compte que le nouveau ne voit pas. Décidez d’abord si le nouveau déploiement authentifie par certificat seul, par un plugin qui joint PAM ou RADIUS, ou par une combinaison des deux, puis vérifiez que chaque option préserve les propriétés dont vous avez besoin. Un certificat partagé, sans identité par utilisateur, est un identifiant unique pour tous ceux qui le détiennent. La révocation doit fonctionner dès le premier jour aussi, ce qui, dans OpenVPN Community, signifie un fichier CRL référencé par crl-verify plus un processus qui le régénère.

Planifiez l’enrôlement avant la bascule, pas après. De nouveaux certificats, un chemin de révocation testé et une manière documentée de désactiver une personne sont des prérequis, pas un travail de suivi. Si l’authentification multifacteur venait de l’intégration de l’ancien produit, nommez explicitement le remplacement, car un plugin qui n’est pas installé échoue en mode fermé au pire moment possible.

Le routage et la résolution de noms suivent celui qui écrit la configuration

Les routes, les réglages DNS et le comportement en tunnel complet sont des options poussées dans les deux produits, mais un seul les calcule pour vous. Dans OpenVPN Community, vous écrivez vous-même les directives push, vous décidez si redirect-gateway appartient au serveur ou au client, et vous confirmez que le transfert de paquets et le NAT existent sur l’hôte. Une poignée de main terminée ne vous dit rien du transfert de paquets, de la traduction d’adresses ou des routes qu’un client a réellement reçues.

Le comportement par client exige client-config-dir plus un fichier nommé d’après le nom commun du certificat du client, et un pair site à site exige des entrées iroute pour les préfixes qui se trouvent derrière lui. Si le nom est faux, les options sont ignorées sans erreur. Testez avec un client hors production dans son propre pool d’adresses, puis relevez l’adresse qui lui a été attribuée, les routes qui lui ont été données et les réglages de résolveur avec lesquels il s’est retrouvé.

Séquencez la bascule pour que l’ancien service puisse revenir

Faites tourner le nouvel écouteur sur un autre port ou une autre adresse, et laissez l’ancien servir le trafic pendant que vous prouvez le remplacement. Deux démons sur une seule socket ne constituent pas un plan de retour arrière.

Déplacez un groupe à la fois, avec ses propres certificats, son propre pool et ses propres routes, et répétez le chemin de retour au lieu de le découvrir pendant un incident. Un retour arrière qui ne fonctionne qu’une fois le nouveau service arrêté reste un retour arrière, mais il doit être testé quand rien ne brûle.

Enfin, listez les fonctionnalités sans équivalent direct et décidez du sort de chacune par écrit : téléchargement du profil en libre-service, indicateurs de permission par utilisateur, l’interface d’administration elle-même, rapport des connexions en direct. Les remplacer par un processus manuel documenté est une réponse légitime. Laisser la ligne vide ne l’est pas.

Le travail est terminé quand un utilisateur qui n’a jamais vu l’ancien portail peut s’enrôler, se connecter, atteindre l’adresse interne voulue et être révoqué proprement. Tout ce qui précède ce point est de la préparation.