¿Es seguro Tailscale? Así funciona su modelo de confianza

¿Es seguro Tailscale? La respuesta breve

¿Es seguro Tailscale? En el aspecto que más preocupa a la mayoría, sí: el servidor de coordinación que administra tu tailnet nunca conserva las claves privadas que cifran el tráfico, por lo que no puede leer lo que tus dispositivos se envían entre sí. La página de seguridad de Tailscale lo indica directamente: "Las claves privadas nunca salen del dispositivo. Todo el tráfico está cifrado de extremo a extremo, siempre." La pregunta útil es otra. Un servidor de coordinación comprometido o sujeto a una orden judicial no necesita leer tus paquetes. Decide en qué claves públicas confían tus dispositivos, por lo que podría inscribir un dispositivo que nunca aprobaste.

Ese es el modelo de confianza en una frase: el cifrado protege los datos y el plano de control decide quién pertenece a la red. Cada sección siguiente identifica una entidad en la que tienes que confiar, explica qué puede hacer realmente y proporciona el control que limita sus capacidades. Si el producto es nuevo para ti, empieza por qué es Tailscale y cómo funciona su red mallada.

El plano de control y el plano de datos están separados

Tailscale es una VPN de malla (red privada virtual) basada en WireGuard, el mismo protocolo que configuraría manualmente en un VPS WireGuard autohospedado. Cada dispositivo genera localmente su propio par de claves de WireGuard. El artículo cómo funciona de Tailscale denomina al servidor de coordinación «un buzón compartido para claves públicas» y afirma: «La clave privada nunca, jamás, sale de su nodo».

El plano de datos es el tráfico cifrado entre sus dispositivos. Viaja directamente de un dispositivo a otro siempre que la red lo permite. El plano de control es todo lo demás: qué dispositivos pertenecen al tailnet, qué clave pública corresponde a cada dispositivo, la política de acceso, la configuración de DNS y la lista de relays. Tailscale ejecuta el plano de control como un servicio alojado. Usted ejecuta el plano de datos en sus propias máquinas.

Mantenga ambos planos separados y podrá responder a todas las preguntas de seguridad de este caso. El cifrado es una propiedad del plano de datos. La pertenencia es una decisión del plano de control. Ninguna cantidad de cifrado le indica quién puede ser un peer.

¿Qué podría hacer un servidor de coordinación comprometido?

No podría descifrar el tráfico. Las claves que realizan el cifrado se generan en los dispositivos y nunca se cargan en el servidor. Por tanto, no hay nada que se pueda incautar o filtrar para abrir el túnel. Esto también se aplica al tráfico retransmitido, que se explica más adelante.

Podría inscribir un nodo. Cuando Tailscale anunció tailnet lock, la empresa describió el riesgo con sus propias palabras: un servidor malicioso podría «usar un nodo añadido en secreto para enviar o recibir tráfico hacia los nodos existentes» y, en ese caso, «no importaría que el tráfico estuviera cifrado, porque el propio par sería malicioso». El dispositivo confía en un par porque el plano de control le indicó que esa clave pertenece al tailnet.

Podría cambiar los destinos a los que pueden acceder los dispositivos. La política de acceso reside en el plano de control y se distribuye a los nodos. El documento técnico de tailnet lock de Tailscale indica que tailnet lock «no impide que un plano de control comprometido interrumpa la conectividad de la red, por ejemplo, al no distribuir las claves de nuevos nodos o al distribuir una política de control de acceso que deniegue el acceso a todos los nodos».

Vería los metadatos de conexión en cualquier caso. Los registros de flujo de red de Tailscale registran los eventos de apertura y cierre de cada conexión entre máquinas. La documentación indica que esos registros «no contienen estrictamente ninguna información sobre las operaciones de los clientes ni sobre el contenido del tráfico de red». Por tanto, el plano de control puede saber qué dispositivos se comunicaron entre sí y cuándo. No sabe qué se dijeron.

Sólo uno de esos puntos está relacionado con el cifrado. Los demás se refieren a quién es miembro y a lo que establece la política. Por eso, los controles que deben recibir más atención son los que regulan la inscripción.

Tu proveedor de identidad es la raíz de confianza de la tailnet

Tailscale no mantiene una base de datos de contraseñas propia. Su documentación indica claramente que no existen contraseñas de Tailscale y que el inicio de sesión se delega en un proveedor de identidad (IdP): Apple, Google, GitHub, Microsoft, Okta, OneLogin o un proveedor OpenID Connect personalizado.

