Changer de fournisseur VPN : planifier le nom d’hôte, pas seulement l’IP

Votre enregistrement DNS est correct, le remplacement est sain, et pourtant certains clients passent des heures à composer l’ancienne adresse. Quelques-uns échouent aussitôt face à un nom qui se résout et ne répond jamais. Les deux résultats viennent d’un même manque : un nom d’hôte change ce qu’un client recherche, pas quand il le recherche, ni ce à quoi il se fie quand la réponse arrive.

Le symptôme : un enregistrement correct, des tunnels obsolètes

Un profil qui stocke un nom n’est pas un client qui le résout en permanence. La plupart le résolvent une fois, à l’application de la configuration ou quand le tunnel monte, puis réutilisent cette adresse jusqu’à la fin de la session. Un TTL long empilé par-dessus explique pourquoi la bascule doit être planifiée autour des reconnexions et non autour de la modification DNS.

Aucun des deux comportements n’est un défaut, et c’est précisément ce qui rend le symptôme déroutant. Le client travaille à partir d’une réponse obtenue plus tôt, et rien côté serveur n’indique laquelle c’était. Planifiez la reconnexion dans la fenêtre de maintenance et dites aux utilisateurs ce qu’ils verront, ou passez la fenêtre à répondre aux tickets. Une file de rapports identiques est le résultat habituel.

Qui contrôle le nom, et ce que le client vérifie

Le contrôle de la zone décide de la vitesse à laquelle une migration peut avancer. Gardez l’enregistrement chez un registraire où vous pouvez vous connecter, et notez qui d’autre peut le modifier.

La confiance ne suit pas le nom. Un client basé sur TLS peut vérifier l’identité d’un certificat ou un nom épinglé, tandis que WireGuard authentifie la clé publique du pair et ignore entièrement le nom d’hôte. Cette différence décide si une modification DNS suffit ou si chaque profil a besoin d’une nouvelle empreinte. Un changement d’enregistrement ne devrait jamais autoriser un point de terminaison que personne n’a approuvé.

Gardez l’accès administratif et l’accès de récupération à l’écart du nom public du client. Perdre un compte d’hébergement ne devrait pas aussi vous coûter l’enregistrement qui redirige les clients. Stockez le chemin de récupération ailleurs, là où il ne dépend pas du fournisseur que vous quittez.

Quand chaque client relit le nom

Le moment de la résolution est une propriété propre à chaque client, alors vérifiez l’implémentation que vous livrez réellement avant de promettre une fenêtre de bascule. wg-quick résout le point de terminaison à la montée de l’interface et conserve cette adresse jusqu’au redémarrage du tunnel. Un client OpenVPN cherche le nom lors de la connexion, et s’il regarde à nouveau lors d’une reconnexion dépend de ses options.

Les clients mobiles sont la surprise habituelle, car ils peuvent conserver une adresse résolue pendant une veille ou un changement de réseau. Publiez des enregistrements A et AAAA uniquement si le remplacement répond sur les deux familles. Une adresse qui répond sur une famille ne prouve rien pour l’autre, et un enregistrement AAAA mort ajoute un délai à chaque tentative. Documentez le comportement de résolution de chaque client que vous prenez en charge, puis testez sur les appareils que les gens utilisent vraiment.

Une reconnexion est une action de l’utilisateur dans la plupart des clients, et le serveur ne peut pas l’imposer. Inscrivez cette étape dans la note de maintenance, avec une ligne sur ce que l’utilisateur verra quand elle se produira.

Basculez sur preuve, puis retirez l’ancien point de terminaison

Avant la bascule, prouvez chaque couche sur le remplacement : l’écouteur répond, le pare-feu laisse passer le port, les routes reviennent dans le bon sens, le nom se résout vers la nouvelle adresse et une identité connue est acceptée. Un écouteur qui accepte une connexion n’est pas la même chose qu’un qui termine une poignée de main, alors testez la poignée de main et non le port. Gardez la liste de révocation actuelle à côté de la configuration, car une sauvegarde restaurée recrée la liste des pairs telle qu’elle était et rouvrirait un accès que vous avez déjà fermé. Notez avec quelle identité vous avez testé, car « ça marche » n’est pas une preuve que quiconque peut reproduire.

getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakes

Pendant la transition, surveillez les tentatives de connexion sur les deux points de terminaison pour la même identité. Un client qui s’authentifie encore contre l’ancienne adresse est un profil ou une réponse en cache qui n’a jamais bougé. Retirez l’ancien point de terminaison selon un plan daté, car deux services qui acceptent une identité laissent deux portes ouvertes.

Le test de bascule est une session applicative à travers le nouveau point de terminaison, pas un ping. Une fois cette session fonctionnelle et l’ancien point de terminaison ne journalisant aucune tentative autorisée sur un cycle complet de reconnexion, le déménagement est terminé.