Wireguard endpoints et adresses ip

Lorsque vous démarrez avec WireGuard, il peut être difficile de comprendre l’interaction entre les couches réseau sous WireGuard (le « vrai » réseau, souvent un réseau Ethernet ou WiFi physique) 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 retracera comment un paquet individuel circule entre les deux.

Si vous vous interrogez sur la terminologie utilisée dans cet article, consultez l’article Terminologie WireGuard pour plus de précisions.

Paramètres d’adresses IP

Regardons d’abord un simple fichier de configuration WireGuard. Ici, vous verrez trois paramètres différents avec des adresses IP - Adresse, 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

Adresse

Le paramètre Adresse 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 en tant que tel, vous pouvez le définir comme vous le souhaitez (ce qui a du sens pour le réseau virtuel WireGuard que vous construisez).

Comme pour les autres interfaces réseau, l’adresse IP d’une interface WireGuard est définie avec un préfixe réseau, qui indique à l’hôte local quelles 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 (qui est généralement une valeur par défaut sûre pour une interface WireGuard). Si nous le définissons sur /24, cela indiquerait à l’hôte local que d’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 n’utilise pas ce préfixe réseau pour régir ce qui est réellement acheminé via l’interface - WireGuard s’appuie plutôt sur le paramètre AllowedIPs, configuré séparément pour chaque pair auquel l’interface peut se connecter. WireGuard supprimera tout trafic acheminé vers l’interface qui a une adresse de destination en dehors des adresses IP autorisées configurées pour les pairs de l’interface, et supprimera également tout trafic entrant dans l’hôte via l’interface qui a une adresse source en dehors de ces mêmes adresses IP autorisées.

Si vous utilisez le programme wg-quick (ou l’application WireGuard sur des plates-formes comme iOS, Android, etc.) pour configurer une interface WireGuard, ce programme configurera également la table de routage de l’hôte avec des itinéraires correspondant au paramètre AllowedIPs, de sorte que le trafic qui peut être acheminé vers l’interface WireGuard sera acheminé vers celle-ci.

Si vous vouliez acheminer tout le trafic d’un hôte via une interface WireGuard, vous devez configurer l’interface avec un pair et définir les adresses IP autorisées de ce pair sur 0.0.0.0/0, ::/0. Dans l’exemple ci-dessus, cependant, nous souhaitons acheminer uniquement un sous-réseau particulier vers l’interface WireGuard - un site interne particulier auquel nous voulons pouvoir accéder via un tunnel WireGuard vers un pair situé sur le site - nous avons donc défini AllowedIPs pour le pair à 192.168.200.0/24 (le bloc d’adresses de 192.168.200.0 à 192.168.200.255).

Si nous voulions également que cette interface puisse être acheminée vers le sous-réseau 10.0.0.0/24, quel que soit ce que nous avons défini pour le paramètre d’adresse de l’interface, nous devrions explicitement ajouter ce sous-réseau au paramètre AllowedIPs pour l’un des pairs de l’interface. . (Ou plus probablement, appliquez différents blocs du sous-réseau au paramètre AllowedIPs de différents pairs, si l’interface a plusieurs pairs.)

Notez que vous pouvez spécifier plusieurs adresses IP (ou blocs d’adresses) en les séparant par des virgules dans un paramètre AllowedIPs individuel, ou vous pouvez simplement spécifier 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
# or alternately:
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 un mélange d’adresses “réelles” (comme un “vrai” sous-réseau distant) et d’adresses virtuelles (comme les autres adresses de votre VPN WireGuard).

Endpoint

Lorsque le trafic est acheminé vers une interface WireGuard virtuelle, WireGuard doit savoir où envoyer ce trafic sur un réseau « réel ». Le paramètre Endpoint de chaque pair indique à WireGuard l’adresse IP “réelle” et le port auquel il doit finalement envoyer le trafic.

Dans l’exemple d’origine ci-dessus, l’homologue 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 acheminé vers l’interface au sein d’une adresse IP comprise entre 192.168.200.0 et 192.168.200.255, WireGuard cryptera et redirigera le trafic via une “vraie” interface réseau vers la “vraie” adresse distante de 203.0. 113.2 (au port UDP 51822).

Notez que vous n’avez besoin de configurer un paramètre de point de terminaison statique que d’un côté d’une connexion WireGuard. Si, sur le pair A, nous configurons un paramètre de point de terminaison pour le pair B, nous pouvons ignorer la configuration d’un paramètre de point de terminaison sur le pair B pour le pair A - Le pair B attendra que le pair A s’y connecte, puis mettra à jour dynamiquement son paramètre de point de terminaison sur le paramètre réel. Adresse IP et port à partir desquels le Peer A s’est connecté.

Packet Flow

