NOPE LinkedIn

Catégories:
wireguard

Configuration WireGuard Point to Site

Configuration WireGuard Point to Site image

{< 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 Point to Site Configuration de Justin Ludwig

{< /admonitionblock >}

Configuration d’un Point à Site avec WireGuard

Cet article explique comment configurer deux pairs WireGuard dans une topologie Point to Site. C’est la configuration que vous utiliseriez lorsque vous souhaitez connecter un seul point de terminaison exécutant WireGuard à un autre hôte exécutant WireGuard qui peut transmettre des paquets du premier point de terminaison aux autres points de terminaison.

Dans de nombreux cas, cela permet d’accorder à un point de terminaison distant l’accès à un LAN (Réseau local) ; mais vous pouvez également utiliser la même approche pour configurer un point de terminaison pour accéder à un WAN (Réseau large), comme Internet.

Le scénario spécifique que je couvrirai dans cet article implique une station de travail utilisateur exécutant WireGuard, que j’appellerai “Point de terminaison A”, sur un LAN ; et un autre hôte exécutant WireGuard dans un autre LAN, configuré en tant que routeur pour ce LAN. Je l’appellerais “Hôte β”, et son LAN “Site B”. Dans Site B, nous aurons un autre point de terminaison, que j’appellerai “Point de terminaison B”, exécutant un serveur HTTP qui écoute sur le port 80.

L’Internet se trouve entre Point de terminaison A et Site B. Point de terminaison A est derrière NAT (Traduction de Network Address Translation) et un pare-feu qui permet uniquement les connexions établies à travers. Site B est également derrière NAT et un pare-feu, mais son NAT + pare-feu permet le transfert du port 51822 de l’Internet vers Host β. Nous utiliserons ce port, 51822, pour WireGuard sur Host β. Le pare-feu au sein de Site B permet à Host β d’établir de nouvelles connexions avec Point de terminaison B sur le port 80.

Le diagramme ci-dessous illustre ce scénario :

Scénario point-to-site avec Wireguard

En connectant le Point de terminaison A et l’Hôte β dans un VPN WireGuard (Réseau privé virtuel), le Point de terminaison A pourra accéder au serveur HTTP en cours d’exécution sur le Point de terminaison B comme si il était dans le même réseau local que le Point de terminaison B. L’Point de terminaison B a une adresse IP de 192.168.200.22 à l’intérieur du Site B, donc un utilisateur utilisant le Point de terminaison A pourra accéder au serveur HTTP sur le Point de terminaison B simplement en naviguant vers http://192.168.200.22 dans son navigateur web.

Cet article expliquera comment installer et configurer WireGuard sur le Point de terminaison A et l’Hôte β, ainsi que la façon de configurer l’Hôte β pour qu’il puisse transmettre les paquets du Point de terminaison A aux autres points de terminaison au sein du Site B. Nous allons configurer iptables sur l’Hôte β avec le masquage des paquets pour activer ce routage — consultez l’article WireGuard Point to Site Routing pour d’autres stratégies de routage alternatives.

Avant de commencer, notez les adresses IP affichées dans le diagramme ci-dessus : Dans ce scénario, l’adresse IP du Point de terminaison A, à partir de la perspective de l’Internet, est 198.51.100.1, mais à partir de la perspective de son propre réseau local (Site A), elle est 192.168.1.11, et à partir de la perspective du VPN WireGuard que nous allons construire, elle est 10.0.0.1. Le Point de terminaison B n’est pas accessible depuis l’Internet ; mais sur son propre réseau local (Site B), sa adresse IP est 192.168.200.22.

L’adresse IP de l’Hôte β, à partir de la perspective de l’Internet, est 203.0.113.2, mais à partir de la perspective de son propre réseau local (Site B), elle est 192.168.200.2, et à partir de la perspective du VPN WireGuard que nous allons construire, elle est 10.0.0.2. Et à partir de la perspective du Point de terminaison B (ou d’autres points de terminaison au sein du Site B), l’Hôte β a une adresse IP de 10.0.0.2.

es points de terminaison au sein du Site B), les paquets du Point de terminaison A apparaîtront comme venant de l’Hôte β — donc à partir de la perspective du Point de terminaison B, l’adresse IP du Point de terminaison A sera la même que l’adresse IP pour l’Hôte β dans le réseau local du Site B : 192.168.200.2.

