Tailcat livre le plan de données WireGuard de Tailscale sans plan de contrôle
Le 31 août 2026, Brad Fitzpatrick a publié tailcat, un paquet Go et un CLI open source qui expose le plan de données de Tailscale — WireGuard, NAT traversal et DERP — sans compte, sans IP et sans plan de contrôle. Utilisez-le pour relier deux machines isolées ou donner à un agent IA un accès jetable, sans privilège root.
31 août 2026. Brad Fitzpatrick, cofondateur de Tailscale, publie tailcat : un « remix » open source qui donne accès au plan de données de Tailscale — WireGuard, traversée de NAT et relais DERP — sans le plan de contrôle. Septembre 2023. L’outil était né sur un vol long-courrier sous le nom derpcat, avant d’être ressuscité pour l’ère des agents IA. Août 2026. Il est open sourcé à la conférence TailscaleUp, sous licence BSD-3-Clause. Pourquoi c’est important : vous pouvez désormais monter un tunnel chiffré point à point entre deux machines en une seconde, sans compte, sans adresse IP visible et sans toucher à la configuration réseau de l’hôte.
Un netcat qui parle WireGuard, rien de plus
tailcat se résume en une phrase : « comme netcat, mais sur le plan de données de Tailscale, sans le plan de contrôle ». C’est à la fois une bibliothèque Go importable (github.com/tailscale/tailcat) et un CLI construit dessus. Un côté écoute, l’autre compose l’adresse, et le trafic circule chiffré de bout en bout par WireGuard.
Ce que tailcat n’a pas est aussi important que ce qu’il a. Pas d’adresse IP exposée à l’utilisateur, pas de compte, pas de connexion, pas de SSO, pas d’utilisateurs, pas d’administrateurs, pas de règles de gouvernance — et surtout, aucun besoin de privilège root ou admin : tout tourne en espace utilisateur, sans reconfigurer les tables de routage ni le DNS de la machine. La connexion initiale passe par un relais DERP, puis magicsock tente une traversée de NAT pour passer en UDP direct entre les deux pairs ; le relais ne sert de dernier recours que si le hole-punching échoue.
# côté serveur : écouter et afficher l'adresse éphémère
tailcat
# Selected bootstrap relay region 302, San Francisco
# 🐈 Server listening with new address: tcXXXXXXXXXXX
# côté client : envoyer des octets via l'adresse partagée hors bande
echo hello | tailcat tcXXXXXXXXXXXLe point crucial est le mode de distribution de l’adresse : elle est partagée hors bande — un message, un enregistrement TXT en DNS, peu importe — et elle fait office de secret. Tailscale le dit crûment dans sa FAQ : l’adresse est sensible, traitez-la comme un mot de passe, ne la committez pas et ne la tweetez pas.
Des cas d’usage courts, là où un tailnet est de trop
Tailscale est pensé pour une connectivité continue, scalable et auditable : identités, politiques ACL, SSO, journaux. tailcat occupe l’autre extrême : la connexion ponctuelle. La documentation officielle liste les usages types — développement distant, accès SSH, transfert de fichiers, jobs de CI, sessions de jeu, environnements sandboxés — et ajoute un cas devenu central en 2026 : donner à un agent IA un accès temporaire à une machine précise, sans l’intégrer à votre réseau.
C’est exactement le scénario qui a motivé la publication. Fitzpatrick raconte avoir utilisé tailcat pour câbler ses agents de codage à des machines jetables : une flotte de chaque génération de Raspberry Pi, une instance EC2 sandboxée qui pouvait rebooter sa voisine en boucle via kexec, ou un hôte Windows qui créait et détruisait des VM Hyper-V pour déboguer une corruption de pile dans le runtime Go. Dans ces cas, Tailscale complet aurait été possible mais « plus fastidieux au point de ne pas le faire » — on aurait fini par ouvrir des ports sur un pare-feu.
La mécanique interne mérite d’être nommée : chaque pair dérive une adresse IPv6 déterministe de sa clé publique WireGuard, mais c’est un détail d’implémentation jamais exposé. Les deux côtés utilisent une pile TCP en espace utilisateur (gVisor) au-dessus de WireGuard, si bien que le système d’exploitation ne voit jamais les adresses synthétiques de tailcat.
Ce qu’il faut savoir avant de l’adopter
tailcat est gratuit, mais sans promesse de stabilité. Le README est explicite : l’API Go, les flags du CLI, la sortie et même le format sur le fil peuvent changer. Les relais DERP publics de tailcat sont limités en débit, sans SLA de disponibilité, et Tailscale peut en révoquer l’accès à tout moment. Le relais hébergé conserve des journaux de métadonnées et n’est pas pensé pour la vie privée — tailcat n’est pas un service anonyme.
Pour le self-hébergeur, la vraie option est de fournir son propre relais : derper est open source, et Tailscale documente les Custom DERPs. En le déployant chez vous, vous supprimez la dépendance à l’infrastructure de Tailscale et vous reprenez le contrôle du débit et des métadonnées. L’outil embarque aussi des handlers SSH et SFTP natifs — des fichiers tailcat_ssh.go et tailcat_sftp.go dans le dépôt — ce qui en fait plus qu’un simple tube à octets.
# exposer des ports locaux à travers le tunnel
tailcat serve 8080,8443
# côté client : brancher un port local sur le service distant
tailcat tcXXXXXXXXXXX 8080L’installation est aussi large qu’on peut l’attendre d’un outil Go moderne : binaires statiques Linux (.deb, .rpm), Windows, macOS via Homebrew, conteneur sur ghcr.io, paquets AUR et conda-forge, et Nix. Le dépôt affichait déjà 6 300 étoiles et 243 forks quelques jours après l’annonce — un signal que le besoin existait.
Sous le capot : une adresse et un handshake MEOW
La magie tient en deux mécanismes. L’adresse tailcat est une chaîne de la forme tc suivie d’un blob base64(CBOR) qui encode la clé publique du serveur et les informations de bootstrap du relais DERP. Cette adresse est tout le secret : la partager, c’est autoriser la connexion. Le handshake, lui, est volontairement trivial — le client envoie un message MEOW à la clé publique du serveur via DERP pour s’ajouter à la netmap, et le serveur répond par un MEOW heureux s’il accepte la clé, avec une allowlist par clé en option pour verrouiller l’accès.
Côté données, la pile TCP en espace utilisateur (gVisor) court au-dessus de WireGuard, si bien que le système d’exploitation n’intervient jamais dans les connexions. Le serveur répartit ensuite le trafic entrant par port : transfert vers localhost, pipe vers la sortie standard, session SSH ou transfert SFTP selon la configuration. C’est cette sobriété qui rend l’outil adapté aux environnements jetables : rien n’est installé, rien n’est reconfiguré, et une machine compromise n’expose que ce qu’on lui a donné.
Un secret, pas un service anonyme
Un dernier avertissement de taille : tailcat n’est pas un service anonyme. L’accès repose sur la possession de l’adresse et des clés publiques que chaque nœud échange ; les clés représentent l’identité d’un nœud, et le relais DERP hébergé par Tailscale conserve des journaux de métadonnées. Pour qui veut la confidentialité complète des métadonnées, la seule réponse est d’héberger son propre derper — c’est d’ailleurs ce qui rend l’outil réellement « sans Tailscale » : à ce stade, aucune pièce de l’infrastructure de l’entreprise ne touche au trafic.
Verdict
Si vous avez besoin d’une connexion courte entre deux machines — un transfert de fichier, un accès SSH d’une heure, un agent IA qui doit toucher une VM sandboxée sans entrer dans votre réseau — prenez tailcat : une adresse, un pipe, et aucun compte ni privilège à gérer.
Si vous gérez un parc, des identités ou une politique d’accès, restez sur Tailscale (ou Headscale en auto-hébergé) : tailcat abandonne volontairement les comptes, les ACL, l’audit et la gestion des appareils, et ne les remplacera pas.
Si vous voulez vous passer de l’infrastructure de Tailscale, déployez votre propre derper et pointez tailcat dessus — c’est la condition pour supprimer la dépendance au relais public et garder la main sur le débit et les métadonnées.