Tailscale est-il sécurisé ? Comprendre le modèle de

La sécurité de Tailscale : réponse courte

Tailscale est-il sécurisé ? Pour le point qui préoccupe la plupart des utilisateurs, oui : le serveur de coordination qui gère votre tailnet ne détient jamais les clés privées utilisées pour chiffrer votre trafic. Il ne peut donc pas lire les données que vos appareils s’échangent. La page de sécurité de Tailscale l’indique clairement : « Les clés privées ne quittent jamais l’appareil. Tout le trafic est toujours chiffré de bout en bout. » La question utile est différente. Un serveur de coordination compromis ou soumis à une injonction légale n’a pas besoin de lire vos paquets. Il détermine quelles clés publiques vos appareils approuvent. Il pourrait donc inscrire un appareil que vous n’avez jamais autorisé.

Le modèle de confiance tient en une phrase : le chiffrement protège les données et le plan de contrôle détermine les membres du réseau. Chaque section ci-dessous présente une partie à laquelle vous devez faire confiance, précise ce qu’elle peut réellement faire et indique le contrôle qui en limite les capacités. Si le produit vous est nouveau, commencez par ce qu’est Tailscale et le fonctionnement de son réseau maillé.

Le plan de contrôle et le plan de données sont distincts

Tailscale est un VPN mesh (réseau privé virtuel) basé sur WireGuard, le même protocole que vous configureriez manuellement sur un VPS WireGuard auto-hébergé. Chaque appareil génère localement sa propre paire de clés WireGuard. Dans son article comment cela fonctionne, Tailscale décrit le serveur de coordination comme « une boîte de dépôt partagée pour les clés publiques » et précise que « la clé privée ne quitte jamais, au grand jamais, son nœud ».

Le plan de données correspond au trafic chiffré entre vos appareils. Il circule directement d’un appareil à l’autre chaque fois que le réseau le permet. Le plan de contrôle comprend tout le reste : les appareils qui appartiennent au tailnet, la clé publique associée à chaque appareil, la politique d’accès, les paramètres DNS et la liste des relais. Tailscale fournit le plan de contrôle sous forme de service hébergé. Vous exécutez le plan de données sur vos propres machines.

En séparant ces deux plans, vous pouvez répondre à toutes les questions de sécurité qui se posent ici. Le chiffrement est une propriété du plan de données. L’appartenance au réseau est une décision du plan de contrôle. Aucun chiffrement ne permet de déterminer qui est autorisé à être un pair.

Que pourrait faire un serveur de coordination compromis ?

Il ne peut pas déchiffrer votre trafic. Les clés qui assurent le chiffrement sont générées sur vos appareils et ne sont jamais téléversées. Il n’y a donc aucune clé à saisir ou à divulguer pour ouvrir le tunnel. Cela vaut également pour le trafic relayé, traité plus loin.

Il pourrait inscrire un nœud. Lorsque Tailscale a annoncé tailnet lock, l’entreprise a décrit le risque en ces termes : un serveur malveillant pourrait « utiliser un nœud ajouté en secret pour envoyer du trafic vers vos nœuds existants ou en recevoir », et à ce stade « le chiffrement du trafic n’aurait plus d’importance, car le pair lui-même serait malveillant ». Votre appareil fait confiance à un pair parce que le control plane lui a indiqué que cette clé appartient au tailnet.

Il pourrait modifier les ressources auxquelles vos appareils sont autorisés à accéder. La stratégie d’accès se trouve dans le control plane et est distribuée aux nœuds. Le livre blanc sur tailnet lock de Tailscale indique que tailnet lock « n’empêche pas un control plane compromis de perturber la connectivité de votre réseau, par exemple en ne distribuant pas les clés de nouveaux nœuds ou en distribuant une stratégie de contrôle d’accès qui refuse l’accès à tous les nœuds ».

Il voit les métadonnées des connexions dans tous les cas. Les journaux de flux réseau de Tailscale enregistrent les événements d’ouverture et de fermeture de chaque connexion entre machines. La documentation précise que ces journaux « ne contiennent strictement aucune information sur les opérations des clients ni sur le contenu du trafic réseau ». Le control plane peut donc savoir quels appareils ont communiqué entre eux et à quel moment. Il ne sait pas ce qu’ils se sont dit.

