Tailscale : comment fonctionne ce VPN WireGuard ?

Qu’est-ce que Tailscale ?

Tailscale est un VPN qui connecte directement vos machines entre elles, au lieu de faire transiter tout le trafic par une passerelle que vous administrez. Chaque nœud exécute WireGuard. Les paquets circulent donc de manière chiffrée d’un serveur à l’autre, et aucun élément du chemin ne peut les lire. Un serveur de coordination hébergé se charge d’établir les connexions. Il stocke et distribue les clés publiques, puis indique à chaque nœud où se trouvent les autres. Il applique également les règles d’accès que vous avez définies.

Cette séparation constitue toute l’architecture. Le plan de données est pair à pair et chiffré entre les nœuds. Le plan de contrôle est un service que Tailscale exécute pour vous. Toutes les questions importantes concernant Tailscale, notamment celles qui concernent la confiance, découlent de ces deux faits. Si vous avez déjà créé manuellement un VPN WireGuard sur un VPS, Tailscale fournit le même tunnel, avec la distribution des clés et la traversée du firewall prises en charge pour vous.

Comment fonctionne Tailscale ?

Votre réseau privé de nœuds s’appelle un tailnet. Quatre opérations se produisent lorsqu’une machine le rejoint.

1. Le daemon tailscaled démarre, génère une paire de clés WireGuard et conserve son état dans /var/lib/tailscale/tailscaled.state. La clé privée reste sur cette machine. Tailscale le formule clairement : « la clé privée ne quitte jamais, au grand jamais, son nœud ».
2. Le nœud s’authentifie auprès du serveur de coordination et lui envoie sa clé publique, ainsi que les adresses auxquelles il pense pouvoir être joint. Tailscale décrit ce serveur comme « une boîte de dépôt partagée pour les clés publiques ».
3. Le serveur de coordination renvoie une network map : la clé publique, l’adresse du tailnet, le nom de la machine et les endpoints candidats de chaque nœud que celui-ci est autorisé à joindre.
4. Chaque paire de nœuds tente ensuite d’établir un tunnel WireGuard direct entre les deux machines. En cas d’échec, les paquets passent par un relay.

Chaque nœud reçoit une adresse stable dans 100.64.0.0/10, la plage de carrier-grade NAT comprise entre 100.64.0.0 et 100.127.255.255. Tailscale utilise cette plage car elle est réservée à l’infrastructure des fournisseurs, et entre donc rarement en conflit avec les adresses privées déjà utilisées par vos serveurs. Sous Linux, le tunnel apparaît comme une interface nommée tailscale0.

L’implémentation de WireGuard se trouve dans tailscaled en userspace, et non dans le module du kernel. C’est pourquoi Tailscale démarre sur les environnements de virtualisation de conteneurs où sudo modprobe wireguard échoue avec Operation not supported. Cela signifie aussi que le débit maximal sur une machine donnée est inférieur à celui de WireGuard dans le kernel. C’est l’un des compromis abordés dans la comparaison entre Tailscale et WireGuard seul.

Deux commandes vous indiquent la situation.

tailscale ip -4
tailscale status

tailscale status affiche une ligne par nœud. La dernière colonne est celle qui compte.

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

direct suivi d’une adresse et d’un port signifie que les deux machines ont trouvé un chemin direct et que le trafic passe de pair à pair. relay "fra" signifie que le trafic passe par un relay Tailscale à Francfort. Un - signifie qu’aucune session active n’est établie avec ce nœud pour le moment, ce qui est normal.

Ce que le serveur de coordination peut voir ou non

Le serveur de coordination conserve les clés publiques et les métadonnées. Il connaît les noms de vos machines, l’utilisateur ou le tag associé à chaque nœud, l’adresse tailnet de chaque nœud, les adresses publiques auxquelles vos nœuds sont joignables, la date de leur dernière connexion et le fichier de policy que vous avez écrit. Cela constitue une cartographie complète de votre parc.

Il ne détient aucune clé privée. Il ne peut donc pas déchiffrer le trafic entre deux nœuds. Le chiffrement est de bout en bout entre les pairs WireGuard, et le serveur de coordination n’est pas un pair.

