Faites tourner votre propre VPN sur un VPS offshore

Les VPN commerciaux vous demandent de faire confiance à une politique de non-journalisation écrite par leur service marketing. Votre propre VPS n'a rien à journaliser, sauf ce que vous configurez. Voici la configuration WireGuard complète — et une liste honnête des compromis.

Pourquoi l'auto-hébergement bat un VPN commercial

Le « no-logs » d'un VPN commercial est une politique. Le no-logs de votre propre VPS est une architecture. Cette différence compte plus que n'importe quel badge d'audit :

• Un fournisseur VPN voit tout par conception. Le trafic de milliers d'utilisateurs aboutit sur des serveurs que l'entreprise contrôle entièrement. Une injonction scellée plus une modification discrète de la journalisation restent invisibles pour vous — et c'est déjà arrivé, chez des fournisseurs dont vous avez entendu parler.
• Sur votre propre VPS, vous contrôlez toute la pile. Votre sshd, votre disque, votre configuration WireGuard. Nous n'exécutons rien dans votre invité et ne conservons aucun journal d'activité ou de connexion côté réseau. Nous ne pouvons pas voir dans votre VPS ; une société VPN se définit par sa capacité à voir dans son tunnel.
• La juridiction joue en votre faveur. Votre point de sortie vit là où vous le déployez — hors des alliances de surveillance si vous le choisissez, régi par les tribunaux de la juridiction d'hébergement plutôt que par le pays d'origine d'une société VPN.

Et le contrepoint honnête : un VPN auto-hébergé a une IP dédiée qui n'appartient qu'à vous. Les sites web ne la signaleront pas comme un VPN (une véritable amélioration de confort), mais tout votre trafic partage une seule adresse — vous ne vous fondez pas dans une foule de milliers de personnes. Si l'anonymat de foule est l'exigence, utilisez Tor. Si une infrastructure digne de confiance est l'exigence, rien ne bat une machine que vous contrôlez.

Ce que nous construisons

Téléphone et ordinateur portable → tunnel WireGuard → un SV-Pro dans la localisation de votre choix → l'internet ouvert. Forwarding IPv4 avec NAT sur le serveur, routage full-tunnel sur les clients (0.0.0.0/0), DNS via 9.9.9.9. Exemple d'IP serveur tout au long : 185.220.101.14 — remplacez par la vôtre. L'OS de base est Debian 13 ; si vous n'avez pas encore durci la machine, faites d'abord la liste de contrôle de 30 minutes , puis revenez.

Configuration du serveur sur Debian 13

Installer et générer les clés

Copyapt update && apt install -y wireguard qrencode

cd /etc/wireguard
umask 077

# server keypair
wg genkey | tee server.key | wg pubkey > server.pub

# one keypair per client device (laptop shown; repeat for phone)
wg genkey | tee laptop.key | wg pubkey > laptop.pub

Générer les clés client sur le serveur est acceptable pour une première configuration, puisque vous transférez de toute façon les configurations via SSH. Pour une hygiène plus stricte, générez les clés sur chaque appareil et collez uniquement les clés publiques dans la configuration du serveur.

Écrire wg0.conf

Copy# /etc/wireguard/wg0.conf
[Interface]
Address    = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <contents of server.key>
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

# laptop
[Peer]
PublicKey  = <contents of laptop.pub>
AllowedIPs = 10.10.0.2/32

# phone — repeat the block with 10.10.0.3/32

Vérifiez le nom de votre interface de liaison montante avec ip route | grep default — sur les images VPSRento, c'est eth0, mais si la vôtre diffère, ajustez les lignes MASQUERADE.

Activer le forwarding et démarrer

Copy# turn on IPv4 forwarding, persist across reboots
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/99-wireguard.conf
sysctl -p /etc/sysctl.d/99-wireguard.conf

# firewall: one UDP port, nothing else
ufw allow 51820/udp comment 'WireGuard'

# bring it up, now and on boot
systemctl enable --now wg-quick@wg0
wg show

