Ce que nous allons mettre en place

Dans ce guide, le serveur WireGuard est installé sur une machine Debian 13 disposant :

  • soit d'une adresse IPv4 publique ;
  • soit d'une redirection de port sur le routeur ;
  • d'un accès administrateur avec sudo ;
  • d'une connexion réseau stable.

Le tunnel utilisera le réseau privé suivant :

10.66.66.0/24

Le serveur recevra l'adresse :

10.66.66.1

Le premier client recevra l'adresse :

10.66.66.2

WireGuard écoutera sur le port :

51820/UDP

L'architecture obtenue sera la suivante :

                          Internet
                              │
                              │ UDP 51820
                              ▼
                    Routeur ou pare-feu
                              │
                              │ Redirection de port
                              ▼
                Serveur Debian 13 + WireGuard
                       10.66.66.1/24
                              │
              ┌───────────────┴───────────────┐
              │                               │
        Client Windows                  Client mobile
         10.66.66.2                    10.66.66.3

À quoi sert WireGuard ?

WireGuard crée une interface réseau chiffrée entre plusieurs machines appelées pairs ou peers.

Chaque pair possède :

  • une clé privée, qui ne doit jamais être communiquée ;
  • une clé publique, transmise aux autres pairs autorisés ;
  • une ou plusieurs adresses IP accessibles à travers le tunnel.

WireGuard n'utilise pas de comptes ni de mots de passe. L'autorisation repose principalement sur les clés cryptographiques et sur la configuration des adresses autorisées.

Cette approche présente plusieurs avantages :

  • une configuration courte ;
  • peu de composants à maintenir ;
  • de bonnes performances ;
  • des clients disponibles sur les principaux systèmes ;
  • une intégration directe au réseau Linux.

WireGuard ne fournit toutefois pas nativement :

  • d'authentification multifacteur ;
  • de portail utilisateur ;
  • de gestion centralisée des identités ;
  • d'attribution automatique des adresses ;
  • de mécanisme complet de révocation autre que le retrait du pair.

Tunnel complet ou accès limité au réseau local ?

Avant l'installation, il faut choisir ce qui doit passer dans le VPN.

Tunnel complet

Avec un tunnel complet, tout le trafic IPv4 du client passe par le serveur WireGuard :

AllowedIPs = 0.0.0.0/0

Ce mode est utile pour :

  • sécuriser une connexion sur un Wi-Fi public ;
  • utiliser l'adresse IP publique du serveur ;
  • forcer le trafic à passer par le pare-feu de l'entreprise ;
  • centraliser certains contrôles réseau.

Tunnel partagé ou split tunnel

Avec un tunnel partagé, seules les destinations précisées passent par WireGuard :

AllowedIPs = 10.66.66.0/24, 192.168.1.0/24

Ce mode est utile pour :

  • accéder au serveur VPN ;
  • joindre un NAS ou un serveur interne ;
  • conserver la connexion Internet locale du client ;
  • réduire la consommation de bande passante du site distant.

Vérifier l'accès Internet du serveur

Connectez-vous au serveur en SSH, puis vérifiez la configuration réseau :

ip -br address

Affichez ensuite la route par défaut :

ip route show default

Vous devriez obtenir une ligne similaire à celle-ci :

default via 192.0.2.1 dev ens18

Dans cet exemple, l'interface utilisée pour accéder à Internet est :

ens18

Notez le nom de votre interface. Selon l'installation, elle peut s'appeler :

  • ens18 ;
  • ens3 ;
  • enp1s0 ;
  • eth0.

Vous pouvez également récupérer automatiquement son nom avec :

ip route show default | awk '/default/ {print $5; exit}'

Dans la suite de l'article, nous utiliserons ens18. Remplacez ce nom si votre serveur utilise une autre interface.

Vérifier l'adresse publique et le CGNAT

Si le serveur se trouve derrière une box ou un routeur, le port WireGuard devra être redirigé vers son adresse IP locale.

Consultez l'interface d'administration du routeur et relevez son adresse WAN.

Une adresse appartenant à l'une des plages suivantes n'est pas une adresse IPv4 publique directement joignable :

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
100.64.0.0/10

Les trois premières plages peuvent indiquer un double NAT. La plage 100.64.0.0/10 est fréquemment utilisée pour le CGNAT des opérateurs.