En revanche, il peut distribuer des clés. Tout serveur de coordination, hébergé ou auto-administré, est supposé fiable pour indiquer à vos nœuds quelles clés publiques appartiennent à la tailnet. C’est le point central du modèle de menace présenté plus loin et la raison d’être de Headscale, un serveur de coordination open source que vous hébergez vous-même.

Comment deux serveurs situés derrière des pare-feu différents communiquent directement

La translation d’adresses réseau (NAT) permet à plusieurs machines de partager une même adresse publique. Votre VPS possède généralement sa propre adresse publique, mais ce n’est souvent pas le cas des autres machines que vous souhaitez intégrer au tailnet : un serveur personnel, un build runner sur un réseau professionnel ou une machine située derrière le pare-feu d’un fournisseur que vous ne pouvez pas modifier.

Tailscale trouve un chemin à l’aide de techniques fondées sur les standards STUN (session traversal utilities for NAT) et ICE. Chaque nœud envoie un petit paquet UDP à un serveur STUN et découvre l’adresse publique ainsi que le port attribués par son routeur à ce socket. Les deux nœuds transmettent ces candidats au serveur de coordination, qui les communique à l’autre extrémité. Les deux nœuds commencent ensuite à s’envoyer des paquets simultanément. Chaque routeur voit d’abord un paquet sortant. Il crée donc une association et accepte la réponse provenant de cette même adresse. Aucune des deux extrémités n’a besoin d’une règle de pare-feu entrante.

Les ports sont spécifiques. Les tunnels WireGuard directs utilisent UDP avec un port source défini par défaut sur 41641. STUN utilise UDP 3478 pour communiquer avec les serveurs relais de Tailscale. La connexion de contrôle et les éventuelles données relayées utilisent HTTPS sur TCP 443. La plupart du temps, vous n’avez aucun port entrant à ouvrir. Toutefois, sur un réseau équipé d’un NAT difficile, autoriser UDP 41641 en entrée augmente les chances d’établir une connexion directe.

tailscale netcheck

Lisez deux lignes de ce rapport. UDP: true signifie que l’UDP sort effectivement de la machine, tandis que UDP: false signifie que toutes les connexions de ce nœud seront relayées. MappingVariesByDestIP: true signifie que le routeur attribue un port public différent pour chaque destination. La prédiction d’adresse décrite plus haut ne peut donc pas fonctionner, et ces nœuds restent généralement relayés.

Quand Tailscale utilise un relais DERP

DERP (designated encrypted relay for packets) est le mécanisme de secours. Tailscale exploite des relais dans de nombreuses régions, accessibles via TCP 443. Un nœud qui ne peut pas établir de chemin direct envoie ses paquets WireGuard par l’intermédiaire de l’un d’eux.

Les paquets restent chiffrés. Tailscale l’indique clairement : « un serveur DERP ne peut jamais déchiffrer votre trafic. Il se contente de transférer aveuglément le trafic déjà chiffré d’un nœud à un autre ». Un relais voit le texte chiffré et sait quel nœud communique avec quel autre.

Les relais transportent également les premiers paquets de la plupart des connexions. La recherche d’un chemin direct prend un certain temps. Une session commence donc souvent via un relais, puis bascule vers un tunnel direct dès que les deux nœuds se trouvent. Vous pouvez observer ce changement.

tailscale ping db-1

Les premières réponses reviennent via via DERP(fra), puis une ligne ultérieure indique quelque chose comme via 198.51.100.24:41641. Ce changement correspond au passage à un tunnel direct. S’il ne se produit jamais, exécutez tailscale netcheck aux deux extrémités. Un chemin relayé fonctionne malgré tout. Il augmente la latence, car chaque paquet fait un détour par une troisième machine.

Rattacher un VPS à votre tailnet

Le script d’installation prend en charge Ubuntu et Debian.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

sudo tailscale up affiche une URL. Ouvrez-la, authentifiez-vous, puis le nœud apparaît dans votre console d’administration. Vérifiez ensuite que le daemon redémarre après un reboot, car cette étape est souvent oubliée.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled doit afficher enabled, et tailscale status doit répertorier le nouveau nœud avec son adresse 100.x. Pour un serveur créé par un script, une URL interactive ne sert à rien. Générez une auth key dans la console d’administration et transmettez-la avec un tag qui indique le type de machine.

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