Un seul élément de cette liste concerne le chiffrement. Les autres concernent les membres du réseau et le contenu de la stratégie. C’est pourquoi les contrôles à examiner en priorité sont ceux qui régissent l’inscription des nœuds.

Votre fournisseur d’identité est la racine de confiance du tailnet

Tailscale ne gère pas sa propre base de mots de passe. Sa documentation indique clairement qu’il n’existe pas de mots de passe Tailscale et que l’authentification est déléguée à un fournisseur d’identité (IdP) : Apple, Google, GitHub, Microsoft, Okta, OneLogin ou un fournisseur OpenID Connect personnalisé.

Considérez cela comme un point de sécurité, car c’en est un. Toute personne capable de se connecter à votre compte Google ou Microsoft peut se connecter à votre tailnet. Votre authentification multifacteur (MFA) dépend des règles appliquées par l’IdP. Votre procédure de départ dépend de ce que fait l’IdP lorsqu’une personne quitte l’organisation. Un compte IdP compromis devient un compte du tailnet, et l’attaquant n’a jamais besoin d’attaquer WireGuard : il ajoute un appareil et obtient les droits accordés à cet utilisateur par votre stratégie.

Deux contrôles séparent un compte d’identité volé d’un appareil fonctionnel au sein de votre tailnet : l’approbation des appareils et l’expiration des clés. Tailnet lock en constitue un troisième. Il vise le control plane plutôt que le compte.

Approbation des appareils : rien ne se connecte tant qu’une personne n’a pas donné son accord

La documentation de Tailscale décrit l’approbation des appareils comme une fonctionnalité qui « permet aux administrateurs du réseau Tailscale d’examiner et d’approuver les nouveaux appareils avant qu’ils puissent rejoindre votre réseau Tailscale ». Un Owner, un Admin ou un IT admin peut approuver un appareil. Un nouvel appareil affiche le badge « Needs approval » dans la page Machines jusqu’à ce qu’une personne intervienne.

Activez cette fonctionnalité, et le scénario du compte compromis change. L’attaquant se connecte, l’appareil s’enregistre, puis reste bloqué sans pouvoir atteindre quoi que ce soit. Dans votre console d’administration, un badge vous indique qu’une machine que vous ne reconnaissez pas demande à rejoindre le réseau. L’automatisation continue de fonctionner, car vous pouvez marquer une auth key comme préapprouvée lors de sa création, et approuver les appareils via l’API.

Les auth keys sont l’autre moyen d’accès. Traitez-les donc comme des identifiants. La documentation de Tailscale est claire au sujet du type le plus risqué : « Soyez très prudent avec les clés réutilisables ! Elles peuvent être très dangereuses si elles sont volées. Il est préférable de les conserver dans un produit de coffre-fort de clés spécialement conçu à cet effet. » En août 2026, la durée d’expiration documentée va de 1 à 90 jours. Si aucune durée n’est indiquée, la valeur par défaut est la limite maximale de 90 jours. Préférez les clés à usage unique. Marquez-les comme éphémères pour les machines temporaires. Conservez toute clé réutilisable chiffrée avec Ansible Vault ou dans un secrets manager, plutôt que dans un shell script.

Expiration des clés : le délai qui limite toutes les autres erreurs

Les clés des nœuds expirent. Un appareil volé ou oublié devient ainsi un problème temporaire. La documentation de Tailscale indique que « par défaut, les nouveaux domaines ont une période d’expiration de 180 jours » et que « si la réauthentification n’a pas lieu, les clés expirent et les connexions vers le point de terminaison concerné et depuis celui-ci cessent de fonctionner ». Vous pouvez réauthentifier vous-même un appareil :

tailscale up --force-reauth

La documentation avertit que cette opération « peut interrompre la connexion tailnet. Elle ne doit donc pas être effectuée à distance via SSH ou RDP sans autre moyen de se connecter si la connexion est perdue ». Ouvrez une session console ou utilisez un second accès à la machine, car vous êtes sur le point d’interrompre le réseau que vous utilisez.

