NOPE LinkedIn

Catégories:
wireguard

Configuration WireGuard point à point

Configuration WireGuard point à point image

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

Configuration de point à point avec WireGuard

Cet article explique comment configurer deux pairs WireGuard dans une topologie Point to Point. C’est la configuration appropriée lorsque vous voulez simplement connecter un seul point de terminaison exécutant WireGuard à un autre point de terminaison exécutant WireGuard.

Dans le scénario spécifique que je couvrirai dans cet article, nous aurons une station de travail utilisateur finale, que je nommerai “Point de terminaison A”, sur un réseau local (LAN); et un serveur HTTP qui écoute sur le port 80, que je nommerai “Point de terminaison B”, sur un autre; et l’Internet entre eux. 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 à travers. Le Point de terminaison B est également derrière la NAT et le pare-feu, mais sa configuration NAT + pare-feu permet le transfert du port 51822 de l’Internet au Point de terminaison B. Nous utiliserons ce port, 51822, pour WireGuard sur le Point de terminaison B.

Le diagramme ci-dessous illustre ce scénario :

Scénario de point à point avec WireGuard

La exigence clé d’une topologie Point to Point est que l’un des points de terminaison doit permettre un accès public (ou au moins un accès du autre point de terminaison) à son port WireGuard avant que le tunnel WireGuard lui-même ne soit établi. Dans le diagramme ci-dessus, les paquets UDP de l’Internet vers l’adresse IP 203.0.113.2 sur le port 51822 sont transférés au Point de terminaison B (également sur le port 51822). Cela permet au Point de terminaison A d’accéder au port WireGuard du Point de terminaison B via l’Internet et d’établir le tunnel WireGuard.

Si il y avait des règles de pare-feu ou une autre configuration réseau qui bloquaient cette connexion, il ne serait pas possible d’établir une connexion de point à point WireGuard entre le Point de terminaison A et le Point de terminaison B. Au lieu de cela, vous devriez utiliser une approche différente (voir Topologies principales de WireGuard pour d’autres options).

Dans cet article, nous installerons WireGuard et créerons un tunnel WireGuard entre les deux points de terminaison. À l’intérieur du VPN WireGuard (Réseau privé virtuel) que nous allons créer, nous configurerons le Point de terminaison A pour utiliser une adresse IP de 10.0.0.1, et le Point de terminaison B pour une adresse IP de 10.0.0.2. Une fois que nous aurons configuré et lancé WireGuard sur les deux points de terminaison, un utilisateur utilisant le Point de terminaison A pourra accéder au serveur HTTP qui écoute sur le port 80 du Point de terminaison B simplement en naviguant vers http://10.0.0.2/ dans son navigateur web.