Un nœud associé à un tag appartient au tag et non à la personne qui a exécuté la commande. Il continue donc de fonctionner lorsque le compte de cette personne est supprimé. Le tag doit d’abord être déclaré dans votre fichier de policy sous tagOwners, sinon la commande est refusée. Le tagging modifie également le décompte de la machine dans votre plan, car une ressource associée à un tag est facturée séparément des appareils personnels d’un utilisateur. Ce que couvre réellement l’offre gratuite précise où se situent ces limites.

Deux paramètres sont importants pour un parc de machines. Les node keys expirent par défaut après 180 days (en août 2026), et, lorsqu’une clé expire, « les connexions vers et depuis le endpoint concerné cessent de fonctionner » jusqu’à une nouvelle connexion. Ouvrez donc la ligne de la machine dans la console d’administration et sélectionnez Disable Key Expiry sur les serveurs sans surveillance. MagicDNS, activé par défaut pour les tailnets créés le 20 octobre 2022 ou après cette date, attribue à chaque nœud un nom tel que db-1.yak-bebop.ts.net, résolu par un stub resolver à l’adresse 100.100.100.100. Utilisez les noms plutôt que les adresses, car un nœud recréé reçoit une nouvelle adresse tout en conservant son nom.

Si l’installation échoue avec apt ou au niveau du repository, les erreurs courantes d’installation de Tailscale sur Ubuntu présentent les correctifs.

Accéder à un service lié à localhost

C’est ici qu’un tailnet devient utile et que les problèmes commencent souvent. Rejoindre le tailnet ne rend pas un service lié à loopback accessible.

ss -tlnp | grep 3000

Si cette commande affiche 127.0.0.1:3000, le socket n’accepte que les paquets dont la destination est 127.0.0.1. Une requête provenant d’un autre nœud arrive avec comme destination l’adresse 100.x de ce nœud. Le kernel ne trouve donc aucun processus en écoute à cette adresse et répond par un TCP reset. Le client affiche Connection refused. Le tunnel fonctionne. Le problème vient du listener.

Deux solutions sont possibles. Liez le service à l’adresse tailnet du nœud. Il reste ainsi inaccessible depuis l’interface publique, sans proxy intermédiaire : transmettez --bind 100.101.102.104 ou utilisez l’option équivalente dans votre configuration. Pour un conteneur, publiez le port sous la forme -p 100.101.102.104:3000:3000. Vous pouvez aussi laisser le service sur loopback et placer Tailscale devant lui.

tailscale serve 3000

Cette configuration relaie les requêtes vers http://127.0.0.1:3000 et les rend accessibles à l’intérieur de votre tailnet via un nom ts.net en HTTPS, une fois les certificats HTTPS activés pour le tailnet. Le service reste privé et accessible uniquement depuis vos nœuds. La version publique du même mécanisme s’appelle Funnel. Tailscale serve et Funnel explique lequel utiliser.

Deux tâches connexes disposent de leurs propres pages. Pour accéder à l’ensemble d’un réseau privé sur lequel Tailscale n’est pas installé, utilisez un subnet router sur un VPS. Pour faire passer le trafic Internet sortant d’un nœud par un autre nœud, utilisez un exit node.

Fermer les ports dont vous n’avez plus besoin

Une fois que chaque administrateur accède au serveur via le tailnet, le port public 22 ne sert plus à rien. C’est le bénéfice pratique : un port fermé ne peut pas faire l’objet d’attaques par force brute, et vos journaux ne se remplissent plus de tentatives.

L’ordre des opérations est important. Ajoutez l’accès via le tailnet, vérifiez que vous pouvez vous connecter par ce moyen depuis une deuxième session, puis seulement supprimez la règle publique.

sudo ufw allow in on tailscale0
sudo ufw status verbose

Supprimez ensuite la règle SSH publique et reconnectez-vous avec le nom MagicDNS. Notez ce que fait réellement ufw allow in on tailscale0 : il autorise tout ce qui arrive par le tunnel. Votre fichier de policy Tailscale devient donc le mécanisme de contrôle d’accès à la place de ufw. Rédigez la policy en conséquence.

Attention si vous utilisez des conteneurs. Un port Docker publié installe ses propres règles NAT et contourne ufw ; un ufw deny ne le ferme donc pas. Les ports Docker publiés contournent ufw explique ce mécanisme. La publication sur l’adresse du tailnet, comme ci-dessus, permet d’éviter ce problème.