C’est sur les serveurs que ce contrôle est généralement désactivé. Une machine qui doit se réauthentifier tous les 180 jours peut quitter le tailnet à 3 heures du matin, sans personne pour intervenir. Les administrateurs désactivent donc l’expiration des clés sur cette machine. Le délai qui aurait fini par invalider une clé volée disparaît alors. Pour un serveur, un appareil associé à un tag constitue une meilleure solution, car le tag associe la machine à un rôle plutôt qu’à une personne. La machine reste ainsi fonctionnelle même si cette personne quitte l’entreprise. Quelle que soit votre décision, tenez une liste des machines pour lesquelles l’expiration est désactivée : leurs clés restent valides jusqu’à la suppression de l’appareil.

Tailnet lock : retirer le serveur de coordination de la chaîne de confiance

Tailnet lock s’attaque directement au problème de l’inscription. La documentation de Tailnet lock de Tailscale explique le mécanisme : « Lorsqu’un nouveau nœud rejoint le tailnet, sa clé publique de nœud doit recevoir une signature d’une clé Tailnet Lock. Le serveur de coordination distribue la clé publique de nœud signée aux nœuds pairs. » Vos appareils existants vérifient cette signature avant d’accepter un pair. Une clé de nœud créée de sa propre initiative par le control plane est donc refusée.

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init active la fonctionnalité, et vous désignez vos nœuds signataires à ce moment-là. Tailscale exige au moins 2 nœuds signataires lors de l’initialisation et en autorise au maximum 20 dans un tailnet. Ensuite, chaque nouvel appareil doit recevoir une signature de l’un d’eux. Cela représente un véritable coût opérationnel : ajouter un téléphone signifie exécuter une commande sur un ordinateur portable.

Les limites sont documentées et elles comptent davantage que la description de la fonctionnalité :

• Si vous perdez le secret de désactivation, il n’existe aucune procédure de récupération. La documentation indique : « Si vous perdez vos secrets de désactivation et que vous n’en avez pas fourni un au support Tailscale, le tailnet ne peut pas être récupéré. »
• La clé de signature se trouve sur un appareil que vous possédez. Elle hérite donc du niveau de sécurité de cet appareil. La documentation est explicite : « Si l’appareil est compromis, la clé peut être récupérée. »
• Vous ne pouvez pas utiliser les 2 contrôles simultanément. Tailscale indique que Tailnet lock et l’approbation des appareils s’excluent mutuellement. Activer l’un revient donc à renoncer à l’autre.
• Il s’agit d’un mécanisme de confiance au premier usage (TOFU). La configuration initiale passe toujours par le control plane. L’ancrage de confiance ne se déplace dans votre propre réseau qu’après cette première étape.

Tailnet lock protège l’appartenance au tailnet. Il ne protège pas la disponibilité, et le livre blanc le précise.

Une connexion relayée expose-t-elle mon trafic ?

Non. Lorsque deux appareils ne peuvent pas communiquer directement, le trafic passe par un serveur DERP (Designated Encrypted Relay for Packets). La documentation de Tailscale l’indique sans réserve : « Comme les clés privées Tailscale ne quittent jamais l’appareil local qui les a générées, un serveur DERP ne peut pas déchiffrer votre trafic. Un serveur DERP retransmet aveuglément un trafic déjà chiffré d’un appareil vers un autre. »

Un relais réduit toutefois le débit et observe des métadonnées : deux points d’extrémité chiffrés, ainsi que le moment et le volume des données échangées. Vérifiez le type de connexion réellement utilisé :

tailscale status
tailscale netcheck

tailscale status indique pour chaque pair s’il est en connexion directe, affichée comme direct 203.0.113.10:41641, ou relayée, affichée comme relay suivie du nom du relais, avec les compteurs d’octets à la suite. Si un pair reste connecté via un relais, les deux extrémités n’ont pas pu établir un chemin direct, généralement parce que l’UDP est bloqué quelque part ou parce que les deux côtés sont derrière un NAT strict (network address translation). tailscale netcheck indique si l’UDP fonctionne depuis cette machine, comment le NAT mappe les ports et quelle est la latence vers les relais les plus proches. Ces informations permettent de déterminer laquelle de ces deux causes est en jeu.

