Configuration d'un serveur WireGuard sous Linux (wg0, NAT, pairs)

Utilisez un serveur WireGuard lorsque vous souhaitez accéder en privé à une infrastructure hébergée sans exposer les ports d'administration à l'Internet public. Il utilise l'authentification par clé publique, fonctionne au sein du noyau Linux depuis la version 5.6 et reste discret une fois qu'il est opérationnel. Cet article explique quand utiliser un serveur WireGuard, comment le mettre en place wg0et comment assurer le bon fonctionnement quotidien des pairs.

Quand utiliser un serveur WireGuard

Trois cas de figure couvrent la plupart des configurations : l'accès à distance, les liaisons de serveur à serveur et le routage de site à site.

Pour l’accès à distance, exécutez le serveur sur un VPS ou un serveur dédié et acheminez le trafic d’administration via le tunnel. Configurez AllowedIPs sur chaque nœud le sous-réseau de gestion privé (par exemple 10.0.0.0/24) afin que seul le trafic destiné aux systèmes internes utilise le tunnel. Tout le reste reste sur la connexion locale de l’utilisateur. Si les utilisateurs se connectent depuis leur domicile ou via des réseaux mobiles, ajoutez PersistentKeepalive = 25 du côté client pour empêcher la fermeture des sessions NAT.

Pour les liaisons de serveur à serveur, définissez AllowedIPs étroite. En général, un seul /32 ou un petit sous-réseau de serveurs. Cela évite d’acheminer du trafic non pertinent dans le tunnel et garantit un routage prévisible.

Les liaisons de site à site sont différentes. L’hôte WireGuard fait office de passerelle entre les sous-réseaux ; le transfert d’IP doit donc être activé et les règles NAT doivent acheminer le trafic de retour vers la bonne interface.

Configuration du serveur

Le serveur détient la clé privée, écoute sur UDP 51820 par défaut, et termine le tunnel. La même configuration de base s'applique aux trois schémas ci-dessus.

Clés et wg0.conf

Générez la paire de clés du serveur :

wg genkey | sudo tee /etc/wireguard/server_private.key | wg pubkey | sudo tee /etc/wireguard/server_public.key

Sécurisez la clé privée :

sudo chmod 600 /etc/wireguard/server_private.key

La clé privée reste sur le serveur. La clé publique est celle que vous transmettez à vos pairs.

Créer /etc/wireguard/wg0.conf:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o <PUBLIC_IFACE> -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o <PUBLIC_IFACE> -j MASQUERADE
 
[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.8.0.2/32

Identifiez l'interface sortante à intégrer <PUBLIC_IFACE> :

ip -o -4 route show to default | awk '{print $5}'

Transfert, pare-feu et NAT

Ouvrez le port d'écoute :

sudo ufw allow 51820/udp

Activez le transfert IP en ajoutant cette ligne à /etc/sysctl.conf:

net.ipv4.ip_forward = 1

Appliquer sans redémarrer :

sudo sysctl -p

Le PostUp et PostDown lignes dans wg0.conf ajoutent et suppriment la règle de masquage NAT lorsque l'interface est activée ou désactivée. Sans elles, le trafic de retour provenant du LAN ne parvient jamais jusqu'au pair.

La mise en service du tunnel

wg-quick gère l’interface, le routage et les PostUp/PostDown hooks en une seule commande :

sudo wg-quick up wg0

Pour un démarrage automatique après un redémarrage, activez l’unité systemd :

sudo systemctl enable --now wg-quick@wg0

Vérifiez l'état avec :

sudo wg show

Une ligne récente latest handshake ligne confirme que le tunnel fonctionne. Si elle semble obsolète ou vide, vérifiez le pare-feu, les clés des deux côtés et celles du pair AllowedIPs.

Ajout et suppression de pairs

Chaque pair a besoin de sa propre paire de clés. Générez-la sur le client, puis ajoutez la clé publique du pair à wg0.conf dans un nouveau [Peer] bloc avec une AllowedIPs entrée qui lui attribue son adresse IP de tunnel.

Utilisez /32 pour un seul appareil :

AllowedIPs = 10.8.0.3/32

Cela empêche un pair de revendiquer des adresses attribuées à un autre. Pour un accès en tunnel partagé, ne répertoriez que les sous-réseaux privés qui doivent passer par le tunnel, par exemple AllowedIPs = 10.8.0.0/24.

Appliquez les modifications de configuration sans interrompre les sessions actives :

sudo wg syncconf wg0 <(wg-quick strip wg0)

La suppression d’un pair s’effectue de la même manière. Supprimez son [Peer] bloc de wg0.conf et relancez syncconf à nouveau.

Dépannage

Si un pair se connecte mais ne parvient pas à accéder à quoi que ce soit de l'autre côté, la cause est généralement l'une des quatre suivantes :

• Le transfert IP est désactivé
• La règle de masquage NAT est manquante
• L'interface sortante dans la règle NAT est incorrecte
• AllowedIPs n'inclut pas la destination

Vérifiez le transfert :

cat /proc/sys/net/ipv4/ip_forward

Devrait renvoyer 1. Si le résultat est 0, la modification sysctl n'a pas été appliquée ou n'a pas été enregistrée.

Vérifiez la règle NAT et l'interface sortante :

sudo iptables -t nat -L POSTROUTING
ip route get 1.1.1.1

La deuxième commande affiche le nom réel de l'interface sortante, par exemple ens3, enp1s0, ou eth0. Celui-ci doit correspondre à l’interface mentionnée dans la règle MASQUERADE.

Si la négociation elle-même fait défaut, vérifiez que le port UDP 51820 est ouvert au niveau du pare-feu et chez tout fournisseur en amont, et que les deux parties disposent de la bonne clé publique de l’autre.

Pour les pairs situés derrière un NAT résidentiel ou mobile qui interrompt les sessions UDP inactives, définissez PersistentKeepalive = 25 sur le client.

Rotation des clés et clés pré-partagées

Pour les tunnels qui restent actifs pendant des mois, effectuez une rotation des clés environ une fois par an. Générez une nouvelle paire de clés, mettez à jour les deux extrémités et appliquez-la avec wg syncconf. Ne réutilisez pas une même clé privée entre deux pairs. Cela crée des conflits de routage et interrompt la transmission entre eux.

Pour ajouter une couche de sécurité supplémentaire à l’authentification par clé publique, ajoutez une clé pré-partagée par pair :

wg genpsk

Ajoutez le résultat comme suit PresharedKey = <PSK> dans le [Peer] bloc des deux côtés. WireGuard intègre la clé pré-partagée (PSK) dans la poignée de main ; ainsi, même si un attaquant parvient à compromettre l’une des clés asymétriques, il ne pourra toujours pas déchiffrer le trafic sans cette clé.

Commandes utiles au quotidien :

Si vous avez besoin d’un hôte stable et accessible au public pour terminer les tunnels WireGuard et acheminer le trafic privé vers votre infrastructure, découvrez les offres VPS illimitées de FDC.