¿Es seguro Tailscale? Modelo de confianza explicado

¿Es seguro Tailscale? Respuesta breve

¿Es seguro Tailscale? Para la principal preocupación de la mayoría de los usuarios, sí: el servidor de coordinación que gestiona tu tailnet nunca almacena las claves privadas que cifran tu 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 afirma 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 qué claves públicas aceptan 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 de las partes en las que tienes que confiar, explica qué puede hacer realmente esa parte y proporciona el control que limita su capacidad. Si el producto es nuevo para ti, empieza por qué es Tailscale y cómo funciona su malla.

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 autogestionado. Cada dispositivo genera localmente su propio par de claves de WireGuard. El artículo cómo funciona de Tailscale llama al servidor de coordinación «un buzón compartido para claves públicas» y afirma: «La clave privada nunca, nunca 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 DNS y la lista de relés. Tailscale ejecuta el plano de control como un servicio alojado. Usted ejecuta el plano de datos en sus propios equipos.

Mantenga ambos planos separados y todas las preguntas de seguridad de este caso tendrán respuesta. El cifrado es una propiedad del plano de datos. La pertenencia es una decisión del plano de control. Ningún nivel 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 pueda incautarse o filtrarse para abrir el túnel. Esto también se aplica al tráfico retransmitido, que se trata 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 momento, «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 los dispositivos tienen permiso para acceder. 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, si no distribuye las claves de nuevos nodos o distribuye una política de control de acceso que deniega el acceso a todos los nodos».

Ve los metadatos de las conexiones 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 tratan sobre quién es miembro y qué establece la política. Por eso, los controles que merecen su atención son los que regulan la inscripción de nodos.

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

Tailscale no mantiene su propia base de datos de contraseñas. 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 de OpenID Connect personalizado.

Considérelo 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 deja la organización. Una cuenta del IdP obtenida mediante phishing equivale a una cuenta de tailnet, y el atacante no necesita atacar WireGuard: añade un dispositivo y hereda todos los permisos que su política conceda a ese usuario.

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

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

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 dispositivos nuevos antes de que puedan conectarse a la red de Tailscale». Un Owner, Admin o IT admin puede aprobarlos. Un dispositivo nuevo muestra la etiqueta «Needs approval» en la página Machines hasta que alguien actúa.

Actívela y el escenario de una cuenta robada cambia. El atacante inicia sesión, el dispositivo se registra y después queda a la espera, sin poder acceder a nada, mientras aparece una etiqueta 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 mejor es guardarlas en un producto de key vault diseñado específicamente para este fin». En agosto de 2026, el intervalo documentado de expiración de las claves es de 1 a 90 días, y una expiración no especificada usa el máximo de 90 días. Prefiera claves de un solo uso, márquelas como ephemeral para las máquinas que se crean y eliminan con frecuencia, 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 o perdido en un problema temporal. La documentación de Tailscale indica que «De forma predeterminada, los dominios nuevos se configuran con un período de caducidad de 180 días» y que «Si no se produce la 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 «puede interrumpir la conexión de tailnet, por lo que no debe hacerse de forma remota mediante SSH o RDP sin disponer de otro método para iniciar sesión si se pierde la conexión». Ejecute el comando con acceso a la consola disponible o desde una segunda ruta 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 abandonará la tailnet a las 3am cuando nadie esté supervisándola, por lo que los administradores desactivan la caducidad de las claves. Esto elimina el temporizador que terminaría invalidando 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 y permite que la máquina siga funcionando aunque esa persona abandone la empresa. Tome la decisión que tome, mantenga una lista de las máquinas que tienen la caducidad desactivada: esas claves seguirán siendo válidas hasta que elimine el dispositivo.

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

Tailnet lock aborda directamente el problema del registro. 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 un máximo de 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 deshabilitación, no hay recuperación. La documentación indica: «Si pierde los secretos de deshabilitació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 se ve comprometido, la clave se puede obtener».
• No puede ejecutar ambos controles. Tailscale indica que tailnet lock y la aprobación de dispositivos son incompatibles, 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 documento técnico lo indica.

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

