Présentation de tailcat

Tailcat est un paquet Go open source et un outil en ligne de commande qui réutilise le plan de données de Tailscale – WireGuard®, la traversée NAT et le relais DERP – sans recourir au plan de contrôle propriétaire. Le projet, développé par les créateurs de Tailscale, se décrit comme « netcat » fonctionnant au‑dessus du magicsock de Tailscale, c’est‑à‑dire le protocole de transport chiffré et les mécanismes de découverte de pair.

Architecture et fonctionnement

Le serveur tailcat génère une paire de clés (éphémère ou persistante), sélectionne un serveur DERP (défini par l’utilisateur ou automatiquement choisi parmi les serveurs Tailscale) et crée une adresse tailcat sous la forme 

tc+base64(CBOR(public key+DERP bootstrap info))
. Cette chaîne, partagée hors‑bande ou via un enregistrement DNS TXT, encode la clé publique et les informations de point d’ancrage DERP. Le client récupère la même adresse, établit une connexion au serveur DERP indiqué, puis envoie un message « MEOW » contenant sa clé publique. Si le serveur accepte la clé, il répond par un « MEOW » positif et les deux parties initient une connexion TCP utilisateur au‑dessus de WireGuard.

Les adresses IP réelles sont dérivées de la clé publique (IPv6 synthétique) mais restent invisibles pour le système d’exploitation. Aucun dispositif TUN, aucune modification de la table de routage et aucun privilège root ne sont requis ; le trafic passe uniquement par les sockets DERP (TCP) ou les paquets UDP WireGuard, avec la traversée NAT gérée automatiquement par le magicsock. En cas d’échec de la connexion directe, le relais DERP agit comme fallback, mais l’utilisateur peut déployer son propre serveur DERP pour supprimer les limites de bande passante imposées par les serveurs hébergés par Tailscale.

Analyse des performances et limites

Le modèle sans plan de contrôle élimine les dépendances aux comptes, aux ACL et aux services d’authentification, ce qui réduit la surface d’attaque liée à la gestion des identités. Cependant, l’absence de mécanismes d’autorisation centralisée signifie que la sécurité repose entièrement sur la validation manuelle des clés publiques et sur la configuration du serveur DERP. Le chiffrement WireGuard assure la confidentialité et l’intégrité des paquets, mais la latence peut augmenter lorsqu’un relais DERP est utilisé, surtout si le serveur est soumis à une limitation de bande passante (les serveurs Tailscale sont facturés en fonction du trafic).

Le fait que le plan de données fonctionne en espace utilisateur évite les risques liés aux privilèges kernel, mais impose une surcharge CPU pour le traitement du cryptage et de la pile TCP logicielle. Les tests internes indiquent que le débit maximal reste comparable à une connexion WireGuard native tant que le chemin direct est établi; en revanche, le débit chute d’environ 30 % lorsqu’un relais DERP intervient, en fonction de la capacité du serveur de relais.

Cas d’usage et perspectives

Tailcat a trouvé des applications concrètes chez des clients qui souhaitent connecter des agents d’IA sandboxés, des Raspberry Pi ou des machines virtuelles sans exposer de ports ni gérer d’infrastructure d’authentification. Le mode SOCKS intégré permet de faire transiter des processus existants (curl, wget, etc.) via le tunnel tailcat sans modifier la configuration réseau du système hôte. Cette approche favorise des expérimentations rapides, notamment dans des environnements où la mise en place d’un plan de contrôle complet serait trop lourde.

En résumé, tailcat propose une implémentation minimaliste du plan de données Tailscale, offrant une alternative légère pour les scénarios où la gestion d’identités et de politiques n’est pas requise, tout en conservant les garanties de sécurité et de traversée NAT inhérentes à WireGuard et DERP.