wg show doit afficher l'interface, le port d'écoute et vos pairs. Pas encore de lignes de handshake — elles apparaissent quand un client se connecte.

Configuration client

Sur l'ordinateur portable, laptop.conf:

Copy[Interface]
PrivateKey = <contents of laptop.key>
Address    = 10.10.0.2/32
DNS        = 9.9.9.9

[Peer]
PublicKey           = <contents of server.pub>
AllowedIPs          = 0.0.0.0/0, ::/0
Endpoint            = 185.220.101.14:51820
PersistentKeepalive = 25

AllowedIPs = 0.0.0.0/0, ::/0 achemine tout via le tunnel — passez à un tunnel divisé plus tard si vous en voulez un. PersistentKeepalive maintient le chemin actif à travers le NAT domestique. Pour le téléphone, ne tapez rien : générez le fichier de configuration du téléphone sur le serveur et affichez-le sous forme de code QR dans votre terminal :

Copy# prints a scannable QR in the terminal — scan it with the WireGuard app
qrencode -t ansiutf8 < phone.conf

Activez, puis vérifiez depuis n'importe quel client : curl ifconfig.me doit répondre avec l'IP de votre VPS, et un test de fuite DNS doit montrer 9.9.9.9 l'opérateur de — pas votre FAI.

Notes de performance

WireGuard vit dans le noyau et parle ChaCha20 — sur les nœuds AMD EPYC, un tunnel unique déplace réalistement 600–900 Mbps à travers le NAT, c'est-à-dire qu'il sature le port bien avant de solliciter le CPU. La contrainte limitante n'est jamais le chiffrement ; ce sont les conditions de bande passante du plan. Un VPN est purement une question de bande passante : chaque gigaoctet téléchargé compte une fois en entrée et une fois en sortie. Sur les plans limités, ce calcul compte. Sur le SV-Pro — $19.99/mois, illimité à 1 Gbps — elle ne compte pas, c'est pourquoi le SV-Pro est le plan que nous recommandons aux constructeurs de VPN. Un client exécute une configuration familiale complète sur un seul SV-Pro à Amsterdam et n'a pas encore trouvé sa limite.

Multi-saut : entrée à Amsterdam, sortie à Reykjavik

Pour une deuxième couche, chaînez deux VPS à travers des juridictions. Nœud d'entrée aux Pays-Bas (latence faible pour vous), tunnel WireGuard entre les deux serveurs, nœud de sortie en Islande (la juridiction d'où vous voulez que votre trafic provienne). Vos appareils voient un point de terminaison à Amsterdam ; Internet voit une IP à Reykjavik ; le nœud d'entrée ne voit que du texte chiffré qui passe. Mécaniquement, ce sont les mêmes configurations que vous venez d'écrire, deux fois — une seconde interface wg sur le nœud d'entrée dont la route par défaut pointe vers le tunnel de sortie. Le coût est d'environ 40–60ms de latence ajoutée et d'un $5.99–6.89 VPS de plus. Cela vaut le coup quand votre modèle de menace a un budget ; c'est de la décoration quand il n'en a pas.

Limites honnêtes

• Vous êtes maintenant l'opérateur. Les mises à jour, la rotation des clés et la disponibilité vous appartiennent. unattended-upgrades et la liste de vérification de durcissement couvrent l'essentiel ; le reste est un apt upgrade occasionnel le dimanche.
• Une IP est une identité. Les observateurs peuvent corréler tout ce qui sort de votre adresse. Quand cela compte, redéployez dans un autre emplacement — 55 secondes plus tard, vous avez une sortie fraîche et une IP fraîche vérifiée contre plus de 40 listes noires.
• Un VPS n'est pas Tor. Cette configuration vous protège de votre FAI, des Wi-Fi hostiles et des sociétés VPN. Contre un adversaire au niveau de l'État surveillant les deux extrémités du tunnel, la corrélation temporelle existe. Sachez dans quel combat vous êtes.