WireGuard

Qu’est-ce que WireGuard ?

WireGuard est un protocole qui permet d’établir des connexions tunelisées sécurisées. Il peut s’apparenter à IPSEC ou OpenVPN.
A l’inverse des deux précédents, WireGuard est plutôt récent et date de 2020. Ce dernier est censé être plus rapide et plus simple … Pas compliqué quand on voit StrongSwan, mais est-ce sécurisé ? On va regarder tout ça.

N.B: Un rôle ansible est à créer.

Informations complémentaires sur WireGuard

• Pour le configurer, j’ai regardé la documentation présentée par IT-connect. Dans celle-ci, j’ai vu point intéressant, WireGuard ne fonctionne que en UDP. Comme ils le disent eux même, cela peut être un inconvénient pour traverser certains firewalls. Je pourrais pas passer mon WireGuard sur un flux http par exemple. Mais le DNS … A tester ?

• Autre point intéressant, WireGuard fonctionne en peer-to-peer et pas en client serveur.

• Le port par défaut de WireGuard est UDP/51820.

Installation

Pré-requis à l’installation de WireGuard

Par défaut, WireGuard est présent dans le noyau Linux, donc pas d’installation supplémentaire.

N.B : J’ai fait les commandes qui suivent en tant que root, la génération des clés étant sensible.

sudo apt update && sudo apt upgrade
sudo apt install wireguard

Configuration

Générer des clés de connexions

Wireguard va fonctionner sur un système de clé publique/clé privée, mais qui n’a rien avoir avec une IGC. C’est assez chelou, mais il va falloir se générer un couple avec une commande de WireGuard.

cd /etc/wireguard
umask 0077
wg genkey | tee private.key | wg pubkey > public.key

Faut-il préciser que la clé privée est privée et ne dois pas quitter le poste ?

Générer une configuration

Pour la configuration, je suis resté sur les bases que j’utilisais pour StrongSwan, mais incrémentée de 1 au cas où soit :

• Le peer côté serveur doit pouvoir accepter tous les clients ;

• Le peer côté client doit se connecter au serveur ;

• Le réseau d’interconnexion entre les deux est le 192.168.3.192/26.

  • Normalement, la 3.0 est pour les clients, la 3.0/25 est pour les clients locaux; la 3.128/26 pour les clients VPN et la 3.192/26 … Bah pour les admins !

  • Dans l’arborescence, on va prendre la 193 pour le serveur est celles au dessus pour les clients.

  • N.B : Je ferai peut-être l’inverse en la mettant en fin du /26, mais faut que je le calcul, et je l’ai pas là.

• J’ai mis en ListenPort le 4500/UDP, ce qui correspond au NAT-T de l’IPSEC. Petit pied de nez à StrongSwan, il faudra sans doute le changer un jour. (Et bah ça m’a valu 10 minutes de debug quand j’ai pas voulu regarder le syslog et que charon était toujours allumé …)

• J’ai appelé le fichier nomade. Il faut savoir que c’est également le nom de l’interface qui est montée par wireguard. À voir si je la renomme pas wg0 à l’issue des tests.

[Interface]
## My VPN server private IP address ##
Address = 192.168.3.193/26
ListenPort = 4500
DNS = 192.168.3.193

PrivateKey = aXXXXXXXQ=

