NOPE LinkedIn

Catégories:
wireguard

WireGuard Point-to-Site avec Redirection de Ports

WireGuard Point-to-Site avec Redirection de Ports 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 With Port Forwarding de Justin Ludwig

{< /admonitionblock >}

WireGuard Point à Site avec Transfert de Port

Généralement, lorsque vous connectez un point distant (endpoint) à un site local, vous voulez que l’endpoint puisse accéder à certains ressources (comme une application web ou un serveur de messagerie) sur le site local, et ne pas avoir besoin d’autoriser les hôtes du site à pouvoir initier des connexions au point distant. Mais parfois, vous voulez l’inverse — pour les hôtes du site local être en mesure d’accéder à un service (comme une application web ou une base de données) sur le point distant.

Cet article expliquera comment faire cela : nous allons configurer un point distant comme un pair WireGuard, et le connecter à un second pair WireGuard au site local ; puis nous transférerons un port sur le deuxième pair WireGuard avec la traduction de réseau cible (DNAT) pour permettre aux autres hôtes du site local d’accéder au point distant via ce tunnel WireGuard.

C’est l’inverse de la façon dont une topologie WireGuard Point à Site est généralement utilisée, mais la configuration WireGuard pour cela est similaire à la configuration standard Point à Site — juste avec quelques règles de pare-feu différentes pour activer le transfert de port.

Dans l’exemple d’architecture pour cet article, nous aurons le point distant exécutant un serveur web sur le port 80, ainsi que WireGuard en cours d’exécution sur le port 51821. Je l’appellerai “Endpoint A”. Nous aurons également un autre hôte exécutant WireGuard à notre site local sur le port 51822, que je l’appellerai “Host β”, dans “Site B”. Et nous aurons une station de travail utilisateur sur le réseau local (Local Area Network) au Site B, que je l’appellerai “Endpoint B”. Ce point n’exécute pas WireGuard, mais nous voulons quand même qu’il puisse se connecter au serveur web sur Endpoint A.

Le Internet est entre le Point de terminaison A et le Site B. Le Point de terminaison A est derrière une traduction d’adresse réseau (NAT) et un pare-feu qui permet uniquement les connexions établies. Le Site B est également derrière une traduction d’adresse réseau et un pare-feu, mais sa NAT + pare-feu permet le transfert du port 51822 de l’Internet à Host β.

Le diagramme ci-dessous illustre ce scénario :

Scénario point-to-site Wireguard

En connectant le Point de terminaison A et Host β dans un VPN WireGuard (Réseau privé virtuel), le Point de terminaison B pourra accéder au Point de terminaison A comme si le serveur web sur le Point de terminaison A fonctionnait sur Host β à la place. Host β a une adresse IP de 192.168.200.2 dans le Site B, donc un utilisateur utilisant le Point de terminaison B pourra accéder au serveur web sur le Point de terminaison A simplement en naviguant vers http://192.168.200.2 dans son navigateur Web.

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

L’adresse IP de Host β, depuis le point de vue de l’Internet, est 203.0.113.2, mais depuis le point de vue de son propre réseau local (Site B), elle est 192.168.200.2 ; et depuis le point de vue du VPN WireGuard que nous allons construire, elle est 10.0.0.2. Et depuis le point de vue du Point de terminaison B (ou d’importe autres points de terminaison dans Site B), les paquets provenant du Point de terminaison A seront redirigés vers Host β via le VPN WireGuard.

Ainsi, grâce à cette configuration, les utilisateurs du réseau local au Site B pourront accéder au serveur web sur Endpoint A en utilisant l’adresse IP de Host β.

e terminaison A apparaîtront être venus de Host β — donc du point de vue du Point de terminaison B, l’adresse IP du Point de terminaison A sera la même que l’adresse IP pour Host β sur le réseau local du Site B : 192.168.200.2.

Ces sont les étapes que nous suivrons dans ce scénario :

  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 autre 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 paire de clés pour 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 construirons 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 serveur web distant). Sur Endpoint A, créez un nouveau fichier à /etc/wireguard/wg0.conf avec le contenu suivant :

