WireGuard ne fonctionne qu’après l’envoi du serveur : la connaissance du point de terminaison

Le tunnel semble ne fonctionner qu’après que le serveur a envoyé quelque chose en premier. Lancez depuis le client et rien ne se passe, attendez quelques secondes, réessayez et cela réussit. Le diagnostic habituel est un NAT cassé, et le diagnostic habituel est faux. Ce qui a changé, c’est qu’un pair a appris où vit l’autre.

La connaissance du point de terminaison, pas l’accessibilité

Un pair WireGuard ne lancera pas de handshake tant qu’il ne sait pas où l’envoyer. La configuration le fournit sous forme de point de terminaison composé d’une adresse et d’un port, et l’état d’exécution suit le point de terminaison auquel il croit actuellement.

wg show affiche les deux côtés de cette image, et un pair sans point de terminaison dans la sortie ne peut rien lancer, aussi corrects que soient sa clé publique et ses préfixes autorisés. Comparez la vue du client avec celle du serveur avant de modifier la moindre règle, car les deux sont souvent en désaccord sur qui sait quoi.

Comment un pair apprend un point de terminaison

WireGuard est volontairement silencieux. Quand un paquet correctement authentifié arrive d’une adresse que le pair n’attendait pas, l’implémentation met à jour le point de terminaison de ce pair vers la nouvelle source, et c’est ainsi que fonctionne l’itinérance sur un ordinateur portable qui change de réseau. Ce comportement explique la dépendance au sens : si le serveur envoie en premier et que son paquet atteint le client, le client apprend l’adresse actuelle du serveur et peut répondre. Jusque-là, il n’a nulle part où envoyer. Le mécanisme est de l’itinérance authentifiée et non un raccourci de confiance au premier usage, car le paquet devait être valide avant que le point de terminaison ne bouge.

La documentation des outils pour wg décrit cette mise à jour, et elle vaut une lecture si vous comptez concevoir autour.

La traduction avec état ajoute son propre sens

Là où l’UDP traverse une passerelle qui traduit, la passerelle crée un état pour le premier paquet qu’elle voit. RFC 4787 décrit ce comportement et les délais qui finissent par supprimer la correspondance. Une correspondance inactive expire, et un paquet entrant du côté distant est alors écarté par la passerelle avant d’atteindre l’hôte. Un tunnel qui fonctionnait toute la matinée cesse de répondre l’après-midi exactement pour cette raison.

Il s’agit d’un second mécanisme, indépendant, qui produit le même symptôme directionnel. La connaissance du point de terminaison et l’état de traduction doivent tous deux être corrects, et corriger l’un ne corrige pas l’autre.

Configurez le sens que vous voulez réellement

Pour un client qui doit lancer la connexion, placez le point de terminaison du serveur dans la section des pairs du client et laissez-le là. Compter sur un envoi du serveur en premier, c’est compter sur un hasard dans l’ordre du trafic qui changera sur un réseau calme. La configuration devrait énoncer le sens prévu, pas le découvrir.

Pour un pair derrière une traduction qui doit rester joignable, activez un keepalive persistant de ce côté. Un keepalive toutes les 25 secondes est la valeur de départ habituelle, et son but est de garder la correspondance ouverte plutôt que de tester le tunnel. Choisissez un seul côté pour le porter, car l’activer des deux côtés double le trafic et le bruit des journaux sans améliorer le résultat.

Comparez l’état avant et après le déclencheur

Capturez les deux vues au moment de l’échec, puis de nouveau après l’envoi du serveur. La première commande montre les points de terminaison et l’âge du handshake. La seconde montre si une entrée de traduction existe pour le port. La capture montre quel sens a réellement traversé le câble, et la vérification de route confirme que le client n’envoie pas ce trafic ailleurs.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Notez la colonne du point de terminaison et l’entrée de traduction ensemble. Un pair sans point de terminaison et une passerelle sans correspondance sont deux pannes différentes. Une seule des deux se corrige avec un keepalive.