PostUp = iptables -I INPUT 2 -i ens3 -p udp -m udp --dport 4500 -j ACCEPT; iptables -I OUTPUT 2 -o ens3 -p udp -m udp --sport 4500 -j ACCEPT; iptables -I INPUT 3 -i nomade -s 192.168.3.192/26 -d 192.168.3.193/32 -m udp -p udp --dport 53 -j ACCEPT; iptables -I INPUT 4 -i nomade -s 192.168.3.192/26 -d 192.168.3.193/32 -m tcp -p tcp --dport 53 -j ACCEPT; iptables -I OUTPUT 3 -o nomade -s 192.168.3.193/32 -d 192.168.3.192/26 -m udp -p udp --sport 53 -j ACCEPT; iptables -I OUTPUT 4 -o nomade -s 192.168.3.193/32 -d 192.168.3.192/26 -m tcp -p tcp --sport 53 -j ACCEPT; iptables -I FORWARD -i nomade -o ens3 -j ACCEPT; iptables -I FORWARD -i ens3 -o nomade -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE; ip6tables -I INPUT 2 -i ens3 -p udp -m udp --dport 4500 -j ACCEPT; ip6tables -I OUTPUT 2 -o ens3 -p udp -m udp --sport 4500 -j ACCEPT; ip6tables -I INPUT 3 -i nomade -m udp -p udp --dport 53 -j ACCEPT; ip6tables -I INPUT 4 -i nomade -m tcp -p tcp --dport 53 -j ACCEPT; ip6tables -I OUTPUT 3 -o nomade -m udp -p udp --sport 53 -j ACCEPT; ip6tables -I OUTPUT 4 -o nomade -m tcp -p tcp --sport 53 -j ACCEPT; ip6tables -I FORWARD -i nomade -o ens3 -j ACCEPT; ip6tables -I FORWARD -i ens3 -o nomade -j ACCEPT; ip6tables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -D INPUT -i ens3 -p udp -m udp --dport 4500 -j ACCEPT; iptables -D OUTPUT -o ens3 -p udp -m udp --sport 4500 -j ACCEPT; iptables -D INPUT -i nomade -s 192.168.3.192/26 -d 192.168.3.193/32 -m udp -p udp --dport 53 -j ACCEPT; iptables -D INPUT -i nomade -s 192.168.3.192/26 -d 192.168.3.193/32 -m tcp -p tcp --dport 53 -j ACCEPT; iptables -D OUTPUT -o nomade -s 192.168.3.193/32 -d 192.168.3.192/26 -m udp -p udp --sport 53 -j ACCEPT; iptables -D OUTPUT -o nomade -s 192.168.3.193/32 -d 192.168.3.192/26 -m tcp -p tcp --sport 53 -j ACCEPT; iptables -D FORWARD -i nomade -o ens3 -j ACCEPT; iptables -D FORWARD -i ens3 -o nomade -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE; ip6tables -D INPUT -i ens3 -p udp -m udp --dport 4500 -j ACCEPT; ip6tables -D OUTPUT -o ens3 -p udp -m udp --sport 4500 -j ACCEPT; ip6tables -D INPUT -i nomade -m udp -p udp --dport 53 -j ACCEPT; ip6tables -D INPUT -i nomade -m tcp -p tcp --dport 53 -j ACCEPT; ip6tables -D OUTPUT -o nomade -m udp -p udp --sport 53 -j ACCEPT; ip6tables -D OUTPUT -o nomade -m tcp -p tcp --sport 53 -j ACCEPT; ip6tables -D FORWARD -i nomade -o ens3 -j ACCEPT; ip6tables -D FORWARD -i ens3 -o nomade -j ACCEPT; ip6tables -t nat -A POSTROUTING -o ens3 -j MASQUERADE

Ok, les postup/postdown peuvent faire peur. On va les reprendre ici :

• iptables -I INPUT 2 -i ens3 -p udp -m udp --dport 4500 -j ACCEPT ==> On accepte le wireguard entrant

• iptables -I OUTPUT 2 -o ens3 -p udp -m udp --sport 4500 -j ACCEPT ==> On accepte le wireguard sortant

• iptables -I INPUT 3 -i nomade -s 192.168.3.192/26 -d 192.168.3.193/32 -m udp -p udp --dport 53 -j ACCEPT ==> On accepte les flux DNS

• iptables -I INPUT 4 -i nomade -s 192.168.3.192/26 -d 192.168.3.193/32 -m tcp -p tcp --dport 53 -j ACCEPT ==> On accepte les flux DNS

• iptables -I OUTPUT 3 -o nomade -s 192.168.3.193/32 -d 192.168.3.192/26 -m udp -p udp --sport 53 -j ACCEPT ==> On accepte les flux DNS