Dans ce cas, une simple redirection de port peut ne pas suffire. Il faudra envisager :

  • la demande d'une IPv4 publique auprès de l'opérateur ;
  • l'utilisation d'IPv6 avec une configuration adaptée ;
  • un serveur relais disposant d'une IP publique ;
  • une solution de réseau maillé capable de traverser le NAT.

Mettre Debian à jour

Commencez par mettre à jour l'index des paquets :

sudo apt update

Installez ensuite les mises à jour disponibles :

sudo apt full-upgrade

Redémarrez le serveur si une mise à jour du noyau ou de composants importants le nécessite :

sudo reboot

Reconnectez-vous ensuite en SSH.

Installer WireGuard et les outils nécessaires

Installez WireGuard, nftables et l'outil de génération de QR codes :

sudo apt install wireguard nftables qrencode

Vérifiez que la commande wg est disponible :

wg --version

Chargez le module WireGuard si nécessaire :

sudo modprobe wireguard

Vérifiez sa présence :

lsmod | grep wireguard

L'absence de résultat n'indique pas toujours une erreur tant qu'aucune interface WireGuard n'a encore été créée. La commande suivante permettra plus tard de confirmer que l'interface fonctionne :

sudo wg show

Créer les clés du serveur

Créez un répertoire protégé pour les clés :

sudo install -d -m 700 /etc/wireguard/keys

Générez la clé privée du serveur, puis dérivez sa clé publique :

sudo sh -c 'umask 077; wg genkey | tee /etc/wireguard/keys/server-private.key | wg pubkey > /etc/wireguard/keys/server-public.key'

Vérifiez les permissions :

sudo ls -l /etc/wireguard/keys

Les fichiers privés ne doivent être lisibles que par root.

Affichez la clé publique :

sudo cat /etc/wireguard/keys/server-public.key

Cette clé pourra être copiée dans les configurations clientes.

Affichez temporairement la clé privée lorsque vous serez prêt à créer le fichier de configuration :

sudo cat /etc/wireguard/keys/server-private.key

Activer le routage IPv4

Le serveur doit être autorisé à transférer les paquets entre l'interface WireGuard et son interface réseau principale.

Créez un fichier sysctl dédié :

sudo nano /etc/sysctl.d/99-wireguard-forwarding.conf

Ajoutez :

net.ipv4.ip_forward = 1

Appliquez la configuration :

sudo sysctl --system

Vérifiez la valeur :

sysctl net.ipv4.ip_forward

Le résultat attendu est :

net.ipv4.ip_forward = 1

Cette méthode rend le routage persistant après un redémarrage.

Créer la configuration du serveur

Créez le fichier avec des permissions restrictives :

sudo install -m 600 /dev/null /etc/wireguard/wg0.conf

Ouvrez-le :

sudo nano /etc/wireguard/wg0.conf

Ajoutez la configuration suivante en remplaçant CLE_PRIVEE_DU_SERVEUR :

[Interface]
Address = 10.66.66.1/24
ListenPort = 51820
PrivateKey = CLE_PRIVEE_DU_SERVEUR

Enregistrez le fichier.

Vérifiez ses permissions :

sudo stat -c '%A %U:%G %n' /etc/wireguard/wg0.conf

Le fichier doit appartenir à root et ne pas être lisible par les autres utilisateurs.

Configurer nftables

Pour qu'un client utilisant un tunnel complet puisse accéder à Internet, le serveur doit :

  1. autoriser le transfert entre wg0 et l'interface WAN ;
  2. effectuer une traduction d'adresse avec une règle de masquerade.

Avant toute modification, affichez les règles existantes :

sudo nft list ruleset

Si le serveur possède déjà un pare-feu, Docker, un hyperviseur ou des règles personnalisées, ne remplacez pas aveuglément sa configuration. Intégrez les règles WireGuard au jeu de règles existant.

La configuration suivante convient à un serveur dédié simple. Elle applique également un filtrage minimal au trafic entrant.

Sauvegardez d'abord le fichier existant :

sudo cp --archive /etc/nftables.conf /etc/nftables.conf.before-wireguard

Ouvrez le fichier :

sudo nano /etc/nftables.conf

Utilisez cette base en remplaçant ens18 et, si nécessaire, le port SSH :

#!/usr/sbin/nft -f

flush ruleset