Mais d’abord, notez les adresses IP affichées dans le diagramme ci-dessus : Dans ce scénario, l’adresse IP du Point de terminaison A, vue à partir de l’Internet, est 198.51.100.1 ; mais à partir de sa propre LAN (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. De même, l’adresse IP du Point de terminaison B, vue à partir de l’Internet, est 203.0.113.2 ; mais à partir de sa propre LAN (Site B), elle est 192.168.200.22 ; et à partir de la perspective du VPN WireGuard que nous allons construire, elle est 10.0.0.2.

Ces sont les étapes que nous suivrons :

  1. Installer WireGuard
  2. Générer des clés WireGuard
  3. Configurer WireGuard sur le Point de terminaison A
  4. Configurer WireGuard sur le Point de terminaison B
  5. Démarrer WireGuard
  6. Tester le tunnel

Installer WireGuard

Installez WireGuard sur les deux points de terminaison A et B en suivant les instructions d’installation pour la plateforme appropriée sur la page WireGuard Installation. Vous pouvez vérifier que vous avez installé WireGuard avec succès en exécutant wg help sur chaque point de terminaison.

Génération des clés WireGuard

Ensuite, générez deux paires de clés WireGuard, une pour le point de terminaison A et une pour le point de terminaison B. Une paire de clés WireGuard (également connue sous le nom de “paire de clés”) est composée de deux parties : la “clé privée” (également appelée “clé secrète”) et la “clé publique”. La magie de ce type de cryptographie (connu 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 points de terminaison, il est souvent le meilleur moyen de garder sa clé privée sécurisée en générant la clé d’un point de terminaison sur lui-même — ainsi la clé privée ne quitte jamais le point de terminaison. Si vous générez vos clés à l’extérieur du point de terminaison, soyez très prudent avec les clés privées, car la sécurité de WireGuard dépend entièrement de garder les 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 le point de terminaison B :

$ wg genkey > endpoint-b.key
$ wg pubkey < endpoint-b.key > endpoint-b.pub

Cela générera quatre fichiers : endpoint-a.key, endpoint-a.pub, endpoint-b.key et endpoint-b.pub. Les fichiers *.key contiennent les clés privées, et les fichiers *.pub contiennent les clés publiques. Le contenu de chaque fichier sera 44 caractères de texte encodé en Base64 :

$ cat endpoint-a.key
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
$ cat endpoint-a.pub
/TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=

$ cat endpoint-b.key
ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
$ cat endpoint-b.pub
fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=

Vous n’avez pas besoin de conserver ces fichiers — le contenu de chacun sera utilisé dans les fichiers de configuration que nous construirons pour les points de terminaison A et B dans la section suivante. La clé privée d’un point de terminaison 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 point de terminaison 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 le Point de Terminaison A

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

# /etc/wireguard/wg0.conf

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

# paramètres distants pour le Point de Terminaison B
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=

Endpoint = 203.0.113.2:51822
AllowedIPs = 10.0.0.2/32

Définissez le propriétaire du fichier sur root et ses permissions à 600 (le propriétaire peut lire+écrire ; tout le monde else est refusé l'accès — le fichier contient la clé privée du point de terminaison, qui doit être gardée secrète).

Passons en revue la configuration, paramètre par paramètre :

**Interface.PrivateKey**
:   C'est la clé privée du Point de Terminaison A — remplacez cette valeur par la clé privée réelle que vous avez générée pour le Point de Terminaison A. Cette valeur est secrète et c'est la seule place où elle doit vivre.

**Interface.Address**
:   C'est l'adresse IP interne du Point de Terminaison A dans le VPN WireGuard que nous construisons — remplacez cette valeur par une valeur appropriée pour votre réseau. Vous pouvez utiliser n'importe quelle adresse que vous souhaitez 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.

Avec une topologie Point-to-Point, cette configuration dans le fichier de configuration d'Endpoint A doit correspondre exactement à la configuration Peer.AllowedIPs dans le fichier de configuration d'Endpoint B (discutée dans la section suivante).

Ce paramètre n'est pas utilisé directement par WireGuard — il est utilisé uniquement par le service d'aide wg-quick lorsqu'il configure une interface réseau virtuelle pour WireGuard. Pour que les paquets 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 ce paramètre, à moins qu'il n'y ait une utilisation particulière, vous devriez simplement utiliser une seule adresse IP (au format d'un bloc /32 avec une adresse IPv4 ou d'un bloc /64 avec une adresse IPv6).

**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 ce paramètre, WireGuard sélectionnera un nouveau port aléatoire et non utilisé dans la plage de ports éphémères du système d'exploitation (qui peut varier de 1024 à 65535 en fonction du système d'exploitation) chaque fois qu'il démarrera.

**Peer.PublicKey**
:   C'est la clé publique d'Endpoint B — remplacez cette valeur par la clé publique réelle que vous avez générée pour Endpoint B. Cette valeur n'est pas secrète ; cependant, elle est un identifiant globalment unique pour Endpoint B.

**Peer.Endpoint**
:   C'est l'adresse IP et le port public d'Endpoint B — l'adresse IP et le port que Endpoint A utilisera pour se connecter à Internet à Endpoint B afin de configurer le tunnel WireGuard. Remplacez cette valeur par l'adresse IP réelle que vous utiliseriez normalement pour vous connecter à Endpoint B depuis Endpoint A (et ajoutez-y le port WireGuard réel que vous utiliserez pour Endpoint B).

Point de terminaison B doit être capable d'accepter de nouvelles connexions UDP à partir d'Internet à cette adresse et au port ; et le point de terminaison A doit être capable d'envoyer du trafic UDP sur Internet vers celui-ci à cette adresse et au port.

**Peer.AllowedIPs**
:   C'est l'adresse IP du 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. 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](https://tools.ietf.org/html/rfc6890) pour tous les blocs d'adresses disponibles).

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.

Avec une topologie Point à Point, cette configuration dans le fichier de configuration du point de terminaison A devrait correspondre exactement à la configuration de l'Interface.Address du point de terminaison B (discutée dans la section suivante).

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 à Point, vous devriez simplement utiliser une seule adresse IP (au format d'un bloc /32 avec une adresse IPv4, ou d'un bloc /64 avec une adresse IPv6).

## Configurer WireGuard sur le point de terminaison B

Maintenant configurons le point de terminaison B (le côté "serveur" de la connexion). Sur le point de terminaison B, créez un nouveau fichier à `/etc/wireguard/wg0.conf` avec le contenu suivant :

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

# paramètres locaux pour le point de terminaison B
[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 à 600 (le propriétaire peut lire+écrire ; tout le monde else est refusé l’accès — le fichier contient la clé privée du point de terminaison, qui doit être gardée secrète).

Passons en revue la configuration, paramètre par paramètre :

Interface.PrivateKey
C’est la clé privée de l’Endpoint B — remplacez cette valeur par la clé privée réelle que vous avez générée pour l’Endpoint B. Cette valeur est confidentielle, et c’est le seul endroit où elle devrait résider.
Interface.Address
C’est l’adresse IP de l’Endpoint B à 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 — voir RFC 6890 pour tous les blocs d’adresses disponibles), et ne doit pas entrer en conflit avec n’importe quel autre sous-réseau privé auquel l’endpoint lui-même ou l’un de ses pairs peut se connecter.

Avec une topologie Point à Point, cette configuration dans le fichier de configuration de l’Endpoint B devrait correspondre exactement à la configuration Peer.AllowedIPs de l’Endpoint A (discutée plus haut).

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. Pour que les paquets 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 avez définie 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 l’Endpoint B. L’Endpoint B doit être capable de recevoir du trafic UDP pour de nouvelles connexions sur ce port depuis Internet (ou où que le trafic des autres pairs WireGuard avec lesquels il communiquera vienne).

Avec une topologie Point à Point, cette configuration dans le fichier de configuration de l’Endpoint B devrait être la même que le port dans la configuration Peer.Endpoint de l’Endpoint A (discutée plus haut).

Peer.PublicKey
C’est la clé publique de l’Endpoint A — remplacez cette valeur par la clé publique réelle de l’Endpoint A. Cette valeur est utilisée pour établir une connexion sécurisée entre les deux endpoints.

Voici le texte corrigé :

par la clé publique réelle que vous avez 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 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 l’endpoint lui-même ou l’un de ses pairs peut se connecter.

Avec une topologie Point à Point, cette configuration dans le fichier de configuration de l’Endpoint B devrait correspondre exactement à la configuration de l’Interface.Address de l’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 à Point, 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 le paramètre Peer.Endpoint du fichier de configuration de l’Endpoint B que nous avons utilisé dans la configuration de l’Endpoint A. Dans ce scénario, car l’Endpoint A initie toutes les connexions à l’Endpoint B (ce qui se produit lorsque l’utilisateur final effectue des requêtes HTTP de l’Endpoint A à l’Endpoint B), l’Endpoint B n’a pas besoin de savoir comment initier une connexion à l’Endpoint A — et donc il ne nécessite pas une valeur pré-configurée pour Peer.Endpoint.

Dans la plupart des cas, vous n’avez besoin de configurer qu’un seul côté d’un tunnel WireGuard avec l’option Peer.Endpoint — vous en aurez besoin sur les deux côtés uniquement si a) vous voulez que l’un des côtés puisse initier une connexion, et b) vos règles de pare-feu et autres configurations réseau permettent réellement à l’un des côtés d’initier une connexion. Si a) est vrai mais b) ne l’est pas, consultez la section Supplémentaire : Autoriser Endpoint B à initier l’accès à Endpoint A à la fin de cet article.

