Deux peers WireGuard partagent une plage : lequel reçoit le paquet

Deux peers listent des plages qui se touchent, et le trafic arrive au mauvais. Rien n’est corrompu : WireGuard choisit un peer en faisant correspondre la destination aux plages configurées, et la correspondance la plus spécifique gagne. Avant d’élargir quoi que ce soit, décidez quel peer est censé posséder quel préfixe.

Le préfixe le plus long gagne à l’intérieur de WireGuard

Chaque entrée de peer porte un ensemble de préfixes de destination. Lorsqu’un paquet est routé vers l’interface, l’implémentation cherche l’entrée dont le préfixe correspondant est le plus spécifique — la même règle qu’applique une table de routage. Un /24 bat donc un /16 qui le contient, et le peer le plus étroit reçoit le trafic.

Les installations road-warrior l’utilisent délibérément. Un peer possède une plage large pour un site, et des hôtes individuels sont détachés avec des entrées /32 qui appartiennent à d’autres peers. Le schéma fonctionne parce que les détachements sont plus spécifiques, non à cause de l’ordre.

Consignez la propriété sous forme de tableau préfixe et peer. Si deux entrées décrivent le même préfixe, la configuration n’exprime plus une intention, elle exprime une course.

Le système d’exploitation choisit d’abord l’interface

WireGuard ne choisit qu’entre les peers d’une seule interface. Quelle interface reçoit le paquet se décide plus tôt, par la table de routage de l’hôte, et une seconde route par défaut ou une route périmée peut envoyer le trafic là où la liste des peers ne le voit jamais. C’est pourquoi un diagnostic au niveau du peer peut être correct et pourtant ne pas expliquer la panne. Vérifiez la route vers la destination avant de lire la configuration du peer, car une route qui pointe vers l’interface physique contourne toute la question.

L’outil installe généralement ces routes à partir des plages des peers, ce qui signifie qu’une modification de la liste d’un peer peut silencieusement rediriger du trafic qui appartenait auparavant à un autre. Modifier un peer est donc un changement de routage déguisé. Examinez les deux à la fois, sinon vous en réparerez un et casserez l’autre.

Les paquets entrants sont vérifiés par la source

La liste des plages remplit une double fonction. Pour le trafic sortant, elle choisit un peer selon la destination ; pour le trafic entrant, elle autorise une adresse source. Un paquet arrivant d’une adresse hors des plages de ce peer est rejeté avant qu’un pare-feu ne le voie.

Cette asymétrie est facile à manquer quand on lit un seul côté de la configuration. Un peer qui peut atteindre un sous-réseau n’est pas pour autant autorisé à émettre depuis ce sous-réseau, et les deux directions sont appliquées par des contrôles différents.

Une propriété de source étroite transforme cela en avantage. Donnez à chaque peer un /32 pour sa propre adresse et le pare-feu en aval dispose d’une source fiable à comparer, plutôt qu’une plage de groupe que n’importe quel membre pourrait revendiquer.

Les plages en double ne sont pas du failover

Attribuer le même préfixe à deux peers ne crée ni répartiteur de charge ni chemin de secours. Il n’y a ni contrôle de santé ni affinité de session : l’entrée gagnante est décidée par l’ordre interne de l’implémentation, qui n’est pas un contrat sur lequel concevoir. Si vous avez besoin de sorties alternatives, exprimez-les là où la sélection est définie. Une politique de routage, une métrique ou une paire de préfixes distincts avec un propriétaire documenté chacun produisent un comportement que vous pouvez prévoir et tester.

Élargir une plage pour corriger une panne sans rapport est l’autre erreur courante. Cela éloigne le trafic du peer qui fonctionnait, et le nouveau symptôme arrive avant que l’ancien soit compris.

Vérifiez la sélection avant de modifier

Trois commandes répondent aux trois questions dans l’ordre. La première liste les plages que chaque peer revendique. La deuxième montre quelle interface l’hôte utiliserait pour une destination. La troisième montre l’état des peers en direct après que le trafic a circulé.

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

Exécutez-les avant et après un changement, puis comparez. Si la sortie de route a changé mais que le trafic arrive toujours au mauvais peer, les listes de préfixes se chevauchent d’une manière que vous n’avez pas encore consignée. Si la sortie de route n’a pas changé, la configuration du peer n’était jamais ce qui était consulté.

Consignez la destination, l’interface choisie et le peer choisi dans le ticket. Ce triplet rend un chevauchement vérifiable plus tard et il est bien plus utile qu’une capture d’écran de la configuration.