Comment retirer un serveur VPN sans laisser d’accès derrière

Votre client se connecte encore le jour où le ticket de retrait s’ouvre. Un profil siège dans l’application, il négocie, et le tunnel monte comme si rien n’avait changé. C’est le moment de travailler dans la direction opposée à celle de la construction du service : partez de la liste des clients, avancez vers l’extérieur jusqu’à l’écouteur, puis jusqu’au pare-feu, et terminez par les identifiants qui survivent à tout cela. Éteindre la VM est la dernière étape, pas la première. Ce parcours suppose que vous avez un accès console à l’hôte et l’autorité pour modifier les enregistrements clients et le DNS.

Parcourez d’abord la liste des clients

Ouvrez ce qui distribue vos profils et lisez la liste avant de toucher au serveur. Chaque entrée est un appareil qui croit avoir accès : téléphones, ordinateurs portables, un routeur d’agence, un conteneur qui se synchronise chaque nuit. Exportez cette liste dans le ticket, car une fois l’hôte disparu, il n’y a plus de wg show pour vous dire qui était connecté.

Classez chaque appareil en point de terminaison de remplacement, plus nécessaire ou inconnu. Le bac des inconnus est celui qui compte, car ce sont les profils que quelqu’un trouvera dans un tiroir des mois plus tard et essaiera. Envoyez l’avis sur le même canal que celui utilisé pour les demandes d’accès, et y mettre une date pour le moment où l’ancien point de terminaison cessera de répondre.

Révoquez l’identité, pas seulement le fichier

Deux actions différentes portent toutes deux le nom de révocation. Sur WireGuard, un pair n’est autorisé que par sa clé publique figurant dans une section de pair avec une entrée AllowedIPs, donc supprimer le fichier de configuration du portable ne change rien sur le serveur. Retirez le bloc du pair et réappliquez le fichier sans faire tomber les pairs que vous gardez, comme le décrit le manuel de wg(8) :

wg show
wg set wg0 peer <CLIENT_PUBLIC_KEY> remove
wg syncconf wg0 <(wg-quick strip wg0)

wg syncconf est la partie qui vous épargne une fenêtre de maintenance. Il reconstruit l’interface à partir du fichier sur place, donc retirer un pair ne détruit pas le tunnel que tous les autres utilisent. Si vous retirez l’hôte entier plutôt qu’un pair, l’ordre compte encore, car ces clés peuvent être approuvées ailleurs.

Avec une configuration X.509, l’étape de révocation est le certificat, pas le fichier : openssl ca -revoke client.crt puis openssl ca -gencrl -out crl.pem. Cela n’a d’effet que là où le vérificateur le lit, ce qui signifie qu’un OpenVPN serveur avec crl-verify configuré et rechargé ensuite. Si cette passerelle est le seul consommateur de cette AC, la CRL cesse d’avoir de l’importance le jour où elle meurt ; si la même AC signe pour une seconde passerelle, un certificat que vous n’avez jamais révoqué continue d’y fonctionner.

Les comptes sont le troisième cas et le plus souvent oublié. Quand la passerelle s’authentifiait auprès de RADIUS, LDAP ou d’un fournisseur d’identité hébergé, le compte vit hors du VPN. Désactivez-le dans l’annuaire. Supprimer une strophe d’utilisateur sur le serveur laisse un identifiant valide que le point de terminaison de remplacement acceptera dès qu’il pointera vers le même annuaire.

Fermez les écouteurs et les chemins qui y mènent

Arrêtez le service d’une manière qui survive à un redémarrage, puis confirmez avec une liste de sockets plutôt qu’avec l’état de l’unité. systemctl disable --now wg-quick@wg0 arrête l’interface et supprime les routes et règles ajoutées par wg-quick ; systemctl disable --now openvpn-server@server fait de même pour une instance OpenVPN modèle. Enchaînez avec ss -lunp et ss -ltnp. Un résultat vide pour l’ancien port est la seule preuve qui compte.

Ce que wg-quick a ajouté, wg-quick le retire. Ce que vous avez ajouté à la main reste : une règle NAT persistante, une autorisation de pare-feu, une redirection de port du routeur, une règle d’entrée de groupe de sécurité cloud, un écouteur d’équilibreur de charge. Tous exigent un retrait explicite, et l’enregistrement DNS aussi, c’est-à-dire le A, le AAAA et tout CNAME pointant vers le nom. Un nom qui résout vers un hôte mort échoue différemment d’un nom qui ne résout pas, et cette différence coûtera un après-midi à quelqu’un.

La copie que vous oubliez est le clone. Un instantané ou une VM restaurée depuis une sauvegarde conserve encore les clés de l’hôte et l’ancienne liste de pairs, et si quelque chose la ramène à la même adresse, les clients se reconnectent à un service que vous croyez retiré. Étiquetez le jeu de sauvegardes comme appartenant à un service décommissionné et tenez-le hors des chemins de restauration automatique.

Traquez ce qui pointe encore vers l’ancien point de terminaison

Les profils en cache survivent au DNS. Une configuration enregistrée avec une adresse numérique continue de composer après la disparition de l’enregistrement, et un client toujours actif réessaie à chaque changement de réseau. C’est du bruit et non de l’accès, car l’écouteur est fermé, mais savoir lequel des deux vous regardez décide de la réponse au ticket.

Balayez ensuite les dépendances que personne ne classe sous VPN : contrôles de disponibilité qui sondent le port, tâches de sauvegarde qui tiraient des configurations de l’hôte, identifiants d’automatisation utilisés pour pousser des entrées de pairs, comptes de récupération créés pour ce seul point de terminaison. Chacune est un chemin d’accès avec sa propre durée de vie et son propre propriétaire, donc chacune reçoit une décision plutôt qu’une suppression silencieuse.

Vérifiez, puis consignez

Le retrait est terminé quand un test depuis l’extérieur échoue comme vous l’attendez. Depuis un réseau que vous ne contrôlez pas, connectez-vous à l’ancienne adresse et au port. Un résultat filtré ou refusé est le cas de succès. Dans l’application cliente, confirmez que le profil a été supprimé et non simplement désactivé, et qu’aucun profil de gestion ne le rajoute discrètement.

Consignez ensuite ce que vous avez fait : point de terminaison, date, clés et certificats révoqués, comptes désactivés, où vivent les sauvegardes. Celui qui trouvera ensuite une ancienne configuration doit pouvoir répondre si elle a été révoquée ou seulement supprimée, sans deviner, et un court tableau dans le ticket le permet.

Avant de fermer le ticket :

• profils clients supprimés ou remplacés, appareils inconnus résolus
• pairs supprimés et la configuration réappliquée, ou certificats révoqués et la CRL publiée
• comptes d’annuaire désactivés, et pas seulement fichiers locaux supprimés
• service désactivé, aucun écouteur restant sur l’ancien port
• pare-feu, redirection de port, groupe de sécurité et enregistrements DNS supprimés
• sauvegardes étiquetées, instantané exclu des chemins de restauration
• identifiants de supervision et d’automatisation retirés

Vérifiez le remplacement séparément, depuis un client qui n’a jamais détenu l’ancien profil. Ce seul test vous dit si vous avez retiré un service ou seulement renommé le problème.