Un VPN WireGuard administré depuis le navigateur
wg-easy fait tourner WireGuard et son interface d'administration dans un seul conteneur, sur un hôte Linux. Les clients se créent, se modifient, se désactivent ou se suppriment depuis le navigateur, et chacun reçoit un QR code et un fichier .conf à télécharger. Le compose de référence publie le port UDP 51820 pour le tunnel et le port TCP 51821 pour l'interface. Tout l'état tient dans un fichier SQLite du volume /etc/wireguard, sans base externe, et une commande cli dans le conteneur réinitialise au besoin le mot de passe administrateur.
Pare-feu appliqué par le serveur et liens valables cinq minutes
- Pare-feu par client : le champ « Firewall Allowed IPs » restreint les destinations d'un client (adresse, sous-réseau, port, TCP ou UDP) et le serveur l'applique par iptables. Le champ Allowed IPs, lui, ne règle que le routage, modifiable par l'utilisateur sur son poste.
- Liens à usage unique : l'adresse
/cnf/<code>sert le fichier.confd'un client pendant cinq minutes et s'efface après le premier téléchargement. Une date d'expiration désactive le client lui-même au jour dit. - Connexion : mot de passe avec TOTP en option, ou OAuth par Google, GitHub ou un fournisseur OIDC. La documentation donne la configuration d'Authelia et de VoidAuth, et la connexion par mot de passe peut être coupée.
- Métriques : le point
/metrics/prometheuss'active depuis le panneau d'administration et peut exiger un jeton Bearer. L'interface trace en plus les débits montant et descendant de chaque client connecté. - Déploiement sans assistant : les variables
INIT_*(compte, hôte, port, DNS, plages IPv4 et IPv6) remplacent l'assistant de premier démarrage, pour un déploiement par Ansible. - AmneziaWG :
EXPERIMENTAL_AWG=trueactive cette variante de WireGuard conçue contre l'inspection profonde de paquets, si son module noyau est installé sur l'hôte. Chaque client a alors besoin d'une application compatible.
Capacités réseau, proxy HTTPS attendu et comptes sans rôles
wg-easy ne s'installe que dans un conteneur. D'après la documentation, l'installation sans Docker n'est pas encore prise en charge. Le compose accorde au conteneur les capacités NET_ADMIN et SYS_MODULE, monte /lib/modules en lecture seule et active le routage IP par sysctl. Seuls x86_64 et arm64 sont pris en charge, et le guide de migration prévient que les machines armv6 et armv7 ne passent pas en v15.
L'interface attend un reverse proxy HTTPS. L'accès en HTTP exige INSECURE=true, un mode que la documentation juge non sûr et réserve au réseau local. wg-easy ne limite pas non plus le débit des requêtes : le tutoriel Caddy confie cette tâche au proxy ou à CrowdSec pour /api/auth/password, /api/auth/verify-2fa et /cnf/*. Un commentaire du code admet que les codes des liens à usage unique sont exposés à la force brute, et compte sur la fenêtre de cinq minutes et l'usage unique pour limiter le risque.
Tout compte est administrateur. La documentation OAuth prévient que les comptes créés à la première connexion reçoivent les droits d'administration, faute de système de permissions. Aucun compte restreint ne permet donc à un utilisateur de récupérer seul sa configuration.
wg-easy n'est pas un projet officiel de WireGuard. Le README dit n'avoir aucun lien avec Jason A. Donenfeld, titulaire de la marque WireGuard, ni avec ZX2C4 ou Edge Security.
La version 15.5.0 date du 24 octobre 2026. Elle corrige des failles de Node.js et passe à AmneziaWG 3.1. La branche 15, sortie le 28 mai 2025, est une réécriture complète : les variables d'environnement ont changé et la plupart des réglages sont passés dans le panneau d'administration. Le tag Docker latest désigne encore la v14, et la documentation demande d'épingler 15. Le pare-feu par client reste marqué expérimental, à vérifier avant de s'y fier en production. L'API sous /api, ni stable ni documentée, ne fonctionne pas sur un compte protégé par double authentification.