define WAN_IF = "ens18"
define WG_IF = "wg0"
define WG_NET = 10.66.66.0/24
define WG_PORT = 51820

table inet filter {
    chain input {
        type filter hook input priority filter;
        policy drop;

        ct state invalid drop
        ct state established,related accept

        iifname "lo" accept

        ip protocol icmp accept
        ip6 nexthdr ipv6-icmp accept

        tcp dport 22 accept comment "SSH"
        udp dport $WG_PORT accept comment "WireGuard"
    }

    chain forward {
        type filter hook forward priority filter;
        policy drop;

        ct state invalid drop
        ct state established,related accept

        iifname $WG_IF oifname $WAN_IF accept
    }

    chain output {
        type filter hook output priority filter;
        policy accept;
    }
}

table ip nat {
    chain postrouting {
        type nat hook postrouting priority srcnat;
        policy accept;

        oifname $WAN_IF ip saddr $WG_NET masquerade
    }
}

Validez la syntaxe sans appliquer les règles :

sudo nft --check --file /etc/nftables.conf

Si aucune erreur n'est affichée, appliquez-les :

sudo nft --file /etc/nftables.conf

Vérifiez immédiatement que votre connexion SSH fonctionne encore en ouvrant une seconde session.

Activez ensuite le service au démarrage :

sudo systemctl enable --now nftables

Affichez les règles chargées :

sudo nft list ruleset

Cas d'un serveur utilisant déjà un pare-feu

Si un pare-feu est déjà présent, les éléments nécessaires sont les suivants :

  • autoriser 51820/UDP dans la chaîne d'entrée ;
  • autoriser le trafic transféré de wg0 vers l'interface de sortie ;
  • autoriser les réponses associées ;
  • ajouter une règle de masquerade pour 10.66.66.0/24.

N'ajoutez pas un deuxième jeu de règles complet sans comprendre les priorités et les politiques déjà appliquées.

Démarrer l'interface WireGuard

Démarrez l'interface :

sudo systemctl start wg-quick@wg0

Activez son démarrage automatique :

sudo systemctl enable wg-quick@wg0

Contrôlez le service :

sudo systemctl status wg-quick@wg0

Vérifiez l'interface :

ip address show wg0

Vérifiez l'état WireGuard :

sudo wg show

Le serveur doit écouter sur le port 51820.

Contrôlez également l'écoute UDP :

sudo ss -lunp | grep 51820

À ce stade, aucun pair n'apparaît encore. Nous allons maintenant créer le premier client.

Créer les clés du premier client

Chaque appareil doit posséder sa propre paire de clés.

Ne réutilisez pas la même configuration sur plusieurs appareils : cela provoquerait des conflits et rendrait la révocation imprécise.

Créez les clés d'un ordinateur portable :

sudo sh -c 'umask 077; wg genkey | tee /etc/wireguard/keys/portable-private.key | wg pubkey > /etc/wireguard/keys/portable-public.key'

Ajoutez une clé prépartagée facultative :

sudo sh -c 'umask 077; wg genpsk > /etc/wireguard/keys/portable-preshared.key'

La clé prépartagée ajoute un secret symétrique en complément des clés publique et privée.

Affichez la clé publique du client :

sudo cat /etc/wireguard/keys/portable-public.key

Affichez la clé prépartagée :

sudo cat /etc/wireguard/keys/portable-preshared.key

Ajouter le client au serveur

Ouvrez la configuration du serveur :

sudo nano /etc/wireguard/wg0.conf

Ajoutez à la fin :

[Peer]
# Ordinateur portable
PublicKey = CLE_PUBLIQUE_DU_CLIENT
PresharedKey = CLE_PREPARTAGEE
AllowedIPs = 10.66.66.2/32

La directive AllowedIPs a ici deux rôles :

  • elle associe l'adresse 10.66.66.2 à ce client ;
  • elle empêche ce pair d'utiliser une autre adresse du tunnel.

Rechargez la configuration :

sudo systemctl restart wg-quick@wg0

Vérifiez le pair :

sudo wg show

Vous devez voir sa clé publique et l'adresse autorisée 10.66.66.2/32.

Créer le fichier de configuration du client

Créez un répertoire dédié :

sudo install -d -m 700 /etc/wireguard/clients

Créez le fichier :

sudo install -m 600 /dev/null /etc/wireguard/clients/portable.conf

