Suspendre un client OpenVPN sans révoquer son certificat

Quand un ordinateur portable part une semaine sur l'établi de réparation, le réflexe habituel est de retirer son certificat de la CA. Cet enregistrement est le registre de l'émetteur, pas un interrupteur d'accès temporaire. OpenVPN dispose déjà d'un mécanisme par client pour refuser une connexion, et l'utiliser préserve l'historique de la CA. Les deux contrôles répondent à des questions différentes, et les mélanger crée du travail au retour de l'appareil.

Deux registres, deux métiers différents

La base de données de la CA consigne ce que l'émetteur a signé et ce qu'il a révoqué ensuite. Elle est consultée par les flux de révocation et par tout ce qui lit la CRL ou sa propre copie du registre. Une règle d'admission vit sur le serveur et s'applique aux connexions que ce serveur accepte.

Supprimer un enregistrement d'émission ne révoque pas un certificat de façon fiable et abîme l'historique dont dépendent la révocation ou l'audit ultérieurs. Le contrôle côté serveur est plus étroit et réversible. Écrivez la différence dans la note de changement pour que la personne suivante ne cherche pas une révocation qui n'a jamais eu lieu.

Placez la directive de désactivation dans le bon fichier

Pour un serveur communautaire qui utilise une configuration propre à chaque client, la directive documentée disable refuse un client choisi. Elle appartient au fichier de ce client sous le client-config-dir actif, et non à la configuration principale du serveur. Confirmez le répertoire que le démon en cours d'exécution utilise réellement, puis confirmez l'identité qui sélectionne le fichier. Un fichier nommé d'après le mauvais nom commun paraît correct et n'est jamais lu.

disable

Les choix de mappage comptent ici. Des options comme username-as-common-name changent l'identité utilisée par la recherche, donc un fichier nommé d'après le sujet du certificat peut ne pas être celui qui s'applique. Lisez la référence OpenVPN de la version installée au lieu de supposer qu'une directive est valide dans tous les contextes.

Séparez la nouvelle admission des sessions actives

Refuser le prochain handshake ne met pas fin à un tunnel déjà établi. Si l'appareil doit être déconnecté maintenant, utilisez aussi la voie autorisée de gestion des sessions du serveur pour cette session précise. Sinon le client peut continuer à fonctionner jusqu'à ce qu'il se reconnecte seul, et fermer le capot de l'ordinateur ou quitter le client est une action côté client qui ne dit rien du serveur.

Vérifiez les deux résultats : la session active s'arrête quand vous le voulez, et un nouveau handshake est refusé. Une fenêtre client fermée ne prouve rien sur la politique du serveur.

Si le déploiement n'a aucun moyen pris en charge de terminer une session active, consignez cette lacune au lieu d'en improviser un. Un port bloqué sur le client n'est pas la même chose qu'une politique côté serveur.

Pause et compromission sont deux événements distincts

Une clé perdue ou volée est un événement de révocation, et une pause d'accès locale ne le remplace pas. Les autres serveurs qui font confiance à la même CA ne partageront pas cette règle propre au client. Suivez le processus de révocation et de remplacement de l'émetteur et gardez la base de données de la CA comme registre faisant foi. Une pause temporaire, en revanche, exige un motif documenté et une étape de restauration.

Une fois l'accès rétabli, retirez la restriction via le composant qui la possède et confirmez qu'une nouvelle connexion réussit. Notez aussi le chemin de la ligne disable, car une synchronisation de configuration ultérieure peut la rétablir en silence. Conservez la pause, son propriétaire et la date dans les notes de déploiement, afin que l'administrateur suivant ne trouve pas des mois plus tard une ligne disable inexpliquée.