No. Cuando dos dispositivos no pueden comunicarse directamente, el tráfico se retransmite a través de un servidor DERP (Designated Encrypted Relay for Packets). La documentación de Tailscale lo establece claramente: «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 a ciegas tráfico ya cifrado de un dispositivo a otro».

Un relay reduce la velocidad y observa metadatos: dos extremos cifrados, además del momento y el volumen de los datos que pasan 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 del relay y de los contadores de bytes. Si un par permanece en un relay, significa que los dos extremos no pudieron establecer una ruta directa. Normalmente se debe a que UDP está bloqueado en algún punto o a que ambos extremos están detrás de una NAT estricta (traducción de direcciones de red). tailscale netcheck informa de si UDP funciona desde ese equipo, de cómo la NAT asigna los puertos y de la latencia hasta los relays más cercanos. Estos datos indican cuál de las dos causas se está produciendo. Si un par ya tiene una conexión directa y el rendimiento sigue siendo inferior al esperado, el relay no es el problema. Una discrepancia en la MTU de la ruta suele ser la causa de la lentitud de WireGuard.

Un nodo de salida cambia el origen de tu tráfico de salida, pero no lo elimina

Un nodo de salida enruta todo el tráfico público de Internet 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 activarlo:

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 salida de toda la tailnet. El mismo control de aprobación se aplica a las rutas de subred. Por tanto, una máquina que anuncia un rango privado permanece inactiva hasta que un administrador lo acepta. Este es el primer requisito para anunciar una red privada a tu tailnet desde un VPS.

Ahora, la cuestión de la confianza. El tráfico se cifra desde tu portátil hasta el nodo de salida. Después sale de esa máquina como tráfico normal de Internet y lleva la dirección IP de esa máquina. Por tanto, el operador del nodo de salida puede ver tus destinos. También pueden verlos el proveedor de alojamiento de esa máquina y su red ascendente. Has cambiado el punto de observación, pero no lo has eliminado. Es una solución adecuada 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 entrega con una política 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 todos los puertos. Esa es una red plana. La trasladó al interior del túnel, lo que ayuda contra usuarios externos, pero no protege frente a un portátil que se infecte.

Endurezca la política en el archivo de política del tailnet. Este archivo acepta listas de control de acceso (ACL) o los grants más recientes. Ambos se escriben en un dialecto de JSON que admite comentarios:

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

Esta política permite que un grupo acceda por SSH a los servidores de producción, permite que sus miembros utilicen un nodo de salida y deniega todo lo demás por omisión. Tailscale indica qué destinos de reglas están disponibles en cada plan. Compruébelo antes de diseñar la política basándose en 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 de forma clara: «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, routers 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 incluye 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 se encuentran en su servidor. Ningún tercero conserva la lista de claves públicas de sus dispositivos, y ningún tercero puede verse obligado a entregar una de ellas o 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 realizaba Tailscale: supervisión de disponibilidad, aplicación de parches, copias de seguridad y seguridad física del equipo. Si ese equipo es un VPS alquilado, esta última depende de la garantía de otra persona y no de su control, porque el hipervisor puede leer la memoria de la máquina virtual y, con ella, el directorio de claves, salvo que el hardware admita memoria cifrada que pueda atestiguar. Un host de Headscale comprometido proporciona a un atacante exactamente lo mismo que proporcionaría un servidor de coordinación comprometido: la capacidad de inscribir un nodo y distribuir políticas. Tailnet lock no forma parte de la lista de funciones de Headscale, por lo que allí no está disponible el control compensatorio para ese riesgo concreto. El coste también lleva a algunos tailnets en la misma dirección, porque Tailscale factura por usuario y no por dispositivo y ese cálculo cambia en cuanto un equipo pequeño supera el plan gratuito. Si la cuestión de la propiedad es la que determina su decisión, alojar por cuenta propia el plano de control con Headscale explica paso a paso la 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 activa usted mismo: Funnel publica deliberadamente un servicio de tailnet en Internet abierto. Por eso conviene saber dónde termina serve y comienza funnel antes de ejecutar cualquiera de los dos comandos. Mantenga también el firewall del host, porque un puerto publicado por Docker crea sus propias reglas y omite ufw en la interfaz pública.
• Intentos de adivinar contraseñas contra accesos expuestos. No hay nada que probar repetidamente cuando el puerto sólo responde dentro del túnel. Es una posición más segura que limitar la tasa de un puerto abierto, aunque fail2ban en Ubuntu 24.04 sigue siendo recomendable en cualquier servicio que deba permanecer público.
• Redes no confiables en el trayecto. 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 la reutilización de una dirección o la copia de una clave incorrecta. La malla gestiona ese registro por usted. Esta es la mayor diferencia práctica entre WireGuard y Tailscale.

