Comment configurer un VPN point à site WireGuard sous Debian 12

Scénario illustratif : Maya utilise un VPS Debian 12 comme point d’accès VPN personnel lorsqu’elle travaille depuis un café. Son ordinateur portable doit se connecter au VPS via un tunnel WireGuard chiffré et acheminer son trafic Internet IPv4 par ce serveur. Cet exemple ne constitue pas un test en conditions réelles ; les adresses IP publiques, les clés et les résultats de terminal affichés ci-dessous sont des exemples fictifs.

Cette configuration est un VPN point à site : un client se connecte à un serveur. Elle utilise les outils WireGuard fournis avec Debian, un seul pair, le transfert IPv4 et la NAT IPv4. Elle suppose que le VPS possède une adresse IPv4 publique ou avec redirection de port, qu'il est administrable avec sudo et que le port UDP 51820 est accessible. Ce guide ne couvre pas la configuration du routage IPv6 ni d'un réseau privé derrière le VPS.

Planifiez d'abord les adresses et les accès.

Cet exemple utilise 10.8.0.0/24un VPN, configuré 10.8.0.1sur le serveur et 10.8.0.2sur le premier client Maya. Utilisez un sous-réseau qui ne chevauche pas les réseaux Wi-Fi, de bureau ou cloud du client. Un conflit peut rediriger le trafic vers le mauvais chemin, même si l'établissement de la connexion réussit.

WireGuard utilise l'authentification par clé publique. Le serveur a besoin de la clé publique du client, et le client a besoin de celle du serveur ; chaque clé privée reste sur l'appareil qui la possède. La documentation WireGuard de Debian décrit la configuration du paquet et des pairs, tandis que le guide de démarrage rapide de WireGuard explique la génération des clés et le fonctionnement du maintien de la connexion. Consultez la documentation WireGuard de Debian et le guide de démarrage rapide de WireGuard .

Configurer le serveur Debian 12

1. Installez les outils

Mettez à jour l'index des paquets et installez WireGuard ainsi que nftables, qui fournira l'exemple de règle de masquage IPv4. Exécutez les commandes suivantes sur le VPS :

sudo apt update
sudo apt install wireguard nftables

Debian intègre WireGuard via le wireguardmétapaquet et ses outils. Si le serveur utilise déjà un gestionnaire de pare-feu tel que UFW, firewalld ou des règles gérées par le fournisseur, identifiez son ensemble de règles actif avant toute modification. Ne remplacez pas une configuration de pare-feu existante par cet exemple.

2. Trouvez l'interface publique et activez le transfert.

Consultez la table de routage pour savoir quelle interface Debian utilise pour atteindre une adresse IPv4 externe :

ip route get 1.1.1.1

Dans cet exemple, la route utilise «eth0 . ». Votre VPS peut afficher un nom différent, tel que « . » ens3ou «enp1s0 . » ; utilisez le nom affiché par votre VPS dans la règle NAT. Notez également l'adresse IPv4 publique ou le nom DNS du serveur. Si le serveur est situé derrière un routeur, redirigez le port UDP 51820 de ce routeur vers l'hôte Debian.

Le transfert IPv4 est nécessaire pour un tunnel complet. Activez-le maintenant et conservez-le après un redémarrage :

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

La dernière commande devrait afficher un résultat net.ipv4.ip_forward = 1. Ce paramètre autorise le transfert de paquets ; il n’ouvre pas le pare-feu ni ne fournit de NAT à lui seul.

3. Créez une paire de clés serveur et client.

Créez la clé serveur sur l'hôte Debian avec des permissions de fichiers restrictives :

sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server.key; wg pubkey < /etc/wireguard/server.key > /etc/wireguard/server.pub'

Générez la paire de clés client sur le périphérique client lorsque cela est possible. Sur un client Linux avec les éléments suivants wireguard-toolsinstallés :

umask 077
wg genkey | tee client.key | wg pubkey > client.pub

Pour un téléphone, créez un nouveau tunnel dans l'application WireGuard officielle et laissez-la générer les clés de profil. Copiez uniquement la clé publique du client sur le serveur. Conservez client.key-la confidentielle ; ne la collez jamais dans la configuration du serveur et ne l'envoyez jamais par messagerie instantanée. Le manuel Bookworm de Debianwg(8) documente les commandes principales et les champs de l'interface.

