WireGuard VPN - Présentation

WireGuard est une implémentation VPN simple, rapide et moderne, largement déployée et multiplateforme.

Les VPN ont traditionnellement été difficiles à comprendre, à configurer et à déployer. WireGuard a supprimé la majeure partie de cette complexité en se concentrant sur sa tâche unique et en laissant de côté des éléments tels que la distribution des clés et les configurations poussées. Vous obtenez une interface réseau qui crypte et vérifie le trafic, et les tâches restantes comme la configuration des adresses, le routage, etc. sont laissées aux outils système habituels comme ip-route(8) et ip-address(8).

La configuration des clés cryptographiques est très similaire à la configuration de ssh pour l’authentification par clé : chaque côté de la connexion a sa propre clé privée et publique, et la clé publique des peers, et cela suffit pour commencer à chiffrer et vérifier le trafic échangé.

Pour plus de détails sur le fonctionnement de WireGuard et des informations sur sa disponibilité sur d’autres plates-formes, veuillez consulter la section des références.

Concepts WireGuard

Il est utile de considérer WireGuard principalement comme une interface réseau, comme n’importe quelle autre. Il aura les attributs habituels, comme l’adresse IP, CIDR, et il y aura un routage associé. Mais il possède également des attributs spécifiques à WireGuard, qui gèrent la partie VPN des choses.

Tout cela peut être configuré via différents outils. WireGuard lui-même fournit ses propres outils dans le package de l’espace utilisateur wireguard-tools : wg(8) et wg-quick(8). Mais ceux-ci ne sont pas strictement nécessaires : n’importe quel espace utilisateur avec les bons privilèges et les appels du noyau peut configurer une interface WireGuard. Par exemple, systemd-networkd et network-manager peuvent le faire eux-mêmes, sans les utilitaires de l’espace utilisateur WireGuad.

Les attributs importants d’une interface WireGuard sont :

• clé privée : avec la clé publique correspondante, elles sont utilisées pour authentifier et chiffrer les données. Ceci est généré avec la commande wg genkey. port d’écoute : le port UDP sur lequel WireGuard écoutera le trafic entrant. Liste des pairs, chacun avec :
• clé publique : la contrepartie publique de la clé privée. Généré à partir de la clé privée de ce pair, à l’aide de la commande wg pubkey. point de terminaison : où envoyer le trafic chiffré. Ceci est facultatif, mais au moins un des pairs correspondants doit l’avoir pour amorcer la connexion.
• IP autorisées : liste des réseaux ou adresses de destination du tunnel interne pour ce pair lors de l’envoi de trafic, ou, lors de la réception de trafic, quels réseaux ou adresses sources sont autorisés à nous envoyer du trafic.

Ces paramètres peuvent être définis avec l’outil de bas niveau wg(8), directement via la ligne de commande ou avec un fichier de configuration. Cet outil, cependant, ne gère pas les paramètres non-WireGuard de l’interface. Il ne lui attribuera pas d’adresse IP, par exemple, ni ne configurera le routage. Pour cette raison, il est plus courant d’utiliser wg-quick(8).

wg-quick(8) gérera le cycle de vie de l’interface WireGuard. Il peut l’activer ou le désactiver, configurer le routage, exécuter des commandes arbitraires avant ou après l’activation de l’interface, etc. Il augmente le fichier de configuration que wg(8) peut utiliser, avec ses propres paramètres supplémentaires, ce qu’il est important de garder à l’esprit lors de l’envoi de ce fichier à wg(8), car il contiendra des paramètres dont wg(8) ne sait rien.

Le fichier de configuration wg-quick(8) peut avoir un nom arbitraire, et peut même être placé n’importe où sur le système, mais la meilleure pratique est :

• Placez le fichier dans /etc/wireguard.
• Nommez-le d’après l’interface qu’il contrôle. Par exemple, un fichier appelé /etc/wireguard/wg0.conf contiendra les paramètres de configuration nécessaires pour une interface réseau WireGuard appelée wg0. En suivant cette pratique, vous bénéficiez de la possibilité d’appeler wg-quick avec juste le nom de l’interface :

sudo wg-quick up wg0

Et cela affichera l’ wg0interface, lui donnera une adresse IP, configurera le routage et configurera les paramètres spécifiques de WireGuard pour qu’il fonctionne. Cette interface est généralement appelée wg0, mais peut avoir n’importe quel nom d’interface réseau valide, comme office(elle n’a pas besoin d’un numéro d’index après le nom), , home1etc. Il peut être utile de lui donner un nom significatif si vous prévoyez de vous connecter à plusieurs pairs. .

Passons en revue un exemple d’un tel fichier de configuration :

[Interface]
PrivateKey = eJdSgoS7BZ/uWkuSREN+vhCJPPr3M3UlB3v1Su/amWk=
ListenPort = 51000
Address = 10.10.11.10/24

[Peer]
# office
PublicKey = xeWmdxiLjgebpcItF1ouRo0ntrgFekquRJZQO+vsQVs=
Endpoint = wg.example.com:51000 # fake endpoint, just an example
AllowedIPs = 10.10.11.0/24, 10.10.10.0/24

Dans la rubrique [Interface]:

• Address: il s’agit de l’adresse IP et du CIDR avec lesquels l’interface _WireGuard sera configurée.
• ListenPort: le port UDP que WireGuard utilisera pour le trafic (écoute et envoi).
• PrivateKey: la clé secrète utilisée pour déchiffrer le trafic destiné à cette interface. La liste des peers, chacun dans sa propre section [Peer] (l’exemple ci-dessus n’en a qu’un), vient ensuite :
• PublicKey: la clé qui sera utilisée pour chiffrer le trafic vers ce pair.
• Endpoint: où envoyer le trafic crypté.
• AllowedIPs: lors de l’envoi de trafic, il s’agit de la liste des adresses cibles qui identifient ce pair. Lors de la réception du trafic, c’est la liste des adresses qui sont autorisées à être la source du trafic. Pour générer les paires de clés pour chaque pair, la commande wg(8) est utilisée :

$ umask 077
$ wg genkey > wg0.key
$ wg pubkey < wg0.key > wg0.pub

Et puis le contenu de wg0.key et wg0.pub peut être utilisé dans le fichier de configuration.

Voici à quoi cela ressemble lorsque cette interface est mise en place par wg-quick(8):

$ sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.10.11.10/24 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add 10.10.10.0/24 dev wg0

Voici ce qui wg-quick(8) a fait pour nous :

• Création de l’interface WireGuard wg0.
• Configuré avec les données du fichier de configuration.
• Ajout de l’IP/CIDR du Addresschamp à l’ wg0interface.
• Calculé un MTU approprié (qui peut être remplacé dans la configuration si nécessaire)
• Ajout d’un itinéraire pour AllowedIPs. Notez que dans cet exemple llowedIPs est une liste de deux blocs de réseau CIDR, mais wg-quick(8) seulement ajouté une route pour 10.10.10.0/24 et ignoré 10.10.11.0/24. C’est parce que le Address a déjà été spécifié comme un /24. Si nous avions spécifié l’adresse comme 10.10.11.10/32 à la place, wg-quick(8) nous aurions alors ajouté une route pour 10.10.11.0/24 explicitement.

Pour mieux comprendre le AllowedIPsfonctionnement, passons en revue un exemple rapide. Disons que ce système veut envoyer du trafic vers 10.10.10.201/24. Il y a une route pour cela qui dit d’utiliser l’interface wg0 pour cela :

$ ip route get 10.10.10.201
10.10.10.201 dev wg0 src 10.10.11.10 uid 1000
    cache

Puisque wg0 est une interface WireGuard, il consultera sa configuration pour voir si un peer a cette adresse cible dans la liste AllowedIPs. Il s’avère qu’un peer l’a, auquel cas le trafic :

• 1. Sera authentifié comme le notre et crypté pour ce peer.
• 2. Envoyé vers le Endpoint.

Imaginons maintenant l’inverse. Ce système recevait du trafic sur le port ListenPort UDP. S’il peut être déchiffré et vérifié comme provenant de l’un des peers répertoriés à l’aide de sa clé publique respective, et si l’adresse IP source correspond à la liste AllowedIPs correspondante, le trafic est alors accepté.

Et s’il n’y en a pas d’Endpoint ? Eh bien, pour amorcer le VPN, au moins l’un des peers doit avoir un Endpoint, sinon il ne saura pas où envoyer le trafic, et vous obtiendrez une erreur disant “Adresse de destination requise”.

Mais une fois que les peers se connaissent, celui qui n’avait pas de paramètre Endpoint dans l’interface se souviendra d’où provient le trafic et utilisera cette adresse comme point de terminaison actuel. Cela a un effet secondaire très agréable qui est de suivre automatiquement un endpoint mobile (raod warrior peer), qui ne cesse de changer d’adresse IP. C’est très courant avec les ordinateurs portables qui sont suspendus et remis en route dans un nouveau réseau, puis tentent d’établir à nouveau le VPN à partir de cette nouvelle adresse.

Peers

Vous remarquerez que le terme peer est utilisé de indifféremment pour serveur ou client. D’autres termes utilisés dans certaines documentations VPN sont gauche et droite, ce qui commence déjà à signifier que la différence entre un serveur et un client est un peu floue. Seul importe, le cas échéant, au début de l’échange de trafic : qui envoie le premier paquet de données. En ce sens, les serveurs s’attendent à rester inactifs et à attendre que les connexions soient lancées vers eux, et les clients sont les initiateurs. Par exemple, un ordinateur portable dans un café public initiant une connexion au pair VPN de l’entreprise. L’ordinateur portable doit connaître l’adresse de ce pair, car il initie l’échange. Mais le serveur n’a pas besoin de connaître l’adresse IP de l’ordinateur portable au préalable.

Sur un VPN de site à site, cependant, lorsque deux réseaux distincts sont connectés via le tunnel, qui est le serveur et qui est le client ? Les deux, il est donc préférable de les appeler peers à la place.

Récapitulatif

Principaux points à retenir de cette introduction :

• Chaque peer participant au VPN WireGuard possède une clé privée et une clé publique.
• AllowedIPs est utilisé comme clé de routage lors de l’envoi de trafic et comme ACL lors de la réception de trafic.
• Pour établir un VPN avec un peer distant, vous avez besoin de sa clé publique. De même, le peer distant aura besoin de votre clé publique.
• Au moins un des peers a besoin d’un Endpoint configuré afin de pouvoir initier le VPN.

Références:

• Le site de Wireguard
• Wireguard Quickstart
• Explications détaillées des algortihmes utilisés par Wireguard