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 |
| Cryptographie | Suite fixe moderne (ChaCha20, Curve25519, BLAKE2s) | Configurable (dont suites obsolètes possibles) |
| Emplacement | Module noyau (Linux ≥ 5.6) | Espace utilisateur |
| Configuration | Un fichier .conf minimal | Certificats X.509, fichiers multiples |
| Reconnexion / roaming | Quasi 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 |
|---|---|
Address | IP virtuelle attribuée à cette machine sur le tunnel |
AllowedIPs | Réseaux routés à travers le tunnel — 0.0.0.0/0 = tout le trafic (full tunnel), une plage précise = split tunneling |
Endpoint | Adresse et port UDP du pair distant joignable depuis l'extérieur |
PersistentKeepalive | Envoie 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
- Se connecter sur account.protonvpn.com
- Aller dans Downloads → WireGuard configuration
- Choisir le serveur (ou une fonctionnalité comme le NetShield / P2P selon le pays) et le protocole
- 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.
PersistentKeepaliveest 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èglesiptablespar UID est le seul moyen d'obtenir un vrai kill switch — sans ça, une coupure du tunnel expose l'IP réelle.
- Se connecter pour publier des commentaires