Comment configurer un serveur VPN WireGuard point à site sous Debian 12

Un VPN point à site WireGuard sur Debian 12 (Bookworm) est une solution pratique pour permettre à des ordinateurs portables, des téléphones ou des postes de travail distants d'accéder à un serveur ou d'y acheminer du trafic. Une précision importante s'impose : WireGuard ne dispose pas d'un « mode serveur » dédié. Chaque participant est un pair. Dans une architecture point à site, un hôte Debian fait office de hub stable et accessible publiquement, et chaque appareil distant obtient sa propre paire de clés et son adresse de tunnel.

Ce guide utilise les outils WireGuard fournis avec Debian, wg-quickle transfert IPv4 et nftables. Il suppose que le serveur Debian dispose d'un accès root ou sudo et que le port UDP 51820est accessible. Si le serveur se trouve derrière un routeur domestique ou professionnel, vous devez rediriger ce port UDP vers l'hôte Debian. Si votre FAI utilise un NAT de niveau opérateur (CGNAT), la redirection de port classique de votre routeur peut s'avérer insuffisante ; assurez-vous de disposer d'une adresse IP publique accessible avant de procéder au dépannage de WireGuard.

Que fera cette configuration ?

L'exemple de VPN utilise 10.8.0.0/24. Le serveur est 10.8.0.1, et le premier client est 10.8.0.2. Le client peut être configuré soit comme un VPN à tunnel complet, où le trafic Internet IPv4 transite par le serveur Debian, soit comme un tunnel partagé, où seuls certains réseaux privés utilisent WireGuard.

La documentation WireGuard de Debian confirme que WireGuard est disponible via les paquets de la distribution, tandis que le guide de démarrage rapide officiel de WireGuard documente la génération de clés wg-quicket le comportement optionnel de maintien de connexion persistant. Consultez la documentation WireGuard de Debian , le guide de démarrage rapide officiel de WireGuard et la page de manuel wg-quick de Debian .

Étape 1 : Installez WireGuard et nftables

Mettez à jour les métadonnées du paquet, puis installez WireGuard et nftables :

sudo apt update
sudo apt install wireguard nftables

On croit souvent, à tort, que Debian 12 nécessite un module noyau WireGuard externe. C'est faux. WireGuard est intégré au noyau Linux depuis des années ; les paquets Debian fournissent les outils de gestion de l'espace utilisateur nécessaires. Recommandation : utilisez les paquets Debian plutôt que de télécharger un script d'installation non vérifié.

Étape 2 : Générer la paire de clés du serveur

Créez les fichiers clés avec des permissions restrictives :

sudo -i
install -d -m 700 /etc/wireguard
umask 077
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key
chmod 600 /etc/wireguard/server_private.key
cat /etc/wireguard/server_public.key

La clé privée doit rester confidentielle. La clé publique est celle que vous copiez dans la configuration des clients. Idéalement, générez la clé privée de chaque client sur ce dernier plutôt que sur le serveur. Ainsi, le serveur n'aura jamais besoin de posséder les clés privées des clients.

Étape 3 : Activer le transfert IPv4

Un tunnel VPN peut s'établir correctement tandis que le trafic routé échoue. Cela s'explique par le fait que le transfert IP sous Linux est une configuration du noyau distincte de WireGuard. Créez un fichier sysctl persistant :

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

La commande finale devrait afficher un résultat net.ipv4.ip_forward = 1. La documentation du noyau Debian décrit ip_forwardcette option comme permettant le transfert des paquets IPv4. Action : vérifiez explicitement cette valeur au lieu de supposer que l’interface tunnel active automatiquement le routage. Consultez le manuel ip(7) de Debian et la documentation de sysctl.conf .

Étape 4 : Créer la configuration du serveur

Lisez la clé privée du serveur, puis créez/etc/wireguard/wg0.conf :

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32

Protégez ensuite le fichier :

sudo chmod 600 /etc/wireguard/wg0.conf

AllowedIPsOn confond souvent cela avec une simple liste blanche de type pare-feu. Or, cela contrôle également le routage. Sur le serveur, l'attribution 10.8.0.2/32à ce pair indique à WireGuard que les paquets destinés à cette adresse de tunnel précise appartiennent à ce client. Attribuez à chaque client une adresse unique et un [Peer]bloc distinct.

Il est également judicieux d'omettre cette option SaveConfig = truesi vous prévoyez de gérer ce fichier manuellement. Avec cette option SaveConfig, wg-quickl'état en temps réel peut être réécrit dans la configuration lors de l'arrêt, ce qui peut écraser les modifications manuelles. Recommandation : conservez un fichier déclaratif, sauf si vous souhaitez spécifiquement enregistrer l'état en temps réel.

Étape 5 : Configurer le masquage nftables

Si des clients utilisant un tunnel complet doivent accéder à Internet via le serveur Debian, la solution la plus simple consiste à utiliser le masquage IPv4. Commencez par identifier l'interface de sortie du serveur :

ip route get 1.1.1.1

Recherchez l'interface après dev, telle que eth0, ens3, ou enp1s0. Ne présumez pas qu'elle est toujours eth0.

Si vous gérez déjà un ensemble de règles /etc/nftables.conf, fusionnez la table NAT suivante avec votre ensemble de règles existant au lieu de remplacer le fichier :

table ip wireguard-nat {
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        oifname "eth0" ip saddr 10.8.0.0/24 masquerade
    }
}

Remplacez eth0par l'interface de sortie réelle. Validez avant le chargement :

sudo nft -c -f /etc/nftables.conf
sudo systemctl enable --now nftables
sudo nft list ruleset