# /etc/wireguard/wg0.conf

# paramètres locaux pour Endpoint A
[Interface]
PrivateKey = $(cat endpoint-a.key)
Address = 10.0.0.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# paramètres pour Host B
[Peer]
PublicKey = $(cat host-b.pub)
Endpoint = 192.168.200.2:51820
AllowedIPs = 10.0.0.2/32

Configurer WireGuard sur l’Hôte B

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

# /etc/wireguard/wg0.conf

# paramètres locaux pour Host B
[Interface]
PrivateKey = $(cat host-b.key)
Address = 10.0.0.2/24
ListenPort = 51820

# paramètres pour Endpoint A
[Peer]
PublicKey = $(cat endpoint-a.pub)
Endpoint = <IP_PUBLIC_ENDPOINT_A>:51820
AllowedIPs = 10.0.0.1/32

Configurer le routage sur l’Hôte B

Pour permettre à l’Hôte B de communiquer avec Endpoint A via le tunnel WireGuard, vous devez ajouter une route statique pour la plage d’adresses IP du réseau distant :

$ ip route add 10.0.0.1/32 dev wg0

Démarrer WireGuard

Sur les deux hôtes, démarrez le service WireGuard et assurez-vous qu’il est en cours d’exécution :

$ sudo systemctl enable wireguard
$ sudo systemctl start wireguard
$ sudo systemctl status wireguard

Tester le tunnel

Pour tester si le tunnel est correctement configuré, vous pouvez essayer de pinguer l’adresse IP du Point de terminaison A depuis l’Hôte B :

$ ping 10.0.0.1

Si tout fonctionne comme prévu, vous devriez recevoir des réponses.

Dépannage de base

Si le tunnel ne fonctionne pas, vérifiez les journaux du service WireGuard pour obtenir plus d’informations :

$ sudo journalctl -u wireguard

Assurez-vous également que les pare-feux sur les deux hôtes sont configurés correctement pour permettre le trafic sur le port 51820.

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

Pour s’assurer que le pare-feu de l’Hôte B ne bloque pas le trafic WireGuard, vous pouvez ajouter les règles suivantes :

$ sudo iptables -A INPUT -i wg0 -j ACCEPT
$ sudo iptables -A OUTPUT -o wg0 -j ACCEPT

Ces règles permettent aux paquets entrants et sortants sur l’interface wg0 de traverser le pare-feu.

vateKey = 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 PersistentKeepalive = 25

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 c’est le seul endroit où elle devrait vivre.

  • Interface.Address : 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 “Prive” IPv4 ou “Local unique” IPv6 (comme 10.0.0.0/8 — voir RFC 6890 pour tous les blocs d’adresses disponibles), et ne doit pas entrer en conflit avec n’importe quel autre sous-réseau privé auquel 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, à moins qu’il n’y ait une utilisation particulière, vous devriez simplement utiliser une seule adresse (au format d’un bloc /32 avec une adresse IPv4, ou 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 d’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’opérateur système (qui peut varier de 1024 à 65535, en fonction de l’opérateur système) 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 β — l’adresse IP et le port que le Point de terminaison 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 le Point de terminaison 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 le Point de terminaison A doit être capable d’envoyer du trafic UDP sur Internet à cet endroit et à ce port.

  • Peer.AllowedIPs : C’est le bloc de sous-réseau de Site B — remplacez cette valeur par le bloc réel d’adresses IP que Site B utilise. Si l’Hôte β peut routage vers plusieurs sous-réseaux au sein de Site B, vous pouvez spécifier chacun d’eux en séparant les valeurs par des virgules.

que blocs d'adresses IP séparées par des virgules (comme `192.168.200.0/24,192.168.202.64/26,192.0.2.48/28`) pour ce paramètre, ou vous pouvez simplement spécifier ce paramètre plusieurs fois, une fois pour chaque bloc CIDR (Classless Inter-Domain Routing).

Peer.PersistentKeepalive
:   C'est un nombre de secondes entre les paquets keepalive. La valeur par défaut est `0`, ce qui désactive les paquets keepalive.

    Si vous définissez cela à un entier positif N, WireGuard enverra un petit paquet keepalive à l'Hôte β lorsque l'interface WireGuard sur le Point de terminaison A démarre, et une fois encore tous les N secondes. Cela ouvrira tout pare-feu statique entre le Point de terminaison A et l'Hôte β qui accepte uniquement les connexions établies dans la direction du Point de terminaison A.

    Nous avons besoin de cela dans notre scénario d'exemple, qui a des pare-feux devant le Point de terminaison A qui acceptent uniquement le trafic entrant pour les connexions établies, afin d'autoriser l'Hôte β à initier de nouvelles connexions au Point de terminaison A lorsqu'il transfère des requêtes HTTP du Point de terminaison B.

## Configurer WireGuard sur l'Hôte B

Maintenant configurons l'Hôte β (le côté local du site de la connexion). Sur l'Hôte β, créez un nouveau fichier à `/etc/wireguard/wg0.conf` avec le contenu suivant :

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

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

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

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 du Hôte, qui doit être gardée secrète).

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