Démarrer WireGuard

Sur les deux Endpoints A et B, démarrez le service wg-quick. Sur Linux avec systemd, exécutez les commandes suivantes :

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

Sur les systèmes sans systemd, exécutez cette commande à la place :

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

Quelle que soit la méthode, le démarrage du service wg-quick configurera une interface réseau WireGuard nommée wg0 sur l’endpoint et définira certaines règles de routage pour envoyer les paquets destinés à tout IP address listé dans les paramètres AllowedIPs de la configuration /etc/wireguard/wg0.conf.

Notez que le nom wg0 est simplement une 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

La sortie montre les règles de routage que wg-quick a configurées automatiquement pour vous.

Voici le texte corrigé :

art 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 8921 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 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 fichiers et les fichiers dans votre répertoire actuel. Une version légèrement plus sécurisée de cela est de créer un répertoire vide dans votre répertoire actuel et de le servir à la place :

$ mkdir dummydir && cd dummydir
$ python3 -m http.server 8080

Sur le Point de terminaison A, utilisez curl (ou un navigateur web régulier) pour demander une page au serveur web en cours d’exécution sur le port 80 du Point de terminaison B :

$ curl 10.0.0.2

Ou si le serveur web est en cours d’exécution sur le port 8080 (ou un autre port), spécifiez ce port explicitement :

