Tailscale libera Tailcat: túneles seguros sin cuenta ni root

Tailscale lanza Tailcat: el mismo cifrado de WireGuard, pero sin su cuenta ni su control

El equipo detrás de Tailscale publicó como open source Tailcat, una utilidad descrita en su repositorio como "Tailscale sin Tailscale, hecho por Tailscale". Es una remezcla de las piezas open source del cliente de Tailscale (la implementación en userspace de WireGuard, el transporte magicsock y la pila TCP/IP Netstack de gVisor) reutilizadas para crear túneles cifrados punto a punto sin pasar por el plano de control comercial de la compañía.

El lanzamiento se hizo oficial en la conferencia TailscaleUp en agosto de 2026, según el repositorio en GitHub. Tailcat nació en septiembre de 2023 como un proyecto interno llamado derpcat, escrito en un vuelo entre Portland y Chicago, y revivido este año tras un refactor que lo convirtió en un módulo Go regular en lugar de un fork del repo principal.

Cómo funciona un túnel de Tailcat en la práctica

El flujo, según la documentación del repo, es deliberadamente minimalista. Un lado ejecuta el servidor, que genera (o carga) un par de claves WireGuard y un token de conexión corto que imprime por stderr. El otro lado recibe ese token —por chat, por una variable de entorno, por un registro DNS TXT— y se conecta con un solo comando. Todo el tráfico viaja cifrado extremo a extremo con WireGuard.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El handshake inicial pasa por la red de relays DERP (Designated Encrypted Relay for Packets) de Tailscale, que sirve como canal de encuentro y como respaldo cuando el NAT traversal falla. En paralelo, ambos extremos ejecutan el protocolo disco de Tailscale: se anuncian sus endpoints públicos vía STUN, hacen hole-punching UDP y, si lo consiguen, el túnel se actualiza a una ruta peer-to-peer directa. Si no, sigue funcionando por DERP, con la limitación de throughput de los relays públicos gratuitos.

El resultado es que un comando como tailcat --serve=8080 en una máquina imprime un token, y tailcat tcXXXX 8080 en otra abre una sesión TCP cifrada al puerto indicado. La documentación del repo incluye ejemplos para reenviar puertos locales (--serve=8080), servir SSH sin auth (--serve=no-auth-ssh), montar un proxy SOCKS5 sobre el túnel, o actuar como exit node.

Qué trae de nuevo frente a Tailscale "completo"

Tailcat no reemplaza al producto comercial: lo complementa. La diferencia clave es que elimina tres piezas que Tailscale gestiona por defecto y que muchos casos de uso no necesitan.

Sin cuenta de Tailscale. No hay tailnet, no hay panel de administración, no hay ACLs centralizadas. La identidad del servidor es la propia clave WireGuard.
Sin permisos de root ni cambios en el sistema. No se monta un TUN/TAP de kernel, no se tocan tablas de ruteo ni DNS. Es 100% userspace.
Sin plano de control. Los metadatos de la conexión se intercambian fuera de banda, por el canal que el usuario prefiera: chat, email, un QR, un registro DNS.

Esto lo coloca en un punto intermedio interesante. Por un lado, respecto al WireGuard "crudo", Tailcat hereda de Tailscale el NAT traversal automático y los relays DERP, que es exactamente lo que vuelve difícil operar WireGuard puro detrás de CGNAT o con IPs dinámicas, como bien resume el análisis publicado por XDA Developers tras un mes de pruebas con túneles manuales. Por el otro, frente a Tailscale completo, Tailcat prescinde de la orquestación, lo que lo hace útil para escenarios efímeros donde levantar un tailnet completo es overkill.

El propio repo lo deja claro en el aviso legal: la API Go, los flags del CLI y el formato de los tokens no tienen promesa de estabilidad. Los relays DERP públicos son rate-limited, sin SLA y pueden ser revocados. Es un proyecto best effort, no un producto.