Pour rendre ce scénario fonctionnel, voici les étapes que nous suivrons :

  1. Installer WireGuard
  2. Générer les clés WireGuard
  3. Configurer WireGuard sur le Point de terminaison A
  4. Configurer WireGuard sur l’Hôte B
  5. Configurer le routage sur l’Hôte B
  6. Démarrer WireGuard
  7. Tester le tunnel
  8. Dépannage de base
  9. Supplémentaire : Configurer le pare-feu sur l’Hôte B

Installer WireGuard

Installez WireGuard sur les Points de terminaison A et l’Hôte β 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 les clés WireGuard

Ensuite, générez deux paires de clés WireGuard, une pour le Point de terminaison A 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 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 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 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 : endpoint-a.key, endpoint-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 chacun sera de 44 caractères de texte encodé en Base64 :

$ cat endpoint-a.key
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
$ cat endpoint-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 chacun sera utilisé dans les fichiers de configuration WireGuard que nous allons construire pour Endpoint A et Host β 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.

Configurer WireGuard sur Endpoint A

Maintenant, configurons Endpoint A (le côté “client” de la connexion). Sur Endpoint A, créez un nouveau fichier à /etc/wireguard/wg0.conf avec le contenu suivant :

[Interface]
PrivateKey = $(cat /path/to/endpoint-a.key)
Address = 10.0.0.2/24
ListenPort = 51820

[Peer]
PublicKey = $(cat /path/to/host-b.pub)
Endpoint = host-b-ip:51820
AllowedIPs = 0.0.0.0/0

Remplacez host-b-ip par l’adresse IP réelle de l’Hôte β.

Ensuite, assurez-vous que le service WireGuard est démarré et configuré pour démarrer au démarrage :

$ sudo systemctl enable wg-quick@wg0
$ sudo systemctl start wg-quick@wg0

Configurer WireGuard sur l’Hôte B

Sur l’Hôte β, créez un nouveau fichier à /etc/wireguard/wg0.conf avec le contenu suivant :

[Interface]
PrivateKey = $(cat /path/to/host-b.key)
Address = 10.0.0.1/24
ListenPort = 51820

[Peer]
PublicKey = $(cat /path/to/endpoint-a.pub)
Endpoint = endpoint-a-ip:51820
AllowedIPs = 192.168.200.0/24

Remplacez endpoint-a-ip par l’adresse IP réelle du Point de terminaison A.

Ensuite, assurez-vous que le service WireGuard est démarré et configuré pour démarrer au démarrage :

$ sudo systemctl enable wg-quick@wg0
$ sudo systemctl start wg-quick@wg0

Configurer le routage sur l’Hôte B

Pour que les paquets destinés à 192.168.200.0/24 passent par le tunnel WireGuard, ajoutez une route sur l’Hôte β :

$ sudo ip route add 192.168.200.0/24 via 10.0.0.2 dev wg0

Démarrer WireGuard

Sur les deux hôtes, assurez-vous que le service WireGuard est démarré :

$ sudo systemctl start wg-quick@wg0

Tester le tunnel

Pour tester si le tunnel est correctement configuré, essayez de pinguer l’adresse IP du Point de terminaison A depuis l’Hôte β et vice versa :

$ ping 192.168.200.2
$ ping 10.0.0.2

Si tout est correctement configuré, vous devriez être en mesure de pinger les deux adresses IP.

Dépannage de base

Si le tunnel ne fonctionne pas, vérifiez les journaux de WireGuard pour des erreurs :

$ sudo journalctl -u wg-quick@wg0

Assurez-vous également que les pare-feux sur les deux hôtes permettent le trafic sur le port 51820.

Supplémentaire : Configurer le pare-feu sur l’Hôte B

Pour permettre le trafic WireGuard sur l’Hôte β, ajoutez des règles de pare-feu :

$ sudo iptables -A INPUT -i wg0 -j ACCEPT
$ sudo iptables -A FORWARD -i eth0 -o wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT
$ sudo iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT

Remplacez eth0 par le nom de l’interface réseau principale de l’Hôte β.

Ensuite, assurez-vous que les règles de pare-feu sont persistantes :

$ sudo iptables-save > /etc/iptables/rules.v4

Cela devrait permettre le fonctionnement du tunnel WireGuard entre le Point de terminaison A et l’Hôte B.

# /etc/wireguard/wg0.conf

# paramètres locaux pour Endpoint A
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51821

# paramètres distants pour Host β
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = 203.0.113.2:51822
AllowedIPs = 192.168.200.0/24

Définissez le propriétaire du 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 de l’endpoint, qui doit être gardée secrète).

Passons à travers la configuration, paramètre par paramètre :

  • Interface.PrivateKey : C’est la clé privée d’Endpoint A. Remplacez cette valeur par la clé privée réelle que vous avez générée pour Endpoint A. Cette valeur est confidentielle et ne doit vivre que dans ce fichier.

  • Interface.Address : C’est l’adresse IP de Endpoint A à l’intérieur du VPN WireGuard que nous construisons. Remplacez cette valeur par une adresse appropriée pour votre réseau. Vous pouvez utiliser n’importe quelle adresse que vous souhaitez, mais elle doit être dans l’espace d’adressage IPv4 “Prive” ou “Local unique” (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 Endpoint A ou l’un de ses pairs peut se connecter.

    Avec une topologie Point to Site, cette configuration dans le fichier de configuration d’Endpoint A doit correspondre exactement à la configuration Peer.AllowedIPs dans le fichier de configuration du Host β (discutée dans la section suivante).

    Cette configuration n’est pas utilisée directement par WireGuard — elle est uniquement utilisée par le service d’aide 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 endpoint lorsque ils sont en dehors du tunnel WireGuard, ils doivent utiliser l’adresse IP que vous définissez ici.

    Bien que vous puissiez configurer plusieurs adresses IP pour cette configuration, sauf si vous avez un cas d’utilisation spécifique, vous devriez simplement utiliser une seule adresse (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 Endpoint A. Endpoint A doit être capable de recevoir du trafic UDP pour les connexions établies sur ce port à partir de l’Internet (ou où que le trafic des autres pairs WireGuard avec lesquels il communiquera vienne).

    Si vous omettez cette configuration, WireGuard sélectionnera un nouveau port aléatoire et non utilisé dans la plage de ports temporaires de l’os (qui peut varier de 1024 à 65535, en fonction de l’os) chaque fois qu’il démarre.

  • Peer.PublicKey : C’est la clé publique du Host β. Remplacez cette valeur par la clé publique réelle que vous avez générée pour le Host β. Cette valeur n’est pas secrète ; cependant, elle est un identifiant globalment unique pour le Host β.

  • Peer.Endpoint : C’est l’adresse IP publique (et le port) de l’Hôte β que Endpoint A utilisera pour se connecter à Internet à l’Hôte β 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 β depuis Endpoint A (et ajoutez-y le port WireGuard réel que vous utiliserez pour l’Hôte β).

    L’Hôte β doit être capable d’accepter de nouvelles connexions UDP entrantes sur Internet à cette adresse et ce port ; et Endpoint A doit être capable d’envoyer du trafic UDP sur Internet vers cet endroit à cette adresse et ce port.

  • Peer.AllowedIPs : C’est le bloc de sous-réseau de Site B. Remplacez cette valeur par le bloc d’adresses IP réel que Site B utilise. Si l’Hôte β peut routage vers plusieurs sous-réseaux au sein de Site B, vous pouvez spécifier chaque bloc

c’est-à-dire 10.0.0.0/8 pour IPv4 ou fd00::/8 pour IPv6, et ne doit pas entrer en conflit avec n’importe quel autre sous-réseau privé auquel l’endpoint lui-même ou l’un de ses pairs peut se connecter.

Ce paramètre est utilisé par WireGuard pour déterminer les paquets qui doivent être routés à travers le tunnel. Les paquets envoyés à partir de cet hôte vers d'autres hôtes dans le réseau VPN seront envoisés via ce tunnel, et les paquets reçus sur cet hôte provenant du réseau VPN seront également traités par WireGuard.

Dans une topologie Point to Site, ce paramètre est crucial car il détermine où les paquets doivent être envoyés. Vous devez choisir 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écial, vous devriez simplement utiliser une seule adresse (au format d'un bloc `/32` avec une adresse IPv4, ou d'un bloc `/64` avec une adresse IPv6).
Peer.PublicKey
C’est la clé publique de Endpoint A — remplacez cette valeur par la clé publique réelle que vous avez générée pour Endpoint A. Cette valeur n’est pas secrète ; cependant, elle est un identifiant global unique pour Endpoint A.
Peer.AllowedIPs
C’est l’adresse IP de Endpoint A à 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 souhaitez, mais l’adresse doit être dans l’espace d’adressage IPv4 “Prive” ou “Local unique” (comme 10.0.0.0/8 pour IPv4 ou fd00::/8 pour IPv6), et ne doit pas entrer en conflit avec n’importe quel autre sous-réseau privé auquel l’endpoint lui-même ou l’un de ses pairs peut se connecter.

Ce paramètre est utilisé par WireGuard pour déterminer les paquets qui doivent être routés à travers le tunnel. Les paquets envoyés à partir de cet hôte vers d’autres hôtes dans le réseau VPN seront envoisés via ce tunnel, et les paquets reçus sur cet hôte provenant du réseau VPN seront également traités par WireGuard.

Dans une topologie Point to Site, ce paramètre est crucial car il détermine où les paquets doivent être envoyés. Vous devez choisir 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écial, vous devriez simplement utiliser une seule adresse (au format d’un bloc /32 avec une adresse IPv4, ou d’un bloc /64 avec une adresse 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 le point de terminaison lui-même ou l’un de ses pairs peut se connecter.

Avec une topologie Point to Site, cette configuration dans le fichier de configuration de Host β doit correspondre exactement à la configuration Interface.Address de Endpoint A (discutée plus haut).

Bien que vous puissiez configurer plusieurs adresses IP pour cette configuration, sauf si vous avez un cas d’utilisation spécial, avec une topologie Point to Site, il suffit simplement d’utiliser une seule adresse IP (au format d’un bloc /32 avec une adresse IPv4 ou d’un bloc /64 avec une adresse IPv6).

Vous remarquerez que nous avons omis la configuration Peer.Endpoint du fichier de configuration de Host β que nous utilisions dans le fichier de configuration d’Endpoint A. Dans ce scénario, car Endpoint A initie toutes les connexions à Site B (comme lorsque l’utilisateur final effectue des requêtes HTTP depuis Endpoint A vers Endpoint B), Host β n’a pas besoin de savoir comment initier une connexion à Endpoint A — et donc il ne nécessite pas une valeur préconfigurée pour Peer.Endpoint.

Configurer le Routage sur Host B

Si Host β est déjà configuré comme passerelle Internet pour Site B (ou la passerelle pour Site B vers un sous-réseau qui inclut le VPN WireGuard que nous configurons — dans cet exemple, simplement 10.0.0.1/32), vous n’avez rien à faire d’exceptionnel pour WireGuard ; passez simplement à la section suivante.

Sinon, nous devons configurer l’Hôte β pour qu’il route les paquets de l’Endpoint A vers l’Endpoint B (et vice versa). Lorsqu’un paquet envoyé depuis l’Endpoint A, destiné à l’Endpoint B, passe à travers le tunnel WireGuard que nous avons configuré entre l’Endpoint A et l’Hôte β, et arrive à l’interface wg0 de l’Hôte β, son adresse source sera 10.0.0.1, et son port source sera un port éphémère choisi par l’Endpoint A, comme 49999; et son adresse destination sera 192.168.200.22, et le port de destination 80.

L’adresse et le port de destination sont corrects tels quels — l’Hôte β n’a simplement pas besoin d’être configuré pour permettre la transmission de paquets comme cela vers d’autres hôtes. Mais l’adresse source est un problème — l’Endpoint B ne saura pas comment envoyer des paquets à l’Endpoint A à 10.0.0.1. Donc, nous devons utiliser la traduction d’adresse réseau source (SNAT) sur l’Hôte β pour réécrire l’adresse source du paquet afin qu’elle utilise l’adresse de l’Hôte β sur le LAN Site B (192.168.200.2). L’Endpoint B saura comment envoyer des paquets à cette adresse (et l’Hôte β saura à transmettre ces paquets à l’Endpoint A — avec la SNAT, elle réécrira le port source des paquets originaux, 49999 dans cet exemple, à un autre port éphémère qu’elle se rappellera d’être associé à l’Endpoint A, comme 50123).

Donc, en supposant que l’Hôte β soit un hôte Linux, nous devons configurer deux choses sur lui :

  1. Activer la transmission de paquets IP
  2. Configurer iptables pour appliquer le masquage d’adresse IP aux paquets sortants de l’interface wg0

Le masquage d’adresse IP est simplement une forme simplifiée de SNAT, où iptables choisit automatiquement l’adresse source à réécrire (qui dans notre scénario sera toujours 192.168.200.2). Si vous n’avez pas déjà installé iptables sur l’Hôte β (essayez d’exécuter sudo iptables -L pour vérifier), installez-le maintenant.

Bien que vous puissiez utiliser d’autres services pour accomplir cette tâche, la méthode la plus rapide pour nous permettre d’activer le transfert IP et le masquage IP est de faire en sorte que le service wg-quick le fasse lorsque nous allumons l’interface WireGuard. Pour ce faire, mettez à jour le fichier /etc/wireguard/wg0.conf sur l’Hôte β pour ajouter plusieurs paramètres Interface.PreUp et Interface.PostDown.

# /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
# masquage IP
PreUp = iptables -t mangle -A PREROUTING -i wg0 -j MARK --set-mark 0x30
PreUp = iptables -t nat -A POSTROUTING ! -o wg0 -m mark --mark 0x30 -j MASQUERADE
PostDown = iptables -t mangle -D PREROUTING -i wg0 -j MARK --set-mark 0x30
PostDown = iptables -t nat -D POSTROUTING ! -o wg0 -m mark --mark 0x30 -j MASQUERADE

# paramètres distants pour le Point de terminaison A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32

Si vous utilisez des adresses IPv6 pour votre VPN WireGuard, utilisez ces paramètres à la place :

PreUp = sysctl -w net.ipv6.conf.all.forwarding=1
PreUp = ip6tables -t mangle -A PREROUTING -i wg0 -j MARK --set-mark 0x30
PreUp = ip6tables -t nat -A POSTROUTING ! -o wg0 -m mark --mark 0x30 -j MASQUERADE
PostDown = ip6tables -t mangle -D PREROUTING -i wg0 -j MARK --set-mark 0x30
PostDown = ip6tables -t nat -D POSTROUTING ! -o wg0 -m mark --set-mark 0x30 -j MASQUERADE

Le premier paramètre PreUp active le transfert IP. Notez que l’activation du transfert IP est une configuration potentiellement dangereuse à activer si vous n’avez pas les règles de pare-feu appropriées en place devant l’hôte (ou comme partie intégrante du pare-feu de l’hôte) — avec cela activé, l’hôte essayera de transférer tout 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).

Le deuxième paramètre PreUp ajoute une règle iptables pour marquer tous les paquets sortants de l’interface wg0 avec la valeur 0x30. Le troisième paramètre PreUp ajoute une règle iptables pour appliquer le masquage IP à tous les paquets ayant cette marque 0x30 avant qu’ils ne soient transférés vers leur destination (tant que cette destination n’est pas renvoyée à nouveau via l’interface wg0). Notez que 0x30 est une valeur choisie arbitrairement, ce qui signifie qu’elle n’a aucun sens pour personne d’autre que ces deux règles iptables — toute autre valeur fonctionnerait aussi bien.

Les deux paramètres PostDown suppriment les règles iptables ajoutées par les paramètres PreUp. Les paramètres PostDown iptables devraient correspondre exactement aux paramètres PreUp, à l’exception des paramètres PostDown qui utilisent le drapeau -D (supprimer) au lieu du drapeau -A (ajouter).

Démarrage de WireGuard

Sur les deux points de terminaison A et le hôte β, 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 le 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.

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, vous verrez une sortie comme celle-ci :

$ sudo wg-quick up /etc/wireguard/wg0.conf
[#]

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 le même résultat en utilisant l’outil journalctl, comme suit :

$ journalctl -u wg-quick@wg0.service
systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
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 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 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 bloque ou que vous voyez une erreur comme Connection refused ou No route to host, vous pourriez avoir oublié d’activer le transfert IP pour l’Hôte β. Exécutez cette commande sur l’Hôte β 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 (consultez la section Configurer le routage sur l’Hôte B ci-dessus). Si le résultat est 1, le transfert IP est activé.

La prochaine chose à vérifier est de s’assurer que l’Hôte β effectue le masquage d’IP pour le Point de terminaison A. Exécutez cette commande sur l’Hôte β pour lister toutes vos règles iptables :

$ sudo iptables-save -c

Si vous n’avez aucune règle iptables en place, le résultat sera vide. Ce que vous devriez voir à la place est quelque chose comme ceci :

*mangle
:PREROUTING ACCEPT [123:12345]
:INPUT ACCEPT [123:12345]
:FORWARD ACCEPT [12:123]
:OUTPUT ACCEPT [123:12345]
:POSTROUTING ACCEPT [123:12345]
[12:123] -A PREROUTING -i wg0 -j MARK --set-xmark 0x30/0xffffffff
COMMIT
*nat
:PREROUTING ACCEPT [12:123]
:INPUT ACCEPT [12:123]
:OUTPUT ACCEPT [12:123]
:POSTROUTING ACCEPT [12:123]
[12:123] -A POSTROUTING ! -o wg0 -m mark --mark 0x30 -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [123:12345]
:FORWARD ACCEPT [12:123]
:OUTPUT ACCEPT [123:12345]
COMMIT

Si vous avez configuré le masquage d’IP comme suggéré dans la section Configurer le routage sur l’Hôte B, vous devriez avoir cette règle sous la table nat.

Voici le texte corrigé :

* `*mangle` :

```bash
-A PREROUTING -i wg0 -j MARK --set-xmark 0x30/0xffffffff

Et cette règle sous la table *nat :

-A POSTROUTING ! -o wg0 -m mark --mark 0x30 -j MASQUERADE

Si vous n’avez pas une règle avec un MASQUERADE ou un SNAT cible sous votre table *nat, le Point de terminaison B ne sera pas en mesure d’envoyer des paquets à nouveau vers le Point de terminaison A. Essayez de suivre la section Configurer le routage sur l’Hôte B ci-dessus pour configurer le masquage IP.

Les chiffres entre crochets (comme [123:12345]) sont le nombre de paquets et d’octets traités par chaque règle. Si vous voyez [0:0] pour la règle -j MASQUERADE, cela signifie que aucun paquet n’a correspondu à cette règle (c’est-à-dire que aucun paquet n’a été marqué avec 0x30 et transféré directement par une interface réseau physique de l’hôte). Et si vous voyez [0:0] pour la règle -j MARK, cela signifie que aucun paquet n’a entré l’interface réseau wg0 de l’hôte.

Si aucun paquet n’a entré l’interface réseau wg0 de 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 Points de terminaison A et Host β pour voir si l’interface réseau WireGuard sur les deux est active et configurée comme prévu.

Sur Host β, vous verrez probablement une sortie comme celle-ci :

$ sudo wg
interface: wg0
  public key: fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
  private key: (hidden)
  listening port: 51822

peer: /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
  allowed ips: 10.0.0.1/32

Si le Point de terminaison A s’est connecté avec succès, cette affichage comprendra un champ “dernier échange de clés” pour la pair, ainsi qu’un champ “transfert” indiquant que des données ont été reçues. La sortie ci-dessus indique que le Point de terminaison A n’a pas réussi à se connecter encore.

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: 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 ci-dessus), cela signifie probablement que les paquets sont bloqués ou mal dirigés quelque part entre le Point de terminaison A et le Hôte β. Si c’est le cas pour vous, vous devez ajuster vos pare-feux ou d’autres configurations réseau jusqu’à ce qu’ils permettent au Point de terminaison A d’envoyer des paquets UDP au Hôte β via l’adresse IP et le port configurés dans la configuration Peer.Endpoint du Point de terminaison A (dans cet exemple, c’est 203.0.113.2:51822).

Extra : Configurer le Pare-feu sur le Hôte B

Si vous avez déjà des règles de pare-feu de base configurées sur le Hôte β 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 restreindre la transmission du trafic WireGuard, mais vous n’avez pas besoin de le faire.

Si vous n’avez pas déjà de règles de base en place, voici quelques règles simples iptables que vous pouvez utiliser pour refuser les paquets WireGuard inattendus qui essaient d’accéder aux sockets locaux sur le Hôte β lui-même et pour refuser tout trafic WireGuard qui est transmis à une destination inattendue.

D’abord, arrêtez l’interface WireGuard sur le Hôte B 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 :


```bash
# /etc/wireguard/wg0.conf

# paramètres locaux pour le Hôte β
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822

# transmission IP
PreUp = sysctl -w net.ipv4.ip_forward=1
# masquage IP
PreUp = iptables -t mangle -A PREROUTING -i wg0 -j MARK --set-mark 0x30
PreUp = iptables -t nat -A POSTROUTING ! -o wg0 -m mark --mark 0x30 -j MASQUERADE
PostDown = iptables -t mangle -D PREROUTING -i wg0 -j MARK --set-mark 0x30
PostDown = iptables -t nat -D POSTROUTING ! -o wg0 -m mark --mark 0x30 -j MASQUERADE

# pare-feu local pour les pairs de wg
PreUp = iptables -A INPUT -i wg0 -m state --state ESTABLISHED,RELATED -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 pour les autres hôtes de pairs de 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

# paramètres distants pour le Point de terminaison A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32

Puis redémarrez l’interface avec wg-quick ou systemctl :

$ sudo wg-quick up /etc/wireguard/wg0.conf
$ # ou alternativement :
$ sudo systemctl start wg-quick@wg0.service

Cette configuration mise à jour fera en sorte que wg-quick sur l’Hôte β ajoute cinq nouvelles règles iptables avant de redémarrer l’interface WireGuard, et les supprime après avoir redémarré 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 à travers le tunnel WireGuard ; et la deuxième règle rejetera tout autre chose entrant au tunnel destiné à l’Hôte β.

Les trois dernières règles (ajoutées à la chaîne FORWARD) s’appliquent au trafic transféré du Point de terminaison A vers 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 pour les règles de la chaîne INPUT, les deux premières et la troisième règle de la chaîne FORWARD permettent les connexions déjà établies, mais rejettent les nouvelles connexions.

La deuxième règle permet cependant d’accepter de nouvelles connexions TCP qui seront transférées au port 80 du Point de terminaison B (192.168.200.22 sur le Site B). Si vous souhaitez autoriser l’accès à un autre port du Point de terminaison B que le port 80 (comme le port 8080), spécifiez ce port au lieu du port 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 à la fin de --dports) — par exemple, pour autoriser 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

Chaque fois que vous modifiez ces règles, assurez-vous de faire la même modification à la fois dans le paramètre PreUp et son équivalent PostDown (les règles PreUp et PostDown devraient être les mêmes, simplement avec un indicateur -A pour PreUp et -D pour PostDown).

tre 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 préférable de mettre d’abord l’interface hors ligne, de modifier vos configurations, puis de la ramener en ligne à nouveau (au lieu de modifier les configurations alors que l’interface est toujours en ligne, puis de tenter de la 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 l’arrêter 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 nettoyer manuellement).

Pour des conseils sur la façon de configurer un pare-feu iptables sous un scénario plus complexe point-to-site, consultez la section “Point to Site” du guide Contrôle d’accès WireGuard avec Iptables.

Pour utiliser UFW pour configurer un pare-feu similaire au pare-feu décrit dans cet article, consultez la section “Point to Site” du guide Utiliser WireGuard avec UFW ; pour utiliser firewalld, consultez la section “Point to Site” du guide Utiliser WireGuard avec Firewalld ; ou pour utiliser nftables, consultez la section “Point to Site” du guide Utiliser WireGuard avec Nftables.

11/25/2020

par Justin Ludwig


by Justin Ludwig
translated by: Patrice Le Guyader
tags: wireguard point-to-site vpn linux masquage-paquets