Ce que Tailscale protège et ce qu’il ne protège pas

Il faut l’énoncer clairement, car le discours marketing brouille la distinction.

Protégé : le trafic entre deux nœuds est chiffré de bout en bout avec WireGuard, et aucun relay intermédiaire ne peut le lire. Les clés privées ne quittent jamais la machine qui les a générées. Les nœuds n’ont besoin d’aucun port public entrant : Internet n’a donc rien à scanner sur 22 ou 5432. Les accès entre les nœuds sont déterminés par un fichier de stratégie, et non par la personne qui connaît une adresse.

Non protégé : le serveur de coordination connaît la topologie de vos appareils. Ces métadonnées sont sensibles en elles-mêmes, car les noms des machines, leurs propriétaires, leurs adresses et leurs heures de connexion décrivent votre infrastructure. Ce serveur distribue également les clés, ce qui constitue le risque le plus important. Tailscale le dit directement : « Si Tailscale était malveillant et insérait furtivement de nouveaux nœuds dans votre réseau, il pourrait alors envoyer du trafic en clair vers vos nœuds existants ou en recevoir. » Votre fournisseur de single sign-on se trouve dans le même chemin de confiance, car toute personne capable d’y générer une identité peut ajouter un nœud. Un nœud compromis est également un pair à l’intérieur du tailnet ; ce qu’il peut ensuite atteindre dépend donc de ce que votre stratégie autorise. Le caractère acceptable de ce risque dépend de l’adversaire contre lequel vous vous protégez. Le modèle de confiance complet examine chacun de ces cas, notamment ce qu’un compte d’identité volé permet réellement de faire.

Il existe deux réponses au risque lié à la distribution des clés. La première est le tailnet lock. Il exige que des nœuds de confiance existants signent cryptographiquement un nouveau nœud avant que vos autres nœuds l’acceptent. Un control plane qui ajoute un nœud sans signature valide est ignoré. La console d’administration génère la ligne tailscale lock init exacte pour vos nœuds de signature, et chaque nœud peut vérifier ce qu’il reçoit.

tailscale lock status

Tous les nœuds doivent signaler le même ensemble de clés de signature approuvées. La seconde réponse consiste à exécuter vous-même le control plane. Un serveur de coordination Headscale auto-hébergé utilise le même protocole avec les mêmes clients. La topologie des appareils et la distribution des clés sont ainsi déplacées vers du matériel que vous contrôlez. Vous êtes également responsable de la disponibilité de ce serveur. Si vous comparez encore les control planes auto-hébergés au lieu de retenir celui-ci, NetBird est un VPN mesh distinct dont vous exécutez le serveur de bout en bout sur un seul VPS.

Un réglage par défaut doit être corrigé dès le premier jour. Un nouveau tailnet est permissif : « le fichier de stratégie par défaut du tailnet autorise la communication entre tous les appareils du tailnet ». Dès que vous ajoutez une section acls, le modèle passe en deny by default et seules vos règles sont autorisées.

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

Cette stratégie permet aux membres du tailnet d’atteindre SSH sur les serveurs marqués, et rien d’autre. Ajoutez une règle par service au lieu de conserver le wildcard, car celui-ci signifie qu’une seule clé volée sur un ordinateur portable permet d’atteindre votre base de données.

Modes de panne et messages affichés

tailscale status indique toujours relay. Les deux nœuds n’ont jamais établi de chemin direct. Exécutez tailscale netcheck sur les deux extrémités. UDP: false signifie que l’UDP sortant est bloqué ; seul un relay peut donc fonctionner. MappingVariesByDestIP: true signifie qu’un NAT strict est présent. Autoriser l’UDP entrant sur le port 41641 du côté que vous contrôlez règle souvent le problème.

Un nœud qui fonctionnait depuis des mois a disparu. Sa node key a expiré après la durée par défaut de 180 jours. La machine apparaît comme expirée dans la console d’administration, et sudo tailscale up sur la machine la réactive. Désactivez l’expiration des clés sur les serveurs pour éviter que le problème se reproduise.

