Créez votre propre VPN : WireGuard sur un VPS offshore

Pourquoi héberger son propre VPN

Un VPN commercial vous demande de faire confiance à la politique de non-journalisation d'une seule entreprise pour des milliers d'utilisateurs partageant une poignée d'adresses IP de sortie. Auto-héberger WireGuard sur un VPS offshore inverse ce modèle de confiance : vous détenez les clés, vous définissez la politique de journalisation, et les seules métadonnées qui existent sont celles que vous choisissez de conserver. Pour certains modèles de menace, c'est le bon compromis — vous cessez de faire confiance à des arguments marketing pour faire confiance à votre propre configuration et à la juridiction du serveur.

WireGuard est le choix moderne pour cette mission. Il s'agit de quelques milliers de lignes de code noyau audité avec une surface d'attaque minime comparée à OpenVPN ou IPsec, et il embarque une cryptographie moderne fixe — Curve25519, ChaCha20-Poly1305, BLAKE2s — éliminant tout risque de mauvaise configuration de la suite de chiffrement. Les handshakes sont rapides, le roaming entre Wi-Fi et mobile est transparent, et un tunnel inactif ne consomme presque rien. Sur un VPS offshore, vous obtenez une sortie dédiée dans une juridiction choisie parmi 6 régions, en ligne en environ 15 min, avec la mitigation L3/4 de 1.5 Tbps et un port non mesuré en standard sur chaque offre.

Ce qu'un tunnel auto-hébergé cache — et ce qu'il ne cache pas

Soyez honnête sur le modèle avant de le construire. Un tunnel auto-hébergé chiffre tout entre votre appareil et le VPS, le masquant de votre réseau local et de votre FAI, et remplace votre IP personnelle par l'IP du VPS pour ce que vous y faites transiter. C'est réellement utile sur un Wi-Fi hostile, pour accéder à vos propres services derrière une adresse stable, ou pour tenir votre FAI d'accès à l'écart de votre navigation.

Ce qu'il ne fait pas, c'est vous rendre anonyme. L'IP de sortie est la vôtre seule — il n'y a pas de foule d'autres utilisateurs dans laquelle se fondre, donc quiconque peut corréler les deux extrémités de la connexion, ou qui obtient une ordonnance contraignante contre l'hébergeur, peut attribuer cette adresse à votre compte. Du côté de l'hébergeur, la position est fixe : les notifications DMCA ne sont pas traitées ni répondues — la DMCA est une loi américaine sans force dans nos juridictions, et nous n'agissons que sur une ordonnance contraignante d'un tribunal ayant juridiction sur le serveur spécifique. Cela vous protège des robots de retrait automatisés ; cela ne fait pas d'un VPN auto-hébergé un outil d'anonymat. Si votre adversaire est un observateur passif global, tournez-vous vers Tor. Un tunnel auto-hébergé est un outil de confidentialité et de contrôle, pas un bouclier d'invisibilité.

Choisissez d'abord l'emplacement et l'offre

Un VPN personnel est limité par la bande passante, non par le CPU, la plus petite offre est donc amplement suffisante — le VPS Drift à $8.00/mois saturera son port bien avant que le vCPU soit mis à rude épreuve. Consacrez votre réflexion au où plutôt qu'au reste. Placez le serveur près de vous lorsque la latence pour un usage interactif importe, ou loin de vous lorsque la distance juridique prime sur le temps d'aller-retour.

La Roumanie et les Pays-Bas sont facturés au tarif de base et offrent la meilleure connectivité européenne ; la Suisse, l'Islande, la Malaisie et Panama appliquent un modificateur régional affiché en direct dans le configurateur. La Malaisie est le choix Asie-Pacifique ; Panama et l'Islande penchent davantage vers la distance juridictionnelle. En cas de doute, le guide complémentaire quelle région offshore choisir ? analyse les compromis région par région. Quel que soit votre choix, rechargez votre solde dès $30.00 en crypto et déployez — aucune vérification d'identité, aucune carte enregistrée.

Comment les pièces s'assemblent