Debe interpretar esto como una afirmación de seguridad, porque lo es. Cualquiera que pueda iniciar sesión en su cuenta de Google o Microsoft puede iniciar sesión en su tailnet. La autenticación multifactor (MFA) es la que aplica el IdP. La baja de usuarios depende de lo que haga el IdP cuando una persona abandona la organización. Una cuenta del IdP comprometida mediante phishing se convierte en una cuenta de la tailnet, y el atacante no necesita atacar WireGuard: añade un dispositivo y hereda los permisos que la política conceda a ese usuario.

Dos controles separan una cuenta de identidad robada de un dispositivo operativo dentro de la tailnet: la aprobación de dispositivos y la caducidad de las claves. Tailnet lock es un tercer control y protege el plano de control, no la cuenta.

Aprobación de dispositivos: nadie se conecta hasta que una persona lo aprueba

La documentación de Tailscale describe la aprobación de dispositivos como una función que «permite a los administradores de la red de Tailscale revisar y aprobar nuevos dispositivos antes de que puedan conectarse a la red de Tailscale». Un Owner, Admin o IT admin puede aprobarlos. Un dispositivo nuevo muestra la insignia «Needs approval» en la página Machines hasta que alguien actúa sobre él.

Actívela y el escenario de una cuenta robada cambia. El atacante inicia sesión, el dispositivo se registra y queda a la espera, sin poder acceder a nada, junto a una insignia en la consola de administración que indica que una máquina desconocida solicita conectarse. La automatización sigue funcionando, porque una auth key puede marcarse como pre-approved al generarla y los dispositivos se pueden aprobar mediante la API.

Las auth keys son la otra vía de acceso, así que debe tratarlas como credenciales. La documentación de Tailscale es clara sobre el tipo más arriesgado: «Tenga mucho cuidado con las claves reutilizables. Pueden ser muy peligrosas si se roban. Lo más recomendable es guardarlas en un producto de almacén de claves diseñado específicamente para este fin». En agosto de 2026, el intervalo de expiración documentado para las claves es de 1 a 90 días, y una expiración no especificada usa de forma predeterminada el máximo de 90 días. Prefiera claves de un solo uso, márquelas como ephemeral para las máquinas que se conectan y desconectan, y mantenga cualquier clave reutilizable cifrada con Ansible Vault o en un gestor de secretos, en lugar de guardarla en un shell script.

Caducidad de las claves: el temporizador que limita cualquier otro error

Las claves de los nodos caducan. Esto convierte un dispositivo robado u olvidado en un problema temporal. La documentación de Tailscale indica que «De forma predeterminada, los dominios nuevos se configuran con un periodo de caducidad de 180 días» y que «Si no se produce una reautenticación, las claves caducan y las conexiones hacia y desde el endpoint indicado dejan de funcionar». Puede reautenticar un dispositivo manualmente:

tailscale up --force-reauth

La documentación advierte que esto «podría interrumpir la conexión de tailnet y, por tanto, no debe hacerse de forma remota mediante SSH o RDP sin un método alternativo para iniciar sesión si se pierde la conexión». Ejecute el comando con acceso a la consola abierto o desde una segunda vía de acceso a la máquina, porque está a punto de interrumpir la red que está utilizando.

Los servidores son donde este control suele desactivarse. Una máquina que debe reautenticarse cada 180 días se desconectará de tailnet a las 3am cuando nadie la esté supervisando, por lo que los administradores desactivan la caducidad de las claves. Esto elimina el temporizador que finalmente cortaría el acceso de una clave robada. Para un servidor, la mejor opción es un dispositivo etiquetado, porque una etiqueta identifica la máquina en lugar de una persona. Así, la máquina sigue funcionando aunque esa persona deje la empresa. Decida lo que decida, mantenga una lista de las máquinas que tienen desactivada la caducidad: esas claves seguirán siendo válidas hasta que elimine el dispositivo.

Tailnet lock: retirar el servidor de coordinación de la cadena de confianza

Tailnet lock aborda directamente el problema de la incorporación. La documentación de tailnet lock de Tailscale explica el mecanismo: «Cuando un nodo nuevo se incorpora al tailnet, su clave pública de nodo necesita una firma de una clave de Tailnet Lock. El servidor de coordinación distribuye la clave pública de nodo firmada a los nodos pares». Los dispositivos existentes verifican esa firma antes de aceptar un par, por lo que rechazan una clave de nodo que el plano de control haya creado por su cuenta.

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init habilita la función y, en ese momento, se designan los nodos firmantes. Tailscale requiere al menos dos nodos firmantes durante la inicialización y permite como máximo 20 en un tailnet. Después, cada dispositivo nuevo necesita una firma de uno de ellos. Esto supone un coste operativo real: añadir un teléfono implica ejecutar un comando en un portátil.

