Faire tourner votre propre serveur WireGuard sur un VPS Linux bon marché vous donne un tunnel chiffré privé, entièrement sous votre contrôle, pour quelques dollars par mois. Ce n’est pas un remplacement du pool d’IP ou du déblocage streaming d’un VPN commercial, mais pour sécuriser votre propre trafic sur le Wi-Fi public ou accéder à votre réseau domestique à distance, c’est une option vraiment solide. Voici l’installation complète sur Ubuntu.

Ce qu’il vous faut avant de commencer

Un VPS sous Ubuntu 22.04 ou 24.04 (n’importe quel hébergeur économique convient : l’offre la moins chère suffit pour un usage WireGuard personnel), un accès root ou sudo via SSH, et environ quinze minutes. Les mêmes étapes fonctionnent avec de légers ajustements sur Debian.

Envie de comparer tous les VPN côte à côte ? Consultez notre tableau comparatif complet avec les scores sur 18 critères.

Étape 1 : mettre à jour le système et installer WireGuard

Connectez-vous en SSH à votre VPS, puis lancez :

sudo apt update && sudo apt upgrade -y
sudo apt install wireguard qrencode -y

qrencode n’est pas nécessaire pour WireGuard lui-même, mais permet de générer un QR code à scanner directement dans l’application mobile plus tard, ce qui évite de copier les clés manuellement sur un téléphone.

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

cd /etc/wireguard
umask 077
wg genkey | tee server_private.key | wg pubkey > server_public.key

umask 077 a son importance ici : ça garantit que les fichiers de clés ne sont pas lisibles par d’autres utilisateurs du système. Conservez les deux fichiers ; vous référencerez la clé privée dans la config serveur, et la clé publique ne sera transmise à personne (elle reste côté serveur).

Étape 3 : créer la configuration serveur

Créez /etc/wireguard/wg0.conf :

[Interface]
PrivateKey = <collez ici le contenu de server_private.key>
Address = 10.8.0.1/24
ListenPort = 51820
SaveConfig = false

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Remplacez eth0 par le nom réel de l’interface réseau publique de votre VPS s’il diffère (vérifiez avec ip a). Les lignes PostUp/PostDown sont ce qui permet au trafic des clients connectés de sortir par l’IP publique du serveur ; sans elles, vous auriez un tunnel fonctionnel qui ne mène nulle part.

Étape 4 : activer le forwarding IP

WireGuard a besoin que le noyau transfère les paquets entre interfaces :

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Sautez cette étape et les clients se connecteront mais ne pourront pas atteindre internet à travers le tunnel, l’une des pannes de configuration WireGuard les plus fréquentes.

Étape 5 : ouvrir le port sur le pare-feu

Avec UFW :

sudo ufw allow 51820/udp
sudo ufw allow OpenSSH
sudo ufw enable

Vérifiez aussi le tableau de bord de votre hébergeur pour un pare-feu cloud séparé ou un groupe de sécurité ; certains hébergeurs bloquent des ports au niveau réseau indépendamment de ce qu’UFW autorise sur l’instance elle-même, et c’est une étape facile à oublier si une connexion échoue silencieusement plus tard.

Étape 6 : générer une paire de clés client et ajouter le pair

Sur le serveur, générez une paire de clés pour votre premier appareil client :

wg genkey | tee client1_private.key | wg pubkey > client1_public.key

Ajoutez le client comme pair en bas de /etc/wireguard/wg0.conf :

[Peer]
PublicKey = <collez ici le contenu de client1_public.key>
AllowedIPs = 10.8.0.2/32

Étape 7 : démarrer le serveur

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

Vérifiez que le service est actif avant de continuer. S’il ne démarre pas, revérifiez le nom d’interface de l’étape 3 et la syntaxe du fichier de config, une seule ligne mal placée est généralement la cause.

Étape 8 : construire la configuration client

Sur votre appareil (ou dans un fichier texte que vous transférerez de façon sécurisée), créez une config avec la clé privée du client obtenue à l’étape 6 :

[Interface]
PrivateKey = <contenu de client1_private.key>
Address = 10.8.0.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = <contenu de server_public.key>
Endpoint = <IP publique de votre VPS>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

AllowedIPs = 0.0.0.0/0 route tout le trafic client à travers le tunnel, comportement VPN complet standard. Si vous voulez seulement atteindre votre réseau domestique ou VPS sans router tout le trafic internet à travers, restreignez plutôt ce champ à ce seul sous-réseau.

Pour mobile, générez un QR code depuis cette config et scannez-le directement dans l’application WireGuard :

qrencode -t ansiutf8 < client1.conf

Étape 9 : tester la connexion

Activez le tunnel côté client, puis vérifiez votre IP publique (une recherche rapide « quelle est mon IP » ou un curl ifconfig.me depuis le client) pour confirmer qu’elle affiche désormais l’adresse de votre VPS, et non votre adresse d’origine. Vérifiez aussi que la résolution DNS ne fuit pas hors du tunnel.

