WireGuard PersistentKeepalive : garder la correspondance NAT active

La box domestique ouvre le tunnel et atteint le serveur cloud sans difficulté. Le serveur cloud peut atteindre l’application domestique pendant une minute ou deux après que la box a envoyé quelque chose pour la dernière fois, puis il cesse. Rien n’apparaît dans le journal de WireGuard, aucune erreur de handshake n’est signalée, et un redémarrage du tunnel corrige le problème brièvement. Ce schéma est une correspondance qui expire, pas un tunnel cassé, et le guide ci-dessous le confirme avant de changer quoi que ce soit.

Confirmez que le schéma est une expiration par inactivité

Le détail qui le distingue est le moment. Si la connexion inverse fonctionne juste après que le pair domestique a envoyé du trafic et échoue après un intervalle calme, le chemin est bon et l’état intermédiaire ne l’est pas. Si elle n’a jamais fonctionné, même juste après du trafic, c’est un mauvais diagnostic.

sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transfer

Lancez les deux premières juste après que le pair domestique a envoyé quelque chose, attendez cinq minutes et relancez-les. Un horodatage de handshake qui se renouvelle comme prévu sans nouveau point de terminaison vous dit que le tunnel est vivant. Ce qui a changé, c’est la capacité de paquets non sollicités à arriver de l’extérieur, une propriété du chemin et non du tunnel.

Faites ensuite une tentative inverse et surveillez les compteurs de transfert. Si le côté cloud envoie des octets et que le côté domestique n’en reçoit aucun, le paquet a quitté le cloud et est mort dans un équipement à état en chemin. C’est la signature que vous cherchez. Si les deux compteurs bougent, le tunnel a livré le paquet et l’application est le suspect.

Placez le keepalive sur le pair derrière le routeur

Les keepalives persistants maintiennent une correspondance NAT et tout état de pare-feu en vie en envoyant régulièrement un petit paquet authentifié. Le réglage appartient à la machine derrière le routeur, dans son entrée pour le pair distant, car c’est le côté dont le paquet sortant crée l’état.

[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25

Fusionnez-le dans la section de pair existante. Ajouter un second bloc avec la même clé publique n’est pas une façon valide d’ajouter des options, et wg-quick ne les fusionnera pas pour vous. Les 25 secondes documentées sont un exemple choisi pour rester sous les délais UDP courants, pas une valeur au sens particulier.

Mettre la même directive du côté cloud n’aide pas pour ce problème. Les paquets de ce pair arrivent déjà d’une adresse publique, il n’y a donc aucune correspondance à préserver dans la direction qui compte. Cela ajoute du trafic et ne change rien.

Lisez les temporisateurs au lieu de deviner un intervalle

Les keepalives fonctionnent parce qu’ils arrivent plus souvent que l’état n’expire. Cela fait du délai le nombre dont vous avez réellement besoin, et sous Linux il est lisible sur l’appareil qui fait la traduction :

sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820

La première valeur est le délai d’un flux UDP qui n’a été vu que dans un sens, et la seconde s’applique une fois des réponses observées. Les deux sont généralement courts, et une correspondance qui se tait suivra celle qui s’applique à votre flux.

Comparez ce nombre à votre intervalle. Un keepalive de 25 secondes sous un délai de 30 secondes fonctionne ; le même keepalive sous un délai de 15 secondes ne fonctionne pas. Aucune quantité de nouvelles tentatives ne change cette arithmétique. Certains routeurs grand public et opérateurs mobiles utilisent des valeurs bien plus courtes que la valeur par défaut de Linux, ce qui explique qu’une configuration qui marche sur un réseau échoue sur un autre.

Vérifiez l’écouteur et le pare-feu séparément

Une correspondance vivante est nécessaire et pas suffisante. L’application sur la box doit écouter sur la bonne adresse, et le pare-feu de l’hôte doit autoriser le paquet après déchiffrement.

sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/health

Si la socket n’est liée qu’à l’adresse de l’interface physique et non à l’adresse du tunnel, les paquets qui arrivent par le tunnel sont rejetés avant même que le pare-feu soit consulté. Cette panne ressemble, vue du côté cloud, exactement à un problème de correspondance, et elle survit à chaque ajustement de keepalive.

La vérification de la liste autorisée est tout aussi importante dans l’autre sens. Le pair cloud doit autoriser l’adresse du tunnel domestique comme source s’il doit répondre, et le pair domestique doit autoriser l’adresse cloud comme destination. Les paquets keepalive sont du trafic authentifié et appliquent les mêmes règles, c’est pourquoi un keepalive qui semble fonctionner peut coexister avec une application qui ne fonctionne pas.

Déployez le changement et connaissez ses limites

Appliquez le réglage, redémarrez l’interface si c’est votre méthode de mise à jour, puis répétez le test d’inactivité plutôt que le test immédiat. Attendez plus longtemps que le délai que vous avez lu plus tôt, faites une requête inverse et confirmez que les compteurs ont bougé aux deux extrémités.

Notez l’intervalle et le délai que vous avez mesuré à côté. Un changement futur du firmware du routeur, ou un passage à une connexion mobile, peut modifier le délai. La note est ce qui permet à quelqu’un de recalculer la valeur au lieu de la copier. Deux nombres sur une ligne épargnent toute une enquête plus tard.

Les keepalives persistants protègent l’état. Ils n’ouvrent pas de port, ils n’ajoutent pas d’entrée à la liste autorisée et ils ne font pas apparaître un écouteur. Quand la connexion inverse ne fonctionne pas du tout, la faute est l’une de ces trois, et le démarrage rapide de WireGuard décrit le réglage keepalive dans les mêmes termes étroits.