WireGuard : le tunnel qui tient en dix lignes

WireGuard part d'un principe inverse de celui d'OpenVPN ou d'IPsec. Là où ces derniers empilent les options, les modes de négociation et les couches de compatibilité, WireGuard ne fait qu'une chose : chiffrer le trafic entre deux endpoints et le laisser passer. Le reste, c'est le noyau Linux qui s'en charge.

Cette simplicité n'est pas un slogan. Elle a un coût, et il faut le regarder en face avant de choisir.

Ce que tu écris dans le fichier

Sur Linux, WireGuard vit dans le noyau depuis la version 5.6. Tu n'installes pas un démon : tu charges un module. La configuration se fait dans un fichier `.conf`, presque toujours rangé dans `/etc/wireguard/`, par exemple `wg0.conf`.

Le fichier décrit deux choses. D'abord l'interface locale : ta clé privée, ton adresse IP à l'intérieur du tunnel, le port sur lequel tu écoutes. Ensuite les peers : leur clé publique, leur adresse ou nom de domaine, leur port, et les plages IP autorisées à passer par le tunnel.

Il n'y a pas de négociation de cipher. Il n'y a pas de choix d'algorithme. WireGuard impose ChaCha20 pour le chiffrement, Poly1305 pour l'authentification, Curve25519 pour l'échange de clés, BLAKE2s pour le hachage. Tu ne peux pas les changer, et c'est volontaire : moins de surface, moins de pièges.

Le revers, c'est que WireGuard ne cache pas son trafic. Il utilise UDP et rien d'autre. Dans un réseau qui bloque l'UDP ou qui inspecte les flux, un tunnel WireGuard se repère facilement. OpenVPN en TCP sur le port 443 passe là où WireGuard se fait couper. Si ton contexte est une connexion restrictive, ce détail décide à ta place.

Monter et descendre un tunnel

L'outil que tu utilises tous les jours s'appelle `wg-quick`. C'est un script shell qui enveloppe les commandes du noyau — `ip link`, `ip address`, `ip route` — et applique ta configuration sans que tu aies à les taper.

``` wg-quick up wg0 ```

Cette commande lit `wg0.conf`, crée l'interface virtuelle, lui donne son adresse, pose les routes et active le tunnel. Pour tout défaire :

``` wg-quick down wg0 ```

Tu peux mettre ça dans un script, un cron, un hook. C'est du shell, ça se comporte comme du shell.

Pour que le tunnel remonte tout seul au démarrage, tu actives l'unité systemd fournie :

``` systemctl enable wg-quick@wg0 ```

À partir de là, la machine redémarre, le tunnel revient, personne n'y touche. C'est ce qu'on veut sur un serveur qui doit rester joignable.

Les trois montages qu'on rencontre vraiment

Le premier est le site-à-site. Deux réseaux séparés, par exemple un bureau en 10.10.10.0/24 et une annexe en 10.10.11.0/24, se parlent comme s'ils étaient câblés ensemble. Chaque côté a une passerelle qui joue le rôle de peer WireGuard. Tu déclares la clé publique de l'autre, son adresse publique, et les plages qui doivent passer par le tunnel. Une fois monté, les machines d'un côté joignent celles de l'autre sans rien savoir.

Le deuxième est le peer-à-site. Un portable ou un téléphone se connecte à une passerelle centrale — une box, un serveur, un VPS. La passerelle a une adresse fixe ou un nom DDNS, écoute sur un port, et chaque client a son propre couple de clés avec une IP unique dans le tunnel. C'est le montage du télétravail et de l'accès à distance à son propre réseau. Il demande un peu de discipline : chaque client, sa clé, sa ligne dans la config du serveur.

Le troisième consiste à faire passer tout ton trafic par le tunnel. Tu mets `AllowedIPs = 0.0.0.0/0` dans la config du client, et la passerelle devient ta sortie vers internet. Utile sur un wifi d'hôtel ou d'aéroport que tu ne contrôles pas. Ton IP réelle disparaît derrière celle du serveur, et le trafic entre toi et lui est chiffré. Ce que le serveur voit de tes requêtes, en revanche, reste entièrement visible pour lui.

Ce que ça coûte

WireGuard ne gère pas les clés à ta place. Pas de PKI, pas d'autorité de certification, pas de distribution automatique. Tu génères les paires, tu les échanges, tu les colles dans les fichiers. À deux ou trois machines, c'est trivial. À cinquante, ça devient un tableur qu'il faut tenir à jour, et c'est là que les erreurs arrivent.

Il n'y a pas non plus de gestion dynamique des adresses. Chaque peer a son IP fixe dans le tunnel, décidée à la main. Un client qui change de réseau garde la même identité, ce qui est pratique, mais tu dois la lui attribuer toi-même.

Et il n'y a pas de révocation centralisée. Retirer un accès veut dire éditer le fichier du serveur et recharger. Faisable, mais ce n'est pas un bouton dans une interface.

C'est le prix de la légèreté. WireGuard fait une chose, la fait bien, et te laisse le reste.

Quand tu ne veux pas gérer tout ça

Les distributions intègrent WireGuard de façons différentes. Sur beaucoup, NetworkManager sait le piloter, ce qui évite d'écrire les fichiers à la main et range la configuration avec le reste du réseau de la machine. Certaines versions packagées vivent dans un sandbox, avec un accès limité au système, et disparaissent proprement quand tu désinstalles.

Les offres commerciales, de leur côté, ont adopté WireGuard comme moteur parce qu'il est rapide et économe en CPU, y compris sur du matériel modeste. Elles ajoutent par-dessus ce que le protocole ne fournit pas : des applications, un choix de serveurs, une gestion de compte. Tu paies pour ne pas tenir les clés toi-même, et tu acceptes qu'un tiers voie ta sortie.

Aucune des deux approches n'est fausse. Elles répondent à des questions différentes.

La vraie question

WireGuard te convient si tu contrôles les deux bouts, si tu as un nombre raisonnable de peers, et si tu es à l'aise avec un fichier de configuration comme seule source de vérité. Il te convient moins si tu as besoin de révoquer en masse, de traverser des réseaux qui bloquent l'UDP, ou de déléguer l'administration à quelqu'un qui ne lira pas de fichiers texte.

Le noyau s'occupe du chiffrement. Le reste, c'est toi qui décides combien de complexité tu veux autour — et c'est souvent là que se joue le choix, pas dans les algorithmes.