Tailcat : Tailscale sans compte, sans serveur de contrôle et sans root

Il existe une catégorie d’outils qui commence par résoudre un petit problème très précis avant de finir comme couteau suisse dans le dossier ~/bin de tous les administrateurs système.

netcat en fait partie.

Besoin d’envoyer quelques octets d’une machine à une autre ? Netcat. Tester un port ? Netcat. Improviser un transfert ? Netcat. Créer quelque chose qui ressemble vaguement à un protocole réseau avec deux tubes et beaucoup de confiance en l’avenir ? Encore netcat.

Le problème apparaît lorsque les deux machines ne vivent pas tranquillement sur le même réseau local. Dès qu’il faut traverser une box Internet, un NAT d’entreprise ou une connexion mobile, le petit tuyau devient soudain beaucoup plus compliqué.

C’est précisément là que Tailcat devient intéressant.

Publié en open source par Tailscale à la fin du mois d’août 2026, Tailcat reprend les composants réseau du client Tailscale pour créer des connexions chiffrées entre deux machines, mais sans utiliser le plan de contrôle Tailscale. Pas de compte à créer, pas de tailnet à administrer, pas de console web et aucune modification globale du réseau de la machine.

En résumé, Tailscale l’appelle lui-même : « Tailscale without Tailscale, by Tailscale ».

Et pour une fois, le slogan marketing décrit plutôt bien le produit.

Un VPN auquel on a retiré presque tout le VPN

Tailscale classique repose sur plusieurs briques. WireGuard assure le chiffrement du trafic, tandis que le plan de contrôle aide les machines à se découvrir, échange leurs informations de connexion et applique différentes règles d’accès.

Tailcat conserve essentiellement le data plane.

L’outil réutilise WireGuard pour le chiffrement, magicsock pour trouver le meilleur chemin réseau entre les machines et les relais DERP comme canal de rendez-vous ou solution de secours lorsque la traversée directe du NAT échoue.

Mais il n’existe ici aucun serveur de coordination central chargé de savoir que « PC-de-Michel » appartient au même réseau privé que « NAS-du-garage ».

À la place, le serveur Tailcat génère une adresse Tailcat, une chaîne contenant les informations cryptographiques et réseau nécessaires à l’établissement de la connexion. Il suffit ensuite de transmettre cette adresse au client par le moyen de son choix : messagerie privée, terminal distant, QR code maison ou pigeon voyageur particulièrement à l’aise avec Base64.

Le client utilise ces informations pour amorcer la connexion via DERP puis tente d’établir une liaison UDP directe entre les deux machines. Si cela fonctionne, les données circulent directement de pair à pair. Sinon, DERP reste utilisé comme relais.

Pas besoin de root, et c’est probablement le détail le plus pratique

Un VPN traditionnel installe généralement une interface réseau virtuelle, touche aux routes du système et a donc tendance à demander des privilèges administrateur.

Tailcat évite tout cela.

L’outil utilise une pile réseau entièrement en espace utilisateur, avec notamment gVisor netstack, et ne crée pas de périphérique TUN/TAP. Il n’a donc pas besoin de modifier la table de routage ou le DNS du système. Résultat : aucun accès root ou administrateur n’est nécessaire pour le fonctionnement normal.

Cette particularité ouvre quelques scénarios assez sympathiques.

Vous êtes connecté en SSH sur un serveur où vous n’avez aucun droit root mais vous voulez rendre temporairement accessible une application locale ? Tailcat peut le faire.

Vous lancez un environnement de développement jetable dans lequel installer un VPN complet n’a aucun sens ? Même chose.

Vous avez un agent automatisé ou une VM éphémère qui doit communiquer quelques minutes avec une autre machine derrière un NAT ? Tailcat commence également à devenir intéressant.

On est donc davantage face à une bibliothèque de transport sécurisé et à un outil de tunnel ponctuel qu’à un remplacement complet du client Tailscale.

Le « Hello World » ressemble vraiment à netcat

L’utilisation de base est presque insultante de simplicité.

Sur une première machine :

Le programme démarre alors en mode serveur et affiche une adresse Tailcat.

Sur l’autre machine, il suffit de fournir cette adresse :

Le texte ressort directement sur la première machine. Le flux standard d’entrée et de sortie devient donc un tuyau chiffré entre les deux hôtes, comme avec netcat, mais avec WireGuard, NAT traversal et DERP derrière.

Pour tester rapidement quelque chose ou transporter un petit protocole maison entre deux réseaux complètement différents, c’est plutôt élégant.

Mais Tailcat sait désormais faire nettement plus.

Vous voulez exposer un port local ? Trois mots

