VPNSmith
self-host-vpnINFO

WireGuard dans Docker (2026) : la méthode propre pour s'auto-héberger avec docker-compose

Faire tourner WireGuard dans Docker correctement : linuxserver/wireguard vs wg-easy, le fichier docker-compose, les pièges NET_ADMIN et sysctl, la persistance, et quand un conteneur bat une install bare-metal.

Par Eric Gerard · Fondateur · VPNSmith — Spécialiste self-host VPN & VPS GDPR5 min de lecturePhoto via Unsplash

Transparence affiliation — Ce guide renvoie vers Contabo, le VPS sur lequel tourne notre propre WireGuard auto-hébergé. Une commande via notre lien nous rémunère sans surcoût pour vous. Nous ne documentons que ce que nous faisons réellement tourner.

Faire tourner WireGuard dans Docker apporte ce qui rend les conteneurs utiles : un serveur que l'on monte, démonte, versionne et déplace vers un autre hôte en quelques minutes, sans aucun paquet installé sur la machine elle-même. Le hic : un conteneur VPN n'est pas un conteneur normal — il touche à la pile réseau du noyau, donc quelques flags sont non négociables. Bien réglés, un WireGuard conteneurisé est aussi rapide qu'en bare-metal. Mal réglés, le tunnel se connecte mais ne route rien, en silence.

Voici la méthode propre, façonnée pour la production.

D'abord, l'erreur classique sur « WireGuard dans Docker »

WireGuard est un module noyau. Quand vous « faites tourner WireGuard dans Docker », le chiffrement et le routage se passent toujours dans le noyau Linux de l'hôte — le conteneur ne porte que les outils userspace (wg, wg-quick) et votre configuration. C'est pourquoi il n'y a aucune pénalité de performance : le chemin des données n'entre jamais dans le conteneur.

Cela explique aussi les prérequis. Pour créer et gérer une interface réseau depuis un conteneur, celui-ci a besoin d'une capability réseau élevée (NET_ADMIN), et l'hôte doit être autorisé à forwarder les paquets (net.ipv4.ip_forward=1). Ce ne sont pas des options de durcissement — sans elles, le conteneur refuse de démarrer ou monte sans rien router.

Choisir son image : linuxserver/wireguard vs wg-easy

Deux images couvrent presque tous les cas :

  • linuxserver/wireguard — un serveur propre piloté par config. Vous définissez les peers via variables d'environnement ou en éditant des fichiers dans un dossier /config monté. Il génère configs clientes et QR codes au premier lancement. Idéal pour l'infrastructure-as-code, beaucoup de peers, ou pour committer votre setup dans un dépôt privé.
  • wg-easy — WireGuard plus un tableau de bord web. Créez et révoquez des peers depuis un navigateur, scannez les QR codes pour les téléphones, suivez le trafic par client en direct. Idéal pour quelques appareils et un onboarding rapide sans toucher au CLI.

Les deux sont matures et largement utilisées. Le choix est tableau-de-bord-vs-fichiers, pas une question de qualité.

Le fichier docker-compose (wg-easy)

Des baies de serveurs éclairées en bleu dans un datacenter
Des baies de serveurs éclairées en bleu dans un datacenter

services:
  wg-easy:
    image: ghcr.io/wg-easy/wg-easy:latest
    container_name: wg-easy
    environment:
      - WG_HOST=vpn.example.com        # domaine ou IP publique de votre VPS
      - PASSWORD_HASH=<hash-bcrypt>     # login interface web
      - WG_DEFAULT_DNS=1.1.1.1
    volumes:
      - ./config:/etc/wireguard         # persistance — gardez-le sur l'hôte
    ports:
      - "51820:51820/udp"               # données WireGuard
      - "51821:51821/tcp"               # interface web (à pare-feuter sur votre IP)
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv4.conf.all.src_valid_mark=1
    restart: unless-stopped

Trois lignes font le gros du travail et sont les points de panne habituels :

  • cap_add: NET_ADMIN laisse le conteneur gérer l'interface wg0. Sans elle, le conteneur ne peut pas monter le tunnel.
  • sysctls: net.ipv4.ip_forward=1 transforme la machine en routeur. Sans cela, le tunnel se connecte mais aucun trafic ne le traverse — la cause n°1 du « ça dit connecté mais rien ne marche ».
  • volumes: ./config persiste clés et peers sur l'hôte pour qu'un recreate n'efface pas tous les clients.

Exposez le port UDP de données publiquement ; pare-feutez le port TCP de l'interface web sur votre seule IP — ne laissez jamais 51821 ouvert sur internet.

La checklist hôte (à faire avant d'accuser le conteneur)

Un conteneur peut être parfait et ne rien router à cause de la couche en dessous :

  1. Pare-feu cloud : ouvrez 51820/udp dans le security group de votre fournisseur, pas seulement sur l'hôte. C'est la panne silencieuse n°1 sur un VPS.
  2. Module noyau de l'hôte : la plupart des distros récentes embarquent le module WireGuard (Linux 5.6+). Si modprobe wireguard échoue sur l'hôte, installez les headers du noyau — le conteneur ne peut pas charger un module que l'hôte n'a pas.
  3. DNS des clients : réglez WG_DEFAULT_DNS pour que les clients ne fuitent pas leurs requêtes vers leur ancien résolveur. À combiner avec notre guide anti-fuite DNS WireGuard.

Quand le conteneur est le bon choix — et quand non

Utilisez Docker quand vous faites tourner d'autres services sur la même machine et voulez WireGuard isolé et reproductible, quand vous voulez le tableau de bord wg-easy, ou quand vous redéployez souvent entre hôtes. Tout le setup devient un fichier compose versionnable et déplaçable.

Évitez Docker quand le VPS ne fait que WireGuard. Un apt install wireguard bare-metal plus un fichier de config est plus simple, a une pièce mobile en moins, et se scripte trivialement — voyez nos templates de config WireGuard et le tutoriel complet Contabo + WireGuard. Pour une machine VPN mono-usage, le conteneur ajoute un empaquetage inutile.

Le VPS en dessous

Conteneurisé ou non, WireGuard a besoin d'un hôte avec IP publique et lien correct. Un petit VPS suffit largement — WireGuard est assez léger pour qu'une instance à 4–6 €/mois sature son port réseau bien avant que le CPU ne bronche. Nous faisons tourner le nôtre sur Contabo pour le ratio prix/bande passante :

Prenez un VPS Contabo pour votre conteneur WireGuard →

Pour le comparatif prix/performance complet entre fournisseurs, voyez le VPS le moins cher pour un VPN WireGuard.

La limite, honnêtement

Docker rend WireGuard portable, pas plus sûr. Le conteneur partage le noyau de l'hôte, tourne avec NET_ADMIN, et n'est verrouillé que dans la mesure où l'hôte l'est. Il ne met pas WireGuard en bac à sable vis-à-vis de la machine — qui a root sur l'hôte possède le tunnel. Traitez le conteneur comme un confort de déploiement, durcissez l'hôte comme si WireGuard y était installé directement, et gardez le port de l'interface web hors d'internet. Faites cela, et le WireGuard conteneurisé est le setup auto-hébergé le plus propre qui soit.

★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · 200+ Mbps garantis

Héberge ton VPN sur ton propre VPS → ContaboAccès root complet · IPv4 publique · choisis ta région