Passons maintenant à un exemple concret où nous suivons le flux de paquets d’un point de terminaison du réseau à un autre, et vice-versa. Nous utiliserons une topologie point à site, où nous avons un «point de terminaison A», une tablette d’utilisateur final exécutant WireGuard, connectée à «Host Beta», exécutant également WireGuard et servant de routeur pour «Site B». Dans le site B, nous aurons “Endpoint B”, un serveur HTTP auquel Endpoint A essaiera d’envoyer du trafic.

Le schéma ci-dessous illustre ce scénario :

# local settings for Endpoint A
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51821

# remote settings for 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 :

# local settings for Host β
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822

# IP forwarding
PreUp = sysctl -w net.ipv4.ip_forward=1
# IP masquerading (source NAT)
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 --mark 0x30 -j MASQUERADE

# remote settings for Endpoint A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32

Endpoint A

Le point de terminaison A possède 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 illustrée dans la configuration ci-dessus).

Pour commencer, sur le point de terminaison A, l’utilisateur accède à http://192.168.200.22/ dans un navigateur Web (192.168.200.22 est l’adresse IP du point de terminaison B sur le site B.) Le navigateur Web utilisera une API de haut niveau pour essayer d’ouvrir un socket TCP sur le port 80 de 192.168.200.22. La pile réseau du système d’exploitation (système d’exploitation) exécuté sur le point de terminaison A implémentera cela en partie en envoyant quelques paquets TCP (dont nous tracerons le premier).

Avant d’envoyer des paquets, cependant, le système d’exploitation sur le point de terminaison A vérifiera ses tables de routage pour déterminer à quelle interface réseau locale lier le nouveau socket TCP. Puisque nous avons configuré le paramètre AllowedIPs sur l’interface wg0 du Endpoint A sur 192.168.200.0/24 (et utilisé wg-quick pour gérer cette interface), WireGuard a ajouté une entrée à la table de routage du Endpoint A qui lui demande d’utiliser wg0 pour se connecter au bloc d’adresses 192.168.200.0/24.

Par conséquent, puisqu’il est censé se connecter à 192.168.200.22, le point de terminaison A sélectionnera wg0 comme interface pour ce socket TCP et utilisera l’adresse IP de l’interface wg0 de 10.0.0.1 pour l’adresse source du socket. Pour le port source, il sélectionnera un port inutilisé aléatoire sur 10.0.0.1 ; dans notre cas, disons qu’il sélectionne le port 50000.

Ensuite, pour lancer ce socket TCP, le système d’exploitation sur le point de terminaison A générera un paquet TCP SYN et le mettra en file d’attente sur son interface wg0 :

Lorsque l’interface wg0 sur le point de terminaison A extrait ce paquet de sa file d’attente, elle vérifie sa table de pairs configurés pour voir quel pair, le cas échéant, a un paramètre AllowedIPs qui inclut l’adresse de destination du paquet de 192.168.200.22. Dans notre cas, nous n’avons qu’un seul pair configuré pour l’interface, et son paramètre AllowedIPs correspond. Par conséquent, WireGuard chiffrera le paquet TCP d’origine à l’aide de la clé publique du pair et l’enveloppera dans un nouveau paquet UDP qui utilise le paramètre Endpoint du pair comme adresse et port de destination du nouveau paquet (203.0.113.2:51822).

WireGuard utilisera également les tables de routage de l’hôte pour déterminer l’interface réseau et l’adresse IP à utiliser pour envoyer ce nouveau paquet UDP. Dans notre cas, la seule interface réseau “réelle” du point de terminaison A est wlan0, il utilisera donc cette interface pour envoyer le paquet ; et il utilisera la seule adresse IP de l’interface wlan0, 192.168.1.11 comme adresse source du paquet. Pour le port source, il utilisera le paramètre de configuration ListenPort de l’interface wg0 (51821, comme indiqué dans la configuration ci-dessus) :

Routeur NAT

Le paquet UDP se rendra au routeur NAT (Network Address Translation) devant le point de terminaison A, où le routeur traduira l’adresse source du paquet en adresse IP publique du routeur, ainsi que changera le port source à quelque chose dont le routeur se souviendra est associé au point de terminaison A. Dans notre exemple, cette adresse IP est 198.51.100.1, et nous dirons que le port sera 51111 :

Le routeur NAT enverra ensuite le paquet sur Internet, où il finira par se rendre à Host Beta.

Hôte B

L’hôte Beta possède deux interfaces réseau Ethernet, eth0, avec une adresse IP de 203.0.113.2, connectées à Internet ; et eth1, avec une adresse IP de 192.168.200.2, connecté au LAN (réseau local) du site B. Il possède é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 trafic qu’il reçoit entrant vers son interface wg0.

Notez que le NAT pour cette interface wg0 est à l’opposé de la façon dont le trafic du site B serait normalement NAT vers Internet. Normalement, le trafic sortant du site B vers Internet serait NATé pour réécrire l’adresse source de tous les paquets provenant du site B pour utiliser l’adresse externe de sa passerelle Internet (et réécrire l’adresse de destination des paquets revenant au site B en réponse). Mais pour wg0, nous traitons le VPN WireGuard comme le “site local”, et NATons plutôt le trafic sortant de celui-ci vers le site B. Ceci est nécessaire si les hôtes du site B ne sauraient autrement acheminer le trafic pour le VPN WireGuard via Host Beta - mais inutile s’ils le font.