Interface.PrivateKey
:   C'est la clé privée du Hôte β — remplacez cette valeur par la clé privée réelle que vous avez générée pour le Hôte β. Cette valeur est confidentielle, et c'est la seule place où elle devrait vivre.

Interface.Address
:   C'est l'adresse IP interne du Hôte β dans le 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 dans l'espace d'adressage "Utilisation privée" IPv4 ou "Local unique" IPv6 (comme `10.0.0.0/8` — voir [RFC 6890](https://tools.ietf.org/html/rfc6890) 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.

    Ce paramètre n'est pas utilisé directement par WireGuard — il est uniquement utilisé par le service d'aide `wg-quick` lorsqu'il configure une interface réseau virtuelle pour WireGuard. Afin que les paquets réseau soient correctement routés vers et depuis ce hôte lorsque ils sont en dehors du tunnel WireGuard, ils doivent utiliser l'adresse IP que vous avez définie ici.

    Dans un topologie Point to Site, ce paramètre sur le Hôte WireGuard du site n'est pas très important — généralement, vous voulez faire passer les paquets *à travers* le Hôte WireGuard du site (et à d'autres points de terminaison du site), et non *vers* le hôte lui-même. Donc, il suffit de vous assurer que vous choisissez une adresse IP qui ne va pas entrer en conflit avec aucune autre adresse IP que le hôte peut router.

Bien que vous puissiez configurer plusieurs adresses IP pour ce paramètre, sauf si vous avez un cas d'utilisation spécifique, il est préférable 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).

Interface.ListenPort
:   C'est le port WireGuard de l'Hôte β. L'Hôte β doit être capable de recevoir du trafic UDP sur ce port.

DP pour de nouvelles connexions sur ce port à partir de l’Internet (ou où que provienne le trafic des autres pairs WireGuard avec lesquels il communiquera).

Avec une topologie Point to Site, cette configuration dans le fichier de configuration de l’Hôte β doit être la même que le port dans le paramètre Peer.Endpoint du fichier de configuration de l’Endpoint A (discuté plus haut).

Peer.PublicKey

C’est la clé publique de l’Endpoint A — remplacez cette valeur par la clé publique réelle générée pour l’Endpoint A. Cette valeur n’est pas secrète ; cependant, elle est un identifiant globalment unique pour l’Endpoint A.

Peer.AllowedIPs

C’est l’adresse IP de l’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 “Utilisation privée” IPv4 ou “Local unique” IPv6 (comme 10.0.0.0/8 — voir RFC 6890 pour tous les blocs d’adresses disponibles), et ne doit pas entrer en conflit avec aucun autre sous-réseau privé auquel l’endpoint 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 l’Hôte β doit correspondre exactement à la paramètre Interface.Address du fichier de configuration de l’Endpoint A (discuté plus haut).

Bien que vous puissiez configurer plusieurs adresses IP pour ce paramètre, sauf si vous avez un cas d’utilisation spécifique, avec une topologie Point to Site, il est préférable 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).

