NOPE LinkedIn

Catégories:
wireguard
network
VPN

Troubleshooting Wireguard avec Tcpdump

Important

Traduction d’un article du site PRO CUSTODIBUS

Le contenu de cette page est la traduction Française de l’article TROUBLESHOOTING WIREGUARD WITH TCPDUMP de Justin Ludwig

Primary Wireguard topologies

Lorsqu’une connexion WireGuard ne fonctionne pas, c’est généralement l’une des quatre choses suivantes : un problème de configuration WireGuard, un problème de pare-feu, un problème de routage ou un problème DNS. L’utilitaire tcpdump peut vous aider à diagnostiquer rapidement de quel type de problème il s’agit, en identifiant où les paquets vont mal.

Par exemple, disons que nous essayons de configurer un réseau WireGuard point à site, comme celui illustré par le guide de configuration WireGuard point à site. Dans ce scénario, nous essayons d’accéder au point de terminaison B via un tunnel WireGuard du point de terminaison A à l’hôte β. Nous pouvons utiliser tcpdump pour identifier si des paquets sont abandonnés ou mal dirigés aux points suivants (étiquetés A1-A6 sur Endpoint A et B1-B8 sur Host β) :

Troubleshooting wireguard avec tcpdump

Dans ce scénario, Endpoint A a une interface WireGuard wg0, avec une adresse IP de 10.0.0.1, que nous voulons connecter à l’interface wg0 WireGuard sur l’hôte β, avec une adresse IP de 10.0.0.2. Le point d’extrémité A est connecté au LAN (réseau local) du site A via son interface WiFi wlan0, avec une adresse IP de 192.168.1.11 ; et il y a un routeur NAT (Network Address Translation) avec une adresse IP publique de 198.51.100.1 entre lui et Internet.

L’hôte β a une interface WAN (Wide Area Network) de eth0, avec une adresse IP publique de 203.0.113.2, connectée à Internet. Il est connecté au réseau local du site B via une deuxième interface réseau, eth1, avec une adresse IP de 192.168.200.2. Le point de terminaison B a une adresse IP de 192.168.200.22 dans le LAN du site B ; et il exécute un serveur Web sur le port TCP 80 auquel nous voulons nous connecter à partir du point de terminaison A.

Utilisation de Tcpdump

Sur le point de terminaison A, exécutez la commande suivante, en utilisant le propre port d’écoute WireGuard 51821 de l’hôte et l’adresse IP d’un hôte que vous souhaitez que le point de terminaison A puisse contacter via WireGuard — dans cet exemple, le point de terminaison B, avec une adresse IP de 192.168.200.22 :

$ sudo tcpdump -niany udp port 51821 or host 192.168.200.22

Sur l’hôte β, exécutez la commande suivante, cette fois en utilisant le propre port d’écoute WireGuard 51822 de l’hôte β et la même adresse IP :

$ sudo tcpdump -niany udp port 51822 or host 192.168.200.22

Pendant que les deux commandes tcpdump sont en cours d’exécution, ouvrez un autre terminal sur le point de terminaison A et essayez de vous connecter du point de terminaison A au point de terminaison B, en utilisant l’adresse IP du point de terminaison B :

$ curl 192.168.200.22
Tip

Lors du dépannage de WireGuard comme celui-ci, assurez-vous de toujours utiliser des adresses IP au lieu des noms DNS pour tous les hôtes exécutant WireGuard (par exemple, Endpoint A et Host β), et tous les hôtes auxquels vous essayez d’accéder via WireGuard (par exemple, Endpoint B). L’utilisation de noms DNS ne fera qu’ajouter un facteur de confusion à vos efforts de dépannage.

Testez d’abord tout sans les noms DN ; si tout fonctionne comme prévu, mais cesse de fonctionner lorsque vous essayez d’accéder à un hôte par son nom DNS au lieu de son adresse IP, vous avez éliminé tous les autres types de problèmes, alors maintenant vous savez que vous avez “juste” un problème DNS.

Si vous avez déterminé que vous avez un problème DNS et que vous essayez d’utiliser un serveur DNS via WireGuard, vous pouvez utiliser la même technique tcpdump que celle présentée dans cet article pour le résoudre. Par exemple, si l’adresse IP du serveur DNS est 192.168.200.253, vous utiliserez l’hôte 192.168.200.253 au lieu de l’hôte 192.168.200.22 dans vos commandes tcpdump ; et vous utiliseriez un outil comme dig à la place de curl pour tenter de vous connecter au serveur DNS (par exemple avec une commande comme dig @192.168.200.253 example.com).

Si vous n’essayez pas d’utiliser un serveur DNS via WireGuard, mais que vous avez déterminé que vous avez un problème DNS, le problème réside probablement dans la route du point de terminaison A vers le serveur DNS — vous devrez peut-être mettre à jour les routes ou le routage de la politique sur le point de terminaison A pour s’assurer que ses requêtes DNS ne sont pas acheminées via son interface WireGuard.
Tip

Lors du dépannage de WireGuard comme celui-ci, n’utilisez pas ping (sauf s’il s’agit en fait du service réseau que vous essayez de dépanner) — au lieu de cela, testez en utilisant le service réseau auquel vous souhaitez réellement accéder directement. Par exemple, si vous souhaitez accéder à un serveur Web, utilisez curl (ou un navigateur Web) ; si vous souhaitez accéder à un serveur de messagerie, utilisez sendmail (ou votre client de messagerie habituel) ; etc.

Comme DNS, le ping ne fera qu’ajouter un autre facteur de confusion à vos efforts de dépannage : les pare-feu entre le point de terminaison A, l’hôte β et le point de terminaison B (ou les pare-feu sur ces hôtes eux-mêmes) peuvent bloquer les paquets de ping, mais autoriser les connexions au service réseau réel que vous ’essayez d’accéder — ou vice versa : ils peuvent autoriser le ping, mais bloquer le service réseau auquel vous souhaitez réellement accéder.

Lorsque tout fonctionne correctement avec la connexion WireGuard entre le point de terminaison A et l’hôte β, vous vous attendez à voir la sortie suivante de tcpdump sur le point de terminaison A (à l’exception des étiquettes en gras, que nous avons ajoutées pour marquer chaque point clé) :

$ sudo tcpdump -niany udp port 51821 or host 192.168.200.22
    tcpdump: data link type LINUX_SLL2
    tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
    listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