Un nœud de sortie déplace votre trafic sortant, mais ne le supprime pas

Un nœud de sortie achemine tout le trafic Internet public d’un appareil via un autre appareil du tailnet, en utilisant les routes par défaut 0.0.0.0/0 et ::/0. Sous Linux, la machine qui fournit ce service l’annonce, puis chaque client choisit de l’utiliser :

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

Un nœud de sortie doit être approuvé par un Owner, un Admin ou un Network admin dans la console d’administration. Votre policy doit également accorder autogroup:internet avant qu’un client puisse l’utiliser. Ces deux étapes sont intentionnelles : une machine non approuvée ne peut pas devenir discrètement la porte de sortie de tout votre tailnet.

La question est alors celle de la confiance. Le trafic est chiffré entre votre ordinateur portable et le nœud de sortie. Il quitte ensuite cette machine comme du trafic Internet ordinaire, avec l’adresse IP de cette machine. L’opérateur du nœud de sortie voit donc vos destinations. Le voient aussi l’hébergeur de cette machine et son réseau en amont. Vous avez déplacé le point d’observation au lieu de le supprimer. C’est un bon compromis lorsque vous contrôlez l’extrémité distante, ce qui justifie l’exécution de votre propre nœud de sortie sur un VPS, mais un mauvais choix dans le cas contraire.

La stratégie par défaut est un réseau plat

Un tailnet nouvellement créé est permissif. La documentation du contrôle d’accès de Tailscale indique que le fichier de stratégie par défaut « autorise les communications entre tous les appareils du tailnet ». Chaque appareil peut atteindre tous les autres appareils sur tous les ports. C’est un réseau plat. Vous l’avez déplacé à l’intérieur du tunnel, ce qui protège contre les connexions externes, mais ne change rien si un ordinateur portable est infecté.

Durcissez cette configuration dans le fichier de stratégie du tailnet. Celui-ci accepte les listes de contrôle d’accès (ACL) ou les grants plus récents. Les deux utilisent un dialecte JSON qui autorise les commentaires :

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

Cette stratégie permet à un groupe d’accéder au service SSH sur les serveurs de production, autorise les membres à utiliser un exit node et refuse tout le reste par omission. Tailscale indique quelles cibles de règles sont disponibles selon le forfait. Vérifiez donc ces informations avant de concevoir votre configuration autour des tags ou des autogroups, et consultez ce que comprend réellement le forfait gratuit. Pour un appareil qui ne doit jamais accepter de connexions entrantes, comme un téléphone personnel, tailscale set --shields-up les bloque côté client.

Ce que change l’auto-hébergement du control plane avec Headscale

Headscale est « une implémentation open source et auto-hébergée du serveur de contrôle Tailscale ». Son README définit clairement sa portée : « Il couvre un périmètre limité, un seul réseau Tailscale (tailnet), adapté à un usage personnel ou à une petite organisation open source. » Sa liste de fonctionnalités comprend les ACL et les grants, les subnet routers, les exit nodes, un serveur DERP intégré, Tailscale SSH et Taildrop. Si ce périmètre limité pose problème, NetBird est l’autre mesh qui fournit un control plane auto-hébergeable. Exécuter le serveur NetBird sur votre propre VPS déplace la même décision d’enrôlement vers du matériel que vous possédez.

Ce qui change, c’est l’identité de l’entité qui pourrait enrôler un nœud compromis. Avec Headscale, le répertoire des clés et la policy se trouvent sur votre serveur. Aucun tiers ne détient la liste des clés publiques de vos appareils. Aucun tiers ne peut être contraint d’en transmettre une ou d’en signer une.