Ainsi, notre paquet UDP, originaire du point de terminaison A (via le routeur NAT du site A et Internet), entrera dans la version bêta de l’hôte sur eth0 :

Comme configuré par le paramètre ListenPort de l’interface wg0, WireGuard écoutera sur le port UDP 51822 de toutes les interfaces réseau de Host Beta pour ces paquets. WireGuard déchiffrera les données de ce paquet, et quels que soient les paquets qu’il trouve dans les données déchiffrées, il se remettra en file d’attente sur la pile réseau de l’hôte comme s’ils provenaient directement de l’interface wg0 sur Host Beta :

Le système d’exploitation sur Host Beta vérifiera ses tables de routage et verra qu’un paquet destiné à 192.168.200.22 doit être transféré sur son interface réseau eth1. Et puisque Host Beta est également configuré pour le trafic NAT provenant 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 d’origine (disons 52222):

POINT FINAL B Le point de terminaison B possède une interface réseau Ethernet nommée eth0, avec une adresse IP de 192.168.200.22. Il dispose d’un serveur HTTP écoutant sur le port TCP 80 de cette interface, il accepte donc le paquet TCP SYN lorsqu’il le reçoit de l’Host Beta :

Et en réponse, il génère un paquet SYN-ACK qui inverse la source et la destination du paquet SYN d’origine, et envoie ce paquet à Host Beta :

Hôte B retour

L’hôte Beta reçoit ce paquet SYN-ACK et voit qu’il est envoyé à un port (52222) qu’il a récemment utilisé pour NAT :

Il recherche donc 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 acheminé vers son wg0 interface, il met donc le paquet en file d’attente pour sortir de cette interface :

Lorsque l’interface wg0 extrait le paquet de sa file d’attente, WireGuard vérifie sa table de pairs configurés pour voir quel pair a un paramètre AllowedIPs qui inclut l’adresse de destination du paquet 10.0.0.1. L’homologue configuré pour le point de terminaison A, avec son paramètre AllowedIPs de 10.0.0.1/32, correspond ; WireGuard chiffrera donc le paquet à l’aide de la clé publique du point de terminaison A.

Étant donné qu’aucun point de terminaison n’est configuré sur l’hôte bêta 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 le port 198.51.100.1 51111. Les tables de routage sur la version bêta de l’hôte lui indiquent utiliser eth0 pour envoyer le trafic vers 198.51.100.1 et utiliser une adresse IP source de 203.0.113.2 avec. Et le paramètre de configuration ListenPort pour wg0 lui indique d’utiliser le port 51822 comme source de son trafic.

Ainsi, WireGuard mettra en file d’attente un nouveau paquet UDP à envoyer par Host Beta sur son interface eth0 vers 198.51.100.1, contenant le paquet SYN-ACK chiffré :

Retour du routeur NAT

Le routeur NAT devant le point de terminaison A recevra ce paquet UDP de l’hôte bêta sur son interface de réseau public et reconnaîtra le port de destination comme un port qu’il a récemment utilisé pour le NAT. Il retraduira l’adresse et le port de destination en l’adresse et le port d’origine utilisés par le point de terminaison A, et transmettra le paquet au point de terminaison A via l’interface LAN du routeur :

Retour du endpoint A

Le point de terminaison A reçoit le paquet UDP du routeur NAT sur son interface wlan0 :

Et puisque le paramètre ListenPort de l’interface wg0 du Endpoint A est 51821, WireGuard écoutera ce paquet et le déchiffrera. Comme il contient un paquet TCP et que l’adresse source de ce paquet TCP correspond au paramètre AllowedIPs pour le pair distant à partir duquel il a été reçu, WireGuard remettra en file d’attente ce paquet TCP déchiffré sur l’interface wg0 du Endpoint A :

Étant donné que le système d’exploitation du point final A était en train d’ouvrir un socket TCP sur le port local 50000 de l’interface wg0, il gère le paquet, voit qu’il contient le SYN-ACK attendu et termine la poignée de main TCP en renvoyant un nouveau paquet TCP ACK. au point final B.

Ce paquet ACK suit exactement le même flux que le paquet SYN d’origine. Après l’avoir envoyé, le socket TCP a été établi et le système d’exploitation sur le point de terminaison A renvoie le socket nouvellement établi au navigateur Web à partir de l’appel d’API d’origine effectué par le navigateur. Le navigateur peut maintenant envoyer un flux de données à ce socket, que le système d’exploitation regroupera dans des paquets TCP, et enverra au point de terminaison B. Ces paquets suivront également exactement le même flux que le paquet SYN d’origine.

Aller-Retour

Pour conclure, voici un schéma de l’aller-retour complet du paquet SYN et de la réponse SYN-ACK décrit ci-dessus :