A1. 19:47:20.751416 wg0   Out IP 10.0.0.1.45734 > 192.168.200.22.80: Flags [S], seq 1045811890, win 62167, options [mss 1380,sackOK,TS val 133588375 ecr 0,nop,wscale 6], length 0
A2. 19:47:20.751785 wlan0 Out IP 192.168.1.11.51821 > 203.0.113.2.51822: UDP, length 148
A3. 19:47:20.753212 wlan0 In  IP 203.0.113.2.51822 > 192.168.1.11.51821: UDP, length 92
A4. 19:47:20.753591 wlan0 Out IP 192.168.1.11.51821 > 203.0.113.2.51822: UDP, length 96
A5. 19:47:20.754497 wlan0 In  IP 203.0.113.2.51822 > 192.168.1.11.51821: UDP, length 96
A6. 19:47:20.754516 wg0   In  IP 192.168.200.22.80 > 10.0.0.1.45734: Flags [S.], seq 2143248836, ack 1045811891, win 62643, options [mss 1460,sackOK,TS val 659394353 ecr 133588375,nop,wscale 6], length 0
    19:47:20.754534 wg0   Out IP 10.0.0.1.45734 > 192.168.200.22.80: Flags [.], ack 1, win 972, options [nop,nop,TS val 133588379 ecr 659394353], length 0
    19:47:20.754549 wlan0 Out IP 192.168.1.11.51821 > 203.0.113.2.51822: UDP, length 96
    19:47:20.754587 wg0   Out IP 10.0.0.1.45734 > 192.168.200.22.80: Flags [P.], seq 1:79, ack 1, win 972, options [nop,nop,TS val 133588379 ecr 659394353], length 78: HTTP: GET / HTTP/1.1
    19:47:20.754630 wlan0 Out IP 192.168.1.11.51821 > 203.0.113.2.51822: UDP, length 176
    19:47:20.755411 wlan0 In  IP 203.0.113.2.51822 > 192.168.1.11.51821: UDP, length 96
    19:47:20.755420 wg0   In  IP 192.168.200.22.80 > 10.0.0.1.45734: Flags [.], ack 79, win 978, options [nop,nop,TS val 659394354 ecr 133588379], length 0
    19:47:20.756127 wlan0 In  IP 203.0.113.2.51822 > 192.168.1.11.51821: UDP, length 240
    19:47:20.756144 wg0   In  IP 192.168.200.22.80 > 10.0.0.1.45734: Flags [P.], seq 1:156, ack 79, win 978, options [nop,nop,TS val 659394355 ecr 133588379], length 155: HTTP: HTTP/1.0 200 OK
    19:47:20.756152 wg0   Out IP 10.0.0.1.45734 > 192.168.200.22.80: Flags [.], ack 156, win 970, options [nop,nop,TS val 133588380 ecr 659394355], length 0
    19:47:20.756160 wlan0 In  IP 203.0.113.2.51822 > 192.168.1.11.51821: UDP, length 384
    19:47:20.756170 wg0   In  IP 192.168.200.22.80 > 10.0.0.1.45734: Flags [FP.], seq 156:453, ack 79, win 978, options [nop,nop,TS val 659394355 ecr 133588379], length 297: HTTP
    19:47:20.756179 wlan0 Out IP 192.168.1.11.51821 > 203.0.113.2.51822: UDP, length 96
    19:47:20.756252 wg0   Out IP 10.0.0.1.45734 > 192.168.200.22.80: Flags [F.], seq 79, ack 454, win 966, options [nop,nop,TS val 133588380 ecr 659394355], length 0
    19:47:20.756278 wlan0 Out IP 192.168.1.11.51821 > 203.0.113.2.51822: UDP, length 96
    19:47:20.757068 wlan0 In  IP 203.0.113.2.51822 > 192.168.1.11.51821: UDP, length 96
    19:47:20.757099 wg0   In  IP 192.168.200.22.80 > 10.0.0.1.45734: Flags [.], ack 80, win 978, options [nop,nop,TS val 659394356 ecr 133588380], length 0
    19:47:30.984489 wlan0 Out IP 192.168.1.11.51821 > 203.0.113.2.51822: UDP, length 32

Et vous verriez la sortie suivante de tcpdump sur l’hôte β :

$ sudo tcpdump -niany udp port 51822 or host 192.168.200.22
    tcpdump: data link type LINUX_SLL2
    tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
    listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
B1. 19:47:20.752059 eth0  In  IP 198.51.100.1.51821 > 203.0.113.2.51822: UDP, length 148
B2. 19:47:20.752802 eth0  Out IP 203.0.113.2.51822 > 198.51.100.1.51821: UDP, length 92
B3. 19:47:20.753831 eth0  In  IP 198.51.100.1.51821 > 203.0.113.2.51822: UDP, length 96
B4. 19:47:20.753857 wg0   In  IP 10.0.0.1.45734 > 192.168.200.22.80: Flags [S], seq 1045811890, win 62167, options [mss 1380,sackOK,TS val 133588375 ecr 0,nop,wscale 6], length 0
B5. 19:47:20.753880 eth1  Out IP 192.168.200.2.45734 > 192.168.200.22.80: Flags [S], seq 1045811890, win 62167, options [mss 1380,sackOK,TS val 133588375 ecr 0,nop,wscale 6], length 0
B6. 19:47:20.754071 eth1  In  IP 192.168.200.22.80 > 192.168.200.2.45734: Flags [S.], seq 2143248836, ack 1045811891, win 62643, options [mss 1460,sackOK,TS val 659394353 ecr 133588375,nop,wscale 6], length 0
B7. 19:47:20.754079 wg0   Out IP 192.168.200.22.80 > 10.0.0.1.45734: Flags [S.], seq 2143248836, ack 1045811891, win 62643, options [mss 1460,sackOK,TS val 659394353 ecr 133588375,nop,wscale 6], length 0
B8. 19:47:20.754110 eth0  Out IP 203.0.113.2.51822 > 198.51.100.1.51821: UDP, length 96
    19:47:20.754786 eth0  In  IP 198.51.100.1.51821 > 203.0.113.2.51822: UDP, length 96
    19:47:20.754797 wg0   In  IP 10.0.0.1.45734 > 192.168.200.22.80: Flags [.], ack 1, win 972, options [nop,nop,TS val 133588379 ecr 659394353], length 0
    19:47:20.754806 eth1  Out IP 192.168.200.2.45734 > 192.168.200.22.80: Flags [.], ack 1, win 972, options [nop,nop,TS val 133588379 ecr 659394353], length 0
    19:47:20.754863 eth0  In  IP 198.51.100.1.51821 > 203.0.113.2.51822: UDP, length 176
    19:47:20.754881 wg0   In  IP 10.0.0.1.45734 > 192.168.200.22.80: Flags [P.], seq 1:79, ack 1, win 972, options [nop,nop,TS val 133588379 ecr 659394353], length 78: HTTP: GET / HTTP/1.1
    19:47:20.754886 eth1  Out IP 192.168.200.2.45734 > 192.168.200.22.80: Flags [P.], seq 1:79, ack 1, win 972, options [nop,nop,TS val 133588379 ecr 659394353], length 78: HTTP: GET / HTTP/1.1
    19:47:20.754996 eth1  In  IP 192.168.200.22.80 > 192.168.200.2.45734: Flags [.], ack 79, win 978, options [nop,nop,TS val 659394354 ecr 133588379], length 0
    19:47:20.754999 wg0   Out IP 192.168.200.22.80 > 10.0.0.1.45734: Flags [.], ack 79, win 978, options [nop,nop,TS val 659394354 ecr 133588379], length 0
    19:47:20.755020 eth0  Out IP 203.0.113.2.51822 > 198.51.100.1.51821: UDP, length 96
    19:47:20.755719 eth0  In  IP 192.168.200.22.80 > 192.168.200.2: Flags [P.], seq 1:156, ack 79, win 978, options [nop,nop,TS val 659394355 ecr 133588379], length 155: HTTP: HTTP/1.0 200 OK
    19:47:20.755722 wg0   Out IP 192.168.200.22.80 > 10.0.0.1.45734: Flags [P.], seq 1:156, ack 79, win 978, options [nop,nop,TS val 659394355 ecr 133588379], length 155: HTTP: HTTP/1.0 200 OK
    19:47:20.755743 eth0  Out IP 203.0.113.2.51822 > 198.51.100.1.51821: UDP, length 240
    19:47:20.755750 eth1  In  IP 192.168.200.22.80 > 192.168.200.2.45734: Flags [FP.], seq 156:453, ack 79, win 978, options [nop,nop,TS val 659394355 ecr 133588379], length 297: HTTP
    19:47:20.755756 wg0   Out IP 192.168.200.22.80 > 10.0.0.1.45734: Flags [FP.], seq 156:453, ack 79, win 978, options [nop,nop,TS val 659394355 ecr 133588379], length 297: HTTP
    19:47:20.755773 eth0  Out IP 203.0.113.2.51822 > 198.51.100.1.51821: UDP, length 384
    19:47:20.756453 eth0  In  IP 198.51.100.1.51821 > 203.0.113.2.51822: UDP, length 96
    19:47:20.756461 wg0   In  IP 10.0.0.1.45734 > 192.168.200.22.80: Flags [.], ack 156, win 970, options [nop,nop,TS val 133588380 ecr 659394355], length 0
    19:47:20.756465 eth1  Out IP 192.168.200.2.45734 > 192.168.200.22.80: Flags [.], ack 156, win 970, options [nop,nop,TS val 133588380 ecr 659394355], length 0
    19:47:20.756519 eth0  In  IP 198.51.100.1.51821 > 203.0.113.2.51822: UDP, length 96
    19:47:20.756535 wg0   In  IP 10.0.0.1.45734 > 192.168.200.22.80: Flags [F.], seq 79, ack 454, win 966, options [nop,nop,TS val 133588380 ecr 659394355], length 0
    19:47:20.756539 eth1  Out IP 192.168.200.2.45734 > 192.168.200.22.80: Flags [F.], seq 79, ack 454, win 966, options [nop,nop,TS val 133588380 ecr 659394355], length 0
    19:47:20.756656 eth1  In  IP 192.168.200.22.80 > 192.168.200.2.45734: Flags [.], ack 80, win 978, options [nop,nop,TS val 659394356 ecr 133588380], length 0
    19:47:20.756659 wg0   Out IP 192.168.200.22.80 > 10.0.0.1.45734: Flags [.], ack 80, win 978, options [nop,nop,TS val 659394356 ecr 133588380], length 0
    19:47:20.756676 eth0  Out IP 203.0.113.2.51822 > 198.51.100.1.51821: UDP, length 96
    19:47:30.984753 eth0  In  IP 198.51.100.1.51821 > 203.0.113.2.51822: UDP, length 32

