SEC.01

Le playbook

Le run démarre en lecture seule : les sondes de reconnaissance décident de la suite. Les étapes qui suivent sont adaptées à la distribution et à l'état trouvés — une vraie machine est rarement propre.

1. 01reconWireGuard déjà installé ?
2. 02reconinterface ou wg0.conf déjà présents ? ne jamais les écraser
3. 03reconroute par défaut à préserver, et aucun chevauchement avec le sous-réseau VPN choisi
4. 04reconport UDP libre ?
5. 05reconpare-feu actif à ouvrir pour le port UDP
6. 06recondistro et noyau (module WireGuard intégré depuis 5.6)
7. 07agirInstaller WireGuardvérif
8. 08agirGénérer les clés du serveurvérif
9. 09agirÉcrire /etc/wireguard/wg0.confvérif
10. 10agirOuvrir le port UDP (seulement si ufw ou firewalld est actif)vérif
11. 11agirActiver wg0destructifvérif
12. 12agirCréer le premier clientvérif

SEC.02

Ce qu'elle vérifie

Chaque étape embarque sa propre vérification. Le run ne continue que si elle passe, donc ce que la recette annonce comme fait est ce qui est réellement sur le serveur.

1. 01vérifInstaller WireGuardVérifié parwg --version && modprobe wireguard && echo okattendu : une version puis ok
2. 02vérifGénérer les clés du serveurVérifié parstat -c %a /etc/wireguard/privatekey && test -s /etc/wireguard/publickey && echo okattendu : 600 puis ok
3. 03vérifÉcrire /etc/wireguard/wg0.confVérifié parwg-quick strip wg0 >/dev/null && stat -c %a /etc/wireguard/wg0.confattendu : 600
4. 04vérifOuvrir le port UDP (seulement si ufw ou firewalld est actif)Vérifié parufw status 2>/dev/null | grep -c "${port}/udp" || firewall-cmd --list-portsattendu : le port UDP listé
5. 05vérifActiver wg0Vérifié parwg show wg0 listen-port && ip -4 route show defaultattendu : le port choisi, et la même route par défaut qu’en recon
6. 06vérifCréer le premier clientVérifié parwg show wg0 peers | grep -c "$(cat /etc/wireguard/clients/${client_name}.pub)" && test -s /etc/wireguard/clients/${client_name}.conf && echo okattendu : 1 puis ok

SEC.03

Les garde-fous

Les consignes non négociables que le run doit respecter, quoi qu'il trouve sur le serveur.

SEC.04

Les variables

Ce que vous choisissez avant de lancer — la recette s'occupe du reste.

SEC.05

Comment une recette s'exécute dans Servor

Servor est zero-knowledge : la plateforme ne peut rien exécuter seule. Quand vous lancez cette recette, un run lit la reconnaissance, planifie les étapes et demande votre validation. Chaque commande approuvée est signée par votre navigateur — avec une clé que le serveur ne voit jamais — puis relayée telle quelle à l'agent, qui vérifie la signature localement avant d'exécuter.

SEC.06

Bouton Deploy on Servor

Vous maintenez WireGuard ou un projet qui en dépend ? Ajoutez ce bouton à votre README ou à votre site : en un clic, vos utilisateurs l'installent sur leur propre serveur.

SEC.07

D'autres recettes réseau

1. 01TailscaleVPN mesh Tailscale : auth key ou lien de connexion, sans toucher au DNS du serveur.
2. 02Pi-holePi-hole v6 (DNS + blocage de pubs) en conteneur, sur l’IP choisie. Destructif en écoute 0.0.0.0 (port 53).
3. 03AdGuard HomeDNS filtrant AdGuard Home, interface en local. Destructif : peut libérer le port 53.
4. 04OpenVPNServeur OpenVPN via le script road-warrior (angristan), premier client créé. Destructif : réseau.
5. 05Résolveur DNS (Unbound)Résolveur DNS récursif validant (DNSSEC) Unbound, sur localhost.