Les pairs sont listés, mais les connexions expirent. La connectivité fonctionne et la policy refuse le trafic. Consultez la section acls pour trouver une règle qui couvre cette source, cette destination et ce port. Un paquet refusé est supprimé au lieu de recevoir une réponse. C’est pourquoi vous obtenez un délai d’expiration plutôt que Connection refused.

Les noms MagicDNS ne sont pas résolus. ping db-1 échoue alors que ping 100.101.102.104 fonctionne. Quelque chose a remplacé /etc/resolv.conf. Les requêtes n’atteignent donc jamais le stub resolver sur 100.100.100.100. Vérifiez dans cat /etc/resolv.conf la présence de 100.100.100.100 et examinez les autres éléments de la machine qui écrivent dans ce fichier. C’est le même type de problème que DNS qui ne fonctionne plus dans un tunnel WireGuard.

tailscale up refuse votre tag. Le tag n’est pas déclaré sous tagOwners dans le fichier de policy. Ajoutez-le à cet emplacement, puis exécutez de nouveau la commande.

FAQ

Tailscale est-il un VPN ou un réseau mesh ?

Les deux termes sont exacts, mais ils décrivent des couches différentes. Les tunnels utilisent WireGuard, ce qui en fait un VPN. La topologie est un mesh, car chaque nœud établit un tunnel directement avec chaque nœud auquel il communique, au lieu d’envoyer chaque paquet par un serveur central. Le serveur de coordination se trouve dans le plan de contrôle, pas dans le plan de données. S’il devient inaccessible, vos tunnels existants continuent donc à transporter le trafic. Lors d’une panne, seuls l’ajout de nouveaux nœuds et l’application des changements de clés ou de règles sont interrompus.

Tailscale peut-il lire mon trafic ?

Pas son contenu. Le trafic est chiffré de bout en bout entre les nœuds avec WireGuard, les clés privées ne quittent jamais les nœuds, et un relais DERP transfère les paquets sans pouvoir les déchiffrer. Tailscale voit toutefois des métadonnées : noms des machines, propriétaires, clés publiques, adresses des endpoints et état en ligne de chaque nœud. Tailscale distribue également les clés. Un serveur de coordination compromis pourrait donc tenter d’insérer un nœud auquel votre parc accorderait ensuite sa confiance. Tailnet lock bloque cette possibilité en exigeant des signatures de vos propres nœuds de confiance. Headscale retire quant à lui le plan de contrôle hébergé de l’équation.

Dois-je ouvrir des ports du pare-feu pour Tailscale ?

Presque jamais en entrée. Tailscale indique lui-même que « la plupart du temps, vous n’avez pas besoin d’ouvrir de ports sur le pare-feu ». En sortie, un nœud a besoin de TCP 443 vers le serveur de coordination et les relais, ainsi que d’UDP 3478 pour STUN. Les tunnels directs utilisent UDP avec un port source dont la valeur par défaut est 41641. Autoriser UDP 41641 en entrée est facultatif. Cela aide uniquement les connexions directes à aboutir sur certains réseaux difficiles.

Pourquoi les autres nœuds ne peuvent-ils pas atteindre mon service sur le port 3000 ?

Vérifiez d’abord l’adresse d’écoute avec ss -tlnp. Un service qui écoute sur 127.0.0.1:3000 refuse les connexions destinées à l’adresse tailnet 100.x du nœud, car ce socket n’accepte que la destination loopback. Le client reçoit alors Connection refused. Liez le service à l’adresse tailnet ou exécutez tailscale serve 3000 pour faire office de proxy. Si le service écoute déjà sur 0.0.0.0 et que la connexion expire au lieu d’être refusée, la cause est une règle de policy ou un pare-feu de l’hôte, et non l’adresse d’écoute.

Dois-je exécuter Headscale au lieu du serveur de coordination de Tailscale ?

Exécutez Headscale lorsque le graphe des appareils ou la distribution des clés doit rester sur une infrastructure que vous contrôlez, ou lorsque le tailnet doit fonctionner sans dépendre d’un service externe. Les clients et le protocole restent les mêmes. En contrepartie, vous devez exploiter le serveur de coordination. Une panne de ce serveur empêche l’ajout de nouveaux nœuds et l’application des changements de policy. Pour un petit parc, le plan de contrôle hébergé avec tailnet lock activé constitue généralement le meilleur compromis.