A1. Lors de l’initialisation de l’hôte, avant que le paquet ne soit chiffré

La première entrée que vous devriez voir de tcpdump sur Endpoint A est la suivante :

19:47:20.751416 wg0   Out IP 10.0.0.1.45734 > 192.168.200.22.80: Flags [S], seq 1045811890, win 62167, options [mss 1380,sackOK,TS val 133588375 ecr 0,nop,wscale 6], length 0

Cette entrée indique que le point de terminaison A tente d’établir une connexion TCP à partir de son adresse WireGuard 10.0.0.1 vers le port 80 de l’adresse IP du point de terminaison B, 192.168.200.22, qui sortira de l’interface wg0 du point de terminaison A.

Signes de problème :

Aucune entrée tcpdump Si vous ne voyez rien de tcpdump sur le point de terminaison A, vous avez un problème de routage : le point de terminaison A n’a pas de route utilisable pour l’adresse IP du point de terminaison B de 192.168.200.22. Exécutez d’abord la commande wg sur le point de terminaison A pour vérifier que son interface WireGuard est active et que 192.168.200.22 est inclus dans ses plages d’adresses AllowedIPs ; essayez ensuite d’exécuter les commandes ip route et ip rule sur le point de terminaison A pour déboguer ses routes et ses règles de routage de stratégie.

Mauvais nom d’interface Si vous voyez un nom d’interface autre que wg0 dans cette entrée, vous avez un problème de routage : le point de terminaison A n’achemine pas l’adresse IP du point de terminaison B de 192.168.200.22 vers WireGuard. Exécutez d’abord la commande wg sur le point de terminaison A pour vérifier que son interface WireGuard est active et que 192.168.200.22 est inclus dans ses plages d’adresses AllowedIPs ; essayez ensuite d’exécuter les commandes ip route et ip rule sur le point de terminaison A pour déboguer ses routes et ses règles de routage de stratégie.

A2. Lors de l’initialisation de l’hôte, envoi de la poignée de main WireGuard

La deuxième entrée que vous devriez voir de tcpdump sur Endpoint A est la suivante :

19:47:20.751785 wlan0 Out IP 192.168.1.11.51821 > 203.0.113.2.51822: UDP, length 148

Cette entrée indique que le point final A tente d’envoyer un paquet UDP depuis son adresse LAN 192.168.1.11 vers l’adresse publique 203.0.113.2 de l’hôte β sur le port d’écoute WireGuard 51822 de l’hôte β. Le paquet sortira par le propre port WireGuard du point final A. 51821, en utilisant son interface réseau sans fil wlan0.

Il s’agit du paquet d’initiation de prise de contact WireGuard. Cependant, si le point de terminaison A et l’hôte β ont déjà réussi une prise de contact au cours des 2 dernières minutes, vous ne verrez pas cette entrée (ou B1 ou B2 ou A3) — vous verrez à la place A4.

Signes de problème :

Aucune entrée tcpdump Vérifiez d’abord l’entrée A1 pour les problèmes; si cela semble bon, mais que le point de terminaison A et l’hôte β n’ont pas encore réussi à établir une liaison, et que vous ne voyez pas cette entrée, vous pouvez avoir un problème de configuration WireGuard : exécutez la commande wg sur le point de terminaison A pour vérifier que vous avez un Point de terminaison défini pour l’hôte β (et qu’il s’agit de l’adresse IP publique correcte de l’hôte β et du port d’écoute WireGuard : 203.0.113.2:51822 dans cet exemple).

Sinon, si vous ne voyez pas cette entrée tcpdump, vous pouvez avoir un problème de routage : le point de terminaison A peut ne pas avoir de route utilisable pour l’adresse IP de l’hôte β de 203.0.113.2. Essayez d’exécuter les commandes ip route et ip rule sur le point de terminaison A pour déboguer ses routes et ses règles de routage de stratégie.

Mauvaise adresse ou port de destination Si vous voyez une adresse IP de destination autre que l’adresse publique de l’hôte β de 203.0.113.2, ou un port de destination autre que le port d’écoute WireGuard de l’hôte β de 51822, vous avez un problème de configuration WireGuard : Corrigez le paramètre de point de terminaison pour l’hôte β dans WireGuard du point de terminaison A fichier de configuration et redémarrez l’interface WireGuard.

