Pourquoi WireGuard a remplacé OpenVPN dans mon usage quotidien, et comment récupérer une configuration WireGuard native depuis Proton VPN.

WireGuard : le VPN moderne

WireGuard est un protocole VPN conçu pour être simple, rapide et sécurisé — à l'opposé d'OpenVPN ou d'IPsec, réputés pour leur complexité de configuration et leur base de code massive. Son intégralité tient dans environ 4000 lignes de code (contre plusieurs centaines de milliers pour OpenVPN/OpenSSL), ce qui réduit drastiquement la surface d'audit et de bugs. Il est intégré nativement au noyau Linux depuis la version 5.6.

Critère WireGuard OpenVPN
Taille du code~4 000 lignes~400 000 lignes
CryptographieSuite fixe moderne (ChaCha20, Curve25519, BLAKE2s)Configurable (dont suites obsolètes possibles)
EmplacementModule noyau (Linux ≥ 5.6)Espace utilisateur
ConfigurationUn fichier .conf minimalCertificats X.509, fichiers multiples
Reconnexion / roamingQuasi instantané (pas de handshake TLS)Plus lent

Les concepts clés

Contrairement à OpenVPN et ses certificats, WireGuard n'utilise que des paires de clés publique/privée (Curve25519), un peu comme SSH. Chaque pair (client ou serveur) génère sa paire, et n'a besoin de connaître que la clé publique de l'autre pour établir le tunnel.

# Générer une paire de clés
wg genkey | tee privatekey | wg pubkey > publickey

Un fichier de configuration WireGuard typique (wg0.conf) :

[Interface]
PrivateKey = <clé privée locale>
Address = 10.8.0.2/24
DNS = 10.8.0.1

[Peer]
PublicKey = <clé publique du serveur distant>
Endpoint = vpn.exemple.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
Paramètre Rôle
AddressIP virtuelle attribuée à cette machine sur le tunnel
AllowedIPsRéseaux routés à travers le tunnel — 0.0.0.0/0 = tout le trafic (full tunnel), une plage précise = split tunneling
EndpointAdresse et port UDP du pair distant joignable depuis l'extérieur
PersistentKeepaliveEnvoie un paquet vide toutes les N secondes pour maintenir l'association NAT ouverte (indispensable derrière un NAT/box)

Installation et commandes de base

# Debian/Ubuntu
sudo apt install wireguard

# Activer le tunnel
sudo wg-quick up wg0

# État des connexions (handshake, trafic)
sudo wg show

# Couper le tunnel
sudo wg-quick down wg0

# Activer au démarrage
sudo systemctl enable wg-quick@wg0

Utiliser WireGuard avec Proton VPN

Proton VPN supporte nativement WireGuard côté serveur, en plus de son application officielle. C'est utile pour les cas où l'app officielle ne convient pas : routeur, NAS, machine sans interface graphique, ou tout simplement préférence pour une stack native plutôt qu'un client propriétaire.

Récupérer une configuration WireGuard

  1. Se connecter sur account.protonvpn.com
  2. Aller dans Downloads → WireGuard configuration
  3. Choisir le serveur (ou une fonctionnalité comme le NetShield / P2P selon le pays) et le protocole
  4. Générer et télécharger le fichier .conf — Proton génère la paire de clés côté serveur pour vous, le fichier est prêt à l'emploi
# Copier la config téléchargée à l'emplacement standard
sudo cp proton-config.conf /etc/wireguard/wg0.conf
sudo wg-quick up wg0
sudo wg show

Attention à la rotation des clés : chaque configuration téléchargée depuis le dashboard Proton VPN embarque une clé privée générée à cet instant. Si vous en régénérez une nouvelle pour le même usage, l'ancienne configuration devient invalide côté serveur — ne pas multiplier les configs actives inutilement.

NetShield et fonctionnalités avancées

Le NetShield (blocage de pubs/trackers/malwares) et le Kill Switch ne sont disponibles qu'avec le client officiel Proton VPN, pas via une configuration WireGuard brute. Pour un blocage de trackers en complément d'une configuration WireGuard manuelle, il faut le gérer soi-même côté DNS (ex. un résolveur DNS local avec blocklist) ou côté pare-feu.

Split tunneling avec une config Proton