$ curl 10.0.0.2:8080

Si vous voyez une sortie HTML de cette façon, 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”, il est probable que certaines règles de pare-feu ou d’autres configurations réseau bloquent le tunnel WireGuard lui-même, ou bloquent les paquets sur un côté du tunnel ou l’autre. Mais d’abord, essayez d’exécuter sudo wg show all dump sur les deux points de terminaison pour vérifier que l’interface WireGuard sur les deux est active et en cours d’exécution et configurée comme vous le souhaitez.

Sur le Point de terminaison A, vous verrez probablement une sortie comme celle-ci :

$ sudo wg show all dump
wg0     AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=    /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=    51821   off
wg0     fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=    (none)  203.0.113.2:51822       10.0.0.2/32     0       0       1234       off

Pour chaque interface (par exemple wg0), la première ligne de la sortie affiche des informations sur le point de terminaison lui-même (Point de terminaison A), et les lignes suivantes affichent des informations sur les pairs du point de terminaison (comme Point de terminaison B), un pair par ligne. La deuxième colonne à partir de la fin pour un pair montre les octets envoyés au pair, et la troisième colonne à partir de la fin montre les octets reçus. Si la deuxième colonne à partir de la fin est non nulle, mais que la troisième colonne à partir de la fin est zéro (comme c’est le cas dans l’exemple ci-dessus), WireGuard tente d’envoyer des paquets au pair, mais ne reçoit rien en retour.

Sur le Point de terminaison B, vous verrez probablement une sortie comme celle-ci :

$ sudo wg show all dump
wg0     ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=    fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=    51822   off
wg0     /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=    (none)  (none)  10.0.0.1/32     0       0       0       off

Cette sortie montre que aucun octet n’est envoyé ou reçu. Si c’est le cas pour vous, vous devez ajuster vos pare-feu ou d’autres configurations réseau jusqu’à ce qu’ils permettent à Point de terminaison A d’envoyer des paquets au pair.

aquêtes UDP à l’Endpoint B via l’adresse IP et le port configurés dans la configuration Peer.Endpoint de l’Endpoint A (dans cet exemple, c’est 203.0.113.2:51822).

Supplément : Permettre à l’Endpoint B d’initier l’accès à l’Endpoint A

Dans notre scénario d’exemple, l’Endpoint A initie toutes les connexions à l’Endpoint B (ce qui se produit lorsque l’utilisateur final effectue des requêtes HTTP de l’Endpoint A vers l’Endpoint B). Cela fonctionne bien avec les règles de pare-feu au niveau du site du scénario (affichées dans le diagramme en haut de cet article), où le port 51822 sur l’Endpoint B est ouvert à toutes nouvelles connexions, mais le port 58121 (et tous les autres ports) sur l’Endpoint A sont ouverts uniquement aux connexions déjà établies.

Cependant, si nous voulons que la relation entre l’Endpoint A et l’Endpoint B soit une “route à deux sens”, où l’un des deux points pourrait initier une connexion (comme parfois il faut ouvrir une connexion SSH de l’Endpoint A vers l’Endpoint B, et parfois il faut ouvrir une connexion SSH de l’Endpoint B vers l’Endpoint A), nous aurions besoin d’une modification de configuration :

Sur l’Endpoint A, éditez le fichier /etc/wireguard/wg0.conf pour ajouter un paramètre Peer.PersistentKeepalive, comme suit :