Le data plane, lui, ne change pas. Il s’agit toujours de WireGuard, avec le même chiffrement de bout en bout et le même relais de secours lorsqu’un chemin direct est impossible. Vous récupérez aussi les tâches que Tailscale prenait en charge : surveillance de la disponibilité, application des correctifs, sauvegardes et sécurité physique du serveur. Un serveur Headscale compromis donne à un attaquant exactement les mêmes capacités qu’un serveur de coordination compromis : enrôler un nœud et distribuer une policy. Tailnet lock ne figure pas dans la liste des fonctionnalités de Headscale. Le contrôle compensatoire contre ce risque précis n’est donc pas disponible. Si la question de la propriété est celle qui détermine votre choix, auto-héberger le control plane avec Headscale présente la procédure de configuration.

Contre quoi Tailscale vous protège

• Les ports d’écoute publics. Un service lié à une adresse tailnet n’est pas accessible depuis Internet. Les scanners qui testent chaque VPS sur le port 22 ne le voient donc jamais. L’exception est activée par vos soins : Funnel publie volontairement un service tailnet sur Internet. Il est donc utile de savoir où s’arrête serve et où commence funnel avant d’exécuter l’une ou l’autre commande. Conservez malgré tout le pare-feu de l’hôte. Un port Docker publié ajoute ses propres règles et contourne ufw sur l’interface publique.
• La devinette de mots de passe contre les connexions exposées. Il n’y a rien à tester en masse lorsque le port ne répond qu’à l’intérieur du tunnel. C’est une protection plus efficace que la limitation de débit sur un port ouvert. Toutefois, fail2ban sur Ubuntu 24.04 reste utile pour tout service qui doit rester public.
• Les réseaux non fiables sur le chemin. Le trafic entre vos machines est chiffré de bout en bout sur un réseau Wi-Fi de café ou un LAN partagé d’un fournisseur. Il reste également chiffré lorsqu’il est relayé.
• La distribution manuelle des clés. Chaque pair ajouté manuellement à une configuration WireGuard peut entraîner la réutilisation d’une adresse ou le collage de la mauvaise clé. Le maillage gère cette configuration à votre place. C’est l’essentiel de la différence pratique entre WireGuard et Tailscale.

Ce que Tailscale ne protège pas

• Un terminal compromis. Le tailnet fait confiance aux appareils. Un logiciel malveillant présent sur un ordinateur portable approuvé obtient le tunnel, les adresses du tailnet et les accès accordés à cet utilisateur par votre politique. C’est la principale faille, et aucun VPN ne la supprime.
• Un administrateur malveillant ou négligent. Toute personne capable de modifier le fichier de stratégie peut s’accorder l’accès à n’importe quelle ressource. Toute personne qui prend le contrôle du compte d’identité d’un Owner peut faire de même. Examinez les modifications de la stratégie comme vous examinez du code.
• L’analyse du trafic. Votre FAI (fournisseur d’accès à Internet) voit des paquets UDP chiffrés à destination d’un endpoint, ainsi que leur fréquence et leur volume. Les journaux de flux de Tailscale indiquent quels pairs ont communiqué et à quel moment. Aucun des deux ne voit le contenu, mais l’existence de la connexion n’est pas masquée. Consultez les différences entre Tor et un VPN avant de choisir un outil pour ce besoin.
• Un appareil que vous avez déjà perdu. L’expiration de la clé constitue une mesure de secours lente, avec une valeur par défaut de 180 jours. La suppression de l’appareil dans la console d’administration est la mesure rapide. Vous devez donc savoir où se trouve ce bouton avant d’en avoir besoin.

Vérifiez votre propre tailnet

1. Exécutez tailscale status sur un appareil et consultez la liste des pairs. Une machine que vous ne pouvez pas identifier correspond exactement à la situation que l’approbation des appareils doit empêcher.
2. Exécutez tailscale lock status pour vérifier si tailnet lock est activé, puis déterminez si la signature de chaque nouvel appareil justifie le coût pour votre tailnet.
3. Ouvrez la console d’administration et notez chaque machine pour laquelle l’expiration de la clé est désactivée, ainsi que chaque clé d’authentification réutilisable qui existe encore. Dans les deux cas, il s’agit d’identifiants sans délai d’expiration.
4. Lisez votre fichier de policy. S’il s’agit encore de la configuration par défaut, chaque appareil peut joindre tous les autres appareils sur tous les ports, et un ordinateur portable infecté peut tous les atteindre.