Par défaut, la configuration Proton VPN pousse tout le trafic dans le tunnel (AllowedIPs = 0.0.0.0/0, ::/0). Pour ne router qu'une partie du trafic (par exemple uniquement l'accès à un service précis), il suffit de restreindre AllowedIPs aux plages IP concernées :

[Peer]
PublicKey = <clé publique du serveur Proton>
Endpoint = <ip-serveur-proton>:51820
AllowedIPs = 203.0.113.0/24
PersistentKeepalive = 25

Attention : cette approche demande de connaître à l'avance les plages IP à router, ce qui est peu pratique pour un usage "anonymisation du trafic web" classique — dans ce cas, garder 0.0.0.0/0 reste la bonne option.

Router Transmission exclusivement à travers le tunnel

Transmission (client BitTorrent) est un cas d'usage classique pour un VPN : le protocole BitTorrent expose l'IP publique de chaque pair à tous les autres pairs de l'essaim. Sans précaution, si le tunnel WireGuard tombe (redémarrage, coupure réseau), Transmission continue de basculer sur l'interface réseau par défaut et expose l'IP réelle — une simple connexion active du VPN au démarrage ne suffit pas comme garantie.

1. Lier Transmission à l'interface WireGuard

Transmission peut être forcé à n'écouter/émettre que depuis l'IP virtuelle du tunnel, via le paramètre bind-address-ipv4 de settings.json :

sudo systemctl stop transmission-daemon
sudo nano /var/lib/transmission-daemon/info/settings.json
{
  "bind-address-ipv4": "10.8.0.2",
  "bind-address-ipv6": "::1"
}

Remplacer 10.8.0.2 par l'IP virtuelle attribuée dans le champ Address du fichier wg0.conf (voir plus haut). Ainsi, même si l'interface par défaut reste active, Transmission ne peut pas établir de connexions par un autre chemin que le tunnel.

sudo systemctl start transmission-daemon

2. Verrou réseau (kill switch) au niveau du pare-feu

Le point précédent empêche Transmission de choisir une autre interface, mais ne bloque pas une éventuelle fuite si le processus lui-même ignore ce réglage (bug, mauvaise config). Un vrai kill switch se fait avec des règles iptables qui interdisent tout trafic sortant du user/groupe exécutant Transmission, sauf via wg0 :

# Autoriser le trafic du user debian-transmission uniquement sur l'interface wg0
sudo iptables -A OUTPUT -o wg0 -m owner --uid-owner debian-transmission -j ACCEPT
sudo iptables -A OUTPUT -o lo -m owner --uid-owner debian-transmission -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner debian-transmission -j DROP

Avec ces règles, si le tunnel WireGuard tombe, Transmission perd simplement toute connectivité au lieu de basculer en clair sur la connexion normale — c'est le comportement recherché pour un kill switch : préférer la coupure au risque de fuite.

3. Vérifier qu'il n'y a pas de fuite

Un test simple : arrêter le tunnel WireGuard et observer que Transmission n'a plus aucune activité réseau (au lieu de continuer à télécharger) :

sudo wg-quick down wg0
# observer les torrents actifs dans Transmission : le débit doit tomber à zéro immédiatement
watch -n1 'ss -tnp | grep transmission'

Des sites comme ipleak.net permettent aussi de vérifier, via un tracker torrent factice, l'IP réellement annoncée par le client BitTorrent — utile pour confirmer que seule l'IP du serveur Proton VPN apparaît, jamais l'IP réelle.

En résumé

  • WireGuard est plus simple, plus rapide et plus facile à auditer qu'OpenVPN, grâce à une base de code réduite et une cryptographie moderne non configurable.
  • La configuration repose uniquement sur des paires de clés publique/privée, pas de PKI à gérer.
  • PersistentKeepalive est indispensable derrière un NAT pour garder le tunnel ouvert.
  • Proton VPN permet de générer des fichiers de configuration WireGuard prêts à l'emploi depuis son dashboard, utilisables avec les outils natifs wg-quick/wg, sans dépendre du client officiel.
  • Le NetShield et le Kill Switch restent réservés au client officiel — une config WireGuard manuelle n'a que le tunnel chiffré, rien de plus.
  • Pour un client BitTorrent comme Transmission, combiner liaison à l'IP du tunnel (bind-address-ipv4) et règles iptables par UID est le seul moyen d'obtenir un vrai kill switch — sans ça, une coupure du tunnel expose l'IP réelle.
Étiquettes