Wireguard configuration Hub et Spoke
|
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 |
Wireguard configuration Hub et Spoke
Introduction
Cet article explique comment configurer trois peers WireGuard dans une topologie Hub and Spoke. Il s’agit de la configuration que vous utiliseriez lorsque vous souhaitez connecter deux points de terminaison exécutant WireGuard, mais les deux points de terminaison sont derrière un NAT (traduction d’adresse réseau) restrictif ou des pare-feu qui ne permettent pas à l’un des points de terminaison d’accepter de nouvelles connexions de l’autre. Cela nécessite l’utilisation d’un troisième hôte WireGuard (un hub) qui peut accepter de nouvelles connexions à partir des deux points de terminaison (les spokes).
Dans le scénario spécifique que je couvrirai pour cet article, nous aurons un poste de travail d’utilisateur final, que j’appellerai “Endpoint A”, sur un LAN (Local Area Network); et un serveur HTTP écoutant sur le port 80, que j’appellerai “Endpoint B”, sur un autre; et un troisième hôte, le concentrateur, que j’appellerai “Hôte C”, sur un troisième LAN ; avec Internet entre chacun d’eux. Le point de terminaison A et le point de terminaison B sont tous deux derrière le NAT et les pare-feu qui n’autorisent que les connexions établies. L’hôte C est également derrière NAT et un pare-feu, mais son pare-feu NAT + permet de transférer le port 51823 d’Internet vers l’hôte C. Nous utiliserons ce port, 51823, pour WireGuard sur l’hôte C.
Dans cet article, nous allons installer WireGuard sur chaque hôte et créer un tunnel WireGuard entre chaque rayon et le concentrateur. Dans le VPN WireGuard (réseau privé virtuel) que nous allons créer, nous allons définir le point de terminaison A pour utiliser une adresse IP de 10.0.0.1, le point de terminaison B sur une adresse IP de 10.0.0.2 et l’hôte C sur 10.0.0.3. Une fois que WireGuard est configuré et exécuté sur les trois hôtes, un utilisateur utilisant le point de terminaison A pourra accéder au serveur HTTP écoutant sur le port 80 du point de terminaison B simplement en accédant à http://10.0.0.2/ dans son navigateur Web.
Installer Wireguard
Installez WireGuard sur le point d’extrémité A, le point d’extrémité B et l’hôte C en suivant les instructions d’installation pour la plate-forme appropriée sur la page d’installation de WireGuard. Vous pouvez vérifier que vous avez installé WireGuard avec succès en exécutant wg help sur chaque hôte.
Générer les clefs Wireguard
Ensuite, générez trois 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 clé WireGuard (également appelée « paire de clés ») est composée de deux parties, la « clé privée » (également appelée comme “clé secrète”), et la “clé publique”. La magie de ce type de crypto (connu sous le nom de «cryptographie à clé publique») est qu’il 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 savez est la clé publique.
Bien que vous n’ayez pas à générer les clés sur les hôtes, générer une clé d’hôte sur l’hôte lui-même est souvent le meilleur moyen de sécuriser sa clé privée - de cette façon, la clé privée ne quitte jamais l’hôte. Si vous générez vos clés en dehors 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 du secret des clés privées.
Exécutez les commandes suivantes pour générer une nouvelle 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 une nouvelle paire de clés pour Endpoint B
$ wg genkey > endpoint-b.key
$ wg pubkey < endpoint-b.key > endpoint-b.pub
Et des commandes similaires pour générer une nouvelle 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 chacun sera de 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 réellement besoin de conserver ces fichiers - le contenu de chacun sera utilisé dans les fichiers de configuration WireGuard que nous construisons pour les différents hôtes dans les sections suivantes. La clé privée d’un hôte se trouve dans le propre fichier de configuration de l’hôte ; et sa clé publique va dans le fichier de configuration de tous les autres hôtes auxquels vous souhaitez vous connecter. Chaque extrémité d’une connexion doit être préconfigurée avec la clé publique de l’autre extrémité pour que WireGuard puisse établir la connexion.
Avec une topologie Hub and Spoke, cela signifie que le concentrateur, l’hôte C, doit être configuré avec la clé publique de chaque rayon ; tandis que les rayons, Endpoint A et Endpoint B, doivent uniquement être configurés avec la clé publique du hub.
Configurer wireguard sur le serveur C
Configurons maintenant l’hôte C (le concentrateur). Sur l’hôte C, créez un nouveau fichier dans /etc/wireguard/wg0.conf avec le contenu suivant :
# /etc/wireguard/wg0.conf
# local settings for Host C
[Interface]
PrivateKey = CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCGA=
Address = 10.0.0.3/32
ListenPort = 51823
# remote settings for Endpoint A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32
# remote settings for Endpoint B
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
AllowedIPs = 10.0.0.2/32
Définissez le propriétaire du fichier sur root et ses autorisations sur 600 (le propriétaire peut lire + écrire ; tout le monde se voit refuser l’accès - le fichier contient la clé privée de l’hôte, qui doit être gardée secrète).
Passons en revue la configuration, paramètre par paramètre :
Interface.PrivateKey Il s’agit de 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 secrète et c’est le seul endroit où elle doit résider.
Interface.Address Il s’agit de 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 l’adresse de votre choix pour cela, mais l’adresse doit se trouver dans l’espace d’adressage IPv4 “Private-Use” ou “Unique-Local” IPv6 (comme 10.0.0.0/8 - voir RFC 6890 pour tous les blocs d’adresses disponibles), et ne doit pas entrer en collision avec d’autres sous-réseaux privés auxquels le point de terminaison lui-même ou l’un de ses pairs peut se connecter.
Avec une topologie Hub and Spoke, vous décidez généralement d’un seul bloc d’adresses IP à utiliser pour l’ensemble du VPN WireGuard et attribuez à chaque pair une adresse IP à partir de ce bloc. Vous utiliserez ce bloc comme paramètre Peer.AllowedIPs dans le fichier de configuration pour chaque rayon (abordé dans les sections suivantes). Dans ce scénario, nous allons utiliser le bloc 10.0.0.0/24, nous avons donc choisi une adresse dans ce bloc (10.0.0.3) pour le concentrateur, et c’est ce que nous avons mis dans le paramètre Interface.Address du concentrateur. .
Notez que ce paramètre n’est pas utilisé directement par WireGuard - il n’est utilisé que par le service d’assistance wg-quick lorsqu’il configure une interface réseau virtuelle pour WireGuard. Pour que les paquets réseau soient correctement acheminés vers et depuis cet hôte lorsqu’ils se trouvent en dehors du tunnel WireGuard, ils doivent utiliser l’adresse IP que vous avez définie ici.
Bien que vous puissiez configurer plusieurs adresses IP pour ce paramètre, à moins que vous n’ayez un cas d’utilisation particulier, vous ne devez utiliser qu’une seule adresse IP (sous la forme d’un bloc /32 avec une adresse IPv4 ou d’un bloc /64 avec une adresse IPv6 adresse).
Interface.ListenPort Il s’agit du port WireGuard de l’hôte C. L’hôte C doit pouvoir recevoir le trafic UDP pour les nouvelles connexions sur ce port depuis Internet (ou d’où provient le trafic des autres pairs WireGuard avec lesquels il communiquera).
Avec une topologie Hub and Spoke, ce paramètre dans le fichier de configuration de l’hôte C doit correspondre au port dans le paramètre Peer.Endpoint du fichier de configuration de chaque point de terminaison (traité dans les sections suivantes).
Peer[0].PublicKey Il s’agit de la clé publique du Endpoint A — remplacez cette valeur par la clé publique réelle que vous avez générée pour le Endpoint A. Cette valeur n’est pas secrète ; cependant, il s’agit d’un identifiant unique au monde pour Endpoint A.
Peer[0].AllowedIPs Il s’agit de l’adresse IP du point de terminaison A dans le VPN WireGuard que nous construisons. Remplacez cette valeur par une valeur adaptée à votre réseau.
Avec une topologie Hub and Spoke, vous choisissez généralement une valeur pour cette adresse dans le même bloc que Interface.Address du hub, comme décrit ci-dessus. Et ce paramètre Peer.AllowedIPs pour le point de terminaison A dans le fichier de configuration du concentrateur doit correspondre exactement au paramètre Interface.Address dans le fichier de configuration du point de terminaison A (abordé dans une section suivante).
Bien que vous puissiez configurer plusieurs adresses IP pour ce paramètre, à moins que vous n’ayez un cas d’utilisation particulier, vous ne devez utiliser qu’une seule adresse IP (sous la forme d’un bloc /32 avec une adresse IPv4 ou d’un bloc /64 avec une adresse IPv6 adresse).
Peer[1].PublicKey Il s’agit de la clé publique du point de terminaison B — remplacez cette valeur par la clé publique réelle que vous avez générée pour le point de terminaison B. Cette valeur n’est pas secrète ; cependant, il s’agit d’un identifiant unique au monde pour Endpoint B.
Peer[1].AllowedIPs Il s’agit de l’adresse IP du point de terminaison B dans le VPN WireGuard que nous construisons. Remplacez cette valeur par une valeur adaptée à votre réseau.
Avec une topologie Hub and Spoke, vous choisissez généralement une valeur pour cette adresse dans le même bloc que Interface.Address du hub, comme décrit ci-dessus. Et ce paramètre Peer.AllowedIPs pour Endpoint B dans le fichier de configuration du concentrateur doit correspondre exactement au paramètre Interface.Address dans le fichier de configuration Endpoint B (traité dans une section suivante).
Bien que vous puissiez configurer plusieurs adresses IP pour ce paramètre, à moins que vous n’ayez un cas d’utilisation particulier, vous ne devez utiliser qu’une seule adresse IP (sous la forme d’un bloc /32 avec une adresse IPv4 ou d’un bloc /64 avec une adresse IPv6 adresse).
Configurer le routage sur l’hôte C
Si vous avez déjà configuré l’hôte C pour l’utiliser comme routeur, vous n’avez rien à faire de plus pour WireGuard ; passez simplement à la section suivante.
Sinon, pour un hôte Linux, vous devez activer le transfert IP. Il existe plusieurs façons de le faire, mais un moyen pratique avec le service wg-quick que nous utiliserons est de l’activer lorsque l’interface WireGuard est affichée. Mettez à jour le fichier /etc/wireguard/wg0.conf sur l’hôte C pour y ajouter un paramètre Interface.PreUp comme suit :
# /etc/wireguard/wg0.conf
# local settings for Host C
[Interface]
PrivateKey = CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCGA=
Address = 10.0.0.3/32
ListenPort = 51823
PreUp = sysctl -w net.ipv4.ip_forward=1
# remote settings for Endpoint A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32
# remote settings for Endpoint B
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
AllowedIPs = 10.0.0.2/32
Si vous utilisez des adresses IPv6 pour votre VPN WireGuard, utilisez plutôt ce paramètre :
PreUp = sysctl -w net.ipv6.conf.all.forwarding=1
Notez que le transfert IP est un paramètre potentiellement dangereux à activer si vous n’avez pas de règles de pare-feu appropriées en place devant l’hôte (ou dans le cadre du propre pare-feu de l’hôte) - avec lui, l’hôte essaiera aveuglément de transférer sur tous les paquets qu’il reçoit et qui sont destinés à d’autres hôtes (permettant à un acteur malveillant disposant d’un accès réseau à l’hôte d’accéder à tous les autres hôtes auxquels l’hôte lui-même peut accéder).
Configurer wireguard sur le endpoint A
Configurons maintenant le point de terminaison A (le rayon “client”). Sur Endpoint A, créez un nouveau fichier dans /etc/wireguard/wg0.conf avec le contenu suivant :
# /etc/wireguard/wg0.conf
# local settings for Endpoint A
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51821
# remote settings for Host 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 autorisations sur 600 (le propriétaire peut lire + écrire ; tout le monde se voit refuser 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 Il s’agit de 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 le seul endroit où elle doit résider. Interface.Adresse Il s’agit de l’adresse IP du point de terminaison A dans le VPN WireGuard que nous construisons. Remplacez cette valeur par une valeur adaptée à votre réseau.
Avec une topologie Hub and Spoke, ce paramètre dans le fichier de configuration du point de terminaison A doit correspondre exactement au paramètre Peer.AllowedIPs pour le point de terminaison A dans le fichier de configuration du concentrateur (abordé dans une section précédente).
Interface.ListenPort Il s’agit du port WireGuard du point de terminaison A. Le point de terminaison A doit être en mesure de recevoir le trafic UDP pour les connexions établies sur ce port à partir d’Internet (ou de l’endroit d’où provient le trafic de l’hôte C).
Si vous omettez ce paramètre, WireGuard sélectionnera un nouveau port aléatoire et inutilisé dans la plage de ports éphémères du système d’exploitation (qui peut aller de 1024 à 65535, selon le système d’exploitation) à chaque démarrage.
Peer.PublicKey Il s’agit de 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, il s’agit d’un identifiant global unique pour l’hôte C.
Peer.Endpoint Il s’agit de l’adresse IP publique (et du port) de l’hôte C - l’adresse IP et le port que le point de terminaison A utilisera pour se connecter via Internet à l’hôte C pour configurer le tunnel WireGuard. Remplacez cette valeur par l’adresse IP réelle que vous utiliseriez normalement pour vous connecter à l’hôte C à partir du point de terminaison A (et suffixez-la avec le port WireGuard réel que vous utiliserez pour l’hôte C).
L’hôte C doit être en mesure d’accepter de nouvelles connexions UDP à partir d’Internet à cette adresse et à ce port ; et le point de terminaison A doit pouvoir lui envoyer du trafic UDP sur Internet à cette adresse et à ce port.
Peer.AllowedIPs Il s’agit du bloc d’adresses que l’hôte C acheminera vers le point de terminaison A à 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. Puisque nous voulons que le point de terminaison A puisse se connecter au point de terminaison B, il est important que ce bloc inclue l’adresse IP que nous avons configurée pour le point de terminaison B dans la configuration WireGuard de l’hôte C (discutée dans une section précédente), qui était 10.0.0.2. Si le point de terminaison B était le seul hôte auquel nous voulions nous connecter depuis le point de terminaison A dans ce VPN WireGuard, nous pourrions simplement définir ce bloc sur 10.0.0.2/32.
Configurer Wireguard sur le endpoint B
Configurons maintenant Endpoint B (le “serveur” rayon). Sur Endpoint B, créez un nouveau fichier dans /etc/wireguard/wg0.conf avec le contenu suivant :
# /etc/wireguard/wg0.conf
# local settings for Endpoint B
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822
# remote settings for 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 sur root et ses autorisations sur 600 (le propriétaire peut lire + écrire ; tout le monde se voit refuser 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 Il s’agit de la clé privée du Endpoint B - remplacez cette valeur par la clé privée réelle que vous avez générée pour le Endpoint B. Cette valeur est secrète et c’est le seul endroit où elle doit résider.
Interface.Adresse Il s’agit de l’adresse IP du point de terminaison B dans le VPN WireGuard que nous construisons. Remplacez cette valeur par une valeur adaptée à votre réseau.
Avec une topologie Hub and Spoke, ce paramètre dans le fichier de configuration du point de terminaison B doit correspondre exactement au paramètre Peer.AllowedIPs pour le point de terminaison B dans le fichier de configuration du concentrateur (abordé dans une section précédente).
Interface.ListenPort Il s’agit du port WireGuard de l’Endpoint B. Le point de terminaison B doit être en mesure de recevoir le trafic UDP pour les connexions établies sur ce port à partir d’Internet (ou de l’endroit d’où provient le trafic de l’hôte C).
Si vous omettez ce paramètre, WireGuard sélectionnera un nouveau port aléatoire et inutilisé dans la plage de ports éphémères du système d’exploitation (qui peut aller de 1024 à 65535, selon le système d’exploitation) à chaque démarrage.
Peer.PublicKey Il s’agit de 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, il s’agit d’un identifiant global unique pour l’hôte C.
Peer.Endpoint Il s’agit de l’adresse IP publique (et du port) de l’Hôte C - l’adresse IP et le port que le Point de terminaison B utilisera pour se connecter via Internet à l’Hôte C afin de configurer le tunnel WireGuard. Remplacez cette valeur par l’adresse IP réelle que vous utiliseriez normalement pour vous connecter à l’hôte C à partir du point de terminaison B (et suffixez-la avec le port WireGuard réel que vous utiliserez pour l’hôte C).
L’hôte C doit être en mesure d’accepter de nouvelles connexions UDP à partir d’Internet à cette adresse et à ce port ; et le point de terminaison B doit pouvoir lui envoyer du trafic UDP sur Internet à cette adresse et à ce port.
Peer.AllowedIPs Il s’agit du bloc d’adresses que l’hôte C acheminera vers le point de terminaison 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. Puisque nous voulons que le point de terminaison B puisse se reconnecter au point de terminaison A, il est important que ce bloc inclue l’adresse IP que nous avons configurée pour le point de terminaison A dans la configuration WireGuard de l’hôte C (discutée dans une section précédente), qui était 10.0.0.1. Si le point de terminaison A était le seul point de terminaison auquel nous voulions nous connecter depuis le point de terminaison B dans ce VPN WireGuard, nous pourrions simplement définir ce bloc sur 10.0.0.1/32.
Peer.PersistentKeepalive Il s’agit du nombre de secondes entre lesquelles WireGuard enverra des paquets keepalive du point de terminaison B à l’hôte C. S’il est défini sur un nombre différent de zéro, dès que l’interface WireGuard est mise en place, WireGuard commencera à essayer d’envoyer des paquets keepalive à l’hôte C ; s’il est défini sur 0 (valeur par défaut), WireGuard n’enverra aucun paquet keepalive à l’hôte C.
Ce mécanisme ouvre de manière proactive une nouvelle connexion via les pare-feu entre le point de terminaison B et l’hôte C, et la maintient établie, de sorte que l’hôte C puisse transférer le trafic arbitraire du point de terminaison B (sous la forme de requêtes HTTP) à partir du point de terminaison A. Sans cela , le trafic initié par le point de terminaison A et acheminé via l’hôte C serait bloqué par des règles de pare-feu qui n’autorisent que les connexions établies via le point de terminaison B.
Mise en marche de Wireguard
Sur chaque hôte (hôte C et point de terminaison A et point de terminaison B), démarrez le service wg-quick. Sous 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 plutôt cette commande :
$ sudo wg-quick up /etc/wireguard/wg0.conf
Dans tous les cas, le démarrage du service wg-quick configurera une interface réseau WireGuard nommée wg0 sur l’hôte et configurera certaines règles de routage pour acheminer les paquets destinés à n’importe quelle adresse IP répertoriée dans le(s) paramètre(s) Peer.AllowedIPs du /etc /wireguard/wg0.conf pour sortir de l’interface wg0.
Notez que le nom wg0 n’est que 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 pouvez 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é wg-quick up directement sur l’hôte C, vous verrez une sortie comme 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 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 ceci :
$ journalctl -u wg-quick@wg0.service
systemd[1]: Starting WireGuard via wg-quick(8) for 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]: Started WireGuard via wg-quick(8) for 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 à portée de main, un substitut très simple consiste à utiliser le module http.server de Python 3, comme suit, exécuté 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 n’importe quel port au-dessus de 1023 (comme le port 8080) :
$ python3 -m http.server 8080
Le module http.server servira la liste des répertoires et des fichiers dans votre répertoire actuel. Une version un peu plus sûre consiste à créer un répertoire vide dans votre répertoire actuel et à le servir à la place :
$ mkdir dummydir && cd dummydir
$ python3 -m http.server 8080
Sur le point de terminaison A, utilisez curl (ou un navigateur standard) pour demander une page au serveur Web s’exécutant sur le port 80 du point de terminaison B :
$ curl 10.0.0.2
Ou si le serveur Web s’exécute sur le port 8080 (ou un autre port), spécifiez explicitement ce port :
$ curl 10.0.0.2:8080
Si vous voyez une sortie HTML de cela, vos tunnels WireGuard fonctionnent !
Dépannage de base
Si curl se bloque ou si vous voyez une erreur telle que Connexion refusée ou Aucune route vers l’hôte, vous avez peut-être oublié d’activer le transfert IP pour l’hôte C. Exécutez cette commande sur l’hôte C pour vérifier :
$ 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 (voir 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 une autre configuration réseau bloquant la configuration du tunnel WireGuard lui-même ou bloquant les paquets d’un côté du tunnel ou de l’autre. Mais d’abord, essayez d’exécuter sudo wg sur les trois hôtes, pour vérifier que l’interface WireGuard sur les trois est opérationnelle et configurée comme prévu.
Sur l’hôte C, vous verrez probablement une sortie comme 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’était connecté avec succès, cet affichage inclurait un champ “dernière prise de contact” pour le pair, ainsi qu’un champ “transfert” indiquant que certaines données avaient été reçues. La sortie ci-dessus indique que ni le point de terminaison A ni le point de terminaison B ne se sont encore connectés avec succès.
Sur le point de terminaison A, vous verrez probablement une sortie comme celle-ci :
$ sudo wg
interface: wg0
public key: /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
private key: (hidden)
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 Endpoint B, vous verrez probablement une sortie comme 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 certaines données ont été envoyées à un pair, mais qu’aucune n’a été reçue (comme c’est le cas pour le point de terminaison A et le point de terminaison B ci-dessus), cela signifie que WireGuard a tenté d’envoyer des paquets au pair, mais n’a rien obtenu en retour. Si tel est le cas pour vous, vous devez jouer avec vos pare-feu ou toute autre configuration réseau jusqu’à ce qu’ils permettent au point de terminaison A d’envoyer des paquets UDP à l’hôte C via l’adresse IP et le port configurés dans le paramètre Peer.Endpoint du point de terminaison A (dans cet exemple, c’est 192.0.2.3:51823); et de même pour Endpoint B.
Extra : Configurer le pare-feu sur l’hôte C
Si vous avez déjà installé un logiciel de pare-feu sur l’hôte C lui-même, vous n’avez rien d’autre à faire pour votre configuration WireGuard. Vous voudrez peut-être ajouter des règles supplémentaires à votre pare-feu spécifiquement pour restreindre le transfert du trafic WireGuard, mais vous n’êtes pas obligé de 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 le pare-feu à l’origine.
Mais, pour un hôte concentrateur exécutant Linux, comme l’hôte C, si vous n’avez pas déjà configuré de pare-feu sur l’hôte, vous pouvez 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 pour rejeter tout trafic WireGuard devant être transféré vers une destination inattendue.
Sur l’hôte C, vérifiez d’abord les règles iptables que vous avez en place avec cette commande :
$ sudo iptables -L
Si vous obtenez une erreur telle que command not found, vous devez installer iptables. Si vous avez installé iptables, mais qu’aucune règle de pare-feu n’est configurée, vous verrez une sortie comme 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 à la place plusieurs écrans complets de règles répertoriées, vous utilisez probablement un autre outil pour gérer le pare-feu sur l’hôte C, et vous devriez utiliser cet outil au lieu de suivre les étapes suivantes.
À l’étape suivante, désactivez l’interface WireGuard sur l’hôte C avec wg-quick ou systemctl :
$ sudo wg-quick down /etc/wireguard/wg0.conf
$ # or alternately:
$ sudo systemctl stop wg-quick@wg0.service
Modifiez ensuite le fichier /etc/wireguard/wg0.conf pour ajouter plusieurs nouveaux paramètres Interface.PreUp et Interface.PostDown, comme suit :
# /etc/wireguard/wg0.conf
# local settings for Host 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 ESTABLISHED,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
# remote settings for Endpoint A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32
# remote settings for Endpoint B
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
AllowedIPs = 10.0.0.2/32
Puis réactivez l’interface avec wg-quick ou systemctl :
$ sudo wg-quick up /etc/wireguard/wg0.conf
$ # or alternately:
$ sudo systemctl start wg-quick@wg0.service
Cette configuration mise à jour obligera wg-quick sur l’hôte C à ajouter cinq nouvelles règles iptables avant d’afficher l’interface WireGuard, et à supprimer les mêmes règles après l’arrêt de 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 initiées par l’hôte C) passant par le tunnel WireGuard ; et la deuxième règle rejettera tout autre élément 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 transféré entre le point de terminaison A et le point de terminaison B (ou tout autre rayon que vous pouvez 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
Semblables aux règles de la chaîne INPUT, la première et la troisième des règles de la chaîne FORWARD autorisent les connexions déjà établies, mais rejettent les nouvelles connexions.
La deuxième règle, cependant, permettra aux nouvelles connexions TCP d’être transférées 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 port différent du point de terminaison B autre 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 légèrement la règle pour utiliser le multiport. match directive avec l’indicateur –dports (notez le s final dans –dports) — comme, par exemple, pour autoriser 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 d’apporter exactement la même modification au paramètre PreUp et à son paramètre PostDown correspondant (les règles PreUp et PostDown doivent être les mêmes, juste avec un indicateur -A pour PreUp et un indicateur -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 modifiez les paramètres PreUp et PostDown, il est préférable de désactiver d’abord l’interface, d’apporter vos modifications de configuration, puis de réactiver l’interface (plutôt que de modifier la configuration alors que l’interface est toujours en place, puis en essayant de redémarrer par la suite). La raison en est que la plupart du temps, vos paramètres “Up” et “Down” sont censés être symétriques (comme démarrer un service avec PreUp et l’arrêter avec PostDown, ou 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 pouvez laisser par inadvertance un service parasite en cours d’exécution ou une règle de pare-feu en place à partir de la version de configuration précédente (que vous devrez rechercher et nettoyer manuellement).