Qué no protege Tailscale

• Un endpoint comprometido. La tailnet confía en los dispositivos. Un malware en un portátil aprobado obtiene el túnel, las direcciones de la tailnet y todo lo que la política conceda a ese usuario. Esta es la mayor brecha, y ninguna VPN la elimina.
• 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 del mismo modo que revisa el código.
• El análisis del tráfico. Su ISP (proveedor de servicios de Internet) ve 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 el hecho de que exista una conexión no queda oculto. Consulte cómo se diferencian Tor y una VPN antes de elegir una herramienta para ese trabajo.
• Un dispositivo que ya ha perdido. La caducidad de claves es una medida de respaldo lenta, con un valor predeterminado de 180 días. Eliminar el dispositivo en la consola de administración es la opción rápida. Por eso, debe saber dónde está ese botón antes de necesitarlo.

Compruebe su propio 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 debe evitar.
2. Ejecute tailscale lock status para comprobar si tailnet lock está habilitado. Después, 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 clave deshabilitada, además de todas las claves de autenticación reutilizables que sigan existiendo. Ambas son credenciales sin temporizador.
4. Lea el archivo de políticas. Si todavía usa la configuración predeterminada, todos los dispositivos pueden alcanzar a los demás en cualquier puerto y un portátil infectado puede acceder a todos ellos.

Tailscale se ha ganado su reputación en el plano de datos, donde el diseño impide que el operador lea 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 continuos con Latacora. Esto aporta información sobre su proceso, no una declaración sobre su configuración.

FAQ

¿Puede Tailscale leer mi tráfico?

No. El tráfico se cifra con claves de WireGuard generadas en tus dispositivos, y la página de seguridad de Tailscale indica que «Private keys never leave the device. All traffic is end-to-end encrypted, always.» Esto también se aplica a las conexiones que usan un relay DERP como alternativa, porque el relay «blindly forwards already-encrypted traffic from one device to another» y no tiene ninguna clave que le permita descifrarlo. La infraestructura de Tailscale sí puede ver 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 de tailnet lock de Tailscale describe el riesgo de añadir en secreto un nodo que podría «send or receive traffic to your existing nodes». En este caso, el cifrado no ayuda «because the peer itself would be malicious». Un plano de control comprometido también podría distribuir una política que cambiara los dispositivos a los que puedes acceder. El documento técnico de tailnet lock señala además que podría interrumpir la conectividad si no distribuyera las nuevas claves de nodo. 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 desde la que te conectas, 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, al igual que su proveedor de hosting y la red ascendente, mientras que 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ú controlas el directorio de claves y la política, por lo que ninguna entidad externa puede verse obligada a inscribir un dispositivo en tu tailnet. También debes encargarte de ejecutar ese servidor: aplicar parches, garantizar su disponibilidad, realizar copias de seguridad y proteger el propio host. Un host de Headscale comprometido ofrece a un atacante el mismo poder de inscripción que ofrecería un servidor de coordinación comprometido. Además, tailnet lock no figura entre las funciones de Headscale, así que debes proteger ese host en consecuencia.

¿Sigo necesitando un firewall en un VPS que está en mi tailnet?

Sí. La interfaz de red pública sigue existiendo, y cualquier servicio enlazado a 0.0.0.0 continúa siendo accesible desde Internet, independientemente de que Tailscale esté ejecutándose. Enlaza los servicios a la dirección de la 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.