Configuration de l’Endpoint alternatif

Vous remarquerez que nous avons omis la configuration de Peer.Endpoint dans le fichier de configuration de l’Hôte β, même si nous l’avions utilisée dans le fichier de configuration du Point A. Dans cet exemple, car le Point A est configuré avec l’adresse de point de terminaison de l’Hôte β et pour envoyer des paquets d’échange de clés à l’Hôte β toutes les 25 secondes, nous n’avons pas besoin de configurer l’Hôte β avec l’adresse du point de terminaison du Point A. WireGuard déterminera automatiquement l’adresse du Point A lorsqu’il recevra le premier paquet d’échange de clés provenant du Point A.

Dans les cas où votre point distant a une adresse IP statique et que son pare-feu permet de nouvelles connexions sur son port WireGuard, vous pouvez inverser ces paramètres et inclure une configuration Peer.Endpoint côté site, tout en l’omissons du côté point. Vous pouvez également omettre la configuration Peer.PersistentKeepalive d’un côté ou de l’autre. Si nous avions fait cela dans cet exemple, c’est ce que le fichier wg0.conf du Point A ressemblerait :

# /etc/wireguard/wg0.conf

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

# paramètres distants pour l'Hôte β
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
AllowedIPs = 192.168.200.0/24

Et ce que le fichier wg0.conf de l’Hôte β ressemblerait :

# /etc/wireguard/wg0.conf

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

# paramètres distants pour le Point A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
Endpoint = 198.51.100.1:51821
AllowedIPs = 10.0.0.1/32

Configurer le Routage sur l’Hôte B

En supposant que l’Hôte β soit un hôte Linux, nous devons configurer deux choses à cet effet :

  1. Activer la transmission de paquets.
  2. Configurer le transfert de port avec iptables.

Si vous n’avez pas iptables installé sur l’hôte, installez-le maintenant avec votre gestionnaire de paquets (comme sudo apt install iptables ou sudo yum install iptables).

stall iptables`, etc.).

Bien que d’autres méthodes puissent être utilisées pour configurer ces deux éléments, la méthode la plus simple est d’ajouter des commandes PreUp et PostDown dans la section [Interface] de notre fichier de configuration WireGuard (wg-quick) — wg-quick les exécutera automatiquement lorsque l’interface WireGuard sera démarrée (et exécutera les commandes PostDown lorsqu’elle sera arrêtée).

Ainsi, mettez à jour le fichier /etc/wireguard/wg0.conf sur le Hôte β pour ajouter les paramètres suivants PreUp et PostDown :

# /etc/wireguard/wg0.conf

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

# transfert de paquets
PreUp = sysctl -w net.ipv4.ip_forward=1

# redirige le port
PreUp = iptables -t nat -A PREROUTING -d 192.168.200.2 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.1
PostDown = iptables -t nat -D PREROUTING -d 192.168.200.2 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.1

# 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, remplacez net.ipv4.ip_forward par net.ipv6.conf.all.forwarding, et iptables par ip6tables.

Le premier paramètre PreUp ci-dessus s’assure que le transfert de paquets est activé (ce paramètre est global pour le sous-système réseau du noyau Linux). Le deuxième paramètre PreUp configure iptables pour transférer les paquets envoyés au port 80 de l’adresse LAN du Hôte β (192.168.200.2) vers le port 80 de l’Endpoint A (10.0.0.1). Comme nous utilisons l’adresse WireGuard de l’Endpoint A comme leur nouveau point de destination, ces paquets seront transférés à travers le tunnel WireGuard entre le Hôte β et l’Endpoint A.

Notez que nous pouvons transférer des paquets vers une autre port de destination en incluant le port différent dans la valeur --to-destination. Par exemple, si nous voulions transférer le port 80 du Hôte β au port 8080 de l’Endpoint A, nous ferions cela comme suit :

PreUp = iptables -t nat -A PREROUTING -d 192.168.200.2 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.1:8080

La commande PostDown supprime la règle iptables lorsque wg-quick arrête l’interface. Si vous modifiez la règle iptables dans la commande PreUp, assurez-vous de faire le changement correspondant à la règle dans la commande PostDown (les deux commandes devraient être identiques, sauf que la commande PreUp utilise le drapeau -A, pour --append, tandis que la commande PostDown utilise le drapeau -D, pour --delete).

Démarrage de WireGuard

Sur les deux points de terminaison A et l’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 l’hôte et définira certaines règles de routage pour envoyer les paquets destinés à tout adresse IP listée dans les paramètres Peer.AllowedIPs du fichier /etc/wireguard/wg0.conf.

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 suit :

2023/04/15 12:34:56 wg-quick[1234]: Starting wg0
2023/04/15 12:34:56 wg-quick[1234]: wg0: setting MTU to 1420
2023/04/15 12:34:56 wg-quick[1234]: wg0: enabling device
2023/04/15 12:34:56 wg-quick[1234]: wg0: setting private key ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
2023/04/15 12:34:56 wg-quick[1234]: wg0: adding peer /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
2023/04/15 12:34:56 wg-quick[1234]: wg0: setting allowed IPs 10.0.0.1/32
2023/04/15 12:34:56 wg-quick[1234]: wg0: enabling IPv4 forwarding
2023/04/15 12:34:56 wg-quick[1234]: wg0: adding iptables rule for DNAT on port 80

Cela indique que le service wg-quick a réussi à démarrer l’interface wg0 et a appliqué les règles nécessaires.

Voici le texte corrigé :

Comme celle-ci :

```bash
$ 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 1420 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 a configurées automatiquement pour vous.