• iptables -I OUTPUT 4 -o nomade -s 192.168.3.193/32 -d 192.168.3.192/26 -m tcp -p tcp --sport 53 -j ACCEPT ==> On accepte les flux DNS

• iptables -I FORWARD -i nomade -o ens3 -j ACCEPT ==> On accepte que le reseau sorte.

• iptables -I FORWARD -i ens3 -o nomade -j ACCEPT ==> On accepte que le reseau sorte.

• iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE ==> Et pour tout reseau sortant, on le NAT-T.

Et après, on a les même en IP v6.

On lance le service après ça :

systemctl start wg-quick@nomade.service

Le peer côté serveur tourne. Il faut le faire côté client maintenant.

Sécurisation

La sécurisation est principalement gérée lors de la configuration (pare-feu). La seule chose qui reste à définir sur chaque machine est l’ouverture du tunnel. A chaque machine, il convient de définir si l’on veut ouvrir tout le /24 ou alors juste un point à point entre le serveur et le client.

Utilisation

Configuration du Peer côté client

Le peer client va se configurer à peu près pareil.

sudo apt update && sudo apt upgrade
sudo apt install wireguard resolvconf
cd /etc/wireguard
umask 0077
wg genkey | tee private.key | wg pubkey > public.key

Puis on met la configuration côté client. Elle va être assez semblable avec celle du serveur. J’ai appelé ma conf Luclis.conf

[Interface]
PrivateKey = aXXXXXXXQ=
Address = 192.168.3.200/32
DNS = 192.168.3.193

[Peer]
PublicKey = SBd1QYigNkh0as4/cC6Bpw13rdmyLAnOdGkPPISE4Bs=
Endpoint = vpn.luclis.fr:4500
AllowedIPs = 0.0.0.0/0
#PersistentKeepalive = 20

Le persistent KeepAlive a pas l’air de servir d’après WireGuard. On verra bien.

Rajout du client côté serveur

Ce qui est moins cool avec WireGuard et son système de clé privée, c’est qu’il faut définir chaque client wireguard à la main !
Mais bon, c’est le jeu …

echo '[Peer]
PublicKey = 2K89GowDAFano22Y8R6LkI9mLecJNgIscOi/+2anLUE=
AllowedIps = 192.168.3.200/26' >> /etc/wireguard/nomade.conf

Lancer le service

Sur le serveur, le service peut être lancer en permanence comme il ne va rediriger que le traffic lié à son peer vers ce dernier. Sur les clients par contre, tout le traffic est redirigé donc il faut le lancer à la volée. Ça nous donne côté serveur :

systemctl start wg-quick@nomade

Et côté client :

systemctl start wg-quick@Luclis

Installation de la GUI de WireGuard (sous Ubuntu)

Comme mon client est mon PC perso, je vais m’installer la GUI. C’est avant tout pour faire le test, et montrer qu’elle fonctionne, parce qu’il n’y a pas de module nm de compiler et rapide d’installation malheureusement. J’ai l’impression que le projet de Max Moser esty légèrement abandonné … On va voir si ça marche quand même. N.B : Une méthode existe avec nm-connection-editor, mais cela oblige presque à le laisser connecter h24 ou à passer par de la ligne de commande après pour le lancer.

Compilation

Pour la compilation, il faut aller jetter un oeil aux PR, qui explique comment l’installer sur GnomeShell. Le ReadMe n’étant pas à jour actuellement.

apt install wireguard git dh-autoreconf libglib2.0-dev intltool build-essential libgtk-3-dev libnma-dev libsecret-1-dev network-manager-dev resolvconf
cd /srv && git clone https://github.com/max-moser/network-manager-wireguard && cd network-manager-wireguard
curl https://raw.githubusercontent.com/max-moser/network-manager-wireguard/e60796a085c64755ccdc159f40bfe8a1d0382020/src/nm-wireguard-service.c > ./src/nm-wireguard-service.c
./autogen.sh --without-libnm-glib
./configure --without-libnm-glib --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib/x86_64-linux-gnu --libexecdir=/usr/lib/NetworkManager --localstatedir=/var
make
make install
sed -i 's|plugin=libnm-vpn-plugin-wireguard.so|plugin=/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-vpn-plugin-wireguard.so|g' /usr/lib/NetworkManager/VPN/nm-wireguard-service.name