Ouvrez-le :

sudo nano /etc/wireguard/clients/portable.conf

Pour un tunnel IPv4 complet, utilisez :

[Interface]
PrivateKey = CLE_PRIVEE_DU_CLIENT
Address = 10.66.66.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = CLE_PUBLIQUE_DU_SERVEUR
PresharedKey = CLE_PREPARTAGEE
Endpoint = vpn.exemple.fr:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Remplacez :

  • CLE_PRIVEE_DU_CLIENT par le contenu de portable-private.key ;
  • CLE_PUBLIQUE_DU_SERVEUR par le contenu de server-public.key ;
  • CLE_PREPARTAGEE par le contenu de portable-preshared.key ;
  • vpn.exemple.fr par votre IP publique ou votre nom DNS ;
  • 1.1.1.1 par le résolveur DNS choisi si nécessaire.

La directive suivante force tout le trafic IPv4 dans le tunnel :

AllowedIPs = 0.0.0.0/0

La directive suivante maintient l'association NAT lorsque le client se trouve derrière un routeur ou un pare-feu :

PersistentKeepalive = 25

Elle n'est pas indispensable dans toutes les architectures, mais elle est généralement utile pour les ordinateurs portables et les téléphones changeant régulièrement de réseau.

Configuration en tunnel partagé

Pour limiter le VPN au réseau WireGuard et au réseau local 192.168.1.0/24, remplacez AllowedIPs par :

AllowedIPs = 10.66.66.0/24, 192.168.1.0/24

Adaptez le réseau local à votre infrastructure.

Attention à IPv6

La configuration précédente force uniquement le trafic IPv4 dans le tunnel.

Si le client dispose également d'une connectivité IPv6, son trafic IPv6 peut continuer à sortir directement par sa connexion locale.

Pour un véritable tunnel complet, il faut :

  • attribuer un préfixe IPv6 au tunnel ;
  • activer le routage IPv6 sur le serveur ;
  • adapter les règles nftables ;
  • ajouter ::/0 dans les routes du client.

Cette configuration dépasse le périmètre de ce premier guide.

Importer le tunnel sous Windows

Installez le client officiel WireGuard pour Windows.

Dans l'application :

  1. cliquez sur Ajouter un tunnel ;
  2. choisissez Importer un ou plusieurs tunnels depuis un fichier ;
  3. sélectionnez portable.conf ;
  4. activez le tunnel.

Avant de transférer le fichier, vérifiez qu'il n'est pas envoyé par un canal non sécurisé. Il contient la clé privée du client.

Après importation, supprimez les copies temporaires inutiles.

Importer le tunnel sur Android ou iOS

Les applications mobiles WireGuard peuvent importer un fichier ou lire un QR code.

Affichez un QR code dans le terminal :

sudo qrencode -t ansiutf8 < /etc/wireguard/clients/portable.conf

Dans l'application mobile :

  1. ajoutez un nouveau tunnel ;
  2. choisissez l'import par QR code ;
  3. scannez le code affiché ;
  4. nommez le tunnel ;
  5. activez-le.

Une fois la configuration importée, supprimez du serveur les clés privées clientes qui ne sont plus nécessaires à l'administration :

sudo shred --remove /etc/wireguard/keys/portable-private.key
sudo shred --remove /etc/wireguard/clients/portable.conf

La commande shred ne garantit pas un effacement physique fiable sur tous les systèmes de fichiers, SSD ou stockages virtualisés. Son principal intérêt ici est d'éviter de conserver inutilement une copie accessible.

Le serveur doit conserver :

  • la clé publique du client ;
  • la clé prépartagée si elle est utilisée ;
  • l'adresse attribuée au pair.

Configurer la redirection de port

Si le serveur Debian se trouve derrière un routeur, créez une redirection :

ParamètreValeur
ProtocoleUDP
Port externe51820
Adresse de destinationAdresse locale du serveur Debian
Port interne51820

Par exemple :

UDP 51820 → 192.168.1.10:51820

Attribuez au serveur une adresse locale fixe ou une réservation DHCP. Dans le cas contraire, la redirection pourrait pointer vers une autre machine après un renouvellement d'adresse.

Il n'est pas nécessaire de rediriger le port en TCP.

Tester la connexion

Désactivez temporairement le Wi-Fi du téléphone et utilisez le réseau mobile pour tester depuis l'extérieur.

