Tailscale : l'architecture Zero Trust qui envoie valser ton VPN
Pourquoi jai déchiré ma config OpenVPN et comment Tailscale a tout changé
J’ai passé des années à me palucher des config de VPNs traditionnels. OpenVPN, IPsec, WireGuard à la main: c’est chiant, et quand tu as PLEIN d’users c’est SUPER chiant. Et à chaque fois, c’était le même merdier : des certificats qui expirent au pire moment, des routes à configurer à la main, des ports à ouvrir sur le firewall, et cette putain de sensation que si un seul truc est compromis, tout le réseau est foutu. Le tout sans savoir exactement ce à quoi les utilisateurs on accès.
Puis un jour j’ai lu un article sur le ZTNA et en cherchant j’ai trouvé Tailscale. Et là, ça a été une claque. Pas un VPN. Un mesh overlay network avec du zero trust au niveau de chaque machine/service. Depuis j’ai viré le VPN chez moi et j’en ai déployé plusieurs pour remplacer des VPN trop permissifs.
Lexique
C’est là mes définitions et si elles vous déplaisent, cassez-vous je suis pas là pour discuter lexique.
- Tailnet: Ton réseau mesh privé avec tous tes devices dedans.
- Control Plane: Le serveur de coordination Tailscale. Il gère l’auth, les clés, les politiques. Il VOIT RIEN de ton trafic.
- Data Plane: Les tunnels WireGuard chiffrés en peer-to-peer entre tes machines. Personne au milieu.
- DERP: Relais de secours quand le NAT traversal marche pas. Il forwarde du WireGuard déjà chiffré, il peut rien lire.
- Netmap: La carte réseau que chaque node reçoit avec la liste des pairs autorisés et leurs clés.
- Subnet Router: Un node qui annonce ton LAN au tailnet pour que t’aies accès à tout sans installer Tailscale partout.
- MagicDNS: Les noms d’hôte automatiques de tes machines (fini les IPs à retenir).
Le problème avec les VPNs d’antan
Tu poses un OpenVPN. Tu génères des certificats. Tu ouvres le port 1194 sur le firewall. Tu configures le split tunnel ou pas. Tu pries pour que les certs expirent pas le week-end. Et à la fin, t’as un énorme point central: le concentrateur, par lequel TOUT le trafic passe. Si quelqu’un le compromet, tout est mort. Si trop de monde s’y connecte, ça lag à mort. Si le firewall se prend une update, plus rien ne marche.
Tout ça pour quoi ? Pour donner à tes utilisateurs un accès réseau complet, sans aucune gestion d’autorisation par sevice. Une fois connecté, tu vois tout, tu touches à tout. C’est une connerie sans nom du point de vue sécurité.
Comment Tailscale repense tout ça
Tailscale, c’est l’inverse de tout ça. L’architecture repose sur une séparation fondamentale : le control plane (centralisé) et le data plane (décentralisé, peer-to-peer).
Le control plane, c’est le serveur de coordination de Tailscale (ou ton propre serveur si tu utilises Headscale). Il fait trois choses :
- T’identifier via SSO (Google, GitHub, Microsoft, Okta — tu choisis)
- Distribuer les clés publiques WireGuard de chaque machine aux machines autorisées à lui parler
- Publier les endpoints pour que les nodes se trouvent
Et c’est tout. Il ne voit JAMAIS tes données. Il ne route JAMAIS ton trafic.
Le data plane, c’est du WireGuard pur. Chaque machine génère sa propre paire de clés. La clé privée ne quitte jamais la machine. Les tunnels sont établis directement entre chaque paire de machines qui en ont besoin.
Le résultat ?
[Laptop à Paris] <--WireGuard--> [Serveur à Londres]
[Laptop à Paris] <--WireGuard--> [Raspberry Pi chez moi]
[Serveur à Londres] <--WireGuard--> [Raspberry Pi chez moi]
Pas de point central. Pas de bottleneck. Du chiffrement de bout en bout partout.
Mais comment ça traverse les NATs ?
C’est la magie du truc. Imagine : ton serveur est derrière la box Free de ton appart, ton laptop est au WiFi du Starbucks. Aucun des deux n’a d’IP publique.
Tailscale utilise du STUN pour que chaque machine découvre son adresse publique. Ensuite, les deux machines tentent un UDP hole punching simultané : elles s’envoient des paquets l’une vers l’autre en même temps. Les NATs des deux côtés créent des mappings temporaires, et hop, la connexion directe est établie.
Si vraiment ça marche pas (symmetric NAT ou firewall trop restrictif), Tailscale tombe en DERP relay. Le DERP relay ne fait que forwarder des paquets WireGuard déjà chiffrés. Il peut RIEN lire. Et dès que le NAT traversal trouve un chemin direct, la connexion passe automatiquement en direct. Tout ça de manière transparente.
Et le zero trust, dans tout ça ?
Tu poses des ACLs. Pas sur un firewall central. Pas sur un routeur. Les ACLs sont distribuées à chaque node dans la netmap, et chaque node les applique LOCALEMENT.
{
"acls": [
{ "action": "accept", "src": ["group:admin"], "dst": ["*:*"] },
{ "action": "accept", "src": ["group:dev"], "dst": ["tag:api:8080"] }
]
}Si un node n’est pas autorisé à en contacter un autre, il ne reçoit même PAS sa clé publique. Pas de clé,pas de tunnel, pas de connexion possible, pas de connexion! C’est pas du blocage au niveau applicatif: c’est au niveau chiffrement, ton app ne voit même pas la connection vue que la connexion ne peut littéralement pas exister. C’est ça, un vrai zero trust réseau.
Mon devlab : le déploiement
Bon assez de blabla. Concrètement, j’ai posé ça dans mon devlab. L’idée : ne plus ouvrir un seul foutu de port sur mon firewall, et accéder à tout mon bordel depuis n’importe où.
L’architecture cible
[Réseau devlab 192.168.42.0/24]
|--- Serveur Debian 12 (192.168.42.10)
| |- Conteneurs Podman
| |- Nginx Proxy Manager
| |- Tailscale (subnet router)
|
|--- VMs de dev (10.0.0.0/24)
| |- Base de données PostgreSQL
| |- API backend Java
|
|--- Raspberry Pi (192.168.42.20)
|- Pi-hole
|- Monitoring
Étape 1 : Installer Tailscale sur le serveur
Le tailscale up te file un lien. Tu cliques, tu t’authentifies, c’est fait. T’as un tailscale status qui te montre ta machine avec une IP en 100.x.x.x.
Étape 2 : Activer le subnet routing
Par défaut, t’as accès au serveur uniquement. Moi je veux accéder à toutes mes VMs, mon Raspberry Pi, et tout le LAN.
0$ echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
1$ sudo sysctl -p
2$ sudo tailscale up --advertise-routes=192.168.42.0/24,10.0.0.0/24Je vais dans l’admin console Tailscale, j’approuve les routes. Sans approbation manuelle, les routes sont pas actives — c’est fait exprès pour la sécurité.
Étape 3 : Configurer le laptop
0$ sudo tailscale up --accept-routes --accept-dnsLe --accept-routes est le flag magique : il dit à mon laptop d’utiliser le serveur comme passerelle pour les réseaux annoncés.
Étape 4 : Vérifier que ça marche
0# Depuis mon laptop en déplacement
1$ ping 10.0.0.5 # VM base de données — ça répond
2$ ping 192.168.42.20 # Raspberry Pi — ça répond aussi
3
4$ curl http://192.168.42.10:8080 # Service web sur le serveur
5$ ssh pi@192.168.42.20 # SSH dans le Pi
6
7# Avec MagicDNS, encore mieux
8$ ssh user@serveur-devlap.tail-abc123.ts.netTout marche. Aucun port ouvert sur le firewall. Aucun certificat à gérer. Rien.
Étape 5 : Mettre des ACLs sérieuses
Parce que bon, tout le monde sur tout le réseau, c’est pas du zero trust. J’ai posé ça :
{
"acls": [
{ "action": "accept", "src": ["group:admin"], "dst": ["*:*"] },
{ "action": "accept", "src": ["tag:dev"], "dst": ["tag:api:8080", "tag:db:5432"] },
{ "action": "accept", "src": ["tag:monitoring"], "dst": ["*:9090,9093"] }
],
"groups": {
"group:admin": ["v4rgas@example.com"],
"group:dev": ["bob@example.com", "alice@example.com"]
},
"tagOwners": {
"tag:dev": ["group:admin"],
"tag:api": ["group:admin"],
"tag:db": ["group:admin"],
"tag:monitoring": ["group:admin"]
}
}
Résultat : les devs accèdent à l’API et à la base. La monitoring stack est accessible à tout le tailnet. Les admins ont accès à tout. Et un node compromis dans le groupe dev peut pas toucher au monitoring, et encore moins aux machines étiquetées prod.
Les trade-offs, parce que tout est trade-off
Faut être honnête. Tailscale, c’est génial, mais y a des trucs à savoir.
Tu dépends du control plane. Si les serveurs de Tailscale sont down, tu peux pas ajouter de nouveau node ni modifier les ACLs. Par contre, les connexions existantes continuent de marcher — les clés sont déjà distribuées.
C’est du UDP. Si ton réseau d’entreprise bloque tout l’UDP, t’es obligé de passer par DERP en permanence. Ça marche, mais la latence est moins bonne.
Le free tier fait 100 devices. Pour un devlab solo ou une petite équipe, c’est large. Pour une grosse orga, il faut passer à la version payante.
C’est pas FIPS compliant. Si t’es dans un environnement qui exige du FIPS, Tailscale est pas fait pour toi. Les choix crypto (Curve25519, ChaCha20-Poly1305) sont pas FIPS compliant.
Alors, on déchire tout ?
Si tu galères encore avec des configs OpenVPN qui pètent le dimanche soir ou des fichiers bien trop longs à modifier dès qu’un nouveau collaborateur arrive, des certs qui expirent, des routes à debugger, pose-toi la question. Tailscale est pas juste “un VPN en mieux”. C’est une architecture différente. C’est repenser l’accès réseau avec du zero trust par défaut, du mesh peer-to-peer, et zéro port ouvert.
J’ai viré mon VPN, et mis du Tailscale partout où il y a un accès critique chez moi: Pas de port ouvert, plus de config imbitable. Et mon devlab est accessible de partout, segmenté, chiffré, sécurisé.
La tristitude c’est quand les ZTNA existent et que tu dois encore gérer du OpenVPN, et ça fait mal…
See ya space-cowboy!