VPN WireGuard : ce que signifie le fichier de configuration, comment vérifier le tunnel et quand un proxy est le meilleur outil
WireGuard est un protocole, pas un service — donc « VPN WireGuard » signifie généralement qu'un fournisseur vous remet un fichier de configuration que vous importez dans l'application officielle. Voici ce que fait chaque ligne de cette configuration, comment prouver que le tunnel transporte réellement votre trafic, comment il
Rechercher « VPN WireGuard » tend à renvoyer deux choses très différentes : le protocole open source et ses applications clientes officielles d'un côté, et une longue liste de fournisseurs commerciaux qui vous permettent de télécharger un fichier de configuration pour celui-ci de l'autre. Les deux sont des réponses correctes à la même requête, c'est pourquoi tant de personnes repartent encore incertaines de ce qu'elles ont installé.
Ce guide traite WireGuard pour ce qu'il est : un protocole avec un format de configuration petit et lisible. Une fois que vous comprenez les quatre ou cinq lignes de ce fichier, la plupart des problèmes WireGuard — « il se connecte mais mon IP n'a pas changé », « le handshake ne se termine jamais », « seules certaines applications sont tunnelisées » — cessent d'être des mystères et deviennent des paramètres que vous pouvez corriger.
WireGuard est un protocole, pas un abonnement
WireGuard est un protocole VPN moderne construit sur le framework du protocole Noise. Il utilise des paires de clés Curve25519, ChaCha20-Poly1305 pour le chiffrement authentifié, et transporte son trafic sur UDP. Sous Linux, il s'exécute dans le noyau ; sous Windows, macOS, Android et iOS, les applications clientes officielles sont gratuites et open source.
Ce que cela signifie en pratique :
- Si vous avez un fichier de configuration WireGuard (généralement un
.confou un QR code), vous pouvez l'importer dans le client officiel et vous connecter — aucune application du fournisseur n'est requise. - Si vous n'avez pas de serveur ou de fournisseur qui génère un pair pour vous, un fichier de configuration seul ne fait rien. WireGuard n'inclut pas de serveurs, de politique de journalisation ni de kill switch.
- Comme le protocole est petit et le format standard, une configuration d'un fournisseur n'est pas structurellement différente de celle d'un autre. Ce qui diffère, c'est le point de terminaison, le nombre de pairs et le service qui l'entoure.
Lire un fichier de configuration WireGuard ligne par ligne
Une configuration client minimale comporte deux sections. Tout ce dont vous aurez jamais besoin pour déboguer est ici :
[Interface]
PrivateKey = <client-private-key>
Address = 10.7.0.2/32
DNS = 10.7.0.1
[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
- PrivateKey — votre moitié de la paire de clés. Traitez-la comme un mot de passe ; quiconque la possède peut usurper l'identité de votre pair.
- Address — l'IP interne au tunnel qui vous est attribuée. Ce n'est pas votre IP publique et elle ne doit jamais être prise pour telle.
- DNS — le résolveur utilisé tant que le tunnel est actif. Omettez cette ligne et votre système peut continuer à interroger le serveur DNS fourni par votre FAI via DHCP, ce qui est la fuite WireGuard la plus courante.
- PublicKey / Endpoint — à qui vous parlez et où. Le point de terminaison est un hôte et un port UDP.
- AllowedIPs — la ligne la plus souvent mal interprétée. Côté client, elle remplit deux fonctions à la fois : elle programme la table de routage et sert de liste de contrôle d'accès cryptographique pour les IP de destination que le pair acceptera de votre part.
0.0.0.0/0, ::/0est un tunnel complet. Une valeur plus étroite comme10.7.0.0/24est un split tunnel qui ne route le trafic que vers ce sous-réseau. - PersistentKeepalive — envoie un paquet keepalive toutes les N secondes pour qu'un NAT ou un pare-feu ne ferme pas la session pendant les périodes d'inactivité. Les valeurs standard sont 25 ou 15 ; une valeur trop basse consomme inutilement la batterie sur mobile.
Si vous voulez volontairement un split tunnel, réduisez AllowedIPs plutôt que d'essayer de filtrer le trafic après coup — c'est à cela que sert ce paramètre. Si vous voulez que tout passe par le tunnel et que ce n'est pas le cas, vérifiez d'abord AllowedIPs.
Monter le tunnel et prouver qu'il fonctionne
Sous Linux et macOS avec wg-quick installé, la configuration se trouve dans /etc/wireguard/wg0.conf :
sudo wg-quick up wg0
sudo wg show
ip route get 1.1.1.1
curl -s https://ifconfig.me/ip; echo
Ce qu'il faut vérifier :
wg showdoit lister le pair, un point de terminaison et un horodatage latest handshake dans les dernières minutes. Pas de handshake signifie que le tunnel ne transporte pas de trafic, même si l'interface existe.ip route get 1.1.1.1doit afficher votre interface WireGuard (commewg0) plutôt que votre route par défaut habituelle.- La commande
curldoit renvoyer l'IP publique associée au point de terminaison auquel vous vous êtes connecté. - Pour vérifier quel résolveur répond réellement, interrogez un nom de test DNS sur votre serveur DNS configuré plutôt que de supposer que la ligne
DNS =a pris effet.
Sous Windows, macOS, Android et iOS, importez la même configuration dans l'application officielle. Sous Android et iOS, vous pouvez scanner la configuration sous forme de QR code. Le client officiel Android prend également en charge « Always-on VPN » — activez-le uniquement après avoir confirmé que le tunnel s'établit de manière fiable, car un handshake échoué combiné à Always-on coupera votre connectivité au lieu de revenir discrètement au réseau ouvert.
La routine de vérification en trois minutes
- Notez votre IP publique avant de vous connecter.
- Connectez-vous, puis vérifiez l'horodatage du handshake avec
wg show. - Revérifiez votre IP publique et confirmez qu'elle a changé.
- Lancez une requête DNS et confirmez que le résolveur qui répond correspond à la configuration de votre tunnel, et non à celle de votre FAI.
- Déconnectez-vous et confirmez que l'IP revient à la normale — si ce n'est pas le cas, vous avez laissé une route statique ou un paramètre always-on derrière vous.
WireGuard vs OpenVPN vs un proxy SOCKS5
Ces trois outils sont constamment comparés et résolvent des problèmes différents. Une carte approximative :
| WireGuard | OpenVPN | Proxy SOCKS5 | |
|---|---|---|---|
| Portée | Appareil entier (ou split tunnel par sous-réseau) | Appareil entier | Par application ou par requête |
| Protocole | UDP (certains clients ajoutent un repli TCP) | TCP ou UDP | TCP (avec association UDP) |
| Chiffrement | Oui, au niveau de la couche réseau | Oui, au niveau de la couche réseau | Non — le tunnel n'est protégé que par ce qui passe dessus |
| Rotation des IP de sortie | Non, un pair par interface | Non, par défaut | Oui, si le fournisseur effectue la rotation |
| Utilisations typiques | Navigation privée, accès à distance, liaisons site à site | Idem, avec une compatibilité héritée plus large | Scraping, vérifications géographiques, routage par application, automatisation |
En bref : utilisez WireGuard lorsque vous voulez que tout ce qui se trouve sur la machine sorte par un seul point de terminaison chiffré. Utilisez un proxy SOCKS5 lorsque vous voulez qu'un seul processus sorte par une seule IP — un navigateur, un scraper, un seul outil CLI — et que vous voulez changer cette IP sans toucher au reste du système.
Quand WireGuard est l'outil inadapté
WireGuard a deux véritables limites qu'il vaut la peine de connaître avant de bâtir un flux de travail dessus :
- Il est facile à identifier et, sur certains réseaux, à bloquer ou à limiter. Le handshake est distinctif et passe par UDP. Dans les environnements où UDP est filtré — réseaux d'entreprise, certains campus, certains réseaux nationaux — un tunnel WireGuard simple ne s'établira pas du tout. Il n'y a pas de couche d'obfuscation intégrée ; tout camouflage doit venir du client ou du service qui l'encapsule.
- Il n'effectue pas de rotation. Un pair WireGuard correspond à un seul point de terminaison, et votre IP publique est celle que ce point de terminaison présente. Si votre tâche nécessite une nouvelle IP par requête ou par région, un pool de proxies rotatifs est le bon instrument et WireGuard le mauvais.
Aucune de ces limites ne rend WireGuard mauvais — elles en font un outil spécifique. Le protocole a été conçu pour être petit et auditable, et c'est précisément pourquoi il est rapide et pourquoi son comportement est prévisible.
Quand un proxy SOCKS5 est le meilleur choix
Optez pour un proxy plutôt qu'un VPN lorsque :
- Une seule application doit passer par le proxy. Routez un navigateur ou un script sans toucher au reste du trafic de votre système. Sous Linux, c'est généralement proxychains ou un wrapper par application ; sous Windows, un outil qui applique des règles par exécutable.
- La tâche nécessite de nombreuses IP. Le scraping web, la surveillance des prix et le suivi de classement veulent un pool et une politique de rotation, pas un seul point de terminaison stable. Notez la différence entre la rotation par requête et les sessions sticky — la cohérence de localisation compte plus que le volume brut dans tout ce qui rapporte des positions ou des prix.
- Vous testez un site comme une région spécifique. Une sortie proxy dans un pays cible est un moyen plus léger et plus rapide de voir cette variante régionale que de monter un tunnel complet.
- Vous ne contrôlez pas la machine. L'importation d'une configuration nécessite des droits d'administrateur sur la plupart des plateformes ; pointer une seule application vers
socks5h://host:portne le nécessite généralement pas.
Les deux ne sont pas mutuellement exclusifs. Router une connexion proxy à l'intérieur d'un tunnel WireGuard est un schéma normal : vous obtenez le transport chiffré vers un serveur de confiance, et le proxy fournit l'IP de sortie et la rotation par-dessus. Soyez simplement clair sur la couche qui fait quoi, car la résolution DNS est l'endroit où les deux sont le plus souvent en désaccord.
Cinq raisons pour lesquelles « le VPN est activé mais rien n'a changé »
- Pas de kill switch. Le tunnel est tombé et tout est revenu silencieusement à votre route normale.
AllowedIPsest trop restrictif. Vous avez configuré un split tunnel et vous avez oublié, donc un seul sous-réseau est routé.- Le DNS est encore local. La ligne
DNS =est absente, ou une application utilise DNS-over-HTTPS vers un résolveur en dehors du tunnel. - Un proxy ou un second VPN est déjà actif. Les paramètres proxy au niveau du navigateur remplacent un tunnel système pour ce navigateur, ce qui est un comportement intentionnel mais déroutant quand cela se produit accidentellement.
- IPv6. Si votre configuration ne couvre que
0.0.0.0/0et non::/0, les destinations compatibles IPv6 peuvent emprunter le chemin non tunnelisé.
Une courte liste de contrôle décisionnelle
Avant d'installer quoi que ce soit, répondez à ces trois questions :
- L'appareil entier doit-il passer par le tunnel, ou une seule application ? L'appareil entier indique WireGuard ou OpenVPN ; une seule application indique un proxy.
- L'IP de sortie doit-elle rester stable ou changer souvent ? Stable indique un tunnel ; changeante indique un pool de proxies rotatifs.
- Le réseau sur lequel vous êtes autorise-t-il l'UDP ? Si non, prévoyez un repli basé sur TCP ou un proxy dès le départ.
À retenir
WireGuard est un protocole avec une configuration de cinq lignes et une très petite surface d'attaque, c'est pourquoi il est rapide, portable et facile à vérifier. Lisez attentivement AllowedIPs et DNS, confirmez le handshake avec wg show, puis vérifiez votre IP publique et votre résolveur — ces quatre étapes résolvent la plupart des plaintes. Lorsque votre problème est « une application a besoin d'une IP différente, de façon répétée », cessez d'essayer de le résoudre avec un tunnel et utilisez plutôt un proxy SOCKS5. Les outils sont complémentaires, et savoir quelle couche vous modifiez fait la différence entre une configuration fonctionnelle et un après-midi de débogage de routes.