Tailscale gagne sa réputation sur le data plane, où la conception ne laisse à l’opérateur aucun moyen de lire votre trafic. Prenez cette affirmation telle que la documente l’éditeur, puis auditez les éléments qui relèvent de votre configuration : les comptes d’identité, le paramètre d’approbation, la liste des expirations et le fichier de policy. La page de sécurité de Tailscale indique une certification SOC 2 Type II et un travail de sécurité continu avec Latacora. Cela fournit des informations sur leurs processus, et non une garantie concernant votre configuration.

FAQ

Tailscale peut-il lire mon trafic ?

Non. Le trafic est chiffré avec des clés WireGuard générées sur vos appareils. La page de sécurité de Tailscale précise que « les clés privées ne quittent jamais l’appareil. Tout le trafic est toujours chiffré de bout en bout ». Cela s’applique aussi aux connexions qui passent par un relais DERP, car celui-ci « transmet aveuglément le trafic déjà chiffré d’un appareil à un autre » et ne détient aucune clé permettant de le déchiffrer. L’infrastructure de Tailscale voit uniquement des métadonnées : les appareils présents, ainsi que les appareils qui se sont connectés entre eux et l’heure de ces connexions.

Que pourrait réellement faire un serveur de coordination Tailscale compromis ?

Il pourrait inscrire un nœud. L’annonce de tailnet lock de Tailscale décrit le risque lié à l’ajout secret d’un nœud qui pourrait « envoyer ou recevoir du trafic vers vos nœuds existants ». Le chiffrement ne protège pas contre ce risque, « car le pair lui-même pourrait être malveillant ». Un control plane compromis pourrait également distribuer une policy modifiant les ressources auxquelles vos appareils peuvent accéder. Le livre blanc sur tailnet lock indique aussi qu’il pourrait interrompre la connectivité en ne distribuant pas les nouvelles clés de nœud. En revanche, il ne pourrait pas déchiffrer le trafic entre vos appareils existants, car il n’a jamais détenu leurs clés privées.

Un exit node masque-t-il ma navigation à mon FAI ?

Il masque les destinations au réseau auquel vous êtes connecté, notamment le FAI de votre domicile ou du café. Tout le trafic quitte votre appareil sous forme chiffrée, à destination de l’exit node. Cela ne vous rend pas anonyme. L’exit node voit ces destinations, tout comme son hébergeur et le réseau en amont. Les sites que vous consultez voient l’adresse IP de l’exit node. Vous choisissez donc un autre observateur. Choisissez-en un auquel vous faites réellement confiance.

Headscale est-il plus sécurisé que le serveur de coordination de Tailscale ?

Il s’agit d’une décision de confiance différente, et pas nécessairement d’une solution plus sûre. Avec Headscale, vous contrôlez l’annuaire des clés et la policy. Aucun tiers ne peut donc être contraint d’inscrire un appareil dans votre tailnet. En contrepartie, vous devez administrer ce serveur : appliquer les correctifs, garantir sa disponibilité, effectuer les sauvegardes et sécuriser l’hôte lui-même. Un hôte Headscale compromis donne à un attaquant le même pouvoir d’inscription qu’un serveur de coordination compromis. De plus, tailnet lock ne figure pas parmi les fonctionnalités de Headscale. Protégez donc cet hôte en conséquence.

Ai-je encore besoin d’un firewall sur un VPS qui appartient à mon tailnet ?

Oui. L’interface réseau publique existe toujours. Tout service lié à 0.0.0.0 reste donc accessible depuis Internet, que Tailscale soit exécuté ou non. Liez les services à l’adresse du tailnet. Conservez une policy par défaut qui refuse le trafic sur l’interface publique. Vérifiez également les ports publiés de vos conteneurs, car Docker ajoute ses propres règles et peut exposer un port que vous pensiez fermé.