WireGuard modélise un VPN comme un ensemble de pairs, chacun identifié par une clé publique, communiquant via une interface virtuelle (ici wg0). Le serveur dispose d'un sous-réseau privé — par exemple 10.66.0.0/24 avec un ULA IPv6 — et chaque client prend une adresse à l'intérieur. Le bloc [Interface] du serveur contient sa clé privée et son port d'écoute ; chaque client est un bloc [Peer] portant la clé publique de ce client et les adresses qu'il est autorisé à utiliser.

Côté client, AllowedIPs = 0.0.0.0/0, ::/0 est ce qui fait de ceci un VPN en tunnel complet : cela indique au client de router tout le trafic via wg0. Le serveur effectue ensuite un NAT de ce trafic via son interface réseau réelle avec une règle de masquerade, d'où la nécessité d'activer le forwarding IP dans le noyau. PersistentKeepalive = 25 maintient le chemin ouvert à travers les pare-feux à états et le NAT des opérateurs. Configurez DNS côté client sur un résolveur de confiance afin que les résolutions transitent par le tunnel plutôt que de fuiter vers votre réseau local. WireGuard est sans connexion — il n'existe pas de session longue durée pouvant être interrompue, de sorte que le lien survit à la mise en veille d'un ordinateur portable ou au passage d'un téléphone du Wi-Fi à la 4G sans aucune reconnexion. Si un chemin présente un MTU problématique et que les paquets volumineux se bloquent, réduire le MTU de l'interface cliente aux alentours de 1380 résout généralement le problème. Maîtrisez ces quatre concepts — interface, pairs, AllowedIPs, masquerade — et la configuration ci-dessous se lit comme de la prose.

Renforcez la sécurité du serveur pendant que vous y êtes

Un point d'entrée VPN mérite d'être sécurisé. Passez SSH en authentification par clé uniquement et désactivez les connexions par mot de passe et root dans /etc/ssh/sshd_config (PasswordAuthentication no, PermitRootLogin prohibit-password), puis rechargez sshd. Conservez le pare-feu en refus par défaut : les seuls ports entrants dont un serveur WireGuard a besoin sont SSH et UDP 51820. Tout le reste reste fermé.

Gardez les fichiers de clés WireGuard à 0600 — le umask 077 dans les étapes ci-dessous s'en charge — et ne copiez jamais une clé privée hors de l'hôte auquel elle appartient. Activez les mises à jour de sécurité automatiques pour que le noyau et le paquet wireguard restent à jour sans surveillance. Testez les fuites DNS une fois le tunnel actif — une résolution qui passe par votre résolveur choisi, et non par votre FAI d'accès, confirme que les requêtes restent bien dans wg0. Si vous exposez d'autres services ultérieurement, ajoutez fail2ban et des règles par service plutôt qu'élargir le pare-feu. Rien de tout cela ne dépend de l'hébergeur : le VPS est le vôtre, root est le vôtre, et l'engagement de disponibilité 99.9% maintient le serveur accessible pour que votre tunnel reste actif.

Ajoutez des appareils et maintenez le service actif

Chaque appareil qui se connecte a besoin de sa propre paire de clés et de son propre bloc [Peer] sur le serveur, chacun avec une adresse unique dans le sous-réseau — réutiliser une paire de clés sur un ordinateur portable et un téléphone casse l'itinérance et complique tout dépannage. Générez une nouvelle paire client2.key/client2.pub, ajoutez un pair, puis rechargez l'interface avec wg syncconf wg0 <(wg-quick strip wg0) ou redémarrez-la avec systemctl restart wg-quick@wg0.

Pour les téléphones, évitez la copie de fichier : générez la configuration client sous forme de QR code sur le serveur avec qrencode -t ansiutf8 < client.conf et scannez-le directement dans l'application WireGuard officielle. Pour voir qui est connecté et quand chaque pair a effectué sa dernière négociation, exécutez wg show — c'est l'intégralité du monitoring pour un déploiement personnel. Des instantanés avant une mise à jour du noyau vous donnent un retour arrière propre si une nouvelle version venait à poser problème.

Quand un VPN commercial ou Tor est le meilleur outil

