Nouveau routeur, même serveur VPN : déplacez son entrée publique

Vous branchez le nouveau routeur, internet revient, et le client VPN du téléphone pointe toujours vers une adresse qui ne répond plus. Rien n’a changé sur le serveur VPN, car le serveur n’a jamais bougé. Le routeur était le point d’entrée public, et le remplacer a remplacé l’adresse, la règle de redirection et peut-être le programme de mise à jour du DNS dynamique en même temps.

Traitez le remplacement comme deux transferts, pas un, et gardez un accès local à l’interface d’administration pendant le travail.

Écrivez le transfert avant de débrancher

Notez le préfixe LAN, l’adresse du serveur et la façon dont elle est attribuée, l’écouteur et le transport que le VPN utilise réellement, la règle entrante qui le publie et le nom que les clients ont enregistré. Notez ensuite quelle machine met à jour l’enregistrement DNS dynamique aujourd’hui : ce peut être le routeur, le serveur lui-même ou un agent séparé sur un autre hôte. Faites-le pendant que les anciennes pages d’administration se chargent encore. Une capture d’écran de la règle entrante vaut mieux qu’un numéro de port mémorisé.

Ajoutez les préfixes privés que les clients sont censés joindre, et la façon dont les appareils du LAN leur renvoient les réponses. Les deux s’oublient facilement, car l’assistant de remplacement parle d’accès à internet et non de chemins de retour. Exportez aussi l’ancienne configuration si le fabricant prend en charge sa restauration, en acceptant qu’une sauvegarde d’un modèle s’importe rarement proprement dans un autre.

Conservez cette trace dans un endroit protégé. Une sauvegarde de routeur peut contenir des identifiants pour la liaison WAN. Traitez le fichier exporté comme un mot de passe et non comme une note de réglages.

Déplacez d’abord l’adresse, ensuite la redirection

Si le nouveau routeur conserve le même préfixe LAN, donnez au serveur la réservation qu’il avait, ou une attribution statique équivalente. Si le préfixe change, mettez d’abord à jour l’adresse du serveur et toute liaison d’écouteur qui la nomme, car une redirection vers l’ancienne adresse enverra silencieusement le trafic nulle part.

Recréez ensuite exactement une règle entrante pour le transport que le VPN utilise. Les guides de fabricant qui décrivent la redirection vers un serveur local montrent le mécanisme, pas une recette universelle, alors adaptez la règle à votre protocole et à votre port réels plutôt qu’à une liste trouvée sur un blog. Une redirection sur le nouveau routeur ne peut pas supprimer le NAT d’opérateur qui se trouve au-dessus, et aucune règle locale ne rendra une adresse privée joignable depuis internet si le fournisseur en partage déjà une avec vous.

Vérifiez que le pare-feu du serveur autorise toujours ce trafic. Contrôlez si une seconde passerelle se trouve entre le routeur et internet, car beaucoup de fournisseurs livrent un modem et un routeur combinés. Lisez l’adresse WAN sur le nouvel appareil et comparez-la à l’adresse que les clients résolvent. Si elles diffèrent, votre redirection atterrit sur quelque chose qui n’est pas le bord.

Décidez qui met à jour le nom public

Les mises à jour du point de terminaison demandent un propriétaire et un seul. Si l’ancien routeur publiait le nom, configurez un programme de mise à jour pris en charge sur le remplaçant et confirmez que l’enregistrement a réellement changé. Si le serveur le publiait déjà, laissez ce dispositif tranquille au lieu d’ajouter un programme concurrent qui oscille entre deux adresses.

Quand le déploiement publie les deux familles d’adresses, lisez à la fois l’enregistrement A et l’enregistrement AAAA. Chacun doit pointer vers un service qui écoute vraiment et qui est autorisé par son propre chemin de pare-feu, et une correspondance IPv4 qui fonctionne ne dit rien du côté IPv6. Conservez aussi les contrôles d’identité dans le profil du client : une adresse publique modifiée n’est pas une raison d’accepter un certificat ou une clé de pair qui ne correspond pas.

Prouvez le remplacement depuis l’extérieur

Testez avec une connexion externe autorisée et une session neuve, pas depuis l’intérieur du LAN. Un test interne vers l’adresse publique dépend du comportement de retour vers sa propre adresse et emprunte un chemin différent de celui d’un vrai client.

Suivez la séquence d’un client : résolvez le nom, négociez le tunnel, authentifiez-vous, puis effectuez une opération vers une ressource privée. C’est cette dernière étape que les gens sautent, et elle seule prouve le chemin de retour. Si la connexion réussit mais que l’opération privée échoue, comparez le nouveau préfixe LAN, les routes choisies par le client et le chemin de réponse de la ressource avec vos notes de transfert.

C’est seulement une fois les quatre étapes passées que l’ancien routeur peut être retiré sans risque. Débranchez-le, puis répétez le test externe une dernière fois. Un enregistrement périmé qui résout encore vers l’ancienne adresse échoue dès la première étape, et c’est plus facile à diagnostiquer tant que l’ancien appareil est encore sur l’étagère.

Gardez la nouvelle correspondance avec vos notes de récupération

Classez l’attribution finale du serveur, la règle entrante et le nom du propriétaire de la mise à jour à côté de la procédure d’accès local au routeur. Le prochain remplacement devrait partir de cette page et non d’un traceroute.

Si le tunnel échoue encore depuis l’extérieur après tout ce qui précède, vérifiez si l’adresse publique annoncée par le routeur correspond à celle que les clients résolvent. Cette seule comparaison sépare un problème de DNS d’un problème de redirection, et elle prend moins de temps que lire encore un guide de redirection de ports.