Los límites están documentados y son más importantes que la descripción de la función:

• Si pierde el secreto de desactivación, no hay recuperación. La documentación indica: «Si pierde los secretos de desactivación y no proporcionó ninguno al soporte de Tailscale, el tailnet no se puede recuperar».
• La clave de firma reside en un dispositivo que usted controla, por lo que hereda la seguridad de ese dispositivo. La documentación es explícita: «Si el dispositivo está comprometido, la clave puede obtenerse».
• No puede ejecutar ambos controles. Tailscale indica que tailnet lock y la aprobación de dispositivos son mutuamente excluyentes, por lo que habilitar uno implica renunciar al otro.
• Es un modelo de confianza en el primer uso (TOFU). La configuración inicial sigue pasando por el plano de control, y el ancla de confianza se traslada a su propia red sólo después de ese primer paso.

Tailnet lock protege la pertenencia. No protege la disponibilidad, y el libro blanco lo indica.

¿Una conexión retransmitida expone mi tráfico?

No. Cuando dos dispositivos no pueden comunicarse directamente, el tráfico pasa por un servidor DERP (Designated Encrypted Relay for Packets). La documentación de Tailscale lo afirma sin ambigüedades: «Como las claves privadas de Tailscale nunca salen del dispositivo local que las generó, un servidor DERP no puede descifrar el tráfico. Un servidor DERP reenvía de forma ciega tráfico ya cifrado de un dispositivo a otro».

Una retransmisión reduce la velocidad y permite observar metadatos: dos extremos cifrados, además del momento y el volumen del tráfico que circula entre ellos. Compruebe qué tipo de conexión tiene realmente:

tailscale status
tailscale netcheck

tailscale status marca cada par como directo, mostrado como direct 203.0.113.10:41641, o retransmitido, mostrado como relay seguido del nombre de la retransmisión y de los contadores de bytes. Si un par permanece en una retransmisión, significa que los dos extremos no pudieron establecer una ruta directa. Normalmente, esto ocurre porque UDP está bloqueado en algún punto o porque ambos lados están detrás de NAT estrictas (network address translation). tailscale netcheck informa de si UDP funciona en esa máquina, de cómo asigna puertos la NAT y de la latencia hasta las retransmisiones más cercanas. Estos datos indican cuál de las dos causas se aplica.

Un nodo de salida cambia el punto de salida de tu tráfico; no lo elimina

Un nodo de salida enruta todo el tráfico de Internet público de un dispositivo a través de otro dispositivo de la tailnet, mediante las rutas predeterminadas 0.0.0.0/0 y ::/0. En Linux, la máquina que ofrece el servicio lo anuncia y cada cliente debe habilitarlo de forma explícita:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

Un Owner, Admin o Network admin debe aprobar el nodo de salida en la consola de administración, y la política debe conceder autogroup:internet antes de que un cliente pueda usarlo. Ambos pasos son deliberados: una máquina no aprobada no puede convertirse silenciosamente en la vía de salida de toda la tailnet.

Ahora, la cuestión es la confianza. El tráfico está cifrado desde tu portátil hasta el nodo de salida. Después sale de esa máquina como tráfico normal de Internet y utiliza la dirección IP de esa máquina. Por tanto, el operador del nodo de salida ve tus destinos, al igual que el proveedor de hosting de esa máquina y su red ascendente. Has cambiado el punto de observación, no lo has eliminado. Es una buena solución cuando controlas el extremo remoto, que es el motivo para ejecutar tu propio nodo de salida en un VPS, y una mala solución cuando no lo controlas.

La política predeterminada es una red plana

Un tailnet nuevo se distribuye con una configuración permisiva. La documentación de control de acceso de Tailscale indica que el archivo de política predeterminado «habilita la comunicación entre todos los dispositivos del tailnet». Cada dispositivo puede acceder a cualquier otro dispositivo en cualquier puerto. Eso es una red plana. La comunicación se trasladó al túnel, lo que ayuda frente a terceros externos, pero no protege contra un portátil que se infecte.

Endurézcala en el archivo de política del tailnet, que admite listas de control de acceso (ACL) o los grants más recientes. Ambos se escriben en un dialecto de JSON que permite comentarios:

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