Tip

Un côté de chaque connexion WireGuard doit avoir une adresse IP accessible au public et un port d’écoute WireGuard, et l’autre côté doit être préconfiguré avec cette adresse et ce port comme paramètre de point de terminaison. Dans cet exemple, l’hôte β a une adresse IP accessible au public et un port d’écoute WireGuard, contrairement au point de terminaison A. Le point de terminaison A doit donc être préconfiguré avec l’adresse et le port de l’hôte β.

Si le point de terminaison A avait une adresse IP accessible au public et un port d’écoute WireGuard, et que l’hôte β n’en avait pas, l’hôte β devrait être préconfiguré avec l’adresse et le port du point de terminaison A — et l’hôte β devrait également être configuré avec le paramètre PersistentKeepalive, pour initier de manière proactive une connexion WireGuard avec le point de terminaison A et la maintenir active (en veillant à ce que le point de terminaison A soit défini dynamiquement avec un point de terminaison utilisable pour l’hôte β).

Mauvaise longueur Si la longueur des données de ce paquet n’est pas exactement de 148 octets, il ne s’agit pas d’un paquet d’initiation de prise de contact WireGuard. Très probablement, une poignée de main WireGuard entre le point de terminaison A et l’hôte β s’est déjà produite au cours des 2 dernières minutes, et il s’agit en fait d’un paquet de données WireGuard chiffré — l’entrée A4 tcpdump.

Entrées répétées Si vous voyez exactement la même entrée A2 répétée environ 20 fois de suite, espacées de 5 secondes, vérifiez d’abord les entrées tcpdump B1 et B2 sur l’hôte β. S’ils sont tous les deux présents et semblent bons, suivez les conseils sous l’en-tête “Pas d’entrée tcpdump” pour l’entrée A3.

B1. Lors de la réception de l’hôte, réception de la poignée de main WireGuard

La première entrée que vous devriez voir de tcpdump sur l’hôte β est la suivante :

19:47:20.752059 eth0  In  IP 198.51.100.1.51821 > 203.0.113.2.51822: UDP, length 148

Cette entrée indique que l’hôte β a reçu un paquet UDP envoyé depuis l’adresse publique 198.51.100.1 du point de terminaison A (techniquement l’adresse WAN du routeur NAT devant le point de terminaison A) à l’adresse WAN de l’hôte β 203.0.113.2 et le port d’écoute WireGuard de 51822 sur l’interface eth0 de l’hôte β.

Il s’agit du paquet d’initiation de prise de contact WireGuard. Si le point de terminaison A et l’hôte β ont déjà réussi une prise de contact au cours des 2 dernières minutes, vous ne verrez pas cette entrée (ou A2 ou B2 ou A3) — à la place, vous verrez B3.

Signes de problème :

Aucune entrée tcpdump Vérifiez d’abord l’entrée A2 sur le point de terminaison A pour les problèmes ; si cela semble bon, mais que le point de terminaison A et l’hôte β n’ont pas encore réussi à établir une liaison et que vous ne voyez pas cette entrée, vous avez soit un problème de pare-feu, soit un problème de routage dans les réseaux entre le point de terminaison A et l’hôte β : Essayez vérifier tous les pare-feu ou routeurs devant l’hôte β auquel vous avez accès. Assurez-vous que ces pare-feu permettent de transférer de nouvelles connexions au moins vers le port UDP 51822 de l’hôte β et l’adresse IP publique de 203.0.113.2 à partir de l’adresse IP publique du point de terminaison A de 198.51.100.1.

S’il ne s’agit pas d’un pare-feu ou d’un problème de routage entre les réseaux, il peut s’agir d’un problème de routage sur l’hôte β : essayez d’exécuter la commande ip route get 198.51.100.1 sur l’hôte β pour vous assurer que a) il a une route vers le point de terminaison A, et b ) cette route sort de l’interface réseau WAN de l’hôte β, eth0.

Mauvaise longueur Si la longueur des données de ce paquet n’est pas exactement de 148 octets, il ne s’agit pas d’un paquet d’initiation de prise de contact WireGuard. Très probablement, une poignée de main WireGuard entre le point de terminaison A et l’hôte β s’est déjà produite au cours des 2 dernières minutes, et il s’agit en fait d’un paquet de données WireGuard chiffré — l’entrée B3 tcpdump.

B2. Lors de la réception de l’hôte, envoi d’une réponse de prise de contact WireGuard

La deuxième entrée que vous devriez voir de tcpdump sur l’hôte β est la suivante :

19:47:20.752802 eth0  Out IP 203.0.113.2.51822 > 198.51.100.1.51821: UDP, length 92

Cette entrée indique que l’hôte β tente d’envoyer un paquet UDP à partir de son adresse WAN de 203.0.113.2 et du port d’écoute WireGuard de 51822. Ce paquet sera envoyé à la même adresse source et au même port à partir desquels B1 a été reçu, indépendamment de tout Paramètre de point de terminaison pour le point de terminaison A dans la configuration WireGuard de l’hôte β.

Il s’agit du paquet de réponse de prise de contact WireGuard. Si le point de terminaison A et l’hôte β ont déjà réussi une prise de contact au cours des 2 dernières minutes, vous ne verrez pas cette entrée (ou A2 ou B1 ou A3).

Signes de problème : Aucune entrée tcpdump Si le point de terminaison A et l’hôte β n’ont pas encore réussi à établir une liaison et que vous ne voyez pas cette entrée, vous avez soit un problème de configuration WireGuard, soit un problème de pare-feu sur l’hôte β : Tout d’abord, exécutez la commande wg sur l’hôte β pour vérifiez que vous avez un pair configuré pour le point de terminaison A.

Si vous avez un pair configuré sur l’hôte β pour le point de terminaison A, exécutez également la commande wg sur le point de terminaison A pour comparer les clés affichées sur sa sortie à celle de l’hôte β. La clé publique répertoriée pour l’interface dans la sortie sur le point de terminaison A doit correspondre à l’homologue du point de terminaison A répertorié dans la sortie sur l’hôte β ; et vice versa. S’il est correctement configuré, vous devriez voir une correspondance comme celle-ci :

justin@endpoint-a:~$ sudo wg
interface: wg0
  public key: /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
  private key: (hidden)
  listening port: 51821

peer: fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
  endpoint: 203.0.113.2:51822
  allowed ips: 192.168.200.0/24
  transfer: 0 B received, 148 B sent

justin@host-b:~$ sudo wg
interface: wg0
  public key: fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
  private key: (hidden)
  listening port: 51822

peer: /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
  allowed ips: 10.0.0.1/32

De plus, si vous utilisez une clé pré-partagée pour cette connexion WireGuard, vérifiez le fichier de configuration WireGuard sur le point de terminaison A et l’hôte β pour vérifier que le paramètre PresharedKey pour le pair correspondant est identique dans les deux fichiers de configuration.

Si les clés WireGuard correspondent, essayez d’exécuter les commandes iptables-save et nft list ruleset sur l’hôte β pour déboguer les problèmes avec son propre pare-feu basé sur l’hôte. Assurez-vous que le propre pare-feu de l’hôte β autorise l’accès entrant pour les nouvelles connexions à son interface eth0, au moins pour son port UDP 51822, à partir de l’adresse IP publique du point de terminaison A de 198.51.100.1.

