Wat is Tailcat?
tailcat is een open-source CLI-tool en Go-pakket, ontwikkeld door het team van Tailscale. Het stelt gebruikers in staat om het data plane van Tailscale (WireGuard®, NAT-traversal en DERP) te gebruiken, maar zonder de bijbehorende control plane. Dit betekent dat de tool functioneert zonder accounts, vaste IP-adressen, centrale administratie of de noodzaak voor root-rechten op het besturingssysteem.
Werking
De tool werkt vergelijkbaar met netcat, maar maakt gebruik van Tailscale's magicsock. Het proces verloopt als volgt:
- Sleutels en Adressering: Er wordt een sleutelpaar gegenereerd en een
tailcat-adres gemaakt (een base64-string met publieke sleutel en DERP-info).
- Verbinding: De client maakt verbinding via een rendezvous DERP-server en communiceert via een "MEOW"-bericht om de verbinding te bevestigen.
- Dataoverdracht: Verkeer gaat via een userspace TCP-stack bovenop WireGuard. NAT-traversal probeert een directe UDP-verbinding te realiseren; indien dit faalt, wordt data via DERP-relays gerouteerd.
Use Cases
De auteur noemt verschillende scenario's waarin tailcat uitblinkt boven de volledige Tailscale-client:
- AI-Agents: Het geven van veilige toegang aan gesandboxte AI-agents tot remote VM's of specifieke hardware (zoals Raspberry Pi's).
- Tijdelijke verbindingen: Snel bestanden kopiëren of SSH-verbindingen maken tussen twee machines in verschillende netwerkomgevingen zonder systeemconfiguraties aan te passen.
- Transparantie: Gebruik als SOCKS-server voor applicaties die geen native ondersteuning hebben voor de tool.
Tailcat: Een open-source CLI voor Tailscale’s WireGuard®, NAT-traversal en DERP
Auteur: Brad Fitzpatrick Datum: 31 augustus 2026
Vandaag brengen we tailcat uit, een remix van onderdelen van Tailscale. Hiermee kun je het open-source data plane van Tailscale (WireGuard® + NAT-traversal + DERP) gebruiken zonder het control plane van Tailscale. Het is geschreven door de mensen die Tailscale hebben gemaakt. In feite is het Tailscale zonder Tailscale, door Tailscale.
Specifiek is tailcat zowel een open-source Go-pakket als een CLI-tool die dit pakket gebruikt. Het stelt je in staat om een server-side listener en een client te draaien om met die server verbinding te maken, waarbij bidirectionele bytes heen en weer worden gestuurd.
Je kunt het zien als netcat, maar dan via Tailscale’s magicsock (WireGuard-encryptie + NAT-traversal + DERP rendezvous/fallback relay).
Belangrijke kenmerken van tailcat
Opvallend is dat tailcat de volgende zaken niet heeft:
- Geen IP-adressen.
- Geen accounts (geen logins, geen wachtwoorden, geen SSO).
- Geen control plane.
- Geen gebruikers.
- Geen beheerders.
- Geen administratieve controles.
- Geen vereiste voor root- of admin-toegang tot het besturingssysteem.
- Geen relatie met of afhankelijkheid van Tailscale als bedrijf (mits je je eigen
cmd/derper DERP-server draait).
Wat betekent "Tailscale" eigenlijk?
Wanneer je mensen online Tailscale beschrijven, zie je vaak verschillende interpretaties van wat "Tailscale" precies betekent.
- De focus op WireGuard: Een groep mensen zegt vaak: "Ik draai WireGuard gewoon zelf." Zij focussen op het WireGuard-gedeelte en negeren (of hebben geen behoefte aan) zaken als NAT-traversal, DERP-fallbacks, centraal beheerde firewall-regels (ACL), SSO-login, tagging, MDM-beleid, audit-logging, etc. Voor hen is WireGuard op een publiek IP voldoende.
- De focus op het bedrijf: Een andere groep spreekt meer over het bedrijf, de bedrijfsstructuur, levensvatbaarheid op lange termijn, oprichters, financieringsfase, prijzen, certificeringen, betrouwbaarheid en de verantwoorde omgang met beveiligingsmeldingen.
- De focus op open source: Weer een andere groep vraagt zich af of Tailscale open source is. Ter herinnering: onze core is open source (met een echte OSI-goedgekeurde licentie!), onze DERP-server is open source, en onze clients zijn open source op platforms die zelf open source zijn: Linux en Android. Ons server-side control plane is dat niet. Veel mensen in deze doelgroep waarderen het bestaan van Headscale (waar we van houden en de ontwikkeling van gedeeltelijk financieren), om dit nu of in de toekomst als fallback-plan te gebruiken.
Al deze interpretaties zijn valide. Of je nu gebruikmaakt van onze officiële GUI-client wrappers rondom ons officiële control plane met een corporate SSO-identiteitsproviders, of aan het andere extreme staat door enkel tsnet op Linux-nodes te gebruiken tegen je eigen self-hosted Headscale-server; er zijn veel manieren om de onderdelen van Tailscale in te zetten:
- Het WireGuard + NAT-traversal + DERP fallback data plane.
- Het control plane.
- Het bedrijf (dat we betalen om zaken voor je te draaien en te ondersteunen).
- De open source code.
tailcat biedt je een nieuwe manier om een subset van Tailscale te gebruiken.
Hoe het werkt
Stel dat je een tailcat-server wilt draaien. Dit is wat er gebeurt:
- Er wordt een sleutelpaar gegenereerd (dit kan tijdelijk zijn, of benoemd en hergebruikt).
- Er wordt een DERP-server gekozen (een door jou opgegeven server, of een automatisch geselecteerde, bandbreedte-beperkte server die door Tailscale wordt beheerd).
- Er wordt een
tailcat-adres gegenereerd. Dit is een string in de vorm: tc + base64(CBOR( publieke sleutel + DERP bootstrap info )).
- Je deelt deze adresstring vervolgens via een extern kanaal met iemand anders, direct of door het in een DNS TXT-record te plaatsen en die DNS-hostname te delen.
De client-zijde werkt nagenoeg hetzelfde:
- Kies een sleutel (tijdelijk of lokaal benoemd en hergebruikt).
- Maak verbinding met de rendezvous DERP-server die in het
tailcat-adres is gespecificeerd.
- Stuur een "MEOW"-bericht naar de publieke sleutel van de server via DERP om jezelf aan de netmap toe te voegen.
Op dat moment, als de server akkoord gaat met de publieke sleutel van de client (dit kan optioneel worden beperkt), antwoordt de server met een bevestigend "MEOW"-antwoord.
De client maakt vervolgens een TCP-verbinding naar de andere kant via een ingebouwde userspace TCP-stack bovenop WireGuard. Er zijn feitelijk IP-adressen op de lijn (IPv6-adressen afgeleid van je publieke sleutel), maar deze zijn nooit zichtbaar voor gebruikers. Je besturingssysteem is op de TCP-laag nooit betrokken en ziet de synthetische tailcat-IP's niet. Het besturingssysteem verzendt enkel de DERP TCP-berichten en/of NAT-punched UDP WireGuard-berichten.
Omdat dit via Tailscale's magicsock data plane verloopt, treedt NAT-traversal automatisch in werking om een directe verbinding te maken. Hierdoor gaat de dataoverdracht (WireGuard UDP-pakketten) direct tussen client en server, zonder dat er een DERP-relay aan te pas komt. Als beide zijden zich echter achter een "harde" NAT bevinden zonder beschikbare port-mapping services, worden de datapakketten als fallback via DERP gerouteerd. Bij gebruik van Tailscale-hosted DERP-servers is er een bandbreedtebeperking (omdat bandbreedte ons geld kost). Als je je eigen DERP-server draait, kun je deze beperkingen zelf beheren.
In de standaardmodus, waarbij je geen poortnummer op de tailcat-server opgeeft, is het standaardgedrag om de ontvangen data simpelweg naar de stdout van de server te sturen, net als bij netcat. Het kan echter ook in een client-modus draaien, waarbij het een SOCKS-server start op een tijdelijke lokale poort en vervolgens een opgegeven child-proces (bijv. curl) uitvoert met een omgevingsvariabele om deze SOCKS-server te gebruiken. Hierdoor kunnen programma's die niets van tailcat weten, de tool transparant gebruiken. (tailcat werkt momenteel uitsluitend in userspace en configureert nooit de netwerkstack van je systeem; er zijn geen TUN-apparaten of wijzigingen in de routingtabel nodig).
Waarom?
Ik schreef tailcat in september 2023 tijdens een lange vlucht van tien uur, terwijl ik slechte films inhaalde. Destijds was tailcat vooral een leuk experiment. Ik presenteerde het intern en gebruikte het zelf af en toe, maar ik vergat het grotendeels. Later kwamen verschillende klanten bij ons met use cases waar het perfect bij paste, dus gaven we hen kopieën, met afspraken dat wij de DERP fallback-relays voor hen zouden hosten in gevallen waarin de magicsock van tailcat geen directe verbinding kon maken.
Een paar maanden geleden, toen de AI-agentic coding-trend in volle gang was, bleek het zeer krachtig om mijn gesandboxte AI-agents toegang te geven tot hun eigen, eveneens onvertrouwde nested VM's en hen tailcat te geven. Met toegang tot exotische hardware op verre locaties liet ik de AI experimenteren met het verbinden van systemen. Enkele voorbeelden:
- Een agent toegang geven tot een vloot van elke generatie Raspberry Pi.
- Een agent toegang geven tot een gesandboxte EC2-instantie die een nabijgelegen EC2-instantie kon besturen en herhaaldelijk kon rebooten via
kexec, terwijl Tailscale werd geport naar de UEFI-omgeving van EC2 (inclusief het porten van de Amazon Nitro ENA netwerkdriver naar pure Go onder Tamago).
- Een agent toegang geven tot een Windows-host om herhaaldelijk Hyper-V VM's aan te maken en te vernietigen om een stack-corruption bug in de Go-runtime en standard library op te sporen en te herstellen.
In de meeste van deze gevallen had ik technisch gezien gewoon de volledige Tailscale kunnen gebruiken, maar dat zou zo omslachtig zijn geweest dat ik het waarschijnlijk niet gedaan zou hebben. In plaats daarvan had ik een paar poorten doorgezet of opengezet in een firewall. Ik merk dat tailcat vaak het perfecte instrument is wanneer ik twee shells open heb staan op twee machines in twee totaal verschillende werelden en ik deze snel wil verbinden voor een kopie van een bestand, een poort-forward, of om van de ene naar de andere te SSH'en. Dit is vooral waardevol wanneer één zijde onvertrouwd of tijdelijk is, of wanneer ik bang ben om de systeemconfiguratie aan te passen.
Toen we Taildrop in 2021 lanceerden, was een van de eerste verzoeken om netcat-achtige sharing tussen nodes. tailcat biedt dit nu, en meer. We willen uiteindelijk iets soortgelijks implementeren in de hoofdclient van Tailscale, maar we moeten eerst uitzoeken hoe dat past binnen het totale product.
Een andere reden om tailcat open source te maken, is dat het logisch en onvermijdelijk is. We hebben er belang bij dat mensen ons data plane gebruiken, verbeteren en bugs melden, wat uiteindelijk het gehele Tailscale-product beter maakt.
Commercieel gebruik
Ik zou nalatig zijn als ik niet zou vermelden dat je contact met ons kunt opnemen als je interessante use cases hebt waarbij tailcat kan helpen, en waar wij kunnen assisteren bij de integratie of het draaien van een wereldwijde vloot van DERP-relays (bijv. voor IoT, P2P-games, distributed GPU's, etc.).
De DERP-servervloot die we momenteel voor tailcat draaien is geknepen en slechts beschikbaar in een handvol regio's wereldwijd. Het idee is dat in de meeste gevallen onze magicsock NAT-traversal zijn werk doet en DERP niet relevant is, waardoor tailcat een directe UDP WireGuard-verbinding tussen de twee peers krijgt. In gevallen waarin dat faalt, zijn we bereid om diensten te leveren in ruil voor betaling.
Of, je kunt natuurlijk ook je eigen DERP-vloot of een enkele server draaien. Dat is namelijk ook open source.
Veel plezier! We kijken ernaar uit om te zien wat je bouwt en hoe je dit gebruikt.
Tailcat: Een open-source CLI voor Tailscale’s WireGuard®, NAT-traversal en DERP
Auteur: Brad Fitzpatrick Datum: 31 augustus 2026
Vandaag brengen we tailcat uit, een remix van onderdelen van Tailscale. Hiermee kun je het open-source data plane van Tailscale (WireGuard® + NAT-traversal + DERP) gebruiken zonder het control plane van Tailscale. Het is geschreven door de mensen die Tailscale hebben gemaakt. In feite is het Tailscale zonder Tailscale, door Tailscale.
Specifiek is tailcat zowel een open-source Go-pakket als een CLI-tool die dit pakket gebruikt. Het stelt je in staat om een server-side listener en een client te draaien om met die server verbinding te maken, waarbij bidirectionele bytes heen en weer worden gestuurd.
Je kunt het zien als netcat, maar dan via Tailscale’s magicsock (WireGuard-encryptie + NAT-traversal + DERP rendezvous/fallback relay).
Belangrijke kenmerken van tailcat
Opvallend is dat tailcat de volgende zaken niet heeft:
- Geen IP-adressen.
- Geen accounts (geen logins, geen wachtwoorden, geen SSO).
- Geen control plane.
- Geen gebruikers.
- Geen beheerders.
- Geen administratieve controles.
- Geen vereiste voor root- of admin-toegang tot het besturingssysteem.
- Geen relatie met of afhankelijkheid van Tailscale als bedrijf (mits je je eigen
cmd/derper DERP-server draait).
Wat betekent "Tailscale" eigenlijk?
Wanneer je mensen online Tailscale beschrijven, zie je vaak verschillende interpretaties van wat "Tailscale" precies betekent.
- De focus op WireGuard: Een groep mensen zegt vaak: "Ik draai WireGuard gewoon zelf." Zij focussen op het WireGuard-gedeelte en negeren (of hebben geen behoefte aan) zaken als NAT-traversal, DERP-fallbacks, centraal beheerde firewall-regels (ACL), SSO-login, tagging, MDM-beleid, audit-logging, etc. Voor hen is WireGuard op een publiek IP voldoende.
- De focus op het bedrijf: Een andere groep spreekt meer over het bedrijf, de bedrijfsstructuur, levensvatbaarheid op lange termijn, oprichters, financieringsfase, prijzen, certificeringen, betrouwbaarheid en de verantwoorde omgang met beveiligingsmeldingen.
- De focus op open source: Weer een andere groep vraagt zich af of Tailscale open source is. Ter herinnering: onze core is open source (met een echte OSI-goedgekeurde licentie!), onze DERP-server is open source, en onze clients zijn open source op platforms die zelf open source zijn: Linux en Android. Ons server-side control plane is dat niet. Veel mensen in deze doelgroep waarderen het bestaan van Headscale (waar we van houden en de ontwikkeling van gedeeltelijk financieren), om dit nu of in de toekomst als fallback-plan te gebruiken.
Al deze interpretaties zijn valide. Of je nu gebruikmaakt van onze officiële GUI-client wrappers rondom ons officiële control plane met een corporate SSO-identiteitsproviders, of aan het andere extreme staat door enkel tsnet op Linux-nodes te gebruiken tegen je eigen self-hosted Headscale-server; er zijn veel manieren om de onderdelen van Tailscale in te zetten:
- Het WireGuard + NAT-traversal + DERP fallback data plane.
- Het control plane.
- Het bedrijf (dat we betalen om zaken voor je te draaien en te ondersteunen).
- De open source code.
tailcat biedt je een nieuwe manier om een subset van Tailscale te gebruiken.
Hoe het werkt
Stel dat je een tailcat-server wilt draaien. Dit is wat er gebeurt:
- Er wordt een sleutelpaar gegenereerd (dit kan tijdelijk zijn, of benoemd en hergebruikt).
- Er wordt een DERP-server gekozen (een door jou opgegeven server, of een automatisch geselecteerde, bandbreedte-beperkte server die door Tailscale wordt beheerd).
- Er wordt een
tailcat-adres gegenereerd. Dit is een string in de vorm: tc + base64(CBOR( publieke sleutel + DERP bootstrap info )).
- Je deelt deze adresstring vervolgens via een extern kanaal met iemand anders, direct of door het in een DNS TXT-record te plaatsen en die DNS-hostname te delen.
De client-zijde werkt nagenoeg hetzelfde:
- Kies een sleutel (tijdelijk of lokaal benoemd en hergebruikt).
- Maak verbinding met de rendezvous DERP-server die in het
tailcat-adres is gespecificeerd.
- Stuur een "MEOW"-bericht naar de publieke sleutel van de server via DERP om jezelf aan de netmap toe te voegen.
Op dat moment, als de server akkoord gaat met de publieke sleutel van de client (dit kan optioneel worden beperkt), antwoordt de server met een bevestigend "MEOW"-antwoord.
De client maakt vervolgens een TCP-verbinding naar de andere kant via een ingebouwde userspace TCP-stack bovenop WireGuard. Er zijn feitelijk IP-adressen op de lijn (IPv6-adressen afgeleid van je publieke sleutel), maar deze zijn nooit zichtbaar voor gebruikers. Je besturingssysteem is op de TCP-laag nooit betrokken en ziet de synthetische tailcat-IP's niet. Het besturingssysteem verzendt enkel de DERP TCP-berichten en/of NAT-punched UDP WireGuard-berichten.
Omdat dit via Tailscale's magicsock data plane verloopt, treedt NAT-traversal automatisch in werking om een directe verbinding te maken. Hierdoor gaat de dataoverdracht (WireGuard UDP-pakketten) direct tussen client en server, zonder dat er een DERP-relay aan te pas komt. Als beide zijden zich echter achter een "harde" NAT bevinden zonder beschikbare port-mapping services, worden de datapakketten als fallback via DERP gerouteerd. Bij gebruik van Tailscale-hosted DERP-servers is er een bandbreedtebeperking (omdat bandbreedte ons geld kost). Als je je eigen DERP-server draait, kun je deze beperkingen zelf beheren.
In de standaardmodus, waarbij je geen poortnummer op de tailcat-server opgeeft, is het standaardgedrag om de ontvangen data simpelweg naar de stdout van de server te sturen, net als bij netcat. Het kan echter ook in een client-modus draaien, waarbij het een SOCKS-server start op een tijdelijke lokale poort en vervolgens een opgegeven child-proces (bijv. curl) uitvoert met een omgevingsvariabele om deze SOCKS-server te gebruiken. Hierdoor kunnen programma's die niets van tailcat weten, de tool transparant gebruiken. (tailcat werkt momenteel uitsluitend in userspace en configureert nooit de netwerkstack van je systeem; er zijn geen TUN-apparaten of wijzigingen in de routingtabel nodig).
Waarom?
Ik schreef tailcat in september 2023 tijdens een lange vlucht van tien uur, terwijl ik slechte films inhaalde. Destijds was tailcat vooral een leuk experiment. Ik presenteerde het intern en gebruikte het zelf af en toe, maar ik vergat het grotendeels. Later kwamen verschillende klanten bij ons met use cases waar het perfect bij paste, dus gaven we hen kopieën, met afspraken dat wij de DERP fallback-relays voor hen zouden hosten in gevallen waarin de magicsock van tailcat geen directe verbinding kon maken.
Een paar maanden geleden, toen de AI-agentic coding-trend in volle gang was, bleek het zeer krachtig om mijn gesandboxte AI-agents toegang te geven tot hun eigen, eveneens onvertrouwde nested VM's en hen tailcat te geven. Met toegang tot exotische hardware op verre locaties liet ik de AI experimenteren met het verbinden van systemen. Enkele voorbeelden:
- Een agent toegang geven tot een vloot van elke generatie Raspberry Pi.
- Een agent toegang geven tot een gesandboxte EC2-instantie die een nabijgelegen EC2-instantie kon besturen en herhaaldelijk kon rebooten via
kexec, terwijl Tailscale werd geport naar de UEFI-omgeving van EC2 (inclusief het porten van de Amazon Nitro ENA netwerkdriver naar pure Go onder Tamago).
- Een agent toegang geven tot een Windows-host om herhaaldelijk Hyper-V VM's aan te maken en te vernietigen om een stack-corruption bug in de Go-runtime en standard library op te sporen en te herstellen.
In de meeste van deze gevallen had ik technisch gezien gewoon de volledige Tailscale kunnen gebruiken, maar dat zou zo omslachtig zijn geweest dat ik het waarschijnlijk niet gedaan zou hebben. In plaats daarvan had ik een paar poorten doorgezet of opengezet in een firewall. Ik merk dat tailcat vaak het perfecte instrument is wanneer ik twee shells open heb staan op twee machines in twee totaal verschillende werelden en ik deze snel wil verbinden voor een kopie van een bestand, een poort-forward, of om van de ene naar de andere te SSH'en. Dit is vooral waardevol wanneer één zijde onvertrouwd of tijdelijk is, of wanneer ik bang ben om de systeemconfiguratie aan te passen.
Toen we Taildrop in 2021 lanceerden, was een van de eerste verzoeken om netcat-achtige sharing tussen nodes. tailcat biedt dit nu, en meer. We willen uiteindelijk iets soortgelijks implementeren in de hoofdclient van Tailscale, maar we moeten eerst uitzoeken hoe dat past binnen het totale product.
Een andere reden om tailcat open source te maken, is dat het logisch en onvermijdelijk is. We hebben er belang bij dat mensen ons data plane gebruiken, verbeteren en bugs melden, wat uiteindelijk het gehele Tailscale-product beter maakt.
Commercieel gebruik
Ik zou nalatig zijn als ik niet zou vermelden dat je contact met ons kunt opnemen als je interessante use cases hebt waarbij tailcat kan helpen, en waar wij kunnen assisteren bij de integratie of het draaien van een wereldwijde vloot van DERP-relays (bijv. voor IoT, P2P-games, distributed GPU's, etc.).
De DERP-servervloot die we momenteel voor tailcat draaien is geknepen en slechts beschikbaar in een handvol regio's wereldwijd. Het idee is dat in de meeste gevallen onze magicsock NAT-traversal zijn werk doet en DERP niet relevant is, waardoor tailcat een directe UDP WireGuard-verbinding tussen de twee peers krijgt. In gevallen waarin dat faalt, zijn we bereid om diensten te leveren in ruil voor betaling.
Of, je kunt natuurlijk ook je eigen DERP-vloot of een enkele server draaien. Dat is namelijk ook open source.
Veel plezier! We kijken ernaar uit om te zien wat je bouwt en hoe je dit gebruikt.
Groetjes,