Activez le tunnel, puis vérifiez sur le serveur :

sudo wg show

Un pair connecté doit afficher notamment :

  • un endpoint ;
  • un latest handshake récent ;
  • des compteurs de données reçues et envoyées.

Exemple :

peer: CLE_PUBLIQUE_DU_CLIENT
  endpoint: 198.51.100.24:41236
  allowed ips: 10.66.66.2/32
  latest handshake: 14 seconds ago
  transfer: 52.34 KiB received, 81.90 KiB sent

Depuis le client, testez d'abord l'adresse du serveur WireGuard :

10.66.66.1

Sous Linux ou macOS :

ping -c 4 10.66.66.1

Sous Windows PowerShell :

Test-NetConnection 10.66.66.1

Pour un tunnel complet, testez ensuite une adresse Internet :

ping -c 4 1.1.1.1

Puis vérifiez la résolution DNS :

getent hosts debian.org

Comprendre la commande wg show

La commande suivante est le premier outil de diagnostic :

sudo wg show

public key

Il s'agit de la clé publique du pair distant.

endpoint

Cette ligne indique la dernière adresse IP et le dernier port UDP utilisés par le pair.

L'endpoint peut changer lorsqu'un téléphone passe du Wi-Fi au réseau mobile.

allowed ips

Cette valeur indique les adresses que WireGuard associe au pair.

Côté serveur, un client classique possède généralement une adresse unique :

10.66.66.2/32

latest handshake

Cette valeur indique la date du dernier échange cryptographique réussi.

Un handshake récent confirme que :

  • le client atteint le serveur ;
  • les clés sont cohérentes ;
  • le port UDP n'est pas entièrement bloqué.

transfer

Ces compteurs montrent le volume reçu et envoyé.

Un handshake réussi avec des compteurs bloqués peut indiquer un problème de routage, de pare-feu ou de DNS.

Dépannage : aucun handshake

Si latest handshake n'apparaît jamais, vérifiez les éléments suivants.

Le service fonctionne-t-il ?

sudo systemctl status wg-quick@wg0

Le serveur écoute-t-il ?

sudo ss -lunp | grep 51820

Le port est-il autorisé dans nftables ?

sudo nft list ruleset

La redirection du routeur est-elle correcte ?

Confirmez :

  • le protocole UDP ;
  • le port externe ;
  • l'adresse locale du serveur ;
  • le port interne ;
  • l'adresse fixe du serveur.

Le client utilise-t-il le bon endpoint ?

Vérifiez :

Endpoint = vpn.exemple.fr:51820

Si votre adresse publique change régulièrement, configurez un nom DNS dynamique.

Les clés sont-elles inversées ?

Dans la configuration cliente :

  • PrivateKey est la clé privée du client ;
  • PublicKey dans [Peer] est la clé publique du serveur.

Dans la configuration serveur :

  • PublicKey dans [Peer] est la clé publique du client.

Le serveur est-il derrière un CGNAT ?

Contrôlez l'adresse WAN du routeur. Une redirection locale ne permet pas de traverser le CGNAT de l'opérateur.

Observer les paquets

Installez tcpdump si nécessaire :

sudo apt install tcpdump

Écoutez le port WireGuard :

sudo tcpdump -ni any udp port 51820

Si aucun paquet n'arrive pendant une tentative, le problème se situe probablement avant WireGuard :

  • DNS ;
  • adresse publique ;
  • redirection ;
  • pare-feu amont ;
  • CGNAT ;
  • blocage UDP.

Dépannage : handshake présent, mais aucun accès Internet

Un handshake réussi confirme le tunnel cryptographique, pas le routage complet.

Vérifiez le transfert IPv4 :

sysctl net.ipv4.ip_forward

Le résultat doit être :

net.ipv4.ip_forward = 1

Vérifiez la règle NAT :

sudo nft list table ip nat

Vérifiez que le nom de l'interface WAN est correct :

ip route show default

Contrôlez les compteurs de règles :

sudo nft list ruleset

Si le serveur utilise ens3 mais que la règle mentionne ens18, le trafic ne sera pas traduit.

Dépannage : les adresses IP fonctionnent, mais pas les noms de domaine

Si cette commande fonctionne :

ping -c 4 1.1.1.1

mais que celle-ci échoue :

getent hosts debian.org