Un service web tourne sur le port 8080 d’un serveur situé derrière une box Internet et vous voulez y accéder sans ouvrir le port au monde entier.

Sur la machine distante :

Tailcat affiche son adresse.

Sur votre poste :

Votre port local est alors relié au service de l’autre côté du tunnel. Le même mécanisme peut exposer plusieurs ports, rediriger un port vers une autre machine du LAN distant ou choisir automatiquement un port disponible localement.

La commande browse simplifie même le cas du serveur web :

Tailcat crée le port local puis ouvre directement le navigateur dessus.

Ce n’est pas révolutionnaire pris séparément. SSH sait faire du port forwarding depuis l’époque où les écrans LCD coûtaient un rein.

Ce qui change ici, c’est que vous n’avez pas besoin que les deux machines soient déjà capables de se joindre sur Internet.

C’est Tailcat qui s’occupe de cette partie.

SSH sans ouvrir SSH sur Internet

Et puisqu’on parle de SSH, Tailcat peut maintenant fournir son propre serveur.

Il est possible de lancer :

puis de se connecter avec :

L’outil accepte des clés publiques locales, des clés OpenSSH directement passées en argument ou même les clés publiques associées à un compte GitHub.

Cela permet par exemple de fournir ponctuellement un accès shell vers une machine située derrière un NAT sans configurer de redirection de port sur le routeur et sans exposer sshd publiquement.

Il existe même un mode no-auth-ssh dans lequel l’adresse Tailcat sert elle-même de secret d’accès.

Et là, il faut évidemment commencer à lire les petites lignes.

L’adresse Tailcat est un mot de passe déguisé

Depuis la version 0.6, les adresses Tailcat embarquent par défaut une clé pré-partagée WireGuard en plus des informations nécessaires à la découverte du pair. Cela renforce l’authentification cryptographique du tunnel, mais transforme de fait l’adresse en bearer token.

En français : si quelqu’un récupère l’adresse et que vous n’avez ajouté aucun contrôle d’accès supplémentaire, cette personne peut potentiellement se connecter.

Le README est particulièrement clair sur ce point : ne publiez pas une adresse Tailcat dans un DNS public, un dépôt GitHub ou un endroit accessible à tout Internet, sauf si le service derrière applique lui-même une authentification solide.

Avec no-auth-ssh, la conséquence est encore plus simple : celui qui possède l’adresse possède le shell.

Pratique pour une machine jetable entre deux équipements qui vous appartiennent.

Beaucoup moins drôle lorsque l’adresse finit accidentellement dans les logs d’une CI publique.

Tailcat sait aussi transférer des fichiers

L’outil intègre des mécanismes de copie reposant sur SFTP et sait notamment travailler avec tailcat cp. Les versions récentes ont amélioré la compatibilité avec les clients OpenSSH 8.7 à 8.9, comme celui fourni dans Ubuntu 22.04.

Le projet propose également un mode destiné à recevoir des fichiers, pratique lorsqu’on souhaite créer une sorte de boîte de dépôt temporaire.

Cette partie a d’ailleurs déjà donné lieu à plusieurs corrections de sécurité. Des chercheurs avaient remarqué que les premières implémentations du mode d’écriture pouvaient permettre d’écraser des fichiers existants ou de tester leur présence en devinant leur nom. Les développeurs ont modifié le fonctionnement pour que les fichiers reçus soient stockés sous des noms choisis par le serveur et ont rendu l’acceptation des répertoires explicitement optionnelle.

Et c’est justement là que l’on arrive au gros astérisque attaché au projet.

C’est open source, très pratique… et encore expérimental

Tailcat s’appuie sur des composants Tailscale utilisés en production : WireGuard, magicsock, DERP et gVisor netstack.

Mais le wrapper Tailcat lui-même est encore considéré comme expérimental.

Le document de sécurité officiel explique que son modèle de menace historique correspond surtout à une personne utilisant les deux extrémités elle-même. L’outil n’a pas encore été durci pour tous les scénarios dans lesquels deux utilisateurs mutuellement méfiants échangent des adresses Tailcat et exposent des shells, des dossiers accessibles en écriture ou des exit nodes.

Les développeurs déconseillent donc d’accepter aveuglément des adresses provenant d’inconnus ou de donner des services particulièrement puissants à des gens auxquels vous ne faites pas confiance.

Ils préviennent également que l’API Go, les options de la CLI et même le format réseau peuvent encore changer.

En clair : c’est excellent pour bidouiller, automatiser, expérimenter et relier rapidement vos propres machines.

Pour remplacer demain matin le VPN critique d’une banque internationale, on peut peut-être attendre la version 1.0.

Les relais Tailscale sont disponibles, mais vous pouvez aussi héberger les vôtres