Casos de uso que un founder puede probar hoy

El repositorio destaca varios patrones que resuelven problemas muy concretos de equipos chicos y desarrolladores individuales.

Exponer un servicio local sin tocar el firewall. El típico localhost:3000 que un diseñador o un cliente necesita ver desde fuera se vuelve tailcat --serve=3000 y se comparte el token. Sin port forwarding, sin ngrok, sin tunnels-as-a-service.
SSH a una máquina sin abrir el puerto 22. Con tailcat --serve=no-auth-ssh y un par de claves generadas con tailcat genkey --client y --allow=, solo el cliente autorizado puede hacer handshake; cualquier otro es descartado silenciosamente.
Publicar el endpoint en DNS. El token puede ir en un registro TXT (my-server.example.com IN TXT "tailcat=tcXXX") y resolverse por nombre. El ejemplo del repo usa esto para mostrar cómo evitar el port knocking y mantener un servidor SSH accesible "desde cualquier lugar" sin un solo puerto entrante abierto.
Debug de NAT traversal. El subcomando tailcat ping --until-direct repite pings hasta conseguir una ruta directa y reporta si cada pong llegó por DERP o por UDP directo, con la latencia de cada uno.
Integración programática. El paquete github.com/tailscale/tailcat se importa como librería Go; el repo trae un ejemplo de servidor y cliente en pocas líneas, útil para embeber túneles efímeros en herramientas internas o en flujos de CI.

Para equipos más grandes, el repo abre la puerta a desplegar relays DERP propios en lugar de depender de los públicos, lo que cambia el cálculo de throughput y de SLA pero mantiene la arquitectura.

¿Qué significa esto para tu startup?

Tailcat no es una alternativa a tu VPN corporativo ni va a reemplazar a Tailscale como solución de acceso remoto para tu equipo. Pero abre tres palancas concretas que vale la pena explorar.

Demostraciones y soporte en vivo sin infraestructura. Si tu producto corre en una máquina del cliente o en una VM de desarrollo, podes compartir una sesión con un inversor, un diseñador o un integrador sin pedir acceso a la red ni abrir puertos. El token vive lo que dura la demo.
Diagnóstico rápido entre entornos. Para un equipo de infraestructura que necesita probar conectividad entre una VM en la nube y un portátil detrás de CGNAT, tailcat ping --until-direct da una respuesta binaria y latencias en menos de 10 segundos, sin tener que negociar con el equipo de red.
Prototipos de features que requieren túneles efímeros. Herramientas de pairing, sesiones remotas temporales, integraciones one-shot con un partner: cualquier funcionalidad donde un túnel permanente sea excesivo y un Tailscale completo sea caro de configurar cabe en unas decenas de líneas usando la librería Go.

Acciones concretas:

Clonar el repo github.com/tailscale/tailcat, compilarlo (go install ./cmd/tailcat@latest) y probar tailcat --serve=8080 contra un servicio local en otra máquina en menos de cinco minutos.
Si ya usás Tailscale, identificar un caso donde el plano de control te estorba —por ejemplo, una demo con un cliente externo que no debería tener cuenta en tu tailnet— y reemplazarlo por un túnel Tailcat ad-hoc con --allow= para mantener el control de quién se conecta.
Auditar qué relays DERP vas a usar. Para empezar alcanza con los públicos gratuitos; en producción propia conviene self-hostear DERP para tener SLA y ancho de banda predecibles.

Conclusión

Tailcat es una señal de cómo Tailscale está exportando su tecnología de transporte fuera del producto comercial. Para founders y equipos técnicos hispanohablantes, lo más valioso no es el túnel en sí —WireGuard lo hace hace tiempo— sino que se ofrezca el NAT traversal automático y los relays sin pedir cuenta, sin pedir root y sin pedir que adoptes un SaaS. Es una pieza más en la caja de quien construye infraestructura propia y quiere moverse rápido sin abrir puertos al mundo.