Expulser un client OpenVPN : kill, deny ou révoquer un certificat ?

Vous avez un common name et une adresse dans vos notes, et trois commandes qui semblent toutes supprimer un client. Une seule fait ce que vous voulez, et le choix dépend de ce que vous devez arrêter : la session en cours, la prochaine connexion ou le droit de vous connecter tout court. Lisez l'identité que vous détenez réellement avant de toucher à quoi que ce soit, car un pool OpenVPN attribue la même adresse de tunnel à une autre session plus tard.

Quelle identité vous avez réellement

Un fichier d'état en version 3 est le point de départ habituel. La section CLIENT_LIST porte le common name, l'adresse réelle, les compteurs d'octets et la durée de connexion ; la section ROUTING TABLE associe une adresse virtuelle à un common name avec un horodatage de dernière référence. Le common name est l'identité stable. L'adresse virtuelle est une attribution, et l'adresse réelle derrière un NAT peut changer d'une session à l'autre sans que rien ne change sur le serveur.

L'interface de gestion expose une vue similaire via sa commande status et ajoute un ID de client par session. C'est cet ID qu'attend client-kill, et ce n'est pas l'adresse du tunnel. Si vous devez savoir quel common name a reçu quelle adresse au moment de la connexion, l'environnement d'un script client-connect contient les deux, ainsi que l'adresse extérieure de confiance, mais ce script s'exécute en tant qu'utilisateur OpenVPN et a besoin d'un chemin de journal inscriptible.

Tuer maintenant, refuser à la connexion, révoquer définitivement

Les deux commandes de suppression de l'interface de gestion sont des actions de session. kill prend un common name ou une adresse réelle et un port ; client-kill prend l'ID de client et termine cette instance immédiatement. Aucune n'est un blocage : un client expulsé avec un certificat et un mot de passe valides se reconnecte en quelques secondes, ce qui convient quand vous recyclez un pair de test et ne sert à rien quand un ordinateur portable a été volé.

client-deny est un autre type de décision. Il est normalement émis depuis un hook d'authentification ou client-connect et rejette la session avec un motif, donc il correspond à une politique qui refuse une connexion plutôt qu'à une qui interrompt une session. La documentation avertit aussi qu'un refus émis pendant une renégociation TLS invalide la clé renégociée tandis que la session existante peut continuer jusqu'à la fermeture de la fenêtre de transition. Si l'exigence est que le client soit parti maintenant, la réponse documentée est client-kill.

La suppression durable se situe sous tout cela. Révoquez le certificat et assurez-vous que crl-verify pointe vers une liste que le serveur recharge réellement, désactivez le fichier de configuration propre au client dans le répertoire ccd, ou désactivez le compte dans le backend que le hook d'authentification interroge. Une révocation n'est pas instantanée non plus : avec les réglages par défaut de reneg-sec, une session établie peut continuer jusqu'à sa renégociation, donc l'action de session et l'action sur les identifiants sont complémentaires, pas alternatives.

Le socket de gestion est-il libre ?

L'interface de gestion sert un client à la fois. Si une GUI ou un démon de supervision tient déjà la connexion, votre script ne peut pas s'y attacher à côté, et selon le client vous risquez d'expulser l'existant plutôt que d'échouer proprement. Son mot de passe circule en clair sur ce socket, il appartient donc à une adresse locale ou à un socket unix, jamais à une interface publique.

Quand vous ne pouvez pas prendre le socket, il vous reste des options, et elles sont toutes plus lentes. Libérez d'abord la session de la GUI si vous la contrôlez, ou acceptez la voie de la couche d'identifiants et attendez la prochaine renégociation. Ce que vous ne devez pas faire, c'est redémarrer le service pour vous débarrasser d'un client, car cela termine aussi toutes les autres sessions et détruit les preuves du fichier d'état pour celle-ci.

La séquence que j'exécute sur un serveur en production

Attachez-vous, lisez l'état courant, agissez sur l'ID que vous venez de lire, puis relisez-le. Les valeurs copiées depuis un document sont le moyen le plus courant de tuer la mauvaise personne.

status                     # note the client ID and common name
client-kill 3              # end that session now
kill Test-Client           # alternative: by common name
status                     # confirm the session is gone

Le nom et le numéro ci-dessus sont des espaces réservés, et les ID sont réutilisés après la déconnexion d'autres clients. Confirmez que la ligne est absente avant de noter quoi que ce soit comme fait, et vérifiez que le nombre de clients connectés a bougé de un et non de plusieurs.

Confirmer qu'il est resté absent

Notez le common name, l'adresse du tunnel, l'adresse extérieure et la minute de la suppression. Si le même common name réapparaît une minute plus tard, l'action de session a fonctionné et la couche d'identifiants non, ce qui est une réparation complètement différente de celle d'une commande qui n'a jamais pris effet.

Testez ensuite côté client. Un certificat révoqué devrait échouer à la poignée de main suivante ; s'il se connecte encore, la CRL n'est pas lue du tout, et c'est le constat qui vaut la peine d'être signalé. Choisissez l'action selon ce que vous devez terminer, confirmez avec un second status, et corrigez la couche d'identifiants quand la réponse doit durer plus longtemps que la session.