Par défaut, Tailcat peut utiliser les relais DERP publics proposés gratuitement par Tailscale.

DERP ne déchiffre pas le trafic WireGuard : le serveur relaie des paquets chiffrés entre les pairs lorsque ceux-ci n’arrivent pas à créer une connexion UDP directe.

Mais ces relais publics Tailcat sont fournis sans SLA, avec des limitations de débit, et Tailscale précise qu’il peut modifier ou retirer leur accès.

Pour une infrastructure réellement autonome, il est donc possible d’héberger son propre serveur DERP et d’utiliser sa propre carte de relais.

On obtient alors quelque chose d’assez amusant : la mécanique réseau de Tailscale, mais sans compte Tailscale, sans plan de contrôle Tailscale et potentiellement sans infrastructure Tailscale du tout.

La marque vient vraiment de publier un outil permettant d’utiliser moins de sa marque.

On ne peut pas leur enlever une certaine élégance.

Et ça tourne presque partout

L’installation est assez généreuse.

Les releases officielles proposent des binaires Linux statiques, des paquets .deb et .rpm, ainsi que des versions Windows. macOS peut passer par Homebrew, Windows par Scoop, Linux par Snap, Nix ou l’AUR, et une image Docker est également disponible. Il est bien sûr possible de compiler directement le projet en Go.

Tailcat existe même dans une version WebAssembly expérimentale utilisable directement depuis un navigateur pour transférer du texte ou des fichiers avec la CLI.

Dans le navigateur, il existe toutefois une limitation importante : le trafic passe actuellement uniquement par DERP, puisque la connexion directe nécessiterait une couche WebRTC qui n’est pas encore implémentée.

La dernière release stable disponible au moment d’écrire ces lignes est la 0.7.0, publiée le 19 septembre 2026. Elle ajoute notamment le forwarding UDP pour les exit nodes, améliore le transfert de fichiers, introduit une commande browse et ajoute plusieurs mécanismes supplémentaires autour des services et des connexions.

Le projet évolue donc plutôt vite pour quelque chose qui vient officiellement de sortir de la boîte.

Un outil particulièrement intéressant pour les agents et les environnements jetables

Il existe un cas d’usage qui explique probablement assez bien pourquoi Tailscale a pris la peine de transformer cette expérimentation en véritable projet open source : les machines temporaires et les agents automatisés.

Un agent IA qui travaille quelques minutes dans une VM peut avoir besoin d’accéder à un service de développement situé sur une autre machine. Créer un compte réseau, enregistrer le nœud dans un VPN, distribuer une identité permanente puis penser à supprimer cette identité ensuite représente beaucoup de plomberie pour une connexion qui vivra quinze minutes.

Tailcat permet au contraire de fabriquer un tunnel dont toutes les informations nécessaires sont contenues dans une chaîne que l’on peut transmettre à l’agent puis jeter après usage.

Le même principe peut servir dans une CI, un environnement de test éphémère ou une VM démarrée uniquement pour une tâche précise.

Cela explique également pourquoi Tailcat est disponible comme bibliothèque Go et pas uniquement comme binaire. Un développeur peut directement intégrer ce transport chiffré et cette traversée de NAT dans son propre logiciel sans devoir installer et piloter un VPN système complet.

Là, ça devient beaucoup plus qu’un petit netcat rigolo.

Le retour du tuyau Unix, mais avec WireGuard autour

Les outils réseau ont parfois une drôle de trajectoire.

On passe plusieurs années à construire des plateformes complètes avec comptes, consoles, ACL, API, dashboards et politiques d’accès sophistiquées, puis quelqu’un finit par demander :

« Et si je voulais juste envoyer des octets de cette machine à celle-là ? »

Tailcat revient exactement à cette idée.

Deux programmes.

Une adresse.

Un tunnel WireGuard.

Une tentative de connexion directe.

Un relais si Internet décide d’être pénible.

Et rien à installer au niveau du système.

Il ne remplacera pas Tailscale pour gérer un véritable réseau privé composé de dizaines de machines. Il n’a ni la gestion centralisée des identités, ni les ACL, ni l’expérience d’administration d’un tailnet complet.

Mais ce n’est précisément pas son objectif.

Pour une connexion temporaire entre deux machines qui ne peuvent normalement pas se voir, pour accéder à un petit service derrière un NAT ou pour construire son propre outil réseau sécurisé sans réinventer la traversée NAT, Tailcat est le genre de projet qui finit très vite dans la boîte à outils du geek.

Netcat avait un tuyau.

Tailcat lui a ajouté WireGuard, du hole punching et un chat dans le nom.

Difficile de faire beaucoup plus Internet que ça.