Ajouter d’autres appareils

Répétez les étapes 6 à 8 pour chaque appareil supplémentaire, en utilisant une nouvelle adresse 10.8.0.x pour chacun (.3, .4, et ainsi de suite) et une nouvelle paire de clés par appareil. Ne réutilisez jamais une clé privée sur plusieurs appareils : si l’un est compromis, une clé partagée compromet tous les autres.

Renforcer la configuration

Une installation WireGuard par défaut est raisonnablement sécurisée en soi, le protocole lui-même a un code source réduit et bien audité, mais quelques étapes supplémentaires ferment des vecteurs d’attaque courants sur le VPS qui l’héberge.

Changez le port SSH par défaut et désactivez l’authentification par mot de passe. WireGuard protège le tunnel, pas le service SSH que vous avez utilisé pour tout installer. Passez à une connexion SSH par clé et envisagez de quitter le port 22 pour réduire le bruit du scan automatisé.

Installez fail2ban avec sudo apt install fail2ban, ce qui bannit automatiquement et temporairement les IP après des tentatives de connexion SSH répétées échouées, une couche de protection peu coûteuse sur un VPS exposé publiquement.

Maintenez le système à jour. Lancez sudo apt update && sudo apt upgrade -y régulièrement, ou activez unattended-upgrades pour les correctifs de sécurité. Un serveur autohébergé n’est sécurisé qu’à hauteur de sa dépendance la moins patchée.

Restreignez AllowedIPs par pair quand c’est possible. Si un appareil n’a besoin d’atteindre que votre réseau domestique plutôt qu’internet en entier, limitez son AllowedIPs à ce sous-réseau plutôt qu’à 0.0.0.0/0. Un accès plus restreint limite ce qu’un appareil compromis pourrait atteindre via le tunnel.

Problèmes fréquents et solutions

Le handshake échoue, aucune connexion du tout : presque toujours un problème de pare-feu, soit UFW sur le VPS lui-même, soit un groupe de sécurité cloud séparé qui bloque l’UDP 51820. Vérifiez les deux, ils se configurent à des endroits différents et il est facile de corriger l’un en oubliant l’autre.

Ça se connecte mais aucun accès internet via le tunnel : c’est l’étape de forwarding IP vue plus haut. Confirmez que net.ipv4.ip_forward est bien à 1 et que les règles NAT PostUp/PostDown référencent le vrai nom de votre interface publique, pas un espace réservé oublié en copiant la config.

Ça fonctionne en Wi-Fi mais échoue en data mobile : certains opérateurs mobiles bloquent ou limitent les ports UDP non standards. Si ça se produit systématiquement, changer ListenPort dans la config serveur pour un port courant comme 443 (et mettre à jour la config client en conséquence) résout souvent le problème, car le filtrage au niveau opérateur touche bien moins souvent un port qui transporte aussi du trafic HTTPS ordinaire.

Ce que l’autohébergement ne vous apporte pas

Cette installation chiffre et route votre trafic via un serveur que vous contrôlez, ce qui est vraiment précieux pour sécuriser le Wi-Fi d’un hôtel ou d’un aéroport et pour atteindre votre réseau domestique à distance. Ce que ça ne vous apporte pas, c’est un large pool d’IP pour débloquer du streaming, puisque vous sortez toujours par la même IP unique de votre VPS, ni le déni plausible que procure le partage d’une adresse IP avec des milliers d’autres utilisateurs comme le font les serveurs partagés d’un VPN commercial. Une IP dédiée unique est aussi plus facile à repérer et blacklister avec le temps par les services qu’un pool renouvelé fréquemment chez un fournisseur commercial.

Si votre objectif est l’accès streaming, la flexibilité géographique, ou vous fondre dans une large base d’utilisateurs plutôt que contrôler votre propre infrastructure, un VPN commercial reste le meilleur outil pour ce job précis ; un serveur WireGuard autohébergé et un VPN commercial résolvent des problèmes différents et se complètent plutôt qu’ils ne se concurrencent.

Notre avis

Autohéberger WireGuard sur un VPS Ubuntu bon marché prend environ quinze minutes et vous donne un vrai tunnel privé sous votre propre contrôle pour quelques dollars par mois. Excellent pour sécuriser le trafic sur Wi-Fi public et atteindre votre réseau domestique à distance. C'est le mauvais outil s'il vous faut du déblocage streaming ou un large pool d'IP tournant, c'est le travail d'un VPN commercial avec une vraie infrastructure serveur et des pratiques zéro-log auditées.

À lire aussi

Pour une installation autohébergée similaire sur du matériel moins cher, voir Installer un serveur VPN WireGuard sur Raspberry Pi avec PiVPN. Pour faire tourner WireGuard sur votre routeur domestique plutôt qu’un VPS, lisez Comment installer un VPN sur un routeur OpenWrt. Et si vous hésitez encore entre protocoles, voir Protocoles VPN expliqués 2026 : WireGuard, OpenVPN, IKEv2 comparés.