Configuration WireGuard Site à Site
|
Important
|
Traduction d’un article du site Pro Custodibus Le contenu de cette page est la traduction Française de l’article WireGuard Site to Site Configuration de Justin Ludwig |
Configuration de WireGuard Site à Site
Cet article explique comment configurer deux pairs WireGuard dans une topologie Site à Site. C’est la configuration que vous utiliseriez lorsque vous souhaitez connecter un ensemble divers de ordinateurs sur un site via un seul tunnel WireGuard à un ensemble divers d’ordinateurs sur un autre site ; comme pour connecter le réseau local (LAN) d’une emplacement d’entreprise à un autre, ou pour connecter votre réseau d’entreprise à une série de serveurs que vous avez configurés dans un réseau cloud.
Dans le scénario spécifique que je couvrirai dans cet article, nous aurons “Host α” qui exécute WireGuard sur un LAN, “Site A”, connecté à travers Internet à “Host β” qui exécute WireGuard sur un autre LAN, “Site B”. Host α sera configuré comme la passerelle du Site A vers le Site B, et Host β comme la passerelle du Site B vers le Site A. “Point de terminaison A” est une station de travail utilisateur finale dans le Site A qui pourra se connecter à travers notre tunnel WireGuard à un serveur HTTP sur “Point de terminaison B” dans le Site B.
Le diagramme ci-dessous illustre ce scénario :
Pour accomplir cela, Host α doit être capable de se connecter à travers le pare-feu du Site B au port UDP 51822 sur Host β, et Host β doit être capable de se connecter à travers le pare-feu du Site A au port UDP 51821 sur Host α. À partir du point de vue de Host β et d’Internet, l’adresse IP de Host α est 198.51.100.1, mais à partir du point de vue du Site A, l’adresse IP de Host α est 192.168.1.1, et à partir du point de vue du tunnel WireGuard entre Host α et Host β, l’adresse IP de Host α sera 10.0.0.1.
De même, du point de vue de l’Hôte α et de l’Internet, l’adresse IP de l’Hôte β est 203.0.113.2, et du point de vue du Site B, l’adresse IP de l’Hôte β est 192.168.200.2, et à partir du point de vue du tunnel WireGuard entre l’Hôte α et l’Hôte β, l’adresse IP de l’Hôte β sera 10.0.0.2.
L’adresse IP de l’Endpoint A sera 192.168.1.11, et celle de l’Endpoint B sera 192.168.200.22. Avec le tunnel WireGuard en cours d’exécution, un utilisateur sur l’Endpoint A pourra accéder au serveur HTTP de l’Endpoint B simplement en naviguant vers http://192.168.200.22 dans son navigateur web.
Cet article expliquera comment installer et configurer WireGuard sur l’Hôte α et l’Hôte β, ainsi que comment configurer l’Hôte α et l’Hôte β pour qu’ils puissent routage les paquets entre le Site A et le Site B. Voici les étapes que nous suivrons :
- Installer WireGuard
- Générer des clés
- Configurer WireGuard
- Configurer le routage
- Démarrer WireGuard
- Tester le tunnel
- Dépannage de base
- Supplémentaire : Configurer le pare-feu
Installer WireGuard
Installez WireGuard sur les deux Hôtes α et β en suivant les instructions d’installation pour la plateforme appropriée sur la page WireGuard Installation. Vous pouvez vérifier que vous avez installé WireGuard avec succès en exécutant wg help sur les deux hôtes.
Générer des clés
Ensuite, générez deux paires de clés WireGuard, une pour l’Hôte α et une pour l’Hôte β. Une paire de clés WireGuard (aussi appelée “paire de clés”) est composée de deux parties : la “clé privée” (aussi appelée “clé secrète”) et la “clé publique”. La magie de ce type de cryptographie (connue sous le nom de “cryptographie à clé publique”) est que c’est trivial de calculer la clé publique si vous connaissez la clé privée, mais pratiquement impossible de calculer la clé privée si tout ce que vous saisissez est la clé publique.
Voici le texte corrigé :
C’est la clé publique.
Bien que vous n’ayez pas besoin de générer les clés sur les hôtes, la génération d’une paire de clés pour l’hôte lui-même est souvent la meilleure façon de protéger sa clé privée — ainsi, la clé privée ne quitte jamais l’hôte. Si vous géneriez vos clés à l’extérieur de l’hôte, soyez très prudent avec les clés privées, car la sécurité de WireGuard dépend entièrement du maintien des clés privées secrètes.
Exécutez les commandes suivantes pour générer une nouvelle paire de clés pour l’Hôte A :
$ wg genkey > host-a.key
$ wg pubkey < host-a.key > host-a.pub
Et des commandes similaires pour générer une nouvelle paire de clés pour l’Hôte β :
$ wg genkey > host-b.key
$ wg pubkey < host-b.key > host-b.pub
Cela générera quatre fichiers : host-a.key, host-a.pub, host-b.key et host-b.pub. Les fichiers *.key contiennent les clés privées, et les fichiers *.pub contiennent les clés publiques. Le contenu de chaque sera 44 caractères de texte encodé en Base64 :
$ cat host-a.key
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
$ cat host-a.pub
/TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
$ cat host-b.key
ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
$ cat host-b.pub
fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Vous n’avez pas besoin de conserver ces fichiers en permanence — le contenu de chaque sera utilisé dans les fichiers de configuration de WireGuard que nous construirons pour l’Hôte α et l’Hôte β dans les sections suivantes. La clé privée d’un hôte va dans son propre fichier de configuration ; et sa clé publique va dans le fichier de configuration de chaque autre hôte auquel vous souhaitez qu’il se connecte. Chaque bout d’une connexion doit être pré-configuré avec la clé publique de l’autre bout afin que WireGuard puisse établir la connexion.
Configurer WireGuard
Maintenant, configurons WireGuard. Sur l’Hôte α, créez un nouveau fichier à /etc/wireguard/wg0.conf avec le contenu suivant :
# /etc/wireguard/wg0.conf
# paramètres locaux pour l'Hôte α
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51821
# paramètres distants pour l'Hôte β
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = 203.0.113.2:51822
AllowedIPs = 192.168.200.0/24
Et sur l’Hôte β, créez un nouveau fichier à la même emplacement avec le contenu suivant :
# /etc/wireguard/wg0.conf
# paramètres locaux pour l'Hôte β
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822
# paramètres distants pour l'Hôte α
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
Endpoint = 198.51.100.1:51821
AllowedIPs = 192.168.1.0/24
Définissez le propriétaire de chaque fichier sur root, et ses permissions sur 600 (le propriétaire peut lire+écrire ; tout le monde else est refusé l’accès — le fichier contient la clé privée du point de terminaison, qui doit être gardée secrète).
Avec une topologie Site à Site, la configuration des deux hôtes WireGuard est généralement parfaitement symétrique, avec la section [Interface] pour chaque hôte décrivant l’hôte lui-même, et la section [Peer] décrivant l’autre hôte. Passons en revue chaque paramètre de configuration :
-
Interface.PrivateKey : C’est la clé privée propre à cet hôte — remplacez cette valeur par la clé privée réelle générée pour l’hôte. Cette valeur est secrète, et c’est le seul endroit où elle devrait vivre.
-
Interface.Address : C’est l’adresse IP de l’hôte à l’intérieur du VPN WireGuard que nous construisons — remplacez cette valeur par une valeur appropriée pour votre réseau. Vous pouvez utiliser n’importe quelle adresse que vous voulez, mais l’adresse doit être dans l’espace d’adressage “Utilisation privée” IPv4 ou “Local unique” IPv6 (comme
10.0.0.0/8— voir RFC 6890 pour tous les blocs d’adresses disponibles), et
ne doit pas entrer en conflit avec n’importe quel autre sous-réseau privé auquel l’hôte lui-même ou l’un de ses pairs peut se connecter.
Ce paramètre n’est pas utilisé directement par WireGuard — il est utilisé uniquement par le service d’assistance wg-quick lorsqu’il configure une interface réseau virtuelle pour WireGuard. Afin que les paquets de réseau soient correctement routés vers et depuis cet hôte lorsque ils sont en dehors du tunnel WireGuard, ils doivent utiliser l’adresse IP que vous définissez ici.
De plus, avec une topologie Site à Site, ce paramètre n’est pas si important — généralement, vous voulez qu’un paquet soit routé à travers l’hôte (et vers d’autres points de terminaison dans le site), et non vers l’hôte lui-même. Ainsi, il suffit de vous assurer que vous choisissez une adresse IP qui ne va pas entrer en conflit avec aucune autre adresse IP que l’hôte peut router.
Bien que vous puissiez configurer plusieurs adresses IP pour ce paramètre, à moins qu’il n’y ait un cas d’utilisation spécifique, il est préférable de simplement utiliser une seule adresse IP (au format d’un bloc /32 avec une adresse IPv4 ou d’un bloc /64 avec une adresse IPv6).
- Interface.ListenPort
- C’est le port WireGuard de l’hôte. L’hôte doit être capable de recevoir du trafic UDP pour de nouvelles connexions sur ce port à partir de l’Internet (ou où que le trafic des autres pairs WireGuard avec lesquels il communiquera vienne).
Avec une topologie Site à Site, ce paramètre dans le fichier de configuration d’Hôte α doit correspondre au port dans la configuration
Peer.Endpointde l’hôte β, et vice versa. - Peer.PublicKey
- C’est la clé publique de l’autre hôte — remplacez cette valeur par la clé publique réelle que vous avez générée pour l’autre hôte. Sur Hôte α, cela doit être la clé publique d’Hôte β ; et sur Hôte β, cela doit être la clé publique d’Hôte α.
- Peer.Endpoint
- C’est l’adresse IP et le port public de l’autre hôte — l’adresse IP et le port que cet hôte utilisera pour se connecter à travers l’Internet à l’autre hôte afin de configurer le tunnel WireGuard. Remplacez cette valeur par l’adresse IP réelle que vous utiliseriez normalement pour vous connecter à l’autre hôte (et ajoutez-y le port WireGuard réel que vous utiliserez pour l’autre hôte).
Dans notre exemple, l’adresse IP publique de l’Hôte β est 203.0.113.2 (et WireGuard écoute sur le port 51822 de l’Hôte β), donc c’est cette adresse IP (et ce port) que nous insérons dans la configuration Peer.Endpoint de l’Hôte α. L’adresse IP publique de l’Hôte α est 198.51.100.1 (avec WireGuard qui écoute sur le port 51821), donc c’est cette adresse (et ce port) que nous insérons dans la configuration Peer.Endpoint de l’Hôte β.
L’Hôte α doit être capable d’accepter de nouvelles connexions UDP entrantes à partir d’internet à cette adresse et ce port (198.51.100.1:51821), et de même, l’Hôte β doit également être capable d’accepter de nouvelles connexions UDP entrantes à partir d’internet à son adresse et son port (203.0.113.2:51822).
- Peer.AllowedIPs
- C’est le bloc de sous-réseau de l’autre site — remplacez cette valeur par le bloc réel d’adresses IP que l’autre site utilise. Si l’autre hôte peut routage vers plusieurs sous-réseaux au sein du autre site, vous pouvez spécifier chaque bloc d’adresses IP séparées par des virgules (comme
192.168.200.0/24, 192.168.202.64/26, 192.0.2.48/28) pour cette configuration, ou vous pouvez simplement spécifier cette configuration plusieurs fois, une pour chaque bloc CIDR (Classless Inter-Domain Routing).
Dans notre exemple, le bloc de sous-réseau du Site B est 192.168.200.0/24, donc c’est ce bloc que nous insérons dans la configuration Peer.AllowedIPs de l’Hôte α. Le bloc de sous-réseau du Site A est 192.168.1.0/24, donc c’est ce bloc que nous insérons dans la configuration Peer.AllowedIPs de l’Hôte β.
|
Tip
|
Pour permettre à l’un (ou les deux) des hôtes WireGuard d’accéder au site distant, vous devez ajouter l’adresse WireGuard de l’hôte au paramètre AllowedIPs du site distant.
Par exemple, si vous souhaitez exécuter curl sur l’hôte α afin d’accéder au serveur web de l’Endpoint B (ou exécuter ping sur l’hôte α afin de tester sa connexion avec l’hôte β), ajoutez l’adresse IP WireGuard de l’hôte α (10.0.0.1) au paramètre AllowedIPs de l’hôte β :
AllowedIPs = 192.168.1.0/24, 10.0.0.1/32
Vous devrez peut-être également ajouter une route pour cette adresse au site B, comme décrit dans la section suivante.
Configurer le Routage
Si les deux hôtes WireGuard sont déjà configurés en tant que passerelle Internet pour leur site (ou la passerelle de leur site vers un sous-réseau qui inclut le LAN du site distant), vous n’avez rien à faire d’exceptionnel pour WireGuard ; passez simplement à la section suivante.
Sinon, nous devons faire deux choses :
- Activer le transfert IP sur les hôtes WireGuard
- Mettre à jour les tables de routage pour chaque site
Comme nous utiliserons wg-quick pour activer et désactiver le tunnel WireGuard sur l’hôte α et l’hôte β, la manière la plus simple d’assurer que le transfert IP est activé lorsque le tunnel WireGuard est actif est de faire en sorte que wg-quick le fasse lui-même lorsqu’il active le tunnel WireGuard. Mettez à jour le fichier /etc/wireguard/wg0.conf sur l’hôte α pour ajouter le paramètre suivant Interface.PreUp :
# /etc/wireguard/wg0.conf
# paramètres locaux de l'hôte α
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51821
# transfert IP
PreUp = sysctl -w net.ipv4.ip_forward=1
# paramètres distants pour l'Hôte β
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = 203.0.113.2:51822
AllowedIPs = 192.168.200.0/24
Et ajoutez les mêmes paramètres exactement au /etc/wireguard/wg0.conf sur l’Hôte β :
# /etc/wireguard/wg0.conf
# paramètres locaux pour l'Hôte β
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822
# transfert IP
PreUp = sysctl -w net.ipv4.ip_forward=1
# paramètres distants pour l'Hôte α
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
Endpoint = 198.51.100.1:51821
AllowedIPs = 192.168.1.0/24
Si vous utilisez des adresses IPv6 pour votre VPN WireGuard, utilisez ce paramètre Interface.PreUp à la place (sur les deux hôtes) :
PreUp = sysctl -w net.ipv6.conf.all.forwarding=1
Pour la deuxième chose, mettre à jour les tables de routage de chaque site, malheureusement vous ne pouvez pas le faire via la configuration WireGuard. Vous pourriez configurer chaque point de terminaison dans les deux sites individuellement pour diriger le trafic qu’il génère destiné au autre site via l’hôte WireGuard de son propre site — mais la chose la plus simple à faire est simplement de mettre à jour la configuration d’un passerelle existante dans chaque site pour effectuer ce routage.
Ainsi, pour le Site A, vous voulez mettre à jour la passerelle pour le sous-réseau qui englobe le sous-réseau du Site B (192.168.200.0/24), qui est généralement la passerelle par défaut pour le Site A (comme si le Site A était une petite bureau, c’est probablement le routeur Internet pour le bureau). Vous voulez ajouter un itinéraire vers cette passerelle afin qu’elle dirige le sous-réseau du Site B (192.168.200.0/24) via l’Hôte α (192.168.1.1) sur le côté LAN de la passerelle.
Si cette passerelle est une boîte Linux, exécutez la commande ip route sur la passerelle pour vérifier quels itinéraires (IPv4) elle utilise actuellement (pour IPv6,
exécutez ip -6 route. Sur le Site A, le résultat pourrait ressembler à ceci :
$ ip route
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.100
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.128
default via 192.0.2.1 dev eth0
L’exemple ci-dessus montre que la passerelle a une adresse IP de 192.0.2.100 sur son dispositif réseau eth0, et 192.168.1.128 sur son dispositif réseau eth1. Le dispositif réseau eth1 est connecté au sous-réseau Site A, 192.168.1.0/24.
Alors exécutez la commande suivante sur la passerelle pour (temporairement) ajouter une route vers Site B via l’hôte α sur le dispositif réseau eth1 :
ip route add 192.168.200.0/24 via 192.168.1.1 dev eth1
Remplacez le sous-réseau pour Site B (192.168.200.0/24) par le sous-réseau Site B réel que vous utilisez, l’adresse IP de l’hôte α (192.168.1.1) par l’adresse IP réelle de l’hôte α que vous utilisez, et le nom du dispositif réseau (eth1) par le nom réel du dispositif par lequel la passerelle est connectée au sous-réseau Site A.
Notez que l’ajout d’une route de cette manière ne la rend qu’ temporaire, jusqu’à ce que la passerelle soit redémarrée ou reconfigurée — si vous testez le tunnel WireGuard et tout fonctionne bien, vous voudrez rendre le changement de route permanent via n’importe quel mécanisme régulièrement utilisé pour configurer la passerelle (comme via les fichiers de configuration networkd ou netplan, ou vos propres scripts shell personnalisés, ou un outil avec une interface graphique utilisateur).
De même, vérifiez les routes utilisées sur le passerelle par défaut de Site B avec ip route, puis exécutez une commande similaire pour y ajouter une route vers Site A via l’hôte β :
ip route add 192.168.1.0/24 via 192.168.200.2 dev eth1
Démarrage de WireGuard
Sur les deux hôtes α et β, démarrez le service wg-quick. Sur Linux avec systemd, exécutez les commandes suivantes :
$ sudo systemctl enable wg-quick@wg0.service
$ sudo systemctl start wg-quick@wg0.service
Sur les systèmes sans systemd, exécutez cette commande à la place :
$ sudo wg-quick up /etc/wireguard/wg0.conf
Quelle que soit la méthode utilisée, le démarrage du service wg-quick configurera une interface réseau WireGuard nommée wg0 sur l’hôte et définira certaines règles de routage pour envoyer les paquets destinés à tout adresse IP listée dans les paramètres Peer.AllowedIPs du fichier /etc/wireguard/wg0.conf.
Note que le nom wg0 est simplement la convention standard pour votre première interface WireGuard. Vous pouvez créer autant d’interfaces WireGuard que vous le souhaitez et les nommer comme vous le souhaitez. Par exemple, vous pourriez créer un autre fichier de configuration nommé /etc/wireguard/mytunnel.conf, et le démarrer avec la commande wg-quick up /etc/wireguard/mytunnel.conf; cela créera une nouvelle interface WireGuard nommée mytunnel.
Mais pour l’instant, si vous exécutez directement wg-quick up, vous verrez une sortie similaire à celle-ci :
$ sudo wg-quick up /etc/wireguard/wg0.conf
[#] sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.0.0.1/32 dev wg0
[#] ip link set mtu 8921 up dev wg0
[#] ip -4 route add 10.0.0.2/32 dev wg0
Cette sortie montre les règles de routage que wg-quick configure automatiquement pour vous.
Si vous avez exécuté systemctl start à la place, vous pouvez voir la même sortie en exécutant l’outil journalctl, comme suit :
$ journalctl -u wg-quick@wg0.service
systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
wg-quick[271288]: [#] sysctl -w net.ipv4.ip_forward=1
wg-quick[271288]: net.ipv4.ip_forward = 1
wg-quick[271288]: [#] ip link add wg0 type wireguard
wg-quick[271288]: [#] wg setconf wg0 /dev/fd/63
wg-quick[271288]: [#] ip -4 route add 10.0.0.1/32 dev wg0
wg-quick[271288]: [#] ip link set mtu
8921 up dev wg0
wg-quick[271288]: [#] ip -4 address add 10.0.0.2/32 dev wg0
systemd[1]: Started WireGuard via wg-quick(8) for wg0.
## Tester le Tunnel
Sur le Point de terminaison B, démarrez un serveur web sur le port 80 (ou tout autre port, comme 8080). Si vous n'avez pas de serveur web à disposition, une substitution très simple est d'utiliser le module `http.server` de Python 3, comme suit, en tant que root pour écouter sur le port 80 :
```bash
$ sudo python3 -m http.server 80
Ou exécutez-le en tant qu’utilisateur régulier pour écouter sur tout port supérieur à 1023 (comme le port 8080) :
$ python3 -m http.server 8080
Le module http.server servira la liste des répertoires et les fichiers dans le répertoire courant. Une version légèrement plus sécurisée de cela est de créer un répertoire vide dans le répertoire courant et de le servir à la place :
$ mkdir dummydir && cd dummydir
$ python3 -m http.server 8080
Sur le Point de terminaison A, utilisez curl (ou un navigateur web régulier) pour demander une page au serveur web en cours d’exécution sur le port 80 du Point de terminaison B :
$ curl 192.168.200.22
Ou si le serveur web est en cours d’exécution sur le port 8080 (ou un autre port), spécifiez ce port explicitement :
$ curl 192.168.200.22:8080
Si vous voyez une sortie HTML de cette façon, votre tunnel WireGuard fonctionne !
Dépannage de base
Si curl s’emballe ou que vous voyez une erreur comme Connection refused ou No route to host, vous pourriez avoir oublié d’activer le transfert IP sur l’un de vos hôtes WireGuard. Exécutez cette commande sur l’Hôte α et l’Hôte β pour vérifier à nouveau :
$ sudo sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
Ou, si vous utilisez des adresses IPv6, exécutez la variante IPv6 :
$ sudo sysctl net.ipv6.conf.all.forwarding
net.ipv6.conf.all.forwarding = 0
Si le résultat est 0, vous devez activer le transfert IP (consultez la section Configurer le Routage ci-dessus). Si le résultat est 1, le transfert IP est activé.
La prochaine chose à faire est d’essayer d’utiliser traceroute ou tracepath pour voir comment les paquets ICMP sont routés entre le Point de terminaison A et le Point de terminaison B. Si nous exécutons tracepath 192.168.200.22 (l’adresse IP du Point de terminaison B), nous pourrions voir un résultat comme celui-ci :
$ tracepath 192.168.200.22
1?: [LOCALHOST] pmtu 1500
1: 192.168.1.1 0.411ms
2: no reply
3: no reply
4: no reply
...
Le résultat ci-dessus indique que nos paquets ICMP du Point de terminaison A n’ont atteint qu’Hôte α. Ce que nous devrions voir est quelque chose comme ceci :
$ tracepath 192.168.200.22
1?: [LOCALHOST] pmtu 1500
1: 192.168.1.1 0.411ms
2: 10.0.0.2 3.832ms pmtu 1420
3: 192.168.200.22 0.390ms reached
Resume: pmtu 1420 hops 3 back 3
Le-dessus indique que nos paquets ICMP ont atteint le Point de terminaison B et sont revenus.
Si les paquets ne parviennent jamais même à l’Hôte α, cela signifie probablement que vous devez travailler sur les règles de routage pour le Site A (voir la section Configurer le Routage ci-dessus). Si les paquets s’arrêtent à l’Hôte α, c’est probablement soit que le tunnel de l’Hôte α vers l’Hôte β n’a pas été configuré avec succès, soit que les règles de pare-feu de l’Hôte β bloquent les paquets. Si les paquets s’arrêtent à l’Hôte β, cela peut être dû soit aux règles de routage du Site B, soit à un pare-feu entre l’Hôte β et le Point de terminaison B.
Si vous utilisez iptables sur vos hôtes WireGuard, vous pouvez vérifier les règles de pare-feu actives des hôtes en exécutant sudo iptables-save (voir la section Supplémentaire : Configurer le Pare-feu ci-dessus).
Voici le texte corrigé :
Pour quelques suggestions de règles iptables. Si vous utilisez nftables, vous pouvez obtenir une liste similaire via sudo nft list ruleset. Si vous ne voyez rien d’un des commandes, cela signifie que vous n’avez pas de pare-feu configuré ; si vous voyez une erreur, il est probable que vous n’ayez pas installé iptables ou nftables.
Si tout sur l’Hôte α et l’Hôte β semble correct, mais les paquets semblent toujours s’arrêter à l’Hôte α, vous avez probablement d’autres règles de pare-feu ou une configuration réseau bloquant le tunnel WireGuard lui-même. Essayez d’exécuter sudo wg sur les deux Hôtes α et β pour voir si l’interface WireGuard sur les deux est active et configurée comme prévu.
Sur l’Hôte β, vous verrez probablement une sortie similaire à celle-ci :
$ sudo wg
interface: wg0
public key: fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
private key: (hidden)
listening port: 51822
peer: /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
allowed ips: 192.168.1.0/24
Si le Hôte α s’est connecté avec succès au Hôte β, la fenêtre d’affichage du Hôte β inclurait un champ “dernier échange de clés” sous la ligne de pair, ainsi qu’un champ “transfert” indiquant que des données ont été reçues. La sortie ci-dessus indique que le Hôte α n’a pas encore réussi à se connecter.
Sur le Hôte α, vous verrez probablement une sortie comme celle-ci :
$ sudo wg
interface: wg0
public key : /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
private key : (masquée)
listening port : 51821
peer: fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
endpoint : 203.0.113.2:51822
allowed ips : 192.168.200.0/24
transfer : 0 B received, 123 B sent
Si le champ “transfer” indique que des données ont été envoyées au Hôte β, mais aucune n’a été reçue (comme c’est le cas ci-dessus), cela signifie probablement que les paquets sont bloqués ou mal dirigés quelque part entre le Hôte α et le Hôte β avant que les hôtes ne puissent configurer le tunnel WireGuard. Si ce est le cas pour vous, vous devez ajuster vos pare-feux ou d’autres configurations réseau jusqu’à ce qu’ils permettent au Hôte α d’envoyer des paquets UDP au Hôte β via l’adresse IP et le port configurés dans la configuration Peer.Endpoint du Hôte α (dans cet exemple, c’est 203.0.113.2:51822), et vice versa.
Extra : Configurer le Pare-feu
Si vous avez déjà des règles de pare-feu de base pour le trafic transféré configurées sur vos hôtes WireGuard, il n’y a rien d’autre à faire pour votre configuration WireGuard. Cependant, si vous ne disposez pas encore de règles de base en place, voici quelques règles simples iptables que vous pouvez utiliser pour rejeter le trafic WireGuard inattendu qui accède aux sockets locales sur les hôtes WireGuard eux-mêmes, et pour rejeter tout trafic WireGuard qui est transféré vers des destinations inattendues dans vos sites.
Je vais examiner ces règles en utilisant Site B comme exemple, où pour l’instant nous voulons bloquer tout le trafic WireGuard à l’exception du port 80 sur Endpoint B. Vous pouvez appliquer des règles similaires à Site A (en ajoutant des règles supplémentaires --state NEW pour chaque service du site que vous souhaitez permettre à l’autre site d’initier un accès).
D’abord, arrêtez l’interface WireGuard sur le Hôte β avec wg-quick ou systemctl :
$ sudo wg-quick down /etc/wireguard/wg0.conf
$ # ou alternativement :
$ sudo systemctl stop wg-quick@wg0.service
Ensuite, éditez le fichier /etc/wireguard/wg0.conf pour ajouter plusieurs nouveaux paramètres Interface.PreUp et Interface.PostDown, comme suit :
# /etc/wireguard/wg0.conf
# paramètres locaux pour le Hôte β
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822
# transfert IP
PreUp = sysctl -w net.ipv4.ip_forward=1
# pare-feu local pour le Hôte β contre les pairs wg
PreUp = iptables -A INPUT -i wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
PreUp = iptables -A INPUT -i wg0 -p udp --dport 80 -j ACCEPT
PreUp = iptables -A INPUT -i wg0 -j DROP
# pare-feu local pour le Hôte β contre les transferts IP
PreDown = iptables -D INPUT -i wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
PreDown = iptables -D INPUT -i wg0 -p udp --dport 80 -j ACCEPT
PreDown = iptables -D INPUT -i wg0 -j DROP
Ces règles permettent d’accepter les paquets WireGuard établis et en cours de transfert, ainsi que les paquets UDP sur le port 80, tout en bloquant tous les autres paquets entrants via l’interface wg0. Assurez-vous de tester ces règles après avoir appliqué les modifications pour vous assurer qu’elles fonctionnent comme prévu.
ELATED -j ACCEPT
PreUp = iptables -A INPUT -i wg0 -j REJECT
PostDown = iptables -D INPUT -i wg0 -m state –state ESTABLISHED,RELATED -j ACCEPT
PostDown = iptables -D INPUT -i wg0 -j REJECT
pare-feu d’autres hôtes contre les pairs wg
PreUp = iptables -A FORWARD -i wg0 -m state –state ESTABLISHED,RELATED -j ACCEPT
PreUp = iptables -A FORWARD -i wg0 -m state –state NEW -d 192.168.200.22 -p tcp –dport 80 -j ACCEPT
PreUp = iptables -A FORWARD -i wg0 -j REJECT
PostDown = iptables -D FORWARD -i wg0 -m state –state ESTABLISHED,RELATED -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -m state –state NEW -d 192.168.200.22 -p tcp –dport 80 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j REJECT
ajuster la taille maximale des segments (MSS) des connexions TCP transférées aux pairs wg
PreUp = iptables -t mangle -A FORWARD -o wg0 -p tcp –tcp-flags SYN,RST SYN -j TCPMSS –clamp-mss-to-pmtu
PostDown = iptables -t mangle -D FORWARD -o wg0 -p tcp –tcp-flags SYN,RST SYN -j TCPMSS –clamp-mss-to-pmtu
paramètres distants pour l’Hôte α
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
Endpoint = 198.51.100.1:51821
AllowedIPs = 192.168.1.0/24
$ sudo wg-quick up /etc/wireguard/wg0.conf
$ # ou alternativement :
$ sudo systemctl start wg-quick@wg0.service
Cette configuration mise à jour entraînera wg-quick sur l’Hôte β à ajouter six nouvelles règles iptables avant de mettre en route l’interface WireGuard, et à les supprimer après avoir arrêté l’interface.
Les deux premières règles (ajoutées à la chaîne INPUT) s’appliquent au trafic destiné à l’Hôte β lui-même :
iptables -A INPUT -i wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i wg0 -j REJECT
La première règle acceptera tous les paquets pour les connexions déjà établies (c’est-à-dire les connexions que l’Hôte β a initiées) entrant via le tunnel WireGuard ; et la deuxième règle rejetera tout autre chose entrant via le tunnel destiné à l’Hôte β.
Les trois règles du milieu (ajoutées à la chaîne FORWARD) s’appliquent au trafic transmis par l’Hôte β aux points de terminaison dans le Site B :
iptables -A FORWARD -i wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i wg0 -m state --state NEW -d 192.168.200.22 -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -i wg0 -j REJECT
Comme les règles pour la chaîne INPUT, les deux premières et la troisième des règles pour la chaîne FORWARD permettent les connexions déjà établies, mais rejettent les nouvelles connexions.
Cependant, la deuxième règle permettra de transmettre de nouvelles connexions TCP vers le port 80 du Point de terminaison B (192.168.200.22 dans le Site B). Si vous souhaitez autoriser l’accès à un autre port du Point de terminaison B que le port 80 (comme 8080), spécifiez ce port au lieu de 80. Si vous souhaitez autoriser l’accès à plusieurs ports du Point de terminaison B, ajustez la règle légèrement pour utiliser la directive multiport avec l’indicateur --dports (notez le s en fin de --dports) — comme, par exemple, pour permettre les ports 80 et 443 :
iptables -A FORWARD -i wg0 -m state --state NEW -d 192.168.200.22 -p tcp -m multiport --dports 80,443 -j ACCEPT
La règle finale (ajoutée à la chaîne FORWARD de la table mangle) s’applique au trafic transmis sortant du Hôte β depuis les points de terminaison du Site B :
iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Elle ajuste automatiquement l’option MSS (Maximum Segment Size) des paquets TCP SYN et SYN-ACK transmis sortants via sa interface WireGuard, en tenant compte de la taille inférieure de l’MTU (Maximum Transmission Unit) de l’interface. Cela aide les points de terminaison du Site A, à l’autre bout des connexions TCP, à optimiser la taille des paquets qu’ils envoient au Site B, évitant ainsi la fragmentation des paquets.
Chaque fois que vous modifiez ces règles, assurez-vous d’ajouter les nouvelles règles avant de supprimer les anciennes.
Vous devez faire le même changement dans les paramètres PreUp et leur correspondant PostDown (les règles PreUp et PostDown devraient être identiques, sauf qu’il faut utiliser un indicateur -A pour PreUp et -D pour PostDown). Et si vous utilisez des adresses IPv6 dans votre VPN WireGuard, remplacez la commande ip6tables par iptables dans tout ce qui précède.
Notez également que lorsque vous travaillez avec les paramètres PreUp et PostDown, il est préférable de désactiver d’abord l’interface, apporter vos modifications de configuration, puis la réactiver (au lieu de modifier les paramètres de configuration alors que l’interface est toujours active, puis essayer de les redémarrer plus tard). La raison en est que la plupart du temps, vos paramètres “Up” et “Down” sont conçus pour être symétriques (comme ajouter une règle de pare-feu avec PreUp et la supprimer avec PostDown) — donc si vous modifiez une règle PostDown alors que votre interface WireGuard est toujours en cours d’exécution, vous pourriez laisser accidentellement une règle de pare-feu erronée en place à partir de la version précédente de la configuration (que vous devrez rechercher et nettoyer manuellement).
Pour des conseils sur la façon de configurer un pare-feu iptables dans un scénario plus complexe de site à site, consultez la section “Site à Site” du guide “Contrôle d’accès avec WireGuard et iptables”.
Pour utiliser UFW pour configurer un pare-feu similaire au pare-feu décrit dans cet article, consultez la section “Site à Site” du guide “Utiliser WireGuard avec UFW” ; pour utiliser firewalld, consultez la section “Site à Site” du guide “Utiliser WireGuard avec Firewalld” ; ou pour utiliser nftables, consultez la section “Site à Site” du guide “Utiliser WireGuard avec Nftables”.
15/12/2020
par Justin Ludwig
by Justin Ludwig translated by: Patrice Le Guyader