WireGuard utilise toujours l’ancien point de terminaison après un changement DNS

Le tunnel a cessé d’acheminer du trafic après le déplacement de l’enregistrement DNS du serveur, et le nom se résout correctement depuis la même machine. Ces deux faits ne se contredisent pas. Une configuration WireGuard contient un point de terminaison, et l’outil résout le nom au moment où il applique cette configuration, si bien que l’interface en cours d’exécution peut continuer d’utiliser l’adresse qu’elle a consultée il y a des heures. Vérifiez ce que l’interface utilise avant de remplacer des clés ou de toucher à la plage du tunnel.

Le nom est résolu une fois, pas en continu

La configuration de base de WireGuard prend un point de terminaison sous forme d’adresse et de port, et l’outil qui monte une interface résout un nom d’hôte à cet instant. Rien dans le protocole de base n’interroge le DNS selon un calendrier, et une application cliente peut ajouter par-dessus son propre comportement de rafraîchissement. Consigner l’adresse résolue, la famille et le port à côté du nom rend l’écart visible. Sans cette trace, la configuration paraît correcte alors que l’interface parle à autre chose.

Il existe une véritable mise à jour automatique, et elle vaut la peine d’être connue car elle ressemble à un rafraîchissement DNS sans en être un. Le point de terminaison d’un pair peut se déplacer lorsque du trafic correctement authentifié arrive d’une nouvelle adresse, ce qui est de l’itinérance et non une résolution de nom. Il suit le pair, il ne peut donc pas découvrir un nouveau serveur sans rapport que l’ancien point de terminaison n’a jamais contacté.

Comparez l’enregistrement avec l’adresse réellement utilisée

Interrogez le nom documenté via le résolveur qu’utilise le client, puis demandez à l’interface quel point de terminaison elle détient. Les deux réponses forment la comparaison qui décide du reste de cette page :

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

La page de manuel wg(8) documente les sous-commandes show utilisées par ces lignes. Comparez aussi la famille d’adresses, pas seulement l’adresse, car un enregistrement qui a gagné une entrée IPv6 est une comparaison différente de celui dont l’adresse IPv4 a changé. Si le point de terminaison diffère de l’enregistrement, l’interface fonctionne sur des informations périmées et le nom n’a jamais été le problème. S’ils concordent et que le tunnel échoue toujours, passez à l’écouteur et aux règles plutôt qu’au profil.

L’horodatage de la poignée de main figure dans ce bloc car le point de terminaison seul ne dit pas si le pair est joignable. Un horodatage périmé à côté d’un point de terminaison correct est un problème de chemin, pas de résolution, et cette distinction change ce que vous toucherez ensuite.

Redémarrez via le gestionnaire de l’interface

Une fois le point de terminaison confirmé périmé, rafraîchissez-le via le mécanisme qui possède l’interface au lieu de modifier la configuration active. Pour une interface démarrée par wg-quick, c’est un arrêt et un démarrage, pour une unité systemd c’est un redémarrage, et pour une interface gérée par un gestionnaire c’est une modification faite dans ce gestionnaire, car une modification à chaud est écrasée à la prochaine application :

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

Confirmez ensuite que l’écouteur de remplacement et son identité sont bien le service voulu. Un déplacement DNS n’est pas un changement d’identité, il ne devrait donc jamais être l’occasion de faire confiance à une clé que vous n’avez pas vérifiée. Si l’interface signale maintenant la nouvelle adresse et ne produit toujours aucune poignée de main, la panne s’est déplacée vers le nouveau chemin réseau ou l’écouteur, ce qui est un progrès et non la même panne deux fois.

D’abord la poignée de main, ensuite le chemin des données

Séparez les deux issues avant de choisir une liste de vérification. Une poignée de main qui réussit sous une application qui échoue est un problème de chemin de données : routes, préfixes autorisés ou DNS à l’intérieur du tunnel. Une poignée de main qui n’a jamais lieu est un problème de joignabilité ou d’identité au point de terminaison. Mélanger les deux produit un rapport que personne ne peut reproduire et un journal de modifications avec trois éditions sans rapport.

Notez le nom, l’adresse résolue, le point de terminaison utilisé et si la poignée de main a abouti. Ces quatre faits répondent à la question que cette panne ne cesse de poser, et transforment l’occurrence suivante en vérification de deux minutes. La maintenance du nom et l’adoption côté client restent des tâches distinctes : corriger l’enregistrement ne réalise pas l’adoption, et redémarrer l’interface ne répare pas un enregistrement encore faux.