OSEF : Je serai toujours surpris par le nombre d’erreur de compilation que l’on reçoit à chaque fois …

A l’issue de tout ça, il est possible de créer un nouveau réseau Wireguard comme n’importe quel autre type de VPN.

Installation sous Windows

Wireguard sous Windows et relativement simple : tu télécharges/installe et tu configures le fichier comme du texte.

Il faudra donc faire un nouveau peer côté serveur.
N.B : Wireguard sur Windows semble se lancer de façon automatique au démarrage (ce qui m’arrange bien pour mon pc d’admin). Ou alors il prends peut-être le dernier état (à tester).

Installation sous Android

Wireguard est également disponible sous Android ! C’est la même logique : téléchargement sur le Playstore et configuration.

Il faudra donc faire un nouveau peer côté serveur.

TroubleShooting

Test côté client

Moyen simple de le voir si le réseau fonctionne ? Si t’as internet, c’est bon. Autre point, tu peux curl le site icanhazip.com et avoir ton ip :

curl icanhazip.com
141.95.158.29

Port déjà ouvert

Je me suis fait avoir bêtement avec un StrongSwan toujours up au début. Voici le débug et comment on s’en rends compte :

ss -lunp | grep 4500 #Si t'as l'intelligence d'aller voir tes ports en ecoute. Moi je regarde que le TCP, et je l'ai pas vu du coup ...
UNCONN 0      0                               0.0.0.0:4500      0.0.0.0:*    users:(("charon",pid=50632,fd=16))
UNCONN 0      0                                  [::]:4500         [::]:*    users:(("charon",pid=50632,fd=14))
systemctl start wg-quick@nomade
Job for wg-quick@nomade.service failed because the control process exited with error code.
See "systemctl status wg-quick@nomade.service" and "journalctl -xeu wg-quick@nomade.service" for details.
systemctl status wg-quick@nomade.service
Oct 12 13:55:22 srvprj02ovh.luclis.fr wg-quick[51015]: [#] ip -4 address add 192.168.3.193/26 dev nomade
Oct 12 13:55:22 srvprj02ovh.luclis.fr wg-quick[51015]: [#] ip link set mtu 1420 up dev nomade
Oct 12 13:55:22 srvprj02ovh.luclis.fr wg-quick[51040]: RTNETLINK answers: Address already in use
Oct 12 13:55:22 srvprj02ovh.luclis.fr wg-quick[51015]: [#] ip link delete dev nomade
Oct 12 13:55:22 srvprj02ovh.luclis.fr systemd[1]: wg-quick@nomade.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Oct 12 13:55:22 srvprj02ovh.luclis.fr systemd[1]: wg-quick@nomade.service: Failed with result 'exit-code'.

N.B : Je trouve la ligne avec le RTNETLINK super trompeuse, on penserait que c’est l’adresse IP qui est déjà utilisée, mais non ! En regardant le fichier /var/log/syslog, on comprends mieux :

tail -f -n 50 /var/log/syslog
2023-10-12T14:00:22.729686+02:00 srvprj02ovh systemd[1]: Starting wg-quick@nomade.service - WireGuard via wg-quick(8) for nomade...
2023-10-12T14:00:22.812801+02:00 srvprj02ovh wg-quick[51190]: [#] ip link add nomade type wireguard
2023-10-12T14:00:22.817222+02:00 srvprj02ovh wg-quick[51190]: [#] wg setconf nomade /dev/fd/63
2023-10-12T14:00:22.820405+02:00 srvprj02ovh wg-quick[51190]: [#] ip -4 address add 192.168.3.193/26 dev nomade
2023-10-12T14:00:22.823687+02:00 srvprj02ovh charon: 06[KNL] 192.168.3.193 appeared on nomade
2023-10-12T14:00:22.824241+02:00 srvprj02ovh charon-systemd[50707]: 192.168.3.193 appeared on nomade
2023-10-12T14:00:22.832408+02:00 srvprj02ovh wg-quick[51190]: [#] ip link set mtu 1420 up dev nomade
2023-10-12T14:00:22.843763+02:00 srvprj02ovh kernel: [60841.893547] wireguard: nomade: Could not create IPv4 socket
2023-10-12T14:00:22.843779+02:00 srvprj02ovh kernel: [60841.899182] A link change request failed with some changes committed already. Interface nomade may have been left with an inconsistent configuration, please check.
2023-10-12T14:00:22.844137+02:00 srvprj02ovh wg-quick[51215]: RTNETLINK answers: Address already in use
2023-10-12T14:00:22.846700+02:00 srvprj02ovh wg-quick[51190]: [#] ip link delete dev nomade
2023-10-12T14:00:22.849096+02:00 srvprj02ovh charon: 07[KNL] 192.168.3.193 disappeared from nomade
2023-10-12T14:00:22.849330+02:00 srvprj02ovh charon-systemd[50707]: 192.168.3.193 disappeared from nomade
2023-10-12T14:00:22.849519+02:00 srvprj02ovh charon: 09[KNL] interface nomade deleted
2023-10-12T14:00:22.849709+02:00 srvprj02ovh charon-systemd[50707]: interface nomade deleted
2023-10-12T14:00:22.949748+02:00 srvprj02ovh charon: 11[NET] using forecast interface ens3
2023-10-12T14:00:22.949965+02:00 srvprj02ovh charon: 11[CFG] joining forecast multicast groups: 224.0.0.1,224.0.0.22,224.0.0.251,224.0.0.252,239.255.255.250
2023-10-12T14:00:22.950086+02:00 srvprj02ovh charon-systemd[50707]: using forecast interface ens3
2023-10-12T14:00:22.950194+02:00 srvprj02ovh charon-systemd[50707]: joining forecast multicast groups: 224.0.0.1,224.0.0.22,224.0.0.251,224.0.0.252,239.255.255.250
2023-10-12T14:00:23.017234+02:00 srvprj02ovh systemd[1]: wg-quick@nomade.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
2023-10-12T14:00:23.017478+02:00 srvprj02ovh systemd[1]: wg-quick@nomade.service: Failed with result 'exit-code'.
2023-10-12T14:00:23.017752+02:00 srvprj02ovh systemd[1]: Failed to start wg-quick@nomade.service - WireGuard via wg-quick(8) for nomade.

Dans mon cas, c’est charon qui occupe déjà le port et qui supprime simplement wireguard.

systemctl stop strongswan-starter && systemctl disable strongswan-starter
systemctl start wg-quick@nomade

Accès au serveur

Avec les règles de pare-feu que j’ai précisé, les peers n’ont pas accès au serveur sur l’interface 192.168.3.193. Toutefois, je crois qu’ils ont accès entre eux (Je ne l’ai pas vérifié). Ils passent donc par la WAN pour y avoir accès et ont donc les même restrictions. Pour créer un accès unrestricted (ex : un poste d’administration qui doit être dans le domaine), il va falloir rajouter une règle. J’ai mis cette règle en 3 pour qu’elle arrive après la règle du wireguard. Ons “en fout un peu d’où elle est précisément tant que ce n’est pas avant la dernière règle de log.

iptables -I INPUT 3 -i nomade -s 192.168.3.199 -j ACCEPT
iptables -I OUTPUT 3 -o nomade -d 192.168.3.199 -j ACCEPT

Sources

• La documentation d’IT Connect

• Le site de WireGuard

• Un site au pif pour l’installation de nm-wireguard

• Un autre site chelou pour vérifier si wg est bien configuré