Esa política permite que un grupo acceda por SSH a los servidores de producción, permite que sus miembros usen un nodo de salida y deniega todo lo demás por omisión. Tailscale indica qué destinos de regla están disponibles en cada plan. Compruébelo antes de diseñar la configuración con tags o autogroups y consulte qué incluye realmente el plan gratuito. Para un dispositivo que nunca debería aceptar conexiones entrantes, como un teléfono personal, tailscale set --shields-up las bloquea en el cliente.

Qué cambia al alojar el plano de control con Headscale

Headscale es «Una implementación de código abierto y autohospedada del servidor de control de Tailscale». Su README delimita el alcance con claridad: «Implementa un alcance limitado, una única red de Tailscale (tailnet), adecuada para uso personal o para una organización pequeña de código abierto». Su lista de funciones incluye ACL y grants, enrutadores de subred, nodos de salida, un servidor DERP integrado, Tailscale SSH y Taildrop. Si ese alcance limitado es el principal inconveniente, NetBird es la otra mesh que ofrece un plano de control autohospedable, y ejecutar el servidor de NetBird en su propio VPS traslada la misma decisión de inscripción a hardware que usted controla.

Lo que cambia es la identidad de la entidad que podría inscribir un nodo no autorizado. Con Headscale, el directorio de claves y la política están en su servidor. Ningún tercero conserva la lista de las claves públicas de sus dispositivos, y ningún tercero puede ser obligado a entregar una de ellas ni a firmarla.

Lo que no cambia es el plano de datos. Sigue siendo el mismo WireGuard, con el mismo cifrado de extremo a extremo y el mismo mecanismo de respaldo mediante relay cuando no es posible establecer una ruta directa. También asume las tareas que antes realizaba Tailscale: garantizar el tiempo de actividad, aplicar parches, realizar copias de seguridad y proteger físicamente el equipo. Un host de Headscale comprometido proporciona al atacante exactamente lo que proporcionaría un servidor de coordinación comprometido: la capacidad de inscribir un nodo y distribuir la política. Tailnet lock no figura en la lista de funciones de Headscale, por lo que no está disponible ese control compensatorio para este riesgo concreto. Si la cuestión de la propiedad es la que determina su decisión, autohospedar el plano de control con Headscale explica el procedimiento de configuración.

Qué protege Tailscale

• Puertos públicos en escucha. Un servicio vinculado a una dirección de tailnet no es accesible desde Internet, por lo que los escáneres que prueban todos los VPS en el puerto 22 nunca lo ven. La excepción es una función que se activa manualmente: Funnel publica deliberadamente un servicio de tailnet en Internet abierto. Por eso conviene saber dónde termina serve y empieza funnel antes de ejecutar cualquiera de los dos comandos. Mantenga de todos modos el firewall del host, porque un puerto de Docker publicado crea sus propias reglas y omite ufw en la interfaz pública.
• Intentos de adivinar contraseñas contra inicios de sesión expuestos. No hay nada que probar cuando el puerto sólo responde dentro del túnel. Es una posición más segura que aplicar límites de tasa a un puerto abierto, aunque fail2ban en Ubuntu 24.04 sigue siendo recomendable en cualquier sistema que deba permanecer público.
• Redes no confiables en la ruta. El tráfico entre sus máquinas está cifrado de extremo a extremo a través de la red de una cafetería o de la LAN compartida de un proveedor, y permanece cifrado cuando se retransmite.
• Distribución manual de claves. Cada peer que se añade manualmente a una configuración de WireGuard puede provocar que se reutilice una dirección o que se pegue una clave incorrecta. La malla gestiona ese registro por usted. Esta es la principal diferencia práctica de WireGuard frente a Tailscale.

Qué no protege Tailscale

• Un endpoint comprometido. El tailnet confía en los dispositivos. El malware de un portátil aprobado obtiene acceso al túnel, a las direcciones del tailnet y a todo lo que la política conceda a ese usuario. Esta es la principal limitación y ninguna VPN la resuelve.
• Un administrador malicioso o negligente. Cualquiera que pueda editar el archivo de políticas puede concederse acceso a cualquier recurso. Lo mismo puede hacer quien tome el control de la cuenta de identidad de un Owner. Revise los cambios de política igual que revisa el código.
• El análisis del tráfico. Su ISP (proveedor de servicios de Internet) ve el tráfico UDP cifrado hacia un endpoint, además de los tiempos y el volumen. Los registros de flujo de Tailscale muestran qué pares se comunicaron y cuándo. Ninguno ve el contenido, pero la conexión no queda oculta. Lea en qué se diferencian Tor y una VPN antes de elegir una herramienta para ese fin.
• Un dispositivo que ya ha perdido. La caducidad de la clave es una medida de respaldo lenta, con un valor predeterminado de 180 días. Eliminar el dispositivo desde la consola de administración es la medida rápida. Identifique ese botón antes de necesitarlo.