Si vous avez exécuté systemctl start au lieu de cela, vous pouvez obtenir 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[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 1420 up dev wg0
wg-quick[271288]: [#] ip -4 address add 10.0.0.2/32 dev wg0
systemd[1]: Démarrage de WireGuard via wg-quick(8) pour wg0 terminé.

Tester le Tunnel

Sur le Point de terminaison A, si ce n’est pas déjà fait, démarrez le serveur web sur le port 80. Sur le Point de terminaison B, utilisez curl (ou tout autre navigateur) pour demander une page au Point de terminaison A :

$ curl 192.168.200.2

Si vous voyez un code HTML en sortie, votre tunnel WireGuard fonctionne !

Dépannage de base

Si curl s’emballe ou que vous voyez une erreur comme Connection refused ou No route to host, vous pourriez avoir oublié d’activer le transfert de paquets sur l’Hôte β. Exécutez cette commande sur l’Hôte β pour vérifier :

$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

Ou, si vous utilisez des adresses IPv6, exécutez la variante IPv6 :

$ sysctl net.ipv6.conf.all.forwarding
net.ipv6.conf.all.forwarding = 0

Si le résultat est 0, vous devez activer le transfert de paquets (consultez la section Configurer le routage sur l’Hôte B ci-dessus). Si le résultat est 1, le transfert de paquets est activé.

La prochaine chose à vérifier est d’assurer que l’Hôte β effectue le transfert de ports pour le Point de terminaison A. Exécutez cette commande sur l’Hôte β pour lister toutes les règles des tables 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 :

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [12:123]
:POSTROUTING ACCEPT [34:567]
[21:432] -A PREROUTING -d 192.168.200.2/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1
COMMIT

En particulier, vous devriez voir cette règle sous la table *nat :

[21:432] -A PREROUTING -d 192.168.200.2/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1

Si vous n’avez pas cette règle, le Hôte β ne sera pas capable de transférer les requêtes HTTP de l’Endpoint B à l’Endpoint A. Essayez de suivre la section Configurer le routage sur l’Hôte B ci-dessus pour configurer le transfert de ports.

Les chiffres entre crochets (comme [21:432]) sont le nombre de paquets et d’octets traités par chaque règle. Si vous voyez [0:0] pour la règle DNAT, cela signifie que aucun paquet n’a correspondu à cette règle. Dans ce cas, il est possible que vous ayez d’autres règles de pare-feu ou une configuration réseau bloquant les paquets envoyés au port 80 sur le Hôte β.

Sinon, essayez d’exécuter sudo wg sur les deux Endpoint A et Host β pour voir si l’interface WireGuard sur les deux est active et configurée comme prévu.

Sur le Hôte β, 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 l’Endpoint A s’est connecté avec succès, cett

e 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 l’Endpoint A n’a pas réussi à se connecter encore.

Sur l’Endpoint 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
  persistent keepalive: every 25 seconds

Si le champ "transfer" indique que des données ont été envoyées au Hôte β, mais aucune n'a été reçue (comme dans l'exemple 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

Tant que le Site B n'est pas configuré pour utiliser le Hôte β comme passerelle, seul le trafic qui sera routé avec succès entre le Site B et notre réseau WireGuard sera les paquets envoyés et répondants au port 80 du Point de terminaison A. Mais en tant qu' mesure supplémentaire de sécurité, vous pouvez peut-être ajouter quelques règles de pare-feu supplémentaires sur le Hôte β pour empêcher le trafic de votre réseau WireGuard d'accéder à tout service sur le Hôte β lui-même (et si vous ajoutez des pairs WireGuard supplémentaires au réseau du Hôte β, pour empêcher ces pairs de se connecter entre eux via le Hôte β).

Voici quelques règles simples `iptables` que vous pouvez utiliser pour refuser le trafic WireGuard qui accède aux services locaux sur le Hôte β lui-même, et pour refuser tout trafic transféré WireGuard utilisé pour établir de nouvelles connexions à quelque chose d'autre que le port 80 du Point de terminaison A. D'abord, arrêtez l'interface WireGuard sur le Hôte B 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 le Hôte β
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822

# transfert de paquets
PreUp = sysctl -w net.ipv4.ip_forward=1

# redirection de ports
PreUp = iptables -t nat -A PREROUTING -d 192.168.200.2 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.1
PostDown = iptables -t nat -D PREROUTING -d 192.168.200.2 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.1

# pare-feu local du Hôte β contre les pairs WireGuard
PreUp = iptables -A INPUT -i wg0 -j REJECT
PreUp = iptables -A OUTPUT -o wg0 -j REJECT
PostDown = iptables -D INPUT -i wg0 -j REJECT
PostDown = iptables -D OUTPUT -o wg0 -j REJECT

# pare-feu d'autres hôtes contre les pairs WireGuard
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.1 -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 10.0.0.1 -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

Redémarrez ensuite l’interface avec

wg-quick ou systemctl :

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

Les premiers commandes de pare-feu PreUp du nouveau ensemble empêcheront tout pair WireGuard de se connecter directement aux services sur le Hôte β (et vice versa) :

PreUp = iptables -A INPUT -i wg0 -j REJECT
PreUp = iptables -A OUTPUT -o wg0 -j REJECT

Les deuxièmes commandes PreUp du pare-feu empêcheront le Hôte β de transférer tout connexion vers et depuis ses pairs WireGuard, à l’exception des connexions liées au port 80 du Point de terminaison A :

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.1 -p tcp --dport 80 -j ACCEPT
PreUp = iptables -A FORWARD -i wg0 -j REJECT

Pour un guide sur la mise en place d’un pare-feu iptables plus complexe, consultez la section “Point to Site” de l’article Contrôle d’accès avec WireGuard et Iptables.

Pour utiliser UFW pour configurer un pare-feu similaire au pare-feu décrit dans cet article, consultez la section “Extra: Transfert de port sur le hôte β” de l’article Utiliser WireGuard avec UFW; pour utiliser firewalld, consultez la section “Extra: Transfert de port sur le hôte β” de l’article Utiliser WireGuard avec Firewalld; ou pour utiliser nftables, consultez la section “Point to Site avec Transfert de port” de l’article Utiliser WireGuard avec Nftables.

4/9/2021

par Justin Ludwig


by Justin Ludwig
translated by: Patrice Le Guyader
tags: wireguard vpngateway portforwarding nattraversal pointtosite configuration