le problème concerne probablement le DNS.

Vérifiez la ligne du client :

DNS = 1.1.1.1

Vous pouvez la remplacer par :

  • un résolveur public de confiance ;
  • le DNS de l'entreprise ;
  • un serveur Pi-hole ou AdGuard Home accessible par le VPN ;
  • un contrôleur de domaine, si les postes doivent résoudre les noms internes.

Dans ce dernier cas, autorisez les flux DNS nécessaires et utilisez l'adresse du serveur DNS interne.

Dépannage : certains sites ne chargent pas

Un tunnel peut fonctionner tandis que certaines pages restent bloquées ou chargent partiellement.

Le problème peut venir de la MTU.

Ajoutez temporairement dans la section [Interface] du client :

MTU = 1380

Reconnectez le tunnel et testez à nouveau.

La valeur optimale dépend :

  • du fournisseur d'accès ;
  • des encapsulations intermédiaires ;
  • du réseau mobile ;
  • d'un éventuel PPPoE ;
  • d'autres tunnels déjà présents.

Ne réduisez pas la MTU systématiquement si la valeur automatique fonctionne.

Dépannage : accès au VPN, mais pas au réseau local

Pour joindre un réseau interne tel que 192.168.1.0/24, vérifiez d'abord que le client possède cette route :

AllowedIPs = 10.66.66.0/24, 192.168.1.0/24

Le serveur doit ensuite être autorisé à transférer le trafic de wg0 vers l'interface du réseau local.

Enfin, le réseau local doit savoir répondre vers 10.66.66.0/24.

Deux approches sont possibles :

  1. ajouter sur le routeur local une route vers 10.66.66.0/24 via le serveur WireGuard ;
  2. appliquer une règle NAT entre WireGuard et le réseau local.

La route statique conserve les adresses réelles des clients et constitue généralement la solution la plus propre.

La règle NAT est plus rapide à déployer, mais les équipements internes verront les connexions comme provenant du serveur WireGuard.

Ajouter un deuxième appareil

Créez une nouvelle paire de clés et attribuez une nouvelle adresse :

10.66.66.3/32

Ajoutez un pair distinct au serveur :

[Peer]
# Téléphone
PublicKey = CLE_PUBLIQUE_DU_TELEPHONE
PresharedKey = CLE_PREPARTAGEE_DU_TELEPHONE
AllowedIPs = 10.66.66.3/32

Ne copiez pas la configuration du premier appareil en changeant seulement son nom.

Chaque appareil doit disposer :

  • de sa propre clé privée ;
  • de sa propre clé publique ;
  • de sa propre clé prépartagée, si utilisée ;
  • de sa propre adresse IP.

Révoquer un appareil perdu

Supprimez le bloc [Peer] correspondant dans :

/etc/wireguard/wg0.conf

Rechargez le service :

sudo systemctl restart wg-quick@wg0

Vérifiez que la clé n'apparaît plus :

sudo wg show

La révocation est immédiate dès que le pair est retiré de la configuration active.

Sauvegarder la configuration

Sauvegardez au minimum :

  • /etc/wireguard/wg0.conf ;
  • la clé privée du serveur ;
  • les clés prépartagées ;
  • /etc/sysctl.d/99-wireguard-forwarding.conf ;
  • /etc/nftables.conf ;
  • la correspondance entre les clés publiques, les appareils et les utilisateurs.

Conservez cette sauvegarde :

  • chiffrée ;
  • hors du serveur ;
  • avec des accès limités ;
  • dans votre procédure de reprise.

Bonnes pratiques de sécurité

Utiliser une clé par appareil

Cette règle permet de révoquer un seul terminal sans interrompre tous les utilisateurs.

Limiter les adresses autorisées

Côté serveur, utilisez une adresse en /32 par client :

AllowedIPs = 10.66.66.2/32

N'attribuez pas tout le sous-réseau à un poste client.

Protéger les fichiers

Vérifiez régulièrement :

sudo find /etc/wireguard -type f -exec stat -c '%a %U:%G %n' {} \;

Les fichiers contenant des secrets doivent appartenir à root et utiliser des permissions restrictives.

Mettre le serveur à jour

Appliquez régulièrement les correctifs Debian :

sudo apt update
sudo apt full-upgrade

Ne pas compter sur Fail2ban pour WireGuard

