Déplacer un serveur VPN vers une nouvelle IP publique : quoi vérifier d’abord

Réattribuer une adresse prend une minute. La semaine qui suit est le moment où le déplacement casse, et rarement là où la console du fournisseur le suggère. Une nouvelle IP publique est référencée à quatre endroits : la socket sur laquelle le démon écoute, l’ancre de confiance que les clients vérifient, chaque règle qui nomme l’ancienne adresse, et l’enregistrement DNS qui les relie. Deux déplacements paraissent identiques depuis un panneau de contrôle mais se comportent tout autrement : réattribuer l’adresse sur la machine que vous exploitez, ou monter un second endpoint et y déplacer les clients. Les vérifications ci-dessous placent d’abord les pannes bon marché, et chaque section indique à quel déplacement elle s’applique.

Le remplacement sur place et le basculement parallèle sont des travaux différents

Le remplacement sur place conserve l’hôte, les clés, la table de routage et la liste des utilisateurs ; seule l’adresse change. C’est ce que fait une réattribution d’IP flottante, et chez plusieurs fournisseurs l’invité ne s’en aperçoit pas, parce que la traduction se fait devant l’instance. Une reconstruction ou une réattribution par le fournisseur est plus rude : l’invité voit le changement, et tout ce qui avait mis l’ancienne valeur en cache l’apprend au même moment.

Un endpoint parallèle est un second hôte qui fait le même travail. Construisez-le, testez-le avec un profil, et laissez l’ancien répondre jusqu’à ce que le nouveau fasse ses preuves sur un chemin réel. Le prix est l’état. Sans entrées de peer partagées, révocations et journalisation, vous avez deux réseaux qui partagent par hasard un nom.

Trouvez chaque endroit où l’ancienne adresse est écrite

Commencez par un balayage textuel, car les fichiers de configuration sont la moitié facile. Cherchez dans la configuration du démon, les fragments de pare-feu, les cibles de supervision et tout paquet client généré sur le disque. Incluez l’adresse IPv6 si vous en publiez une ; un déplacement qui ne suit que l’enregistrement A laisse les clients double pile sur l’ancien chemin.

OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpoints

Passez ensuite le noyau au crible, car un système en marche garde l’adresse à des endroits qu’aucun fichier ne mentionne. Une règle NAT source statique, une entrée ipset, une adresse de bind et une entrée conntrack survivent à la modification de configuration qui les a supprimées, et certaines survivent à un redémarrage parce qu’elles sont revenues d’un jeu de règles enregistré. Un cran plus haut, les groupes de sécurité du fournisseur, les cibles du répartiteur de charge et les contrôles de supervision ne sont pas du tout sur votre système de fichiers.

Écrivez l’inventaire avant de changer quoi que ce soit ; il sert aussi de script de retour arrière.

Les clients par nom d’hôte se rétablissent ; les clients en IP littérale se taisent

Si les clients joignent le serveur par nom d’hôte, le basculement est surtout un problème de DNS, et le TTL que vous avez fixé hier décide de la gravité. Les résolveurs mettent en cache, les résolveurs stub en remettent, et beaucoup de clients ne cherchent le nom que sur une nouvelle connexion, donc un tunnel établi conserve son adresse de départ.

Si l’endpoint est une adresse littérale, rien ne se résout à nouveau et rien ne journalise de plainte. WireGuard stocke une adresse de socket résolue : Endpoint = vpn.example.net:51820 devient une IP à l’instant où wg-quick up s’exécute et reste cette IP jusqu’à ce que vous la changiez. OpenVPN est plus indulgent : il résout le nom d’hôte remote au moment de la connexion et, avec resolv-retry infinite, retente le DNS à la reconnexion. Avec une IP littérale, les deux continuent d’appeler une machine qui n’existe plus.

Ce qui trompe les gens, c’est l’image en miroir. Un client déjà pointé vers la nouvelle adresse, alors que l’ancien écouteur répond encore, passe tous les tests que vous faites depuis votre bureau. J’ai été piégé par ça : le nouvel endpoint est monté sur un téléphone du premier coup, et un client avec un profil périmé n’est apparu que lorsque l’ancien écouteur a été coupé bien plus tard.

La confiance ne se déplace pas avec l’adresse

WireGuard sépare l’identité de l’accessibilité, ce qui rend un déplacement d’adresse presque gratuit. Les peers sont identifiés par clé publique, et l’endpoint n’est que l’endroit où vont les paquets à un instant donné ; un hôte met à jour l’endpoint d’un peer à partir de l’adresse source du dernier paquet authentifié. Un peer inactif a tout de même besoin d’une raison de parler au nouvel endroit, et il n’apprend l’adresse que lorsque sa session vieillit et que les tentatives de handshake échouent à un endroit visible. Le démarrage rapide de WireGuard couvre le champ endpoint.

Les serveurs à base de TLS sont le cas inverse. Le certificat est lié à un nom, et un client qui compose une adresse compare ce qu’il a composé aux noms alternatifs du sujet. Connectez-vous par IP à un certificat qui ne porte qu’un SAN DNS et la vérification échoue : le nom utilisé par le client n’est pas dans le certificat. Réémettre avec un SAN IP corrige cette connexion et aggrave le déplacement suivant. Garder un nom d’hôte dans le profil et laisser verify-x509-name en place maintient le contrôle strict pendant que l’adresse en dessous change.

Vérifiez ensuite ce à quoi le démon est lié ; une socket épinglée à l’ancienne adresse échoue en silence. Un serveur OpenVPN démarré avec local 203.0.113.10 refuse de monter une fois cette adresse disparue, tandis qu’un écouteur sur 0.0.0.0 suit le changement gratuitement. Le NAT se divise de la même manière : MASQUERADE suit l’adresse que la machine possède désormais, et un SNAT --to-source 203.0.113.10 statique continue de réécrire vers une adresse que vous ne possédez plus, si bien que le trafic de retour disparaît. Si la nouvelle adresse arrive avec une autre passerelle upstream, vérifiez rp_filter : le filtrage de chemin inverse écarte le trafic de retour arrivant sur une interface que le noyau n’attendait pas.

Ordre du basculement et les preuves qu’il a fonctionné

Baissez le TTL un jour avant, montez le nouvel écouteur, et prouvez-le avec un profil que vous seul détenez. Un test depuis l’intérieur du même réseau ne prouve presque rien, alors utilisez un téléphone en réseau mobile et testez quelque chose que le tunnel est censé transporter plutôt qu’un ping vers l’endpoint.

Surveillez les deux adresses pendant toute la fenêtre. wg show all latest-handshakes sur le nouvel hôte, ou le fichier d’état d’OpenVPN, indique combien de peers ont réellement déménagé. Quand le nouvel endpoint a les peers attendus et que l’ancien n’a que des retardataires, retirez l’ancien écouteur, supprimez la règle NAT obsolète et retirez l’adresse du pare-feu du fournisseur. Retirer l’ancien écouteur est l’étape que l’on saute, et elle ferme la brèche où un profil périmé atteint encore l’ancien réseau.

Fixez par écrit le déclencheur de retour arrière avant de commencer : si le nouvel endpoint n’a de handshake d’aucun client réel après la fenêtre convenue, restaurez l’ancienne adresse et cessez de distribuer des profils. Relancez le balayage ensuite et confirmez qu’aucun écouteur n’est encore lié à une adresse retirée. Deux choses passent au déplacement suivant : un nom d’hôte dans le profil client pour que le prochain changement soit une édition DNS, et l’inventaire conservé à côté des notes de récupération du serveur.