WireGuard : aucune route vers le pair après un changement de sous-réseau — deux issues

La poignée de main est fraîche dans wg show, le point de terminaison est correct, les clés n’ont jamais changé — et ping dit toujours qu’il n’y a aucune route vers le pair. Vous avez changé le sous-réseau du tunnel il y a une heure. Ce symptôme est la signature d’une inadéquation de préfixe et non d’un problème de clés : WireGuard a terminé la poignée de main puis a rejeté les données parce qu’une adresse source ne correspond plus à ce que le pair récepteur acceptera. Il existe deux façons raisonnables de mener un changement de sous-réseau, et elles échouent à des endroits différents.

Deux façons de mener le changement, et ce que chacune coûte

L’option A est la renumérotation sur place : modifiez l’adresse de l’interface, les plages des pairs, les routes et chaque copie de la configuration, puis rechargez. L’option B consiste à construire une seconde interface sur le nouveau préfixe à côté de l’ancienne, à y déplacer les pairs et à retirer l’ancienne interface une fois que le trafic a réellement bougé.

C’est l’état à moitié appliqué qui rend l’option A dangereuse, car il n’a pas l’air cassé. L’interface monte, la poignée de main réussit et seul le chemin des données échoue. L’option B coûte plus de travail mais garde un chemin fonctionnel vivant pendant que vous trouvez chaque référence.

Ce qui doit bouger ensemble de votre côté

Quatre choses sur l’hôte local décrivent le même sous-réseau, et changer l’une revient à changer toutes : l’adresse de l’interface, l’AllowedIPs de chaque pair, la route que le système utilise pour ces destinations et tout ce que le gestionnaire installe en votre nom. Avec wg-quick, les deux dernières sont générées à partir de la configuration chaque fois que l’interface monte, si bien qu’une copie obsolète réinstalle silencieusement l’ancien préfixe.

Comparez ce qui est configuré à ce qui est vivant plutôt que de faire confiance à l’un des deux :

wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5

La consultation de route est l’étape que les gens sautent. Elle répond ce que le noyau ferait réellement pour une destination, y compris une route plus spécifique laissée par un gestionnaire ou un environnement d’exécution de conteneurs. Si elle indique une interface différente de celle du tunnel, ce n’est pas la configuration le problème.

Pour une interface en cours d’exécution, appliquez le fichier modifié sans démonter le tunnel :

wg syncconf wg0 <(wg-quick strip wg0)

Cela met à jour les pairs et les plages sur place. Cela ne met pas à jour l’adresse de l’interface ni les routes, car ce ne sont pas des réglages WireGuard — une renumérotation exige donc toujours de recréer l’interface ou de changer l’adresse avec ip, puis de revérifier le routage.

Ce qui doit bouger ensemble à l’autre bout

C’est là qu’un changement de sous-réseau meurt généralement. AllowedIPs n’est pas seulement une indication de routage ; c’est aussi la liste des adresses source qu’un pair est autorisé à présenter. Quand vous renumérotez des clients et laissez l’AllowedIPs du serveur sur l’ancien préfixe, le serveur accepte la poignée de main, reçoit les paquets chiffrés et les rejette parce que la source interne ne correspond à aucune plage qu’il associe à ce pair. Aucune erreur n’est journalisée et le client voit un délai d’attente.

Mettez donc à jour le côté récepteur avec intention : l’entrée du pair sur le serveur doit lister le nouveau préfixe du client, la route de retour du serveur doit pointer vers le tunnel pour ce préfixe, et tout réseau en aval derrière le serveur doit apprendre le nouveau chemin. La politique de pare-feu qui nommait l’ancienne plage a besoin du même traitement, tout comme ce qui fait une sélection par source.

Le diagnostic qui sépare les deux défaillances est bon marché. Une poignée de main récente sans données signifie que le tunnel est monté et que l’adressage interne n’est pas d’accord. Aucune poignée de main du tout signifie que vous regardez l’accessibilité ou les clés. Ne changez pas les clés pour un problème de préfixe ; cela réinitialise la seule chose qui fonctionnait.

Des copies obsolètes qui survivent à votre modification

Modifier un fichier n’est pas la même chose que changer le système en marche, et les copies sont plus nombreuses que les gens ne l’imaginent : l’unité ou le gestionnaire qui possède l’interface, un second profil du même nom dans un autre répertoire, un conteneur dont la configuration est intégrée à une image, une interface de routeur qui conserve sa propre version modifiée et une application cliente qui réimporte un tunnel enregistré au démarrage. Chacune peut restaurer l’ancien préfixe après que votre changement semble terminé.

Les noms voyagent aussi. Si la route numérique fonctionne mais que le nom d’hôte échoue, un enregistrement DNS interne ou une configuration de service pointe encore vers l’ancienne adresse du tunnel. Corrigez la référence au lieu d’élargir chaque plage de pair, ce qui masquerait le vrai problème et agrandirait en même temps l’ACL source.

Gardez un chemin de récupération ouvert pendant que vous travaillez : un second moyen d’entrer sur l’hôte, une console série ou un retour arrière planifié des fichiers de configuration. Un changement de tunnel qui vous enferme dehors de la machine que vous modifiez est la façon la plus courante dont cette tâche se transforme en soirée.

Choisir entre les deux, et vérifier la bascule

Choisissez A quand vous possédez chaque pair, que le nombre est faible et qu’une courte interruption est acceptable. Choisissez B quand les pairs sont des mains distantes que vous ne contrôlez pas, quand une liaison de site à site doit rester en place ou quand vous ne pouvez pas garantir que chaque copie sera mise à jour en une seule passe. Dans ce cas, ajoutez le nouveau préfixe aux deux interfaces, déplacez les pairs un par un, surveillez le trafic sur la nouvelle et retirez seulement ensuite l’ancienne interface et ses routes.

Dans les deux options, le changement est fait quand quatre contrôles passent : la poignée de main est récente, la consultation de route pour une destination du nouveau préfixe nomme le tunnel, une charge de quelques centaines d’octets passe dans les deux sens, et il en va de même après un redémarrage de l’hôte ou du gestionnaire. Le manuel wg(8) est la référence de ce que signifie AllowedIPs dans chaque sens, et il vaut la peine de le relire avant d’élargir une plage pour faire disparaître un symptôme.

• Poignée de main récente et aucune donnée : regardez l’AllowedIPs chez le récepteur avant de toucher aux clés.
• La consultation de route indique la mauvaise interface : un gestionnaire ou un conteneur possède la route, pas votre fichier.
• Adresse numérique correcte et nom d’hôte cassé : une ancienne référence, pas une boucle de routage.
• Le changement n’est complet que lorsque, après un redémarrage, le nouveau préfixe est encore utilisé.