WireGuard ne fonctionne pas comme un service SSH exposant un formulaire d'authentification. Les paquets non authentifiés ne produisent pas le même type de journal exploitable par Fail2ban.

Fail2ban peut protéger d'autres services du serveur, mais il ne remplace pas la gestion rigoureuse des clés WireGuard.

Documenter les pairs

Ajoutez un commentaire au-dessus de chaque pair :

# Portable - Alexis - créé le 17/07/2026

Conservez également un inventaire séparé comprenant :

  • le propriétaire ;
  • le nom de l'appareil ;
  • l'adresse WireGuard ;
  • la clé publique ;
  • la date de création ;
  • la date de révocation éventuelle.

Prévoir les limites de l'authentification par clé

WireGuard n'intègre pas nativement le MFA ou le SSO.

Pour des besoins plus avancés, il peut être pertinent d'ajouter :

  • une passerelle d'accès avec authentification ;
  • une solution de réseau maillé gérée ;
  • un contrôle d'accès applicatif ;
  • un bastion pour les services sensibles.

Quand préférer une autre solution ?

WireGuard convient particulièrement bien lorsque vous recherchez :

  • un VPN léger ;
  • une configuration maîtrisée ;
  • de bonnes performances ;
  • un accès distant simple ;
  • un tunnel entre deux sites.

OpenVPN peut rester pertinent lorsque :

  • le transport TCP est nécessaire ;
  • le réseau bloque fortement l'UDP ;
  • une infrastructure existante dépend de certificats et de profils OpenVPN ;
  • certaines fonctions historiques sont indispensables.

Une solution de réseau maillé administrée peut être plus adaptée lorsque :

  • les utilisateurs changent fréquemment ;
  • le CGNAT empêche les connexions entrantes ;
  • le SSO et le MFA sont indispensables ;
  • vous ne souhaitez pas administrer les routes et les clés manuellement.

Checklist avant mise en production

  • ☐ Debian est à jour.
  • ☐ L'interface WAN a été identifiée.
  • ☐ Le serveur possède une IP locale fixe.
  • ☐ Le port 51820/UDP est autorisé.
  • ☐ La redirection du routeur utilise UDP.
  • ☐ L'absence de CGNAT a été vérifiée.
  • ☐ Le routage IPv4 est activé de façon persistante.
  • ☐ La syntaxe nftables a été validée.
  • ☐ Une seconde session SSH a été testée après l'application du pare-feu.
  • ☐ Chaque appareil possède une paire de clés distincte.
  • ☐ Les adresses AllowedIPs ne se chevauchent pas.
  • ☐ Le tunnel a été testé depuis un réseau extérieur.
  • ☐ La résolution DNS fonctionne.
  • ☐ La configuration est sauvegardée et chiffrée.
  • ☐ Une procédure de révocation est documentée.

Conclusion

WireGuard permet de déployer un VPN performant avec relativement peu de composants. La partie cryptographique est simple ; les erreurs apparaissent le plus souvent autour du tunnel :

  • redirection de port incorrecte ;
  • CGNAT ;
  • routage IP désactivé ;
  • règle NAT absente ;
  • interface réseau mal identifiée ;
  • routes AllowedIPs inadaptées ;
  • conflit entre deux réseaux privés.

Une installation professionnelle ne consiste donc pas uniquement à créer deux clés et un fichier wg0.conf. Elle doit également prévoir :

  • le routage ;
  • le filtrage ;
  • la gestion des appareils ;
  • la révocation ;
  • la sauvegarde ;
  • les tests depuis un réseau extérieur ;
  • la documentation de l'infrastructure.

Une fois ces éléments maîtrisés, WireGuard constitue une excellente base pour l'accès distant d'une petite entreprise, l'administration d'un serveur ou la création d'un tunnel entre plusieurs sites.

Besoin d'aide pour déployer un accès distant sécurisé ?

AGE-Info accompagne les TPE, PME et particuliers dans la mise en place de solutions VPN adaptées à leur infrastructure.

Nous pouvons notamment :

  • vérifier l'adressage et le routage ;
  • configurer le serveur et le pare-feu ;
  • préparer les profils clients ;
  • sécuriser les accès administrateurs ;
  • documenter la révocation des appareils ;
  • tester l'accès depuis l'extérieur ;
  • intégrer le VPN au réseau local de l'entreprise.