L'auto-hébergement n'est pas toujours la bonne réponse, et prétendre le contraire serait malhonnête. Si votre objectif est de vous fondre dans la masse, un VPN multi-utilisateurs réputé vous offre des adresses IP de sortie partagées utilisées simultanément par de nombreuses personnes — un tunnel mono-tenant ne peut pas offrir cela. Si vous avez besoin de changer de pays de sortie à la demande, un service commercial avec une application de sélection en un clic est simplement plus pratique que de déployer des serveurs. Et si vous avez besoin d'un véritable anonymat face à un adversaire bien équipé, le routage en oignon de Tor est conçu précisément pour le problème de corrélation qu'un VPN auto-hébergé ne peut pas résoudre.

Là où l'auto-hébergement s'impose, c'est sur le contrôle et la confidentialité : vous ne faites confiance à la politique de journalisation de personne d'autre, vous disposez d'une IP dédiée stable pour l'administration et les listes blanches, et vous choisissez la juridiction. Beaucoup de personnes utilisent les deux — un tunnel auto-hébergé pour la confidentialité quotidienne et Tor pour les rares tâches exigeant l'anonymat. Choisissez l'outil adapté à la menace, pas celui qui a la meilleure page de présentation.

Étape par étape

1. 01

   Déployez le VPS et installez WireGuard

   Déployez un VPS sous Debian 13 ou Ubuntu 24.04, connectez-vous en root via SSH, puis effectuez la mise à jour et installez les deux paquets nécessaires.

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

2. 02

   Activez le transfert IP

   Un VPN en tunnel complet achemine le trafic des clients par l'interface du serveur, le noyau doit donc autoriser le transfert pour IPv4 et IPv6.

   cat > /etc/sysctl.d/99-wg.conf <<'EOF'
   net.ipv4.ip_forward=1
   net.ipv6.conf.all.forwarding=1
   EOF
   sysctl --system

3. 03

   Générer les clés du serveur

   Travaillez dans /etc/wireguard avec un umask restrictif afin que chaque fichier de clé soit créé avec les droits 0600.

   cd /etc/wireguard
   umask 077
   wg genkey | tee server.key | wg pubkey > server.pub

4. 04

   Générez une paire de clés client

   Chaque appareil reçoit sa propre paire de clés. Créez la première maintenant.

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

5. 05

   Rédigez la configuration du serveur

   Trouvez votre interface réseau réelle avec ip route get 1.1.1.1 et remplacez eth0 ci-dessous si elle diffère (souvent enp1s0). Les appels $(cat ...) insèrent les clés que vous venez de générer.

   cat > /etc/wireguard/wg0.conf <<EOF
   [Interface]
   Address = 10.66.0.1/24, fd86:ea04:1115::1/64
   ListenPort = 51820
   PrivateKey = $(cat server.key)
   PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
   PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
   
   [Peer]
   PublicKey = $(cat client.pub)
   AllowedIPs = 10.66.0.2/32, fd86:ea04:1115::2/128
   EOF

6. 06

   Rédiger la configuration client

   Créez client.conf dans le même répertoire. Collez le contenu de client.key et de server.pub aux emplacements indiqués, et renseignez Endpoint avec l'adresse IP publique de votre serveur. AllowedIPs = 0.0.0.0/0, ::/0 fait transiter tout le trafic par le tunnel.

   [Interface]
   PrivateKey = <paste client.key>
   Address = 10.66.0.2/32, fd86:ea04:1115::2/128
   DNS = 9.9.9.9
   
   [Peer]
   PublicKey = <paste server.pub>
   Endpoint = YOUR_SERVER_IP:51820
   AllowedIPs = 0.0.0.0/0, ::/0
   PersistentKeepalive = 25

7. 07

   Ouvrez le pare-feu

   Autorisez SSH et le port UDP de WireGuard, puis activez ufw. Conservez le refus par défaut pour tout le reste.

   ufw allow OpenSSH
   ufw allow 51820/udp
   ufw enable

8. 08

   Montez le tunnel

   Activez l'interface pour qu'elle survive aux redémarrages, puis vérifiez les pairs et les négociations.

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

9. 09

   Connecter un téléphone avec un QR code

   Affichez la configuration client sous forme de code scannable et importez-la dans l'application mobile WireGuard — aucun transfert de fichier requis.

   qrencode -t ansiutf8 < client.conf