Compruebe su propia tailnet

1. Ejecute tailscale status en un dispositivo y lea la lista de pares. Una máquina que no puede identificar es precisamente la situación que la aprobación de dispositivos evita.
2. Ejecute tailscale lock status para comprobar si tailnet lock está habilitado y decida si el coste de firmar cada dispositivo nuevo compensa para su tailnet.
3. Abra la consola de administración y anote todas las máquinas con la caducidad de claves deshabilitada, además de todas las claves de autenticación reutilizables que todavía existan. Ambas son credenciales sin temporizador.
4. Lea el archivo de políticas. Si todavía usa la configuración predeterminada, cada dispositivo puede acceder a cualquier otro dispositivo en cualquier puerto, y un portátil infectado puede alcanzar a todos.

Tailscale se ha ganado su reputación en el plano de datos, donde el diseño impide al operador leer el tráfico. Acepte esa afirmación tal como la documenta el proveedor y audite las partes que le corresponden: las cuentas de identidad, la configuración de aprobación, la lista de caducidad y el archivo de políticas. La página de seguridad de Tailscale informa de una certificación SOC 2 Type II y de trabajos de seguridad continuados con Latacora. Esto aporta evidencias sobre su proceso, no una afirmación sobre su configuración.

FAQ

¿Puede Tailscale leer mi tráfico?

No. El tráfico está cifrado con claves de WireGuard que se generan en tus dispositivos, y la página de seguridad de Tailscale afirma que «las claves privadas nunca salen del dispositivo. Todo el tráfico está cifrado de extremo a extremo, siempre». Esto también se aplica a las conexiones que recurren a un relay DERP, porque el relay «reenvía ciegamente tráfico ya cifrado de un dispositivo a otro» y no tiene ninguna clave que le permita descifrarlo. Lo que sí ve la infraestructura de Tailscale son metadatos: qué dispositivos existen, cuáles se conectaron entre sí y cuándo.

¿Qué podría hacer realmente un servidor de coordinación de Tailscale comprometido?

Podría inscribir un nodo. El anuncio del propio tailnet lock de Tailscale describe el riesgo de añadir en secreto un nodo que pudiera «enviar o recibir tráfico hacia tus nodos existentes», una situación en la que el cifrado no sirve «porque el propio peer sería malicioso». Un plano de control comprometido también podría distribuir una política que cambiara a qué pueden acceder tus dispositivos. Además, el documento técnico de tailnet lock señala que podría interrumpir la conectividad si dejara de distribuir las nuevas claves de los nodos. Lo que no podría hacer es descifrar el tráfico entre tus dispositivos existentes, porque nunca ha tenido sus claves privadas.

¿Un nodo de salida oculta mi navegación a mi ISP?

Oculta los destinos a la red en la que estás conectado, incluido el ISP de tu domicilio o de la cafetería, porque todo sale de tu dispositivo como tráfico cifrado dirigido al nodo de salida. No te hace anónimo. El nodo de salida ve esos destinos. También los ven su proveedor de alojamiento y la red ascendente. Los sitios que visitas ven la dirección IP del nodo de salida. Has elegido otro observador, así que elige uno en el que realmente confíes.

¿Headscale es más seguro que el servidor de coordinación de Tailscale?

Es una decisión de confianza diferente, no una opción estrictamente más segura. Con Headscale, tú administras el directorio de claves y la política, por lo que ninguna entidad externa puede ser obligada a inscribir un dispositivo en tu tailnet. También debes encargarte de ejecutar ese servidor: aplicar parches, mantener su disponibilidad, realizar copias de seguridad y proteger el propio host. Un host de Headscale comprometido ofrece a un atacante la misma capacidad de inscripción que ofrecería un servidor de coordinación comprometido. Además, tailnet lock no forma parte de la lista de funciones de Headscale, así que protege ese host en consecuencia.

¿Sigo necesitando un firewall en un VPS que forma parte de mi tailnet?

Sí. La interfaz de red pública sigue existiendo, y cualquier servicio vinculado a 0.0.0.0 permanece accesible desde Internet, independientemente de que Tailscale esté ejecutándose. Vincula los servicios a la dirección del tailnet, mantén una política predeterminada de denegación en la interfaz pública y comprueba los puertos publicados de tus contenedores, porque Docker inserta sus propias reglas y puede exponer un puerto que creías cerrado.