Mauvais nom d’interface Si vous voyez un nom d’interface autre que eth0 dans cette entrée tcpdump (c’est-à-dire une interface différente de l’entrée B1), vous pouvez avoir un problème de routage : l’hôte β n’achemine pas l’adresse IP publique 198.51.100.1 du point de terminaison A vers la même interface à partir duquel les paquets du point de terminaison A arrivent. Sauf s’il s’agit d’un choix de routage délibéré que vous avez fait, essayez d’exécuter les commandes ip route et ip rule sur l’hôte β pour déboguer ses routes et ses règles de routage.

Mauvaise longueur Si la longueur des données de ce paquet n’est pas exactement de 92 octets, il ne s’agit pas d’un paquet de réponse de prise de contact WireGuard. Très probablement, une poignée de main WireGuard entre le point de terminaison A et l’hôte β s’est déjà produite au cours des 2 dernières minutes, et il s’agit d’un autre paquet. Si cette entrée correspond parfaitement à l’exemple ci-dessus, à l’exception de la longueur des données, il s’agit en fait d’un paquet de données WireGuard chiffré envoyé de l’hôte β au point de terminaison A — l’entrée B8 tcpdump.

A3. Lors de l’initialisation de l’hôte, réception de la réponse de prise de contact WireGuard

La troisième entrée que vous devriez voir de tcpdump sur Endpoint A est la suivante :

19:47:20.753212 wlan0 In  IP 203.0.113.2.51822 > 192.168.1.11.51821: UDP, length 92

Cette entrée indique que le point de terminaison A a reçu un paquet UDP envoyé depuis l’adresse 203.0.113.2 de l’hôte β vers son port d’écoute WireGuard 51821 sur son interface wlan0.

Il s’agit du paquet de réponse de prise de contact WireGuard. Si le point de terminaison A* et l’hôte β ont déjà réussi une prise de contact au cours des 2 dernières minutes, vous ne verrez pas cette entrée (ou A2 ou B1 ou B2).

Signes de problème :

Aucune entrée tcpdump Vérifiez d’abord l’entrée B2 sur l’hôte β pour les problèmes ; si cela semble bon, mais que le point de terminaison A et l’hôte β n’ont pas encore réussi à établir une liaison et que vous ne voyez pas cette entrée, vous avez soit un problème de pare-feu, soit un problème de routage dans les réseaux entre l’hôte β et le point de terminaison A : essayez vérifier tous les pare-feu ou routeurs devant le Endpoint A auquel vous avez accès. Assurez-vous que ces pare-feu permettent de transférer les connexions établies au moins vers le port UDP 51821 du point de terminaison A et l’adresse IP publique de 198.51.100.1 (ou l’adresse LAN de 192.168.1.11 pour le chemin entre le point de terminaison A et son routeur NAT) à partir de l’adresse IP publique de l’hôte β de 203.0.113.2.

Mauvaise longueur Si la longueur des données de ce paquet n’est pas exactement de 92 octets, il ne s’agit pas d’un paquet de réponse de prise de contact WireGuard. Très probablement, une poignée de main WireGuard entre le point de terminaison A et l’hôte β s’est déjà produite au cours des 2 dernières minutes, et il s’agit en fait d’un paquet de données WireGuard chiffré — l’entrée A5 tcpdump.

Entrées répétées Si vous voyez exactement les mêmes entrées A2 et A3 répétées l’une après l’autre environ 20 fois, vous avez un problème de pare-feu sur le point de terminaison A : essayez d’exécuter les commandes iptables-save et nft list ruleset sur le point de terminaison A pour déboguer les problèmes avec son propre hôte. pare-feu basé. Assurez-vous que le propre pare-feu du point de terminaison A autorise l’accès entrant pour les connexions établies à son interface wlan0, au moins pour son port UDP 51821, à partir de l’adresse IP publique de l’hôte β de 203.0.113.2.

A4. Lors de l’initialisation de l’hôte, envoi d’un paquet crypté

La quatrième entrée que vous devriez voir de tcpdump sur Endpoint A est la suivante :

19:47:20.753591 wlan0 Out IP 192.168.1.11.51821 > 203.0.113.2.51822: UDP, length 96

Cette entrée indique que l’Endpoint A tente d’envoyer son premier paquet de données WireGuard crypté depuis son adresse LAN 192.168.1.11 vers l’adresse publique de l’Hôte β 203.0.113.2 sur le port d’écoute WireGuard de l’Hôte β 51822. Le paquet sortira du propre Endpoint A Port WireGuard du 51821, utilisant son interface réseau sans fil wlan0.

La charge utile de données de ce paquet est le paquet TCP d’origine de l’entrée A1, chiffré et enveloppé comme un paquet UDP. Si vous voyez une entrée pour ce paquet (et que la longueur du paquet n’est pas de 148), la poignée de main WireGuard entre le point de terminaison A et l’hôte β s’est terminée avec succès.

Signes de problème :

Aucune entrée tcpdump Vérifiez d’abord l’entrée B2 sur l’hôte β pour les problèmes ; si cela semble bon, mais que le point de terminaison A et l’hôte β n’ont pas encore réussi à établir une liaison et que vous ne voyez pas cette entrée, vous avez un problème de pare-feu sur le point de terminaison A : essayez d’exécuter les commandes iptables-save et nft list ruleset sur Endpoint A pour déboguer les problèmes avec son propre pare-feu basé sur l’hôte. Assurez-vous que le propre pare-feu du point de terminaison A autorise l’accès entrant pour les connexions établies à son interface wlan0, au moins pour son port UDP 51821, à partir de l’adresse IP publique de l’hôte β de 203.0.113.2.

Mauvaise longueur La longueur des données de ce paquet variera en fonction des données sous-jacentes qu’il chiffre, mais si sa longueur est exactement de 148 octets, il s’agit probablement en fait d’une tentative de prise de contact WireGuard, et il s’agit en fait d’une autre entrée A2. Si WireGuard sur le point de terminaison A ne reçoit pas de réponse de poignée de main réussie, vous verrez environ 20 entrées A2, espacées de 5 secondes, car WireGuard essaie encore et encore d’initier une poignée de main avec l’hôte β. Si vous voyez ces entrées entrecoupées d’entrées A3 correspondantes, vous avez un problème de pare-feu sur le point de terminaison A (voir ci-dessus). Si vous ne voyez aucune entrée A3, vous avez un problème de pare-feu ou de routage entre l’hôte β et le point de terminaison A (voir A3).

B3. Lors de la réception de l’hôte, réception du paquet crypté

La troisième entrée que vous devriez voir de tcpdump sur l’hôte β est la suivante :

19:47:20.753831 eth0  In  IP 198.51.100.1.51821 > 203.0.113.2.51822: UDP, length 96

Cette entrée indique que l’hôte β a reçu son premier paquet de données WireGuard chiffré envoyé depuis l’adresse publique 198.51.100.1 du point de terminaison A vers l’adresse WAN 203.0.113.2 de l’hôte β et le port d’écoute WireGuard 51822 sur l’interface eth0 de l’hôte β.

La charge utile de données de ce paquet est le paquet TCP d’origine de l’entrée A1, chiffré et enveloppé comme un paquet UDP. Si vous voyez l’entrée A4 envoyée sur le point de terminaison A (et que sa longueur de paquet n’est pas de 148), vous devriez toujours voir cette entrée correspondante reçue.

Signes de problème :

*Mauvaise longueur La longueur des données de ce paquet variera en fonction des données sous-jacentes qu’il chiffre, mais si sa longueur est exactement de 148 octets, il s’agit probablement en fait d’une tentative de prise de contact WireGuard, et il s’agit en fait d’une autre entrée B1. Si WireGuard sur le point de terminaison A ne reçoit pas de réponse de poignée de main réussie, vous pouvez voir environ 20 entrées B1, espacées de 5 secondes, car WireGuard essaie encore et encore d’initier une poignée de main avec l’hôte β. Si vous voyez ces entrées entrecoupées d’entrées B2 correspondantes, vous avez probablement un problème de pare-feu ou de routage entre l’hôte β et le point de terminaison A (voir A3). Si vous ne voyez aucune entrée B2, vous avez probablement un problème de configuration de pare-feu ou WireGuard sur l’hôte β (voir B1).

B4. À la réception de l’hôte, après le décryptage du paquet

La quatrième entrée que vous devriez voir de tcpdump sur l’hôte β est la suivante :

19:47:20.753857 wg0   In  IP 10.0.0.1.45734 > 192.168.200.22.80: Flags [S], seq 1045811890, win 62167, options [mss 1380,sackOK,TS val 133588375 ecr 0,nop,wscale 6], length 0

Cette entrée doit refléter l’entrée A1 d’origine du point de terminaison A, indiquant que l’hôte β a reçu son premier paquet de données via son tunnel WireGuard et l’a déchiffré avec succès. Il doit afficher un paquet TCP entrant via l’interface wg0 de l’hôte β, à partir de l’adresse WireGuard du point final A de 10.0.0.1, avec une destination de l’adresse LAN du point final B de 192.168.200.22, sur le port 80.

Signes de problème :

Aucune entrée tcpdump Si vous voyez l’entrée B3, mais pas cette entrée, vous avez un problème de configuration WireGuard : exécutez la commande wg sur l’hôte β pour vérifier que son paramètre AllowedIPs pour le point de terminaison A inclut l’adresse WireGuard du point de terminaison A de 10.0.0.1.

B5. Lors de la réception de l’hôte, transfert du paquet

La cinquième entrée que vous devriez voir de tcpdump sur l’hôte β est la suivante :

19:47:20.753880 eth1  Out IP 192.168.200.2.45734 > 192.168.200.22.80: Flags [S], seq 1045811890, win 62167, options [mss 1380,sackOK,TS val 133588375 ecr 0,nop,wscale 6], length 0

Il doit afficher essentiellement les mêmes détails de paquet que l’entrée B4, mais cette entrée doit afficher le paquet sortant de l’interface réseau LAN eth1 de l’hôte β ; et si vous utilisez NAT sur l’hôte β pour masquer les connexions du point de terminaison A avec la propre adresse LAN de l’hôte β, comme nous le sommes dans cet exemple, l’adresse IP source du paquet doit être l’adresse LAN de l’hôte β de 192.168.200.2 (au lieu de l’adresse du point de terminaison A Adresse WireGuard de 10.0.0.1).

Note
 Dans une configuration WireGuard Hub-and-Spoke, où le point de terminaison A utilise l’hôte β comme hub central pour transférer les connexions vers d’autres points de terminaison utilisant également WireGuard, cette entrée doit afficher le paquet en omettant son interface WireGuard wg0, au lieu de eth1. De plus, vous n’utiliseriez généralement pas NAT dans ce scénario, donc l’adresse IP source du paquet doit rester 10.0.0.1.
Note
 Dans une configuration point à point WireGuard, où le point de terminaison A essaie simplement de se connecter à un service réseau sur l’hôte β lui-même, au lieu d’utiliser l’hôte β pour transférer ses connexions vers d’autres hôtes, vous ne verrez pas cette entrée, ou B6 — la prochaine entrée que vous voyez sur l’hôte β devrait être B7.

Signes de problème :

Aucune entrée tcpdump Si vous voyez l’entrée B4, mais pas cette entrée, vous avez soit un problème de pare-feu, soit un problème de routage sur l’hôte β. Exécutez d’abord la commande sysctl net.ipv4.conf.all.forwarding sur l’hôte β pour vérifier que vous autorisez tout transfert de paquets IPv4 (la sortie doit avoir la valeur 1, indiquant que le transfert est autorisé).

Si le transfert de paquets est autorisé, essayez d’exécuter les commandes iptables-save et nft list ruleset sur l’hôte β pour déboguer les problèmes avec son pare-feu (la sortie doit montrer qu’il autorise au minimum le transfert de nouvelles connexions vers le port TCP 80 de l’adresse LAN du point de terminaison B de 192.168.200.22, à l’aide de l’interface LAN eth1 de l’hôte β, à partir de l’adresse WireGuard du point de terminaison A 10.0.0.1, à l’aide de l’interface WireGuard de l’hôte β wg0).

Tip
 Consultez la section Configurer le pare-feu sur l’hôte β du guide de configuration WireGuard point à site, ou la section “Point à site” du guide Comment utiliser WireGuard avec Nftables, pour une explication détaillée des règles de pare-feu que vous devriez être utiliser avec cet exemple.

S’il ne s’agit pas d’un problème de pare-feu, essayez d’exécuter la commande ip route get 192.168.200.22 sur l’hôte β pour vous assurer que a) il a une route vers le point de terminaison B, et b) cette route sort de l’interface réseau LAN de l’hôte β, eth1.

Mauvaise adresse source Si vous envisagez d’utiliser SNAT (Source Network Address Translation, ou masquage de paquets) avec cette connexion, vous devriez voir l’adresse source changer entre l’entrée B4 et celle-ci (dans cet exemple, nous utilisons SNAT pour traduire les l’adresse WireGuard de 10.0.0.1 à la propre adresse LAN de l’hôte β de 192.168.200.2). S’il n’est pas traduit à l’adresse correcte, vous avez un problème de pare-feu : essayez d’exécuter les commandes iptables-save et nft list ruleset sur l’hôte β pour déboguer les problèmes avec ses règles de pare-feu.

Mauvaise adresse de destination Si vous envisagez d’utiliser DNAT (Destination Network Address Translation, ou redirection de port) avec cette connexion, vous devriez voir l’adresse de destination changer entre l’entrée B4 et celle-ci (cependant, dans cet exemple, nous n’utilisons pas DNAT, donc nous ne devrions voir aucun changement). S’il n’est pas traduit à l’adresse correcte, vous avez un problème de pare-feu : essayez d’exécuter les commandes iptables-save et nft list ruleset sur l’hôte β pour déboguer les problèmes avec ses règles de pare-feu.

B6. Lors de la réception de l’hôte, transfert de la réponse du paquet

La sixième entrée que vous devriez voir depuis tcpdump sur l’hôte β est la suivante :

19:47:20.754071 eth1  In  IP 192.168.200.22.80 > 192.168.200.2.45734: Flags [S.], seq 2143248836, ack 1045811891, win 62643, options [mss 1460,sackOK,TS val 659394353 ecr 133588375,nop,wscale 6], length 0

Cette entrée doit afficher la réponse du point de terminaison B, avec un nouveau paquet entrant dans l’interface LAN eth1 de l’hôte β à partir de l’adresse IP LAN du point de terminaison B 192.168.200.22. Si vous utilisez NAT sur l’hôte β pour masquer les connexions du point de terminaison A avec la propre adresse LAN de l’hôte β, comme nous le sommes dans cet exemple, l’adresse IP de destination du paquet doit être l’adresse LAN de l’hôte β de 192.168.200.2 — la source et la destination du paquet doit être inversé exactement entre cette entrée et B5.

Note

Dans une configuration WireGuard Hub-and-Spoke, où le point d’extrémité A utilise l’hôte β comme hub WireGuard central pour transférer les connexions vers d’autres points d’extrémité WireGuard, vous devriez voir au moins deux autres entrées sur l’hôte β entre B5 et cette entrée, montrant WireGuard chiffré paquets envoyés entre l’hôte β et le point de terminaison B.

Par exemple, si le point de terminaison B n’était pas dans le réseau local du site B, mais était à la place un hôte distant accessible quelque part sur Internet à 192.0.2.3, avec un port d’écoute WireGuard de 51823, vous devriez voir au moins les entrées suivantes entre B5 et ce entrée:

19:47:20.753991 eth0  Out IP 203.0.113.2.51822 > 192.0.2.3.51823: UDP, length 176
19:47:20.754002 eth0  In  IP 192.0.2.3.51823 > 203.0.113.2.51822: UDP, length 96

Vous pouvez également voir des paquets supplémentaires envoyés entre l’hôte β et le point de terminaison B pour leur propre poignée de main WireGuard, si 2 minutes ou plus se sont écoulées depuis leur dernier échange de poignée de main. Cependant, si vous ne voyez aucune entrée supplémentaire, cela peut signifier que la connexion WireGuard entre l’hôte β et le point de terminaison B ne fonctionne pas elle-même — si c’est le cas, vous devez l’arrêter et la déboguer séparément avant de continuer.

De plus, avec une configuration en étoile, cette entrée doit afficher le paquet entrant dans wg0 au lieu de eth1 ; et vous n’utiliseriez généralement pas NAT dans un scénario hub-and-spoke, donc l’adresse IP de destination du paquet devrait être 10.0.0.1.
Note
 Dans une configuration WireGuard point à point, où le point de terminaison A essaie simplement de se connecter à un service réseau sur l’hôte β, au lieu d’utiliser l’hôte β pour transférer ses connexions vers d’autres hôtes, vous ne verrez pas cette entrée, ou B5 — la prochaine entrée que vous voyez sur l’Hôte β devrait être B7.

Signes de problème :

Aucune entrée tcpdump Vérifiez d’abord l’entrée B5 pour les problèmes; si cela semble bon, vous avez soit un problème de pare-feu, soit un problème de routage sur le LAN du site B (ou dans les réseaux entre l’hôte β et le point de terminaison B, s’ils ne sont pas simplement sur le même LAN), ou sur le point de terminaison B lui-même.

Si vous utilisez NAT sur l’hôte β pour masquer les connexions du point de terminaison A avec la propre adresse LAN de l’hôte β, comme nous le sommes dans cet exemple, les connexions du point de terminaison A doivent apparaître sur le LAN du site B comme si elles provenaient de la propre adresse LAN de l’hôte β de 192.168.200.2. Dans ce cas, vérifiez que tous les pare-feu entre l’Hôte β et l’Endpoint B autorisent le transfert de nouvelles connexions de 192.168.200.2 vers le port TCP 80 de l’adresse IP 192.168.200.22 de l’Endpoint B ; et sur le point de terminaison B, vérifiez que son propre pare-feu basé sur l’hôte autorise les nouvelles connexions entrantes sur son interface réseau LAN de 192.168.200.2 au port TCP 80.

Si, contrairement à cet exemple, vous n’utilisez pas NAT sur l’hôte β, les connexions du point de terminaison A apparaîtront sur le LAN du site B comme si elles provenaient de l’adresse WireGuard du point de terminaison A de 10.0.0.1. Dans ce cas, vérifiez que le LAN du site B est configuré pour rediriger 10.0.0.1 vers l’adresse LAN de l’hôte β de 192.168.200.2, et que tous les pare-feu entre l’hôte β et le point de terminaison B autorisent le transfert de nouvelles connexions de 10.0.0.1 vers TCP port 80 de l’adresse IP 192.168.200.22 du Endpoint B ; et sur le point de terminaison B, vérifiez que son propre pare-feu basé sur l’hôte autorise les nouvelles connexions entrantes sur son interface réseau LAN de 10.0.0.1 au port TCP 80.

B7. À la réception de l’hôte, avant que la réponse du paquet ne soit cryptée

La septième entrée que vous devriez voir depuis tcpdump sur l’hôte β est la suivante :

19:47:20.754079 wg0   Out IP 192.168.200.22.80 > 10.0.0.1.45734: Flags [S.], seq 2143248836, ack 1045811891, win 62643, options [mss 1460,sackOK,TS val 659394353 ecr 133588375,nop,wscale 6], length 0

Il doit afficher essentiellement les mêmes détails de paquet que l’entrée B6, mais cette entrée doit afficher le paquet sortant de l’interface réseau WireGuard wg0 de l’hôte β ; et si vous utilisez NAT sur l’hôte β pour masquer les connexions du point de terminaison A avec la propre adresse LAN de l’hôte β, comme nous le sommes dans cet exemple, l’adresse IP de destination du paquet sera remplacée par l’adresse WireGuard du point de terminaison A de 10.0.0.1 (si vous n’utilisez pas NAT, l’adresse de destination aurait également été 10.0.0.1 dans l’entrée B6).

*NOTE Dans une configuration point à point WireGuard, où le point de terminaison A essaie simplement de se connecter à un service réseau sur l’hôte β lui-même, au lieu d’utiliser l’hôte β pour transférer ses connexions vers d’autres hôtes, vous devriez voir cette entrée directement après B4. Si ce n’est pas le cas, vous avez un problème de pare-feu sur l’hôte β : essayez d’exécuter les commandes iptables-save et nft list ruleset sur l’hôte β pour déboguer les problèmes avec son pare-feu (la sortie doit indiquer qu’il autorise au minimum les connexions entrantes depuis le point de terminaison A Adresse WireGuard de 10.0.0.1, en utilisant l’interface WireGuard wg0 de l’hôte β, vers le port TCP 80 ou tout autre service réseau auquel le point de terminaison A tente de se connecter).

Signes de problème :

Aucune entrée tcpdump Si vous voyez l’entrée B6, mais pas cette entrée, vous avez un problème de pare-feu sur l’hôte β. Essayez d’exécuter les commandes iptables-save et nft list ruleset sur l’hôte β pour déboguer les problèmes avec son pare-feu (la sortie doit montrer qu’il autorise au minimum le transfert des connexions établies vers l’adresse WireGuard du point de terminaison A de 10.0.0.1, en utilisant l’interface WireGuard de l’hôte β wg0, à partir de l’adresse LAN du point final B de 192.168.200.22, en utilisant l’interface LAN eth1 de l’hôte β).

Mauvais nom d’interface Si vous voyez un nom d’interface autre que wg0 dans cette entrée, vous avez un problème de routage : l’hôte β n’achemine pas l’adresse WireGuard 10.0.0.1 du point de terminaison A vers WireGuard. Essayez d’exécuter les commandes ip route et ip rule sur l’hôte β pour déboguer ses routes et ses règles de routage.

B8. Lors de la réception de l’hôte, envoi d’une réponse de paquet cryptée

La huitième entrée que vous devriez voir de tcpdump sur l’hôte β est la suivante :

19:47:20.754110 eth0  Out IP 203.0.113.2.51822 > 198.51.100.1.51821: UDP, length 96

Cette entrée montre que l’hôte β envoie un paquet de données WireGuard chiffré sur son interface réseau WAN eth0 depuis son adresse IP publique 203.0.113.2 vers l’adresse IP publique 198.51.100.1 du point de terminaison A. La charge utile de données de ce paquet est le paquet TCP de l’entrée B7, chiffré et enveloppé comme un paquet UDP.

Si cette entrée ne correspond pas à ce que vous voyez, revenez en arrière et revérifiez les entrées précédentes — il devrait y avoir un signe révélateur du problème dans une entrée précédente.

A5. Lors de l’initialisation de l’hôte, réception d’une réponse de paquet cryptée

The fifth entry you should see from tcpdump on Endpoint A is the following:

19:47:20.754497 wlan0 In  IP 203.0.113.2.51822 > 192.168.1.11.51821: UDP, length 96

Cette entrée montre que le point de terminaison A a reçu un paquet de données WireGuard chiffré sur le port UDP 51821 de son interface wlan0`` de l'adresse IP publique 203.0.113.2` de l’hôte β. La charge utile de données de ce paquet est le paquet TCP de l’entrée B7, chiffré et enveloppé comme un paquet UDP.

Signes de problème :

Mauvaise longueur La longueur des données de ce paquet variera en fonction des données sous-jacentes qu’il chiffre, mais si sa longueur est exactement de 92 octets, il s’agit probablement en fait d’une réponse de prise de contact WireGuard, et il s’agit en fait d’une autre entrée A3. Si vous voyez plusieurs entrées A2 d’initiation de prise de contact entrecoupées de plusieurs entrées A3 de réponse de prise de contact, vous avez un problème de pare-feu sur le point de terminaison A : essayez d’exécuter les commandes iptables-save et nft list ruleset sur le point de terminaison A pour déboguer les problèmes avec son propre système basé sur l’hôte. pare-feu. Assurez-vous que le propre pare-feu du point de terminaison A autorise l’accès entrant pour les connexions établies à son interface wlan0, au moins pour son port UDP 51821, à partir de l’adresse IP publique de l’hôte β de 203.0.113.2.

A6. Lors de l’initialisation de l’hôte, après le décryptage du paquet

La sixième entrée que vous devriez voir de tcpdump sur Endpoint A est la suivante :

19:47:20.754516 wg0   In  IP 192.168.200.22.80 > 10.0.0.1.45734: Flags [S.], seq 2143248836, ack 1045811891, win 62643, options [mss 1460,sackOK,TS val 659394353 ecr 133588375,nop,wscale 6], length 0

Cette entrée doit refléter l’entrée B7 de l’hôte β, indiquant que le point de terminaison A a reçu sa première réponse de paquet de données via son tunnel WireGuard et l’a déchiffrée avec succès. L’entrée doit afficher un paquet TCP entrant via l’interface wg0 du point de terminaison A, à partir du port 80 de l’adresse LAN du point de terminaison B de 192.168.200.22, avec une destination de l’adresse WireGuard du point de terminaison A de 10.0.0.1.

Signes de problème :

Entrées répétées Si vous voyez exactement les mêmes entrées A5 et A6 répétées plusieurs fois (et aucune autre entrée à part les entrées keepalive), vous avez un problème de pare-feu sur le point de terminaison A : essayez d’exécuter les commandes iptables-save et nft list ruleset sur le point de terminaison A pour déboguer les problèmes avec son pare-feu (la sortie doit montrer qu’il autorise au minimum les connexions établies entrantes vers l’interface WireGuard wg0 du point final A à partir de l’adresse LAN du point final B de 192.168.200.22).

L’application ne reçoit rien Si cette entrée tcpdump semble bonne, mais que l’application sous-jacente (par exemple, curl) ne signale rien recevoir, vous avez un problème de pare-feu sur le point de terminaison A : essayez d’exécuter les commandes iptables-save et nft list ruleset sur le point de terminaison A pour déboguer les problèmes avec son pare-feu (la sortie doit montrer qu’elle autorise au minimum les connexions établies entrantes vers l’interface WireGuard wg0 du point de terminaison A à partir de l’adresse LAN du point de terminaison *B de 192.168.200.22).

Paquets KeepAlive Le reste des entrées dans l’exemple de sortie tcpdump affichent des paquets de données UDP WireGuard supplémentaires envoyés dans les deux sens entre le point de terminaison A et l’hôte β, ou affichent les paquets TCP sous-jacents qui sont tunnellisés via WireGuard. Vous verrez beaucoup de ce trafic une fois que votre connexion WireGuard sera opérationnelle.

Les seules exceptions à cela sont les dernières entrées affichées pour Endpoint A et Host β : ce sont de petits paquets « keepalive » que vous pouvez voir lorsque la connexion WireGuard est autrement inactive.

Dans la sortie Endpoint A tcpdump, la dernière entrée est la suivante :

19:47:30.984489 wlan0 Out IP 192.168.1.11.51821 > 203.0.113.2.51822: UDP, length 32

Et dans la sortie Host β tcpdump, la dernière entrée est la suivante :

19:47:30.984753 eth0  In  IP 198.51.100.1.51821 > 203.0.113.2.51822: UDP, length 32

Ces paquets sont reconnaissables car ce sont des paquets UDP de longueur 32, envoyés entre les deux ports d’écoute WireGuard 51821 et 51822.

Vous ne verrez ces paquets que si la poignée de main WireGuard a déjà été effectuée avec succès. WireGuard enverra automatiquement un keepalive quelques secondes après toute rafale de trafic d’un côté ou de l’autre, pour essayer de maintenir la connexion ouverte via des pare-feu avec état au cas où l’autre côté aurait encore des paquets à envoyer.

De plus, si vous configurez le paramètre PersistentKeepalive pour un pair, WireGuard enverra à plusieurs reprises un paquet keepalive du côté configuré de la connexion toutes les X secondes après l’envoi précédent du dernier paquet de données (ou keepalive) (où X est la valeur du PersistentKeepalive ) — maintenant la connexion ouverte indéfiniment.


by Justin Ludwig
translated by: Patrice Le Guyader
tags: security VPN