4. Créez l'interface serveur et ajoutez le pair.

Créez /etc/wireguard/wg0.confune configuration respectant la structure suivante. Remplacez chaque élément en majuscule par la clé réelle correspondante. Récupérez localement la clé privée du serveursudo cat /etc/wireguard/server.key ; placez la clé publique du client dans la section « pair ».

[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 le fichier car il contient une clé privée :

sudo chown root:root /etc/wireguard/wg0.conf
sudo chmod 600 /etc/wireguard/wg0.conf

AllowedIPs = 10.8.0.2/32Ce routeur attribue une adresse VPN à ce pair et empêche un autre pair de la revendiquer. Attribuez à chaque appareil supplémentaire sa propre paire de clés et une adresse distincte 10.8.0.3/32. N'utilisez pas un même profil client sur plusieurs appareils si vous avez besoin d'une révocation ou d'une identité distincte.

5. Ajoutez une NAT IPv4 et autorisez le port WireGuard

Pour l'exemple de tunnel IPv4 complet, les paquets sortants 10.8.0.0/24doivent emprunter l'interface publique avec NAT source. Ajoutez une règle équivalente à la configuration nftables existante du serveur ou au gestionnaire de pare-feu. Le tableau nftables ci-dessous illustre cette règle ; remplacez-le eth0par l'interface détectée à l'étape 2 :

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

Si vous utilisez Debian nftables.service, fusionnez la table dans la configuration chargée au démarrage et validez le fichier complet sudo nft -c -f /etc/nftables.confavant de le recharger. Vérifiez que votre configuration actuelle ne supprime pas ou ne remplace pas les règles existantes avant de l'appliquer. La NAT seule ne remplace pas une règle de routage qui bloque le trafic : autorisez le routage vers l'interface WAN et le trafic de retour dans votre pare-feu actif. Le manuelwg0 de Debian documente le chargement des règles nftables et les instructions NAT.nft(8)

Autorisez le trafic UDP entrant sur le port 51820, aussi bien sur le pare-feu de votre fournisseur VPS que sur celui de votre hôte. Ne pas ouvrir le port TCP 51820 pour ce tunnel WireGuard. Conservez votre règle d'accès SSH pendant la modification de la politique de pare-feu et utilisez la console de votre fournisseur ou une autre méthode de récupération si un redémarrage du pare-feu risque d'entraîner une déconnexion.

Configurer et connecter le client

6. Établir le profil du client

Créez un nouveau tunnel dans l'application cliente WireGuard ou enregistrez une configuration similaire sur un client Linux. Remplacez la clé privée, la clé publique du serveur et le point de terminaison par des valeurs réelles. L'adresse TEST-NET ci-dessous n'est qu'un exemple et ne permettra pas d'atteindre un serveur réel.

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

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

AllowedIPs = 0.0.0.0/0Le tunnel achemine les destinations IPv4 via le tunnel ; il s'agit donc de l'option pour un tunnel IPv4 complet. Pour un tunnel partagé restreint qui atteint uniquement l'adresse du serveur WireGuard, utilisez 10.8.0.0/24plutôt [nom de l'option manquante]. Pour accéder à un réseau local derrière le serveur, incluez le sous-réseau de ce réseau dans la configuration du client AllowedIPs, ajoutez une route de retour ou une NAT appropriée, et autorisez le trafic à travers le pare-feu du serveur ; ces étapes dépendent du routeur du réseau local et ne sont pas abordées dans cet exemple.

PersistentKeepalive = 25Ce paramètre permet à un client derrière un NAT de rester joignable après des périodes d'inactivité. Il est optionnel ; la documentation de WireGuard indique que la plupart des utilisateurs n'en ont pas besoin, mais recommande un intervalle de 25 secondes pour le maintien d'une correspondance NAT. Ce DNSparamètre est pris en charge par certains clients et par les clients basés surwg-quick ; si votre application l'ignore, configurez le DNS via ses propres commandes.

7. Démarrez le tunnel et vérifiez la poignée de main

