La partie facile et la partie qui vous verrouille dehors
WireGuard est une réelle réussite d'ingénierie : un VPN petit, rapide et moderne qui vit dans le noyau et se cache derrière deux clés et un fichier de config. L'installer prend une commande. Générer une paire de clés en prend une de plus. Et vient ensuite l'étape qui a verrouillé plus de gens hors de leurs propres serveurs que n'importe quel paquet ne le fera jamais : monter l'interface change le routage de la machine, et un changement de routage fait sans soin peut couper la session SSH même dans laquelle vous tapez.
La thèse ici est donc étroite et importante : l'installation est triviale ; l'étape de l'interface est destructrice, et mérite d'être traitée comme telle. Snapshot avant, rollback prêt, et ne fermez jamais la session dont vous disposez tant qu'une nouvelle n'a pas prouvé que la machine est encore joignable. Tout le reste de cet article sert cette seule règle.
Avant le premier paquet : lire le réseau que vous allez toucher
La reconnaissance pour un VPN n'est pas une politesse optionnelle — c'est ainsi que vous évitez d'empiler un second tunnel sur un tunnel qui marche, ou de casser les adresses dont vous dépendez.
- WireGuard est-il déjà là ?
command -v wg && wg --version. Si oui, vous configurez, vous n'installez pas. - Une interface existe-t-elle déjà ?
wg show. Un tunnel actif est une config à ne pas écraser ; lisez-la avant de toucher quoi que ce soit, car clobber unwg0qui marche est exactement ainsi qu'un lien distant disparaît. - Quelles sont les interfaces et adresses actuelles ?
ip -4 addr show | grep -c inet. Vous devez savoir comment vous atteignez actuellement la machine pour que ce que WireGuard fait à la table de routage ne vous retire pas ce chemin en silence.
1. Installer le paquet
Sur Debian et Ubuntu c'est apt-get update && apt-get install -y wireguard. La preuve que ça a marché est une chaîne de version de wg --version — pas le fait qu'apt soit sorti à zéro. Rien dans l'installation du paquet ne touche encore votre connectivité ; le paquet est inerte jusqu'à ce qu'une interface soit configurée et montée. Cet ordre compte, et c'est pourquoi l'étape dangereuse vient en dernier, délibérément, après que les étapes sûres ont été prouvées.
2. Générer les clés — et garder la privée privée
La sécurité de WireGuard repose entièrement sur une paire de clés, donc la façon dont vous les créez n'est pas un détail. L'incantation correcte fixe le mode du fichier avant même que la clé n'existe :
umask 077 && wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey
Le umask 077 fait un vrai travail : il garantit que la clé privée est écrite lisible uniquement par son propriétaire, avant qu'un seul octet n'atterrisse sur le disque. Une clé privée lisible par tous est un VPN que n'importe qui sur la machine peut usurper. La vérification est concrète — test -s /etc/wireguard/privatekey && echo ok confirme que la clé existe et n'est pas vide — et elle devrait être associée à un contrôle que les permissions sont aussi strictes que voulu. Cette étape est sûre : elle crée des fichiers, elle ne touche pas au réseau.
3. Monter l'interface — l'étape destructrice
Maintenant la partie qui mérite son avertissement. Vous écrivez /etc/wireguard/wg0.conf et activez l'interface avec systemctl enable --now wg-quick@wg0. C'est ici que le routage change, et c'est pourquoi l'étape de l'interface est classée réellement destructrice : mal faite, elle emporte votre accès avec elle.
Le piège classique est AllowedIPs = 0.0.0.0/0, qui dit à WireGuard de router tout le trafic à travers le tunnel. Sur un client c'est exactement ce que vous voulez ; sur un serveur distant que vous administrez en SSH, cela peut re-router votre propre trafic d'administration dans un tunnel pas encore pleinement monté, et la session meurt en plein milieu d'une commande. Décidez délibérément si cette interface porte tout ou seulement un sous-réseau privé, et dans le doute, limitez AllowedIPs à la plage du VPN et rien de plus.
Traitez cette étape comme tout changement destructeur devrait l'être : snapshot de l'état qui marche d'abord, rollback à une commande près — systemctl disable --now wg-quick@wg0 — et gardez votre session SSH courante ouverte pendant que vous en ouvrez une nouvelle pour confirmer que la machine est encore joignable. Ne fermez pas la session qui marche tant qu'une connexion neuve n'a pas prouvé que vous ne vous êtes pas verrouillé dehors. Le verify de l'étape est que l'interface est bien montée : wg show wg0 >/dev/null 2>&1 && echo up. Mais le verify qui compte pour vous est un second login, indépendant, qui réussit.
Ce que WireGuard ne fait pas pour vous
WireGuard vous donne un transport chiffré et un adressage privé entre pairs. Ce n'est pas du contrôle d'accès par utilisateur : quiconque a une clé valide et une entrée de pair correspondante est sur le réseau, et une clé privée fuitée est un accès, point — il n'y a pas de mot de passe séparé à franchir en plus. Ce n'est pas un pare-feu pour les services derrière ; lier une base de données à une adresse WireGuard vaut mieux que la lier à l'Internet public, mais le service a toujours besoin de sa propre authentification. Et un VPN ne remplace pas le durcissement dont ces services ont besoin en propre. Un réseau privé restreint qui peut atteindre un port ; il ne décide pas de ce qu'on peut y faire une fois arrivé.
La vérification qui prouve le tunnel, et votre accès
Dans l'ordre : wg --version pour le paquet ; une clé privée qui existe avec des permissions strictes ; wg show wg0 rapportant l'interface montée avec ses pairs ; et — celle qui vous protège réellement — une connexion SSH neuve, ouverte après que l'interface est montée, qui réussit. Prouvez que le changement de routage ne vous a pas coûté votre accès avant de lui faire confiance, et jamais depuis la session que vous perdriez. Si le nouveau login échoue, le rollback est à une commande près, et vous avez encore l'ancienne session pour le lancer.
Ce que Servor apporte là-dedans
Servor livre WireGuard comme une recette — parmi 150+ playbooks vérifiés — et la forme d'une recette est exactement ce dont une tâche qui altère le réseau a besoin. Ce n'est pas un script tiré à l'aveugle : elle commence par la reconnaissance, en lisant si WireGuard est présent, si une interface existe déjà, et quelles sont les adresses actuelles, pour que le run s'adapte à un serveur réel plutôt que d'en supposer un vide. Chaque étape porte sa propre vérification — la version, le fichier de clé, wg show wg0 — si bien que le run prouve qu'il a marché. Le playbook est idempotent : un tunnel existant est lu et rapporté, jamais écrasé.
Surtout, l'étape de l'interface est marquée destructrice, ce qui n'est pas cosmétique : elle déclenche un snapshot au préalable, exige une seconde approbation, et porte un rollback explicite (systemctl disable --now wg-quick@wg0) — parce qu'un changement de routage sur une machine distante est précisément le genre d'opération qui ne devrait jamais être glissée en douce, sans surveillance. Et l'exécution ne quitte jamais le chemin zero-knowledge : chaque commande est signée dans votre navigateur avec une clé dérivée de votre clé de vault, relayée verbatim, et vérifiée par l'agent sur la machine avant de s'exécuter. Parce que l'agent atteint le plan de contrôle via une connexion sortante, votre chemin d'administration ne dépend pas du routage même que vous êtes sur le point de changer — le filet de sécurité ne passe pas par le tunnel que vous pourriez casser.
Le même soin appliqué à la porte d'administration est dans l'article sur le durcissement SSH ; la discipline pour rendre tout changement risqué réversible est dans l'article sur les opérations destructrices sûres ; et la boucle approuver-signer-vérifier derrière tout cela est dans l'article Plan-Execute-Verify. Parcourez le reste du catalogue de recettes, ou voyez comment cela s'articule dans notre guide d'exploitation des serveurs.