Configuration d'un hub et d'un spoke avec 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 Hub and Spoke Configuration de Justin Ludwig
{< /admonitionblock >}
WireGuard Hub et Configuration Spoke
Cet article expliquera comment configurer trois pairs de WireGuard dans une topologie Hub and Spoke. C’est la configuration que vous utiliseriez lorsque vous souhaitez connecter deux points de terminaison exécutant WireGuard, mais que les deux points de terminaison sont derrière un NAT restrictif (Network Address Translation) ou des pare-feux qui ne permettent pas à l’un des points de terminaison d’accepter de nouvelles connexions de l’autre. Cela nécessite d’utiliser un troisième hôte WireGuard (un “hub”) qui peut accepter de nouvelles connexions des deux points de terminaison (les “spokes”).
Dans le scénario spécifique que je couvrirai dans cet article, nous aurons une station de travail utilisateur finale, que je nommerai “Point de terminaison A”, sur un réseau local (Local Area Network) ; et un serveur HTTP qui écoute sur le port 80, que je nommerai “Point de terminaison B”, sur un autre; et un troisième hôte, le hub, que je nommerai “Hôte C”, sur un troisième réseau local ; avec Internet entre eux. Le Point de terminaison A et le Point de terminaison B sont tous les deux derrière un NAT et des pare-feux qui permettent uniquement les connexions établies. L’Hôte C est également derrière un NAT et un pare-feu, mais son NAT + pare-feu permet la transmission du port 51823 de l’Internet à Hôte C. Nous utiliserons ce port, 51823, pour WireGuard sur l’Hôte C.
Le diagramme ci-dessous illustre ce scénario :
Dans cet article, nous installerons WireGuard sur chaque hôte et créerons un tunnel WireGuard entre chaque spoke et le hub. À l’intérieur du VPN WireGuard (Virtual Private Network) que nous allons créer, nous configurerons le Point de terminaison A pour utiliser une adresse IP de 10.0.0.1, le Point de terminaison B pour une adresse IP de 10.0.0.2 et l’Hôte C pour 10.0.0.3. Une fois que nous aurons configuré et exécuté WireGuard sur tous les trois hôtes, un utilisateur utilisant le Point de terminaison A pourra accéder au serveur HTTP qui écoute sur le port 80 du Point de terminaison B simplement en naviguant vers http://10.0.0.2/ dans son navigateur web.
Voici la traduction en français :
Ces sont les étapes que nous suivrons :
- Installer WireGuard
- Générer des clés WireGuard
- Configurer WireGuard sur l’Hôte C
- Configurer le routage sur l’Hôte C
- Configurer WireGuard sur le Point de terminaison A
- Configurer WireGuard sur le Point de terminaison B
- Démarrer WireGuard
- Tester les tunnels
- Dépannage de base
- Supplémentaire : Configurer le pare-feu sur l’Hôte C
Installer WireGuard
Installez WireGuard sur les Points de terminaison A, B et l’Hôte C 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 chaque hôte.
Générer des clés WireGuard
Ensuite, générez trois paires de clés WireGuard : une pour le Point de terminaison A, une pour le Point de terminaison B et une pour l’Hôte C. Une paire de clés WireGuard est composée d’une “clé privée” (aussi appelée la “clé secrète”) et d’une “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.
Aisiez la clé privée, mais pratiquement impossible de calculer la clé privée si tout ce que vous savez, c’est la clé publique.
Bien que vous n’ayez pas besoin de générer les clés sur les hôtes, il est souvent le meilleur moyen de garder sa clé privée sécurisée en générant une clé d’hôte sur l’hôte lui-même — ainsi la clé privée ne quitte jamais l’hôte. Si vous générez 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 un nouveau paire de clés pour le Point de terminaison A :
$ wg genkey > endpoint-a.key
$ wg pubkey < endpoint-a.key > endpoint-a.pub
Et les commandes suivantes pour générer un nouveau paire de clés pour le Point de terminaison B :
$ wg genkey > endpoint-b.key
$ wg pubkey < endpoint-b.key > endpoint-b.pub
Et des commandes similaires pour générer un nouveau paire de clés pour l’Hôte C :
$ wg genkey > host-c.key
$ wg pubkey < host-c.key > host-c.pub
Cela générera six fichiers : endpoint-a.key, endpoint-a.pub, endpoint-b.key, endpoint-b.pub, host-c.key et host-c.pub. Les fichiers .key contiennent les clés privées, et les fichiers .pub contiennent les clés publiques. Le contenu de chaque fichier sera 44 caractères de texte encodé en Base64 :
$ cat endpoint-a.key
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
$ cat endpoint-a.pub
/TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
$ cat endpoint-b.key
ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
$ cat endpoint-b.pub
fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
$ cat host-c.key
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCGA=
$ cat host-c.pub
jUd41n3XYa3yXBzyBvWqlLhYgRef5RiBD7jwo70U+Rw=
Vous n’avez pas besoin de conserver ces fichiers — le contenu de chaque fichier sera utilisé dans les fichiers de configuration WireGuard que nous construirons pour les différents hôtes dans les sections suivantes. La clé privée d’un hôte doit être placée dans son propre fichier de configuration ; et sa clé publique doit être placée 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.
Avec une topologie Hub et Spoke, cela signifie que le hub, Host C, doit être configuré avec les clés publiques de chaque spoke ; tandis que les spokes, Endpoint A et Endpoint B, n’ont besoin que d’être configurés avec la clé publique du hub.
Configurer WireGuard sur l’Hôte C
Maintenant, configurons l’Hôte C (le hub). Sur l’Hôte C, créez un nouveau fichier à /etc/wireguard/wg0.conf avec le contenu suivant :
# /etc/wireguard/wg0.conf
# paramètres locaux pour l'Hôte C
[Interface]
PrivateKey = CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCGA=
Address = 10.0.0.3/32
ListenPort = 51823
# paramètres distants pour le Point de terminaison A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32
# paramètres distants pour le Point de terminaison B
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
AllowedIPs = 10.0.0.2/32
Définissez le propriétaire du fichier sur root et ses permissions à 600 (le propriétaire peut lire+écrire ; tout le monde else est refusé l’accès — le fichier contient la clé privée de l’hôte, qui doit être gardée secrète).
Passons à la configuration, paramètre par paramètre :
- Interface.PrivateKey
- C’est la clé privée de l’Hôte C — remplacez cette valeur par la clé privée réelle que vous avez générée pour l’Hôte C. Cette valeur est confidentielle et c’est le seul endroit où elle doit vivre.
- Interface.Address
- C’est l’adresse IP de l’Hôte C à 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 pour cela, mais l’adresse doit être unique dans le sous-réseau du VPN.
sse exactement au paramètre Interface.Address du fichier de configuration d’Endpoint B (discuté dans une section suivante).
Bien que vous puissiez configurer plusieurs adresses IP pour ce paramètre, à moins qu’il n’y ait un cas d’utilisation spécial, vous devriez 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).
pondre exactement au paramètre Interface.Address de la configuration de Endpoint B (discuté dans une section suivante).
Bien que vous puissiez configurer plusieurs adresses IP pour cette option, sauf si vous avez un cas d’utilisation spécial, vous devriez 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).
Configurer le Routage sur Host C
Si vous avez déjà configuré Host C pour qu’il fonctionne comme un routeur, il n’y a rien à faire supplémentaire pour WireGuard ; passez simplement à la section suivante.
Sinon, pour un hôte Linux, vous devez activer le transfert d’IP. Il existe plusieurs façons de le faire, mais une méthode pratique avec le service wg-quick que nous utiliserons est d’activer ce transfert lorsque l’interface WireGuard est mise en ligne. Mettez à jour le fichier /etc/wireguard/wg0.conf sur Host C pour y ajouter un paramètre Interface.PreUp comme suit :
# /etc/wireguard/wg0.conf
# paramètres locaux pour Host C
[Interface]
PrivateKey = CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCGA=
Address = 10.0.0.3/32
ListenPort = 51823
PreUp = sysctl -w net.ipv4.ip_forward=1
# paramètres distants pour Endpoint A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32
# paramètres distants pour Endpoint B
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
AllowedIPs = 10.0.0.2/32
Si vous utilisez des adresses IPv6 pour votre VPN WireGuard, utilisez ce paramètre à la place :
PreUp = sysctl -w net.ipv6.conf.all.forwarding=1
Notez que l’encapsulation IP est un paramètre potentiellement dangereux à activer si vous n’avez pas les règles de pare-feu appropriées en place devant l’hôte (ou comme partie du pare-feu de l’hôte) — avec celui-ci activé, l’hôte essayera de transférer sur n’importe quel paquet qu’il reçoit qui est destiné à d’autres hôtes (ce qui permet à un acteur malveillant ayant accès au réseau de l’hôte d’accéder à tous les autres hôtes que l’hôte peut lui-même accéder).
Configurer WireGuard sur le Point de terminaison A
Maintenant, configurons le Point de terminaison A (le “client” spoke). Sur le Point de terminaison A, créez un nouveau fichier à /etc/wireguard/wg0.conf avec le contenu suivant :
# /etc/wireguard/wg0.conf
# paramètres locaux pour le Point de terminaison A
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51821
# paramètres distants pour l'Hôte C
[Peer]
PublicKey = jUd41n3XYa3yXBzyBvWqlLhYgRef5RiBD7jwo70U+Rw=
Endpoint = 192.0.2.3:51823
AllowedIPs = 10.0.0.0/24
Définissez le propriétaire du fichier sur root et ses permissions à 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).
Passons en revue la configuration, paramètre par paramètre :
- Interface.PrivateKey
- C’est la clé privée du Point de terminaison A — remplacez cette valeur par la clé privée réelle que vous avez générée pour le Point de terminaison A. Cette valeur est secrète et c’est la seule place où elle devrait vivre.
- Interface.Address
- C’est l’adresse IP interne du Point de terminaison A dans le VPN WireGuard que nous construisons — remplacez cette valeur par une valeur appropriée pour votre réseau.
Avec un topologie Hub and Spoke, ce paramètre dans le fichier de configuration du Point de terminaison A doit correspondre exactement au paramètre
Peer.AllowedIPspour le Point de terminaison A dans le fichier de configuration du hub (discuté dans une section précédente). - Interface.ListenPort
- C’est le port WireGuard de l’Endpoint A. L’Endpoint A doit être capable de recevoir du trafic UDP pour les connexions établies sur ce port à partir d’Internet (ou où provient le trafic de l’Hôte C).
Si vous omettez cette configuration, WireGuard sélectionnera un nouveau port aléatoire.
aléatoire et non utilisé dans la plage de ports temporaires du système d’exploitation (qui peut varier de 1024 à 65535 en fonction du système d’exploitation) chaque fois qu’il démarrera.
- Peer.PublicKey
- C’est la clé publique de l’Hôte C — remplacez cette valeur par la clé publique réelle que vous avez générée pour l’Hôte C. Cette valeur n’est pas secrète ; cependant, elle est un identifiant globalment unique pour l’Hôte C.
- Peer.Endpoint
- C’est l’adresse IP et le port public de l’Hôte C — l’adresse IP et le port que l’Endpoint A utilisera pour se connecter à Internet à l’Hôte C afin d’établir le tunnel WireGuard. Remplacez cette valeur par l’adresse IP réelle que vous utiliseriez normalement pour vous connecter à l’Hôte C depuis l’Endpoint A (et ajoutez-y la portée réelle de WireGuard que vous utiliserez pour l’Hôte C).
L’Hôte C doit être capable d’accepter de nouvelles connexions UDP entrantes à partir d’Internet à cette adresse et ce port ; et l’Endpoint A doit être capable d’envoyer du trafic UDP sur Internet à cet endroit et à ce port.
- Peer.AllowedIPs
- C’est le bloc d’adresses que l’Hôte C routera pour l’Endpoint A dans le VPN WireGuard que nous construisons — remplacez cette valeur par une valeur appropriée pour votre réseau.
Dans ce scénario, nous allons utiliser le bloc 10.0.0.0/24. Comme nous voulons que l’Endpoint A puisse se connecter à l’Endpoint B, il est important que ce bloc comprenne l’adresse IP que nous avons configurée pour l’Endpoint B dans la configuration de WireGuard de l’Hôte C (discuté précédemment), qui était 10.0.0.2. Si l’Endpoint B était le seul hôte auquel nous voulions jamais nous connecter à partir de l’Endpoint A dans ce VPN WireGuard, nous pourrions simplement définir ce bloc sur 10.0.0.2/32.
Maintenant configurons Endpoint B (le “serveur” spoke). Sur Endpoint B, créez un nouveau fichier à /etc/wireguard/wg0.conf avec le contenu suivant :
# /etc/wireguard/wg0.conf
# paramètres locaux pour Endpoint B
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822
# paramètres distants pour Host C
[Peer]
PublicKey = jUd41n3XYa3yXBzyBvWqlLhYgRef5RiBD7jwo70U+Rw=
Endpoint = 192.0.2.3:51823
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25
Définissez le propriétaire du fichier à root et ses permissions à 600 (le propriétaire peut lire+écrire ; tout le monde else est refusé l’accès — le fichier contient la clé privée de l’endpoint, qui doit être gardée secrète).
Passons en revue la configuration, paramètre par paramètre :
- Interface.PrivateKey
- C’est la clé privée d’Endpoint B — remplacez cette valeur par la clé privée réelle que vous avez générée pour Endpoint B. Cette valeur est confidentielle et c’est le seul endroit où elle doit vivre.
- Interface.Address
- C’est l’adresse IP de Endpoint B à l’intérieur du VPN WireGuard que nous construisons — remplacez cette valeur par une valeur appropriée pour votre réseau.
Avec un topologie Hub and Spoke, ce paramètre dans le fichier de configuration d’Endpoint B doit correspondre exactement au paramètre Peer.AllowedIPs pour Endpoint B dans le fichier de configuration du hub (discuté dans une section précédente).
- Interface.ListenPort
- C’est le port WireGuard d’Endpoint B. Endpoint B doit être capable de recevoir le trafic UDP entrant pour les connexions établies sur ce port depuis Internet (ou où que le trafic provenant de Host C vienne).
Si vous omettez ce paramètre, WireGuard sélectionnera un nouveau port aléatoire et non utilisé dans la plage des ports temporaires de l’os (qui peut varier de 1024 à 65535, selon le système d’exploitation) chaque fois qu’il démarrera.
- Peer.PublicKey
- C’est la clé publique de Host C — remplacez cette valeur par la clé publique réelle que vous avez générée pour Host C. Cette valeur n’est pas confidentielle ; cependant, elle est un identifiant globalment unique pour Host C.
Peer.Endpoint :
C’est l’adresse IP publique (et le port) de l’Hôte C — l’adresse IP et le port que l’Endpoint B utilisera pour se connecter à Internet à l’Hôte C afin d’établir le tunnel WireGuard. Remplacez cette valeur par l’adresse IP réelle que vous utiliseriez normalement pour vous connecter à l’Hôte C depuis l’Endpoint B (et ajoutez-y le port WireGuard réel que vous utiliserez pour l’Hôte C).
L’Hôte C doit être capable d’accepter de nouvelles connexions UDP entrantes sur Internet à cette adresse et ce port ; et l’Endpoint B doit être capable d’envoyer du trafic UDP sur Internet vers cet hôte à cette adresse et ce port.
- Peer.AllowedIPs
- Ceci est le bloc d’adresses que l’Hôte C routera pour l’Endpoint B à l’intérieur du VPN WireGuard que nous construisons — remplacez cette valeur par une valeur appropriée pour votre réseau.
Dans ce scénario, nous allons utiliser le bloc 10.0.0.0/24. Comme nous voulons que l’Endpoint B puisse se reconnecter à l’Endpoint A, il est important que ce bloc comprenne l’adresse IP que nous avons configurée pour l’Endpoint A dans la configuration WireGuard de l’Hôte C (discuté précédemment), qui était 10.0.0.1. Si l’Endpoint A était le seul endpoint auquel nous voulions nous connecter depuis l’Endpoint B dans ce VPN WireGuard, nous pourrions simplement définir ce bloc à 10.0.0.1/32.
- Peer.PersistentKeepalive
- Ceci est le nombre de secondes entre lesquelles WireGuard enverra des paquets de maintenance de connexion de l’Endpoint B à l’Hôte C. Si défini sur un nombre non nul, dès que l’interface WireGuard sera mise en ligne, WireGuard commencera à essayer d’envoyer des paquets de maintenance de connexion à l’Hôte C ; si défini sur 0 (la valeur par défaut), WireGuard ne renverra pas de paquets de maintenance de connexion à l’Hôte C.
Ce mécanisme ouvre activement une nouvelle connexion à travers les pare-feux entre le Point de terminaison B et l’Hôte C, et la maintient établie afin que l’Hôte C puisse transférer le trafic arbitraire (au format de requêtes HTTP) du Point de terminaison A au Point de terminaison B. Sans cette configuration, le trafic initié par le Point de terminaison A et routé à travers l’Hôte C serait bloqué par les règles de pare-feu qui permettent uniquement des connexions établies à l’Point de terminaison B.
Démarrage de WireGuard
Sur chaque hôte (l’Hôte C, le Point de terminaison A et le Point de terminaison B), 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 AllowedIPs des configurations /etc/wireguard/wg0.conf.
Notez 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éerait une nouvelle interface WireGuard nommée mytunnel.
Mais pour l’instant, si vous avez exécuté directement wg-quick up sur l’Hôte C, 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.3/32 dev wg0
[#] ip link set mtu 8921 up dev wg0
[#] ip -4 route add 10.0.0.2/32 dev wg0
[#] ip -4 route add 10.0.0.1/32 dev wg0
La sortie montre les règles de routage
que wg-quick a configurées automatiquement pour vous.
Si vous avez exécuté systemctl start au lieu de cela, vous pouvez voir le même résultat en utilisant l’outil journalctl, comme suit :
$ journalctl -u wg-quick@wg0.service
systemd[1]: Démarrage de WireGuard via wg-quick(8) pour wg0...
wg-quick[38161]: [#] sysctl -w net.ipv4.ip_forward=1
wg-quick[38228]: net.ipv4.ip_forward = 1
wg-quick[38161]: [#] ip link add wg0 type wireguard
wg-quick[38161]: [#] wg setconf wg0 /dev/fd/63
wg-quick[38161]: [#] ip -4 address add 10.0.0.3/32 dev wg0
wg-quick[38161]: [#] ip link set mtu 8921 up dev wg0
wg-quick[38161]: [#] ip -4 route add 10.0.0.2/32 dev wg0
wg-quick[38161]: [#] ip -4 route add 10.0.0.1/32 dev wg0
systemd[1]: Démarrage de WireGuard via wg-quick(8) pour wg0.
Tester les Tunnels
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 :
$ 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 votre répertoire actuel. Une version légèrement plus sûre de cela est de créer un répertoire vide dans votre répertoire actuel, 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 10.0.0.2
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 10.0.0.2:8080
Si vous voyez une sortie HTML de cette façon, vos tunnels WireGuard fonctionnent !
Dépannage de base
Si curl est suspendu ou que vous voyez une erreur comme Connection refused ou No route to host, vous pourriez avoir oublié d’activer le forwarding IP pour l’Hôte C. Exécutez cette commande sur l’Hôte C 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 sur l’hôte C ci-dessus). Si le résultat est 1, le transfert IP est activé.
Si le transfert IP n’était pas le problème, vous avez probablement des règles de pare-feu ou d’autres configurations réseau qui bloquent soit le tunnel WireGuard lui-même, soit les paquets sur un côté du tunnel ou l’autre. Mais d’abord, essayez d’exécuter sudo wg sur tous les trois hôtes pour vérifier que l’interface WireGuard sur tous les trois est active et fonctionne comme prévu.
Sur l’hôte C, vous verrez probablement une sortie similaire à celle-ci :
$ sudo wg
interface: wg0
public key: jUd41n3XYa3yXBzyBvWqlLhYgRef5RiBD7jwo70U+Rw=
private key: (hidden)
listening port: 51823
peer: /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
allowed ips: 10.0.0.1/32
peer: fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
allowed ips: 10.0.0.2/32
Si un pair s’est connecté avec succès, cette affichage comprendra un champ “dernier échange de clés” pour le pair, ainsi qu’un champ “transfert” indiquant que des données ont été reçues. La sortie ci-dessus indique que ni Endpoint A ni Endpoint B ne sont connectés avec succès encore.
Sur l’Endpoint A, vous verrez probablement une sortie similaire à celle-ci :
$ sudo wg
interface: wg0
public key: /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
private key: (hidden)
listening port: 51823
peer: fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
allowed ips: 10.0.0.2/32
n) listening port: 51821
peer: jUd41n3XYa3yXBzyBvWqlLhYgRef5RiBD7jwo70U+Rw= endpoint: 192.0.2.3:51823 allowed ips: 10.0.0.0/24 transfer: 0 B received, 234 B sent
Et sur l’Endpoint B, vous verrez probablement une sortie similaire à celle-ci :
$ sudo wg
interface: wg0
public key: fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
private key: (hidden)
listening port: 51822
peer: jUd41n3XYa3yXBzyBvWqlLhYgRef5RiBD7jwo70U+Rw=
endpoint: 192.0.2.3:51823
allowed ips: 10.0.0.0/24
transfer: 0 B received, 123 B sent
Si le champ "transfer" indique que des données ont été envoyées à un pair, mais aucune n'a été reçue (comme c'est le cas pour les Points de terminaison A et B ci-dessus), cela signifie que WireGuard a tenté d'envoyer des paquets au pair, mais n'a rien reçu en retour. Si ce est le cas pour vous, vous devez ajuster vos pare-feux ou d'autres configurations réseau jusqu'à ce qu'ils permettent à l'Endpoint A d'envoyer des paquets UDP au Hôte C via l'adresse IP et le port configurés dans la section Peer.Endpoint de l'Endpoint A (dans cet exemple, c'est 192.0.2.3:51823) ; et la même chose pour l'Endpoint B.
## Extra : Configurer le Pare-feu sur le Hôte C
Si vous avez déjà un logiciel de pare-feu configuré sur le Hôte C lui-même, il n'y a rien d'autre à faire pour votre configuration WireGuard. Vous pourriez vouloir ajouter des règles supplémentaires à votre pare-feu spécifiquement pour limiter la transmission du trafic WireGuard, mais vous ne devez pas le faire. Si vous le faites, il est préférable d'ajouter ces règles avec le logiciel que vous avez utilisé pour configurer initialement le pare-feu.
Mais, pour un hôte de hub exécutant Linux comme le Hôte C, si vous n'avez pas déjà un pare-feu configuré sur l'hôte, vous pouvez envisager d'utiliser iptables pour en ajouter un. Il est assez simple de configurer iptables pour rejeter tout trafic WireGuard inattendu entrant dans le hub lui-même, ainsi que tout trafic WireGuard prévoyant d'être transmis à une destination inattendue.
Sur le Hôte C, vérifiez d'abord les règles iptables en place avec cette commande :
```bash
$ sudo iptables -L
Si vous recevez une erreur comme “command not found”, vous devez installer iptables. Si vous avez iptables installé, mais que vous n’avez pas de règles de pare-feu configurées, vous verrez une sortie similaire à celle-ci :
$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Si vous voyez au lieu de cela plusieurs écrans de règles listées, vous utilisez probablement un autre outil pour gérer le pare-feu sur l'Hôte C et devriez utiliser cet outil à la place des étapes suivantes.
Pour la prochaine étape, arrêtez l'interface WireGuard sur l'Hôte C avec wg-quick ou systemctl :
```bash
$ 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 l'Hôte C
[Interface]
PrivateKey = CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCGA=
Address = 10.0.0.3/32
ListenPort = 51823
PreUp = sysctl -w net.ipv4.ip_forward=1
PreUp = iptables -A INPUT -i wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
PreUp = iptables -A INPUT -i wg0 -j REJECT
PreUp = iptables -A FORWARD -i wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
PreUp = iptables -A FORWARD -i wg0 -m state --state NEW -d 10.0.0.2 -p tcp --dport 80 -j ACCEPT
PreUp = iptables -A FORWARD -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
PostDown = iptables -D FORWARD -i wg0 -m state --state ESTABLISHE
D,RELATED -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -m state --state NEW -d 10.0.0.2 -p tcp --dport 80 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j REJECT
# paramètres distants pour le Point de terminaison A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32
# paramètres distants pour le Point de terminaison B
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
AllowedIPs = 10.0.0.2/32
Ensuite, redémarrez l'interface avec `wg-quick` ou `systemctl` :
```bash
$ 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 C d’ajouter cinq nouvelles règles iptables avant de mettre en place l’interface WireGuard et les supprimera 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 C 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 C a initiées) entrant via le tunnel WireGuard ; et la deuxième règle rejetera tout autre chose entrant dans l’Hôte C via le tunnel.
Les trois dernières règles (ajoutées à la chaîne FORWARD) s’appliquent au trafic forwarding entre le Point de terminaison A et le Point de terminaison B (ou n’importe quel autre spoke que vous pourriez ajouter) :
iptables -A FORWARD -i wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i wg0 -m state --state NEW -d 10.0.0.2 -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 de la chaîne FORWARD permettent les connexions déjà établies, mais rejettent les nouvelles connexions.
Cependant, la deuxième règle permettra d’accepter de nouvelles connexions TCP à transférer vers le port 80 du Point de terminaison B (10.0.0.2 dans ce réseau WireGuard). 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 match avec le drapeau --dports (notez le s à la fin de --dports) — par exemple, pour permettre les ports 80 et 443 :
iptables -A FORWARD -i wg0 -m state --state NEW -d 10.0.0.2 -p tcp -m multiport --dports 80,443 -j ACCEPT
Chaque fois que vous apportez des modifications à ces règles, assurez-vous de faire la même modification pour les paramètres PreUp et leur paramètre correspondant PostDown (les règles PreUp et PostDown devraient être les mêmes, simplement avec 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 jouez avec les paramètres PreUp et PostDown, il est généralement meilleur de mettre d’abord l’interface hors ligne, apporter vos modifications de configuration, puis ramener l’interface en ligne à nouveau (au lieu de faire des modifications de configuration alors que l’interface est toujours en ligne, puis essayer de les redémarrer plus tard). La raison est que la plupart du temps, vos paramètres “Up” et “Down” sont conçus pour être symétriques (comme démarrer un service avec PreUp et le fermer avec PostDown, ou ajouter une règle de pare-feu avec PreUp et la supprimer avec PostDown) — donc si vous changez une règle PostDown alors que votre interface WireGuard est toujours en cours d’exécution, vous pourriez accidentellement laisser un service erroné en cours d’exécution ou une règle de pare-feu en place à partir de la version précédente de la configuration (que vous devrez suivre et ne pas modifier).
ettoyer manuellement).
Pour des conseils sur la façon de configurer un pare-feu iptables sous un scénario plus complexe hub-and-spoke, consultez la section “Hub and Spoke” du guide WireGuard Access Control With Iptables.
Pour utiliser UFW pour configurer un pare-feu similaire au pare-feu décrit dans cet article, consultez la section “Hub and Spoke” du guide How to Use WireGuard with UFW. Pour utiliser firewalld, consultez la section “Hub and Spoke” du guide How to Use WireGuard with Firewalld. Ou pour utiliser nftables, consultez la section “Hub and Spoke” du guide How to Use WireGuard With Nftables.
18/11/2020
by Justin Ludwig translated by: Patrice Le Guyader