Sous Debian, activez l'interface au démarrage avec :

sudo systemctl enable --now wg-quick@wg0
sudo wg show

Importez ou activez le profil client une fois le port UDP 51820 accessible. wg showVérifiez que le pair attendu apparaît et que latest handshakeles mises à jour sont effectuées après l'envoi de trafic par le client. Le wg-quick(8)manuel de Debian Bookworm décrit l'utilitaire de configuration d'interface utilisé par l'unité systemd.

L'absence de négociation indique en premier lieu un problème d'accessibilité ou de clés : vérifiez l'adresse et le port du terminal, les règles de pare-feu UDP, la clé publique du serveur dans le profil client, la clé publique du client wg0.confet l'heure système. Une négociation sans trafic fonctionnel indique généralement un problème de redirection, de NAT, de chevauchement de routes ou de règle de pare-feu dans la chaîne de redirection.

8. Vérifiez le trafic et comprenez la limite IPv6

Une fois le client connecté, testez d'abord l'adresse du tunnel du serveur, puis vérifiez l'adresse IPv4 publique vue par un service externe de vérification d'adresse IPv4 :

ping -c 3 10.8.0.1
curl -4 https://ifconfig.me

Si le protocole ICMP est autorisé, la requête ping devrait atteindre le serveur. La vérification de l'adresse IPv4 externe devrait afficher l'adresse de sortie publique du VPS pour cette configuration de tunnel complet. Si l'adresse publique reste inchangée, examinez AllowedIPsla configuration du routage, le nom de l'interface NAT et la politique de routage du pare-feu.

Cet exemple concerne uniquement IPv4. AllowedIPs = 0.0.0.0/0Il ne prend pas en charge le routage IPv6 ; par conséquent, un client disposant d'une connectivité IPv6 peut toujours envoyer du trafic IPv6 en dehors du tunnel. Ne considérez pas cette configuration comme un tunnel de confidentialité double pile complet. Pour acheminer IPv6 via WireGuard, allouez et acheminez des adresses IPv6 pour le tunnel, activez le transfert IPv6, configurez les règles de pare-feu et de routage appropriées, et ajoutez ::/0le client uniquement une fois le chemin fonctionnel de bout en bout. La prise en charge par les fournisseurs varie. Sinon, choisissez en toute connaissance de cause une stratégie de tunnel partagé et vérifiez le comportement IPv6 du client.

Problèmes courants et vérification finale rapide

• Pas de poignée de main : confirmez le port UDP entrant 51820 au niveau des pare-feu du fournisseur et de l’hôte, l’adresse IP publique ou le DNS du point de terminaison et la clé publique du pair de chaque côté.
• La négociation fonctionne, mais les sites web ne se chargent pas : vérifiez que net.ipv4.ip_forward=1la règle NAT utilise bien l’interface de sortie réelle et que le pare-feu autorise le trafic transféré.
• Seuls certains réseaux rencontrent des problèmes : vérifiez s’il 10.8.0.0/24s’agit d’un réseau local ou distant. Renumérotez le tunnel si nécessaire, en mettant à jour simultanément les deux pairs et la règle de pare-feu.
• Cela fonctionne jusqu'au redémarrage : vérifiez que l'option wg-quick@wg0est activée et que les paramètres du pare-feu et de sysctl sont conservés lors de la configuration normale du système.
• L'IPv6 utilise toujours la connexion locale : c'est normal dans cet exemple utilisant uniquement l'IPv4. Configurez et testez un tunnel IPv6 avant de vous fier à une garantie de confidentialité complète.

Avant de considérer la configuration comme terminée, vérifiez que le service serveur est actif, wg showqu'il signale une connexion récente et que les compteurs de transfert augmentent, que le client peut accéder à l' 10.8.0.1adresse IP et qu'une vérification de sortie IPv4 confirme l'adresse publique du serveur. Redémarrez uniquement après avoir configuré le pare-feu persistant et les paramètres de redirection, puis répétez ces vérifications. Pour les pairs supplémentaires, attribuez des paires de clés distinctes et des adresses IP de tunnel uniques, puis supprimez un périphérique en supprimant son entrée de pair et en rechargeant l'interface.