# /etc/wireguard/wg0.conf

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

# paramètres distants pour l'Endpoint B
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = 203.0.113.2:51822
AllowedIPs = 10.0.0.2/32
PersistentKeepalive = 25

Ensuite, redémarrez le service wg-quick sur l’Endpoint A avec systemctl, ou simplement arrêtez et redémarrez l’interface wg0 avec la commande wg-quick directement :

$ sudo wg-quick down /etc/wireguard/wg0.conf
$ sudo wg-quick up /etc/wireguard/wg0.conf

Cette configuration mise à jour entraînera l’Endpoint A à envoyer un paquet de keepalive à l’Endpoint B toutes les 25 secondes. Cela ouvre proactive une connexion vers l’Endpoint B et la maintient établie, afin que l’Endpoint B puisse librement envoyer des paquets à travers le pare-feu vers l’Endpoint A selon sa propre discrétion.

Supplément : Configurer le Pare-feu sur l’Endpoint A

Si vous avez déjà un logiciel de pare-feu configuré sur l’Endpoint A lui-même, il n’y a rien d’autre à faire — dans la plupart des cas, les règles de pare-feu que vous avez définies pour s’appliquer au trafic non local seront également applicables à votre trafic WireGuard. Ou si vous avez un logiciel préféré pour gérer les pare-feux locaux sur vos points de terminaison, utilisez ce logiciel plutôt que d’essayer de gérer des règles supplémentaires dans la configuration de votre WireGuard.

Sinon, pour un point de terminaison Linux, vous pouvez vouloir ajouter quelques règles iptables simples pour rejeter le trafic inattendu sortant de votre tunnel WireGuard. Cela empêchera un acteur malveillant qui a réussi à s’installer sur l’Endpoint B d’avoir un accès réseau non contrôlé au Endpoint A.

Sur l’Endpoint A, vérifiez d’abord ce que vous avez dans vos règles iptables avec cette commande :

$ sudo iptables -L

Si vous recevez une erreur comme “command not found”, vous devez installer iptables. Si vous avez iptables installé, mais que vous n’avez pas de règles de pare-feu configurées, vous verrez une sortie similaire à celle-ci :

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Si vous voyez au lieu de cela plusieurs écrans de règles listées, vous utilisez probablement un autre outil pour gérer le pare-feu sur l’Endpoint A et devriez utiliser cet ou

Voici le texte corrigé :

Til plutôt que de suivre les étapes suivantes.

En tant que prochain pas, arrêtez l’interface WireGuard 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 paramètres Interface.PreUp et Interface.PostDown, comme suit :

# /etc/wireguard/wg0.conf

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

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

# paramètres distants pour le Point de terminaison B
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = 203.0.113.2:51822
AllowedIPs = 10.0.0.2/32

Ensuite, 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 le Point de terminaison A ajoute deux nouvelles règles iptables avant de redémarrer l’interface WireGuard, et les supprime après avoir redémarré l’interface. La première règle accepte tous les paquets pour les connexions déjà établies (c’est-à-dire les connexions que le Point de terminaison A a initiées) entrant via le tunnel WireGuard ; et la deuxième règle refuse tout autre chose entrant dans le Point de terminaison A via le tunnel.

Notez que si vous utilisez une adresse IPv6 pour votre interface WireGuard, remplacez la commande ip6tables par la commande 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 d’abord redémarrer l’interface, de modifier vos configurations, puis de redémarrer l’interface (au lieu de modifier les configurations alors que l’interface est toujours en cours d’exécution, 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 le fermer avec PostDown, ou ajouter une règle de pare-feu avec PreUp et la supprimer avec PostDown) — donc si vous changez une règle PostDown alors que votre interface WireGuard est toujours en cours d’exécution, vous pourriez laisser accidentellement un service erroné ou une règle de pare-feu en place de la configuration précédente (que vous devrez suivre et nettoyer manuellement).

Extra: Configurer le pare-feu sur l’Endpoint B

De manière similaire, si vous avez déjà configuré un logiciel de pare-feu sur l’Endpoint B, il n’y a rien d’autre à faire — dans la plupart des cas, les règles de pare-feu que vous avez définies pour s’appliquer au trafic non local seront également applicables à votre trafic WireGuard. Ou si vous avez un logiciel préféré pour gérer les pare-feux locaux sur vos endpoints, utilisez ce logiciel plutôt que d’essayer de gérer des règles supplémentaires dans la configuration de votre WireGuard.

Sinon, pour un endpoint Linux, vous pouvez vouloir ajouter quelques règles iptables simples pour rejeter le trafic inattendu sortant de votre tunnel WireGuard. Cela empêchera un acteur malveillant qui aurait réussi à s’installer sur l’Endpoint A d’avoir un accès réseau non contrôlé à l’Endpoint B.

Sur l’Endpoint B, vérifiez d’abord ce que vous avez de configuré en tant que règles iptables avec cette commande :

$ sudo iptables -L

Si vous recevez une erreur comme “command not found”, vous devez installer iptables. Si vous avez iptables installé, mais que vous n’avez pas de règles de pare-feu configurées, vous verrez une sortie semblable à 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

Ce texte est maintenant plus fluide et la grammaire a été améliorée.

INPUT (policy ACCEPT) target prot opt source destination

Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination

Si vous voyez au lieu de cela plusieurs écrans de règles listées, vous utilisez probablement un autre outil pour gérer le pare-feu sur l’Endpoint B et devriez utiliser cet outil plutôt que de suivre les étapes suivantes.

Ensuite, arrêtez l’interface WireGuard 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 paramètres Interface.PreUp et Interface.PostDown, comme suit :

# /etc/wireguard/wg0.conf

# Paramètres locaux pour le Point de terminaison B
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822

PreUp = iptables -A INPUT -i wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
PreUp = iptables -A INPUT -i wg0 -m state --state NEW -p tcp --dport 80 -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 -m state --state NEW -p tcp --dport 80 -j ACCEPT
PostDown = iptables -D INPUT -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

Cette configuration mise à jour fera en sorte que wg-quick sur le Point de terminaison B ajoute trois nouvelles règles iptables avant de redémarrer l’interface WireGuard, et les supprime après avoir redémarré l’interface. Comme les règles pour le Point de terminaison A dans la section précédente, la première règle pour le Point de terminaison B acceptera tous les paquets pour les connexions déjà établies (c’est-à-dire les connexions que le Point de terminaison B a initiées) entrant via le tunnel WireGuard.

La deuxième règle permettra les nouvelles connexions entrantes via le tunnel WireGuard sur le port 80. Si vous souhaitez autoriser l’accès à un autre port au lieu du port 80 (comme 8080), spécifiez ce port au lieu de 80. Si vous souhaitez autoriser l’accès à plusieurs ports, ajustez la règle légèrement pour utiliser le directive multiport match avec le drapeau --dports (notez le s à la fin de --dports) — par exemple, pour permettre les ports 80 et 443 :

PreUp = iptables -A INPUT -i wg0 -m state --state NEW -p tcp -m multiport --dports 80,443 -j ACCEPT

Assurez-vous de faire exactement la même modification à la fois au paramètre PreUp et à son paramètre PostDown correspondant.

La troisième règle iptables rejette tout autre chose entrant sur le Point de terminaison B à partir du tunnel.

Notez que si vous utilisez une adresse IPv6 pour votre interface WireGuard, remplacez la commande ip6tables par la commande iptables dans tout ce qui précède.

Et encore une fois, lorsque vous jouez avec les paramètres PreUp et PostDown, il est préférable de d’abord arrêter l’interface, apporter vos modifications de configuration, puis redémarrer l’interface (au lieu de modifier les paramètres de configuration alors que l’interface est toujours en cours d’exécution, puis essayer de le 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 indésirable en cours d’exécution.

Il est recommandé d’exécuter cette règle de pare-feu en cours d’exécution ou d’ajouter 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-à-point, consultez la section “Point to Point” 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 Point” du guide Utiliser WireGuard avec UFW ; pour utiliser firewalld, consultez la section “Point to Point” du guide Utiliser WireGuard avec Firewalld ; ou pour utiliser nftables, consultez la section “Point to Point” du guide Utiliser WireGuard Avec Nftables.

11/10/2020

by Justin Ludwig


by Justin Ludwig
translated by: Patrice Le Guyader
tags: wireguard nat vpn topology point-to-point