WireGuard n'exige pas intrinsèquement la NAT. Si le réseau local de destination dispose déjà d'une route de retour 10.8.0.0/24, l'accès routé peut fonctionner sans masquage. La NAT est surtout pratique lorsque vous souhaitez que les clients distants utilisent la route Internet existante du serveur et que vous ne contrôlez pas les routes de retour. Recommandation : utilisez le masquage pour les cas simples de sortie Internet ; privilégiez le routage explicite lorsque vous contrôlez le réseau et souhaitez préserver les adresses sources.

Avez-vous également besoin de règles de pare-feu ?

Cela dépend du pare-feu déjà installé. Si votre politique d'entrée nftables est restrictive, autorisez le trafic UDP entrant 51820. Si votre chaîne de routage a une politique de blocage par défaut, ajoutez-y des règles pour autoriser le trafic vers wg0la destination prévue et le trafic de retour établi. Les fournisseurs de VPS cloud peuvent également avoir un groupe de sécurité ou un pare-feu fournisseur distinct qui doit autoriser le protocole UDP 51820.

Ne copiez pas aveuglément un tout nouveau jeu de règles de pare-feu par défaut sur un serveur SSH distant. Cela pourrait vous en bloquer l'accès. Action : inspectez sudo nft list rulesetet intégrez WireGuard à votre pare-feu existant.

Étape 6 : Créer le profil du client

Sur le client, générez sa propre paire de clés à l'aide de l'application WireGuard wg genkey. Un profil IPv4 de tunnel complet ressemble à ceci :

[Interface]
Address = 10.8.0.2/24
PrivateKey = CLIENT_PRIVATE_KEY
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Remplacez vpn.example.compar le nom DNS public ou l'adresse IP publique du serveur. Cette DNSligne est facultative et la prise en charge par les clients varie. Pour un tunnel partagé, modifiez AllowedIPs-la uniquement pour les réseaux qui doivent traverser le VPN, par exemple, 10.8.0.0/24plus un réseau local privé tel que 192.168.50.0/24.

PersistentKeepalive = 25Cette option est également facultative. La documentation officielle de WireGuard recommande une valeur de 25 secondes lorsqu'un homologue derrière un NAT ou un pare-feu avec état doit conserver son mappage pendant les périodes d'inactivité. Il ne s'agit pas d'un paramètre de performance et il n'est pas obligatoire pour tous les clients. Utilisation : utilisez-le principalement pour les clients itinérants ou derrière un NAT qui, autrement, deviendraient injoignables après une période d'inactivité.

Étape 7 : Démarrer WireGuard au démarrage

Commencez par ouvrir nftables, puis activez l'interface WireGuard :

sudo systemctl enable --now nftables
sudo systemctl enable --now wg-quick@wg0
systemctl is-active nftables
systemctl is-active wg-quick@wg0

wg-quick@wg0/etc/wireguard/wg0.confLe wg-quickmanuel confirme que cette convention d'appellation est le raccourci habituel pour les configurations stockées sous . Action/etc/wireguard : utilisez le service plutôt qu'un script de démarrage personnalisé, sauf si votre architecture de gestion de réseau est plus complexe.

Étape 8 : Vérifier la poignée de main et le trafic

Connectez le client, puis inspectez le serveur :

sudo wg show
ip address show wg0
ping -c 3 10.8.0.2

Un pair fonctionnel affiche généralement une connexion établie récemment et des compteurs de transfert non nuls après le passage du trafic dans le tunnel. Si vous avez configuré un tunnel complet, vérifiez l'adresse IPv4 publique du client à l'aide d'un service de vérification d'adresse IP fiable ; elle doit correspondre à l'adresse de sortie du serveur Debian.

Problèmes courants et leur signification réelle

Tunnel complet ou tunnel divisé : lequel choisir ?

Utilisez un tunnel complet lorsque l'objectif est de protéger le trafic sur les réseaux Wi-Fi non sécurisés ou de faire sortir le trafic Internet du serveur Debian. Utilisez un tunnel partagé lorsque vous avez uniquement besoin d'un accès distant à un serveur, un réseau domestique, un laboratoire ou une application interne et que vous souhaitez que le trafic Internet normal reste local. Le choix dépend principalement du client AllowedIPs.

Pour un déploiement point à site de petite taille, la configuration ci-dessus suffit à établir une base de travail maintenable : un bloc pair par client, des adresses de tunnel uniques, des services gérés par Debian et des nftables pour le routage nécessaire. Pour les déploiements plus importants, la distribution des clés, le cycle de vie des pairs, le DNS, la journalisation et la gestion de la configuration deviennent des aspects opérationnels à prendre en compte, même si le protocole WireGuard lui-même reste simple.

Liste de vérification finale

• wg-quick@wg0est actif et wg0possède 10.8.0.1/24.
• Le serveur écoute sur le protocole UDP 51820et ce port est accessible via n'importe quel pare-feu ou routeur en amont.
• Chaque client possède sa propre paire de clés et /32une entrée unique sur le serveur.
• net.ipv4.ip_forwardéquivalent 1lorsque l'accès routé est requis.
• Le masquage nftables est présent pour l'accès Internet en tunnel complet, sauf si vous utilisez intentionnellement des chemins de retour routés.
• wg showaffiche une poignée de main récente après l'envoi de trafic par le client.
• Le projet du client AllowedIPscorrespond à la conception prévue, qu'il s'agisse d'un tunnel complet ou d'un tunnel divisé.

Ces étapes concernent Debian 12 et l'outil WireGuard standard disponible via Debian. La topologie réseau, la NAT en amont, les pare-feu cloud, le routage du réseau local privé et la politique IPv6 étant spécifiques à l'environnement, ces éléments ne peuvent être déduits de la seule configuration de WireGuard. Il est recommandé de vérifier chaque élément séparément plutôt que de considérer tout problème de connectivité comme une défaillance de WireGuard.