Points de terminaison et adresses IP de WireGuard
{< admonitionblock style=“important” >} Traduction d’un article du site Pro Custodibus
Le contenu de cette page est la traduction Française de l’article WireGuard Endpoints and IP Addresses de Justin Ludwig
{< /admonitionblock >}
WireGuard Endpoints et Adresses IP
Quand on commence à utiliser WireGuard, il peut être difficile de comprendre l’interaction entre les couches réseau en dessous de WireGuard (le “réseau réel”, souvent un Ethernet physique ou un réseau WiFi) et le VPN WireGuard (Réseau Privé Virtuel). Cet article couvrira quels paramètres de configuration sont utilisés pour quel (“réseau réel” ou réseau virtuel), et suivra comment un paquet individuel circule entre les deux.
Si vous avez des questions sur certains termes utilisés par cet article, consultez l’article Terminologie WireGuard pour plus de clarification.
Paramètres d’Adresse IP
Commençons par examiner un simple fichier de configuration WireGuard. Ici, vous verrez trois paramètres différents avec des adresses IP — Address, AllowedIPs et Endpoint :
# /etc/wireguard/wg0.conf
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51821
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
AllowedIPs = 192.168.200.0/24
Endpoint = 203.0.113.2:51822
Address
Le paramètre Address est l’adresse virtuelle du pair WireGuard local. C’est l’adresse IP de l’interface réseau virtuelle que WireGuard configure pour le pair ; et comme tel, vous pouvez la définir sur ce qui vous convient (ce qui fait sens pour le réseau WireGuard virtuel que vous construisez).
Comme avec d’autres interfaces réseau, l’adresse IP pour une interface WireGuard est définie avec un préfixe de réseau, qui indique à l’hôte local quels autres adresses IP sont disponibles sur le même sous-réseau virtuel que l’interface. Dans l’exemple ci-dessus, ce préfixe est /32 (ce qui est généralement une valeur sûre par défaut pour une interface WireGuard). Si nous laissons cela à /24, cela indiquerait à l’hôte local qu’autres adresses dans le même bloc /24 que l’adresse elle-même (10.0.0.0 à 10.0.0.255) sont routables via l’interface.
AllowedIPs
Mais WireGuard ne utilise pas ce préfixe de réseau pour gérer ce qui est effectivement routé via l’interface — au lieu de cela, WireGuard repose sur la configuration du paramètre AllowedIPs, qui est définie séparément pour chaque pair à laquelle l’interface peut se connecter. WireGuard ignorera tout trafic routé vers l’interface ayant une adresse de destination en dehors des AllowedIPs configurées pour les pairs de l’interface, et il ignorerait également tout trafic entrant sur l’hôte via l’interface ayant une adresse source en dehors de ces mêmes AllowedIPs.
Si vous utilisez le programme wg-quick (ou l’application WireGuard sur des plateformes comme iOS, Android, etc.) pour configurer une interface WireGuard, ce programme configurera également la table de routage de l’hôte avec des routes qui correspondent au paramètre AllowedIPs, afin que le trafic qui peut être routé vers l’interface WireGuard soit routé à elle.
Si vous vouliez faire passer tout le trafic d’un hôte via une interface WireGuard, vous configureriez l’interface avec un seul pair et définiriez les AllowedIPs de ce pair à 0.0.0.0/0, ::/0. Dans l’exemple ci-dessus, cependant, nous voulons faire passer simplement un sous-réseau spécifique à l’interface WireGuard — un site interne spécifique que nous voulons pouvoir accéder via un tunnel WireGuard à un pair situé dans le site — donc nous définissons les AllowedIPs pour ce pair à 192.168.200.0/24 (le bloc d’adresses de 192.168.200.0 à 192.168.200.255).
Si nous voulons que cette interface puisse également routée vers le sous-réseau 10.0.0.0/24, indépendamment de ce que nous définissons pour l’option d’adresse de l’interface, nous devrons ajouter explicitement ce sous-réseau aux paramètres AllowedIPs d’un des pairs de l’interface (ou plus probablement, appliquer différents blocs du sous-réseau aux options d’AllowedIPs).
paramètres AllowedIPs pour différents pairs si l’interface a plusieurs pairs.
Notez que vous pouvez spécifier plusieurs adresses IP (ou des blocs d’adresses) soit en les séparant par des virgules dans un seul paramètre AllowedIPs, soit en spécifiant le paramètre AllowedIPs plusieurs fois pour le même pair :
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
AllowedIPs = 192.168.200.0/24, 10.0.0.0/24
# ou alternativement :
AllowedIPs = 192.168.200.0/24
AllowedIPs = 10.0.0.0/24
Comme vous pouvez le voir, les adresses IP spécifiées par le paramètre AllowedIPs peuvent être une combinaison d’adresses “réelles” (comme un sous-réseau distant réel) et d’adresses virtuelles (comme les autres adresses dans votre VPN WireGuard).
Point de terminaison
Lorsque le trafic est routé vers une interface virtuelle WireGuard, WireGuard doit savoir où envoyer ce trafic sur un réseau “réel”. L’option Endpoint pour chaque pair indique à WireGuard l’adresse IP et le port “réels” auquel il devrait finalement envoyer le trafic.
Dans l’exemple original ci-dessus, le pair spécifié pour l’interface a un paramètre AllowedIPs de 192.168.200.0/24 et un paramètre Endpoint de 203.0.113.2:51822. Cela signifie que pour tout trafic routé à l’interface dans une adresse IP comprise entre 192.168.200.0 et 192.168.200.255, WireGuard va chiffrer et rediriger le trafic sur une interface réseau “réelle” vers l’adresse “réelle” distante de 203.0.113.2 (au port UDP 51822).
Notez que vous n’avez besoin de configurer un paramètre Endpoint statique qu’à un seul côté d’une connexion WireGuard. Si, sur le pair A, nous configurons un paramètre Endpoint pour le pair B, nous pouvons ignorer la configuration du paramètre Endpoint pour le pair B sur le pair A — le pair B attendra jusqu’à ce que le pair A se connecte à lui et mettra ensuite à jour dynamiquement son paramètre Endpoint avec l’adresse IP et le port réels à partir duquel le pair A s’est connecté.
Flux de paquets
Maintenant, passons en revue un exemple concret où nous suivons le flux des paquets d’un point de terminaison réseau à un autre et vice versa. Nous utiliserons une topologie Point to Site, où nous avons un “Endpoint A”, un tablette utilisateur final exécutant WireGuard, connectée à “Host Beta”, également exécutant WireGuard, et servant de routeur pour “Site B”. Dans Site B, nous aurons “Endpoint B”, un serveur HTTP auquel Endpoint A essayera d’envoyer du trafic.
Le diagramme ci-dessous illustre ce scénario :
Scénario point-to-site (Endpoint A vers Site B)
La configuration pour ce scénario est expliquée dans l’article Configuration Point to Site. Voici les paramètres de configuration WireGuard que nous utiliserions pour Endpoint A :
# paramètres locaux pour Endpoint A
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51821
# paramètres distants pour Host β
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
AllowedIPs = 192.168.200.0/24
Endpoint = 203.0.113.2:51822
Et les paramètres de configuration que nous utiliserions pour Host Beta :
# paramètres locaux pour Host β
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822
# Transfert d'adresses IP
PreUp = sysctl -w net.ipv4.ip_forward=1
# Masquage d'adresse IP (NAT source)
PreUp = iptables -t mangle -A PREROUTING -i wg0 -j MARK --set-mark 0x30
PreUp = iptables -t nat -A POSTROUTING ! -o wg0 -m mark --mark 0x30 -j MASQUERADE
PostDown = iptables -t mangle -D PREROUTING -i wg0 -j MARK --set-mark 0x30
PostDown = iptables -t nat -D POSTROUTING ! -o wg0 -m mark --set-mark 0x30 -j MASQUERADE
# Paramètres distants pour le Point de terminaison A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32
### Point de terminaison A
Le Point de terminaison A a une interface réseau
WiFi nommée wlan0, avec une adresse IP de 192.168.1.11 ; et une interface WireGuard nommée wg0, avec une adresse IP de 10.0.0.1 (l'interface WireGuard affichée dans la configuration ci-dessus).
Pour démarrer, l'utilisateur du Point de terminaison A accède à http://192.168.200.22/ dans un navigateur web (192.168.200.22 est l'adresse IP du Point de terminaison B au Site B). Le navigateur web utilisera une API de haut niveau pour essayer d'ouvrir un socket TCP vers le port 80 de 192.168.200.22. La pile réseau de l'OS (Système d'exploitation) exécutant sur le Point de terminaison A implémentera cela en partie en envoyant quelques paquets TCP (le premier desquels nous suivrons).
Cependant, avant d'envoyer tout paquet, le système d'exploitation du Point de terminaison A vérifiera ses tables de routage pour déterminer quelle interface réseau locale lier au nouveau socket TCP. Comme nous avons configuré la valeur `AllowedIPs` sur l'interface wg0 du Point de terminaison A à 192.168.200.0/24 (et utilisé `wg-quick` pour gérer cette interface), WireGuard a ajouté une entrée dans la table de routage du Point de terminaison A qui lui indique d'utiliser wg0 pour se connecter au bloc d'adresses 192.168.200.0/24.
Par conséquent, étant donné qu'il doit se connecter à 192.168.200.22, le Point de terminaison A sélectionnera wg0 comme l'interface pour ce socket TCP et utilisera l'adresse IP de source de la socket de 10.0.0.1. Pour le port source, il sélectionnera un port aléatoire et non utilisé sur 10.0.0.1 ; dans notre cas, supposons qu'il sélectionne le port 50000.
Pour initier ce socket TCP, le système d'exploitation sur Endpoint A générera un paquet TCP SYN et le mettra en file d'attente sur son interface wg0 :
| Étape | Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | Endpoint A | wg0 | sortant | TCP | 10.0.0.1 | 50000 | 192.168.200.22 | 80 | SYN |
Lorsque l'interface wg0 sur Endpoint A retire ce paquet de sa file d'attente, il vérifiera sa table des pairs configurées pour voir si quelconque pair a une configuration `AllowedIPs` qui inclut l'adresse de destination du paquet, 192.168.200.22. Dans notre cas, nous avons uniquement une seule pair configurée pour l'interface, et sa configuration `AllowedIPs` correspond. Par conséquent, WireGuard chiffrera le paquet TCP original avec la clé publique de la pair, et le enveloppera dans un nouveau paquet UDP qui utilise l'adresse et le port du point de terminaison de la pair comme nouvelle adresse et port de destination (203.0.113.2:51822).
WireGuard utilisera également les tables de routage de l'hôte pour déterminer quelle interface réseau et quelle adresse IP utiliser pour envoyer ce nouveau paquet UDP. Dans notre cas, l'unique "réelle" interface réseau d'Endpoint A est wlan0, donc il utilisera cette interface pour envoyer le paquet ; et il utilisera l'adresse IP unique de l'interface wlan0, 192.168.1.11, comme adresse source du paquet. Pour le port source, il utilisera la configuration `ListenPort` de l'interface wg0 (51821, tel que montré dans la configuration ci-dessus) :
| Étape | Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 2 | Endpoint A | wlan0 | sortant | UDP | 192.168.1.11 | 51821 | 203.0.113.2 | 51822 | données chiffrées |
### Routeur NAT
Le paquet UDP atteint le routeur NAT (Network Address Translation) situé devant Endpoint A, où le routeur traduit l'adresse source du paquet en son propre adresse IP publique et change le port source pour quelque chose que le routeur se souviendra d'être associé à Endpoint A. Dans notre exemple, cette adresse IP est 198.51.100.1, et nous dirons que le port sera 51111 :
| Étape | Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 3 | Site A | eth0 | entrant | UDP | 198.51.100.1 | 51111 | 203.0.113.2 | 51822 | données chiffrées |
Le routeur NAT déchiffre ensuite le paquet UDP et le transmet à Endpoint B sur l'interface wg0, qui est configurée pour recevoir des paquets sur ce port.
A NAT Router | wlan0 | in | UDP | 192.168.1.11 | 51821 | 203.0.113.2 | 51822 | données chiffrées |
| 4 | Site A NAT Router | eth0 | out | UDP | 198.51.100.1 | 51111 | 203.0.113.2 | 51822 | données chiffrées |
Le routeur NAT envoie ensuite le paquet sur Internet, où il finira par atteindre Host Beta.
### Host B
Host Beta a deux interfaces réseau Ethernet, eth0, avec une adresse IP de 203.0.113.2, connectée à Internet ; et eth1, avec une adresse IP de 192.168.200.2, connectée au LAN (Local Area Network) de Site B. Il a également une interface WireGuard nommée wg0, avec une adresse IP de 10.0.0.2 (comme indiqué dans la configuration en haut de cette section de flux de paquets). Il est également configuré pour NAT tout le trafic qu'il reçoit entrant sur sa interface wg0.
Notez que cette NAT pour l'interface wg0 est opposée à la façon dont le trafic de Site B serait normalement NATé vers Internet. Normalement, le trafic sortant de Site B vers Internet serait NATé pour réécrire l'adresse source de tous les paquets originalement issus de Site B afin d'utiliser son adresse externe de passerelle Internet (et réécrire l'adresse destination des paquets venant de retourner dans Site B en réponse). Mais pour wg0, nous traitons le VPN WireGuard comme étant le "site local", et au lieu de NATer le trafic sortant de lui vers Site B. Cela est nécessaire si les hôtes de Site B ne connaîtraient pas autrement comment routage le trafic du VPN WireGuard à travers Host Beta — mais inutile s'ils le font déjà.
Notre paquet UDP original, provenant du Point de terminaison A (par le biais du routeur NAT de Site A et d'Internet), entrera dans l'Hôte Beta sur eth0 :
| Étape | Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 5 | Hôte Beta | eth0 | in | UDP | 198.51.100.1 | 51111 | 203.0.113.2 | 51822 | données chiffrées |
Comme configuré par le paramètre ListenPort de l'interface wg0, WireGuard sera en écoute sur le port UDP 51822 de toutes les interfaces réseau de l'Hôte Beta pour de tels paquets. WireGuard déchiffre les données de ce paquet et, pour tous les paquets qu'il trouve dans les données déchiffrées, il les refile sur la pile réseau de l'hôte comme s'ils avaient entré directement depuis l'interface wg0 de l'Hôte Beta :
| Étape | Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 6 | Hôte Beta | wg0 | in | TCP | 10.0.0.1 | 50000 | 192.168.200.22 | 80 | SYN |
Le système d'exploitation de l'Hôte Beta vérifiera ses tables de routage et verra que un paquet destiné à 192.168.200.22 doit être transmis par le biais de son interface réseau eth1. Et puisque l'Hôte Beta est également configuré pour NAT le trafic qui a origine de wg0, il traduira l'adresse source du paquet en l'adresse IP qu'il utilise pour eth1 (192.168.200.2) et choisira un port aléatoire à associer à l'adresse source originale (par exemple 52222) :
| Étape | Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 7 | Hôte Beta | eth1 | out | TCP | 192.168.200.2 | 52222 | 192.168.200.22 | 80 | SYN |
### Point de terminaison B
Le Point de terminaison B a une interface réseau Ethernet nommée eth0, avec une adresse IP de 192.168.200.22. Il a un serveur HTTP qui écoute sur le port TCP 80 de cette interface, donc il accepte le paquet TCP SYN lorsqu'il le reçoit de l'Hôte Beta :
| Étape | Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 8 | Point de terminaison B | eth0 | entrant | TCP | 192.168.200.2 | 52222 | 192.168.200.22 | 80 | SYN |
Et en réponse, il génère un paquet SYN-ACK qui inverse la source et la destination du paquet SYN original et l'envoie à l'Hôte Beta :
| Étape | Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 9 | Point de terminaison B | eth0 | out | TCP | 192.168.200.22 | 80 | 192.168.200.2 | 52222 | SYN-ACK |
Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 9 | Point de terminaison B | eth0 | sortant | TCP | 192.168.200.22 | 80 | 192.168.200.2 | 52222 | SYN-ACK |
### Retour de l'Hôte B
L'Hôte Beta reçoit ce paquet SYN-ACK et voit qu'il est envoyé à un port (52222) qu'il avait récemment utilisé pour le NAT :
| Étape | Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 10 | Hôte Beta | eth1 | entrant | TCP | 192.168.200.22 | 80 | 192.168.200.2 | 52222 | SYN-ACK |
Il vérifie ce port dans ses tables NAT et traduit l'adresse de destination en 10.0.0.1 et le port de destination en 50000. Il vérifie ses tables de routage pour 10.0.0.1 et voit qu'il doit être routé via son interface wg0, donc il met en file d'attente le paquet pour l'envoyer par cette interface :
| Étape | Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 11 | Hôte Beta | wg0 | sortant | TCP | 192.168.200.22 | 80 | 10.0.0.1 | 50000 | SYN-ACK |
Quand l'interface wg0 retire le paquet de sa file d'attente, WireGuard vérifie sa table des pairs configurées pour voir quel pair a une configuration AllowedIPs qui inclut l'adresse de destination du paquet 10.0.0.1. Le pair configuré pour le Point de terminaison A, avec sa configuration AllowedIPs de 10.0.0.1/32, correspond ; donc WireGuard crypte le paquet à l'aide de la clé publique du Point de terminaison A.
Depuis aucun Point de terminaison n'est configuré sur l'Hôte Beta pour le Pair du Point de terminaison A, WireGuard utilisera l'adresse IP et le port du dernier paquet qu'il a reçu du Pair du Point de terminaison A, qui était 198.51.100.1 port 51111. Les tables de routage sur l'Hôte Beta lui indiquent d'utiliser eth0 pour envoyer le trafic à 198.51.100.1 et d'utiliser une adresse IP source de 203.0.113.2 avec cela. Et la configuration du paramètre ListenPort pour wg0 lui indique d'utiliser le port 51822 comme source de son trafic.
Ainsi, WireGuard en file d'attente un nouveau paquet UDP à envoyer par l'Hôte Beta via sa interface eth0 à 198.51.100.1, contenant le paquet SYN-ACK chiffré :
| Étape | Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 12 | Hôte Beta | eth0 | out | UDP | 203.0.113.2 | 51822 | 198.51.100.1 | 51111 | données chiffrées |
### Retour du routeur NAT
Le routeur NAT devant le Point de terminaison A recevra ce paquet UDP de l'Hôte Beta sur son interface réseau publique, et reconnaîtra le port de destination comme un port qu'il a récemment utilisé pour la traduction NAT. Il traduira l'adresse et le port de destination en retour vers l'adresse et le port d'origine utilisés par le Point de terminaison A, et fera passer le paquet à travers le routeur sur son interface LAN :
| Étape | Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 13 | Routeur NAT de Site A | eth0 | in | UDP | 203.0.113.2 | 51822 | 198.51.100.1 | 51111 | données chiffrées |
| 14 | Routeur NAT de Site A | wlan0 | out | UDP | 203.0.113.2 | 51822 | 192.168.1.11 | 51821 | données chiffrées |
### Retour du Point de terminaison A
Le Point de terminaison A reçoit le paquet UDP du routeur NAT sur son interface wlan0 :
| Étape | Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 15 | Point de terminaison A | wlan0 | in | UDP | 203.0.113.2 | 51822 | 192.168.1.11 | 51821 | données chiffrées |
Et puisque le paramètre ListenPort de l'interface wg0 du Point de terminaison A est défini sur 51821, WireGuard écoute ce paquet et le déchiffre. Il vérifie ensuite les informations de la paquette pour s'assurer qu'elle provient d'un emplacement autorisé avant de traiter le contenu.
Voici le texte corrigé :
Échiffre. Comme il contient un paquet TCP et que l'adresse source de ce paquet TCP correspond aux paramètres `AllowedIPs` pour la pair distante à partir de laquelle il a été reçu, WireGuard refile ce paquet TCP déchiffré sur l'interface `wg0` du point de terminaison A :
| Étape | Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 16 | Point de terminaison A | wg0 | in | TCP | 192.168.200.22 | 80 | 10.0.0.1 | 50000 | SYN-ACK |
Comme le système d'exploitation du point de terminaison A était en train d'ouvrir un socket TCP sur le port local 50000 de l'interface `wg0`, il gère ce paquet, remarque qu'il contient le SYN-ACK attendu et complète l'échange de clés TCP en envoyant un nouveau paquet ACK TCP à Endpoint B.
Ce paquet ACK suit exactement le même flux que le paquet SYN original. Après avoir envoyé ce dernier, le socket TCP a été établi, et le système d'exploitation du point de terminaison A retourne le nouveau socket établi au navigateur web depuis l'appel API original effectué par le navigateur. Le navigateur peut maintenant envoyer un flux de données à ce socket, qui sera empaqueté en paquets TCP et envoyés à Endpoint B. Ces paquets suivront également exactement le même flux que le paquet SYN original.
### Retour d'itinéraire
Pour conclure, voici un diagramme du parcours complet du paquet SYN et de la réponse SYN-ACK décrite ci-dessus :
Itinéraire complet des paquets WireGuard
Et les étapes combinées dans une seule table :
| Étape | Hôte | Interface | Direction | Protocole | Source | Port | Destination | Port | Contenu |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | Point de terminaison A | wg0 | sortant | TCP | 10.0.0.1 | 50000 | 192.168.200.22 | 80 | SYN |
| 2 | Point de terminaison A | wlan0 | sortant | UDP | 192.168.1.11 | 51821 | 203.0.113.2 | 51822 | données chiffrées |
| 3 | Routeur NAT du Site A | wlan0 | entrant | UDP | 192.168.1.11 | 51821 | 203.0.113.2 | 51822 | données chiffrées |
| 4 | Routeur NAT du Site A | eth0 | sortant | UDP | 198.51.100.1 | 51111 | 203.0.113.2 | 51822 | données chiffrées |
| 5 | Hôte Beta | eth0 | entrant | UDP | 198.51.100.1 | 51111 | 203.0.113.2 | 51822 | données chiffrées |
| 6 | Hôte Beta | wg0 | entrant | TCP | 10.0.0.1 | 50000 | 192.168.200.22 | 80 | SYN |
| 7 | Hôte Beta | eth1 | sortant | TCP | 192.168.200.2 | 52222 | 192.168.200.22 | 80 | SYN |
| 8 | Point de terminaison B | eth0 | entrant | TCP | 192.168.200.2 | 52222 | 192.168.200.22 | 80 | SYN |
| 9 | Point de terminaison B | eth0 | sortant | TCP | 192.168.200.22 | 80 | 192.168.200.2 | 52222 | SYN-ACK |
| 10 | Hôte Beta | eth1 | entrant | TCP | 192.168.200.22 | 80 | 192.168.200.2 | 52222 | SYN-ACK |
| 11 | Hôte Beta | wg0 | sortant | TCP | 192.168.200.22 | 80 | 10.0.0.1 | 50000 | SYN-ACK |
| 12 | Hôte Beta | eth0 | sortant | UDP | 203.0.113.2 | 51822 | 198.51.100.1 | 51111 | données chiffrées |
| 13 | Routeur NAT du Site A | eth0 | entrant | UDP | 203.0.113.2 | 51822 | 198.51.100.1 | 51111 | données chiffrées |
| 14 | Routeur NAT du Site A | wlan0 | sortant | UDP | 203.0.113.2 | 51822 | 192.168.1.11 | 51821 | données chiffrées |
| 15 | Point de terminaison A | wlan0 | entrant | UDP | 203.0.113.2 | 51822 | 192.168.1.11 | 51821 | données chiffrées |
| 16 | Point de terminaison A | wg0 | entrant | TCP | 192.168.200.22 | 80 | 10.0.0.1 | 50000 | SYN-ACK |
1/2/2021
par [Justin Ludwig](https://www.procustodibus.com/authors/justin-ludwig/)
- [WireGuard](https://www.procustodibus.com/tags/wireguard/)
- [Réseautage](https://www.procustodibus.com/tags/networking/)
by Justin Ludwig translated by: Patrice Le Guyader