Qué es Tailscale y cómo funciona

¿Qué es Tailscale?

Tailscale es una VPN que conecta directamente sus máquinas entre sí, en lugar de enrutar todo el tráfico a través de una única puerta de enlace que usted administra. Cada nodo ejecuta WireGuard, por lo que los paquetes viajan cifrados de un servidor a otro y ningún elemento intermedio puede leerlos. Un servidor de coordinación alojado se encarga de establecer las conexiones iniciales. Almacena y distribuye las claves públicas e indica a cada nodo dónde están los demás. También distribuye las reglas de acceso que usted ha definido.

Esta separación es la base de todo el diseño. El plano de datos es entre pares y está cifrado entre los nodos. El plano de control es un servicio que Tailscale ejecuta por usted. Todas las cuestiones importantes sobre Tailscale, incluidas las relacionadas con la confianza, se derivan de estos dos hechos. Si ya ha creado una VPN de WireGuard manualmente en un VPS, Tailscale ofrece ese mismo túnel, con la distribución de claves y la atravesabilidad del firewall automatizadas para usted.

¿Cómo funciona Tailscale?

Tu red privada de nodos se denomina tailnet. Cuando una máquina se une a ella, ocurren cuatro cosas.

1. Se inicia el daemon de tailscaled, genera un par de claves de WireGuard y guarda su estado en /var/lib/tailscale/tailscaled.state. La clave privada permanece en esa máquina. Tailscale lo expresa claramente: «la clave privada nunca, nunca sale de su nodo».
2. El nodo inicia sesión en el servidor de coordinación y carga su clave pública, además de las direcciones en las que cree que puede recibir conexiones. Tailscale describe ese servidor como «un buzón compartido para claves públicas».
3. El servidor de coordinación devuelve un mapa de red: la clave pública, la dirección de tailnet, el nombre de la máquina y los endpoints candidatos de cada nodo al que esta máquina tiene permiso para acceder.
4. Cada par de nodos intenta crear un túnel directo de WireGuard entre sí. Si falla, envía los paquetes a través de un relay.

Cada nodo obtiene una dirección estable de 100.64.0.0/10, el rango de NAT de nivel de operador que va de 100.64.0.0 a 100.127.255.255. Tailscale usa ese rango porque está reservado para la infraestructura de los proveedores, por lo que rara vez entra en conflicto con las direcciones privadas que ya usan tus servidores. En Linux, el túnel aparece como una interfaz llamada tailscale0.

La implementación de WireGuard se ejecuta dentro de tailscaled en el espacio de usuario, no en el módulo del kernel. Por eso Tailscale se inicia en entornos de virtualización de contenedores donde sudo modprobe wireguard falla con Operation not supported. También significa que el límite de rendimiento en un equipo determinado es inferior al de WireGuard en el kernel. Este es uno de los compromisos que explica Tailscale frente a WireGuard sin una capa adicional.

Dos comandos indican cuál es la situación.

tailscale ip -4
tailscale status

tailscale status muestra una línea por nodo. La última columna es la importante.

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

direct seguido de una dirección y un puerto significa que las dos máquinas encontraron una ruta entre sí y que el tráfico es entre pares. relay "fra" significa que el tráfico pasa por un relay de Tailscale en Frankfurt. - significa que no hay una sesión activa con ese nodo en este momento, lo cual es normal.

Qué puede ver y qué no puede ver el servidor de coordinación

El servidor de coordinación almacena claves públicas y metadatos. Conoce los nombres de tus máquinas, qué usuario o etiqueta es propietario de cada nodo, la dirección de tailnet de cada nodo, las direcciones públicas desde las que se puede acceder a tus nodos, cuándo estuvo conectado cada uno por última vez y el archivo de políticas que escribiste. Esto proporciona un mapa completo de tu flota.

No almacena ninguna clave privada, por lo que no puede descifrar el tráfico entre dos nodos. El cifrado es de extremo a extremo entre los pares de WireGuard, y el servidor de coordinación no es un par.

Lo que sí puede hacer es distribuir claves. Cualquier servidor de coordinación, alojado por un proveedor o autogestionado, debe considerarse confiable para indicar a tus nodos qué claves públicas pertenecen a la tailnet. Este es el punto central del modelo de amenazas que se explica más adelante y el motivo por el que existe Headscale, un servidor de coordinación de código abierto que alojas tú mismo.

Cómo se comunican directamente dos servidores detrás de firewalls distintos

NAT (traducción de direcciones de red) permite que varias máquinas compartan una dirección pública. Su VPS normalmente tiene su propia dirección pública, pero las otras máquinas que quiere incluir en la tailnet a menudo no la tienen: un servidor doméstico, un ejecutor de compilaciones en una red de oficina o un equipo detrás del firewall de un proveedor que no puede modificar.

Tailscale encuentra una ruta mediante técnicas basadas en los estándares STUN (utilidades de recorrido de sesiones para NAT) e ICE. Cada nodo envía un paquete UDP pequeño a un servidor STUN y obtiene la dirección pública y el puerto que su router asignó a ese socket. Ambos nodos comunican esos candidatos al servidor de coordinación, que los transmite al otro extremo. Después, ambos nodos empiezan a enviarse paquetes al mismo tiempo. Cada router ve primero un paquete saliente, por lo que crea un mapeo y acepta la respuesta que llega desde esa misma dirección. Ningún extremo necesita una regla de firewall entrante. Por eso un NAS o una Raspberry Pi en casa puede seguir siendo accesible sin configurar ningún reenvío de puertos en el router; usar Tailscale en lugar del reenvío de puertos explica esta configuración, incluidas sus limitaciones.

Los puertos son específicos. Los túneles directos de WireGuard usan UDP con un puerto de origen cuyo valor predeterminado es 41641. STUN usa UDP 3478 para comunicarse con los servidores de retransmisión de Tailscale. La conexión de control prefiere HTTP sin cifrar en TCP 80, encapsulado en el transporte cifrado propio de Tailscale, y usa HTTPS en TCP 443 como alternativa cuando el puerto 80 no responde. Los datos retransmitidos mediante los servidores DERP de Tailscale usan HTTPS en TCP 443, mientras que una retransmisión entre pares que ejecute dentro de su propia tailnet los transporta mediante UDP. La mayoría de las veces no es necesario abrir ningún puerto entrante, aunque en una red con NAT restrictivo permitir UDP 41641 entrante aumenta la probabilidad de establecer una conexión directa.

tailscale netcheck

Lea dos líneas de ese informe. UDP: true significa que esta máquina puede enviar UDP a Internet, y UDP: false significa que no puede hacerlo, por lo que todas las conexiones desde este nodo se retransmitirán. MappingVariesByDestIP: true significa que el router asigna un puerto público distinto para cada destino, por lo que la predicción de direcciones anterior no puede funcionar y esos nodos normalmente permanecen retransmitidos.

Cuándo Tailscale usa un relay DERP

DERP (relay cifrado designado para paquetes) es el mecanismo de respaldo. Tailscale ejecuta relays en muchas regiones, accesibles mediante TCP 443, y un nodo que no puede establecer una ruta directa envía sus paquetes WireGuard a través de uno de ellos. La excepción es un tailnet en el que haya designado relays de pares, que son sus propios dispositivos y reenvían el tráfico mediante UDP. Tailscale prueba primero esos relays y recurre a DERP sólo cuando ninguno está disponible; tailscale status muestra entonces la conexión como peer-relay.

Los paquetes permanecen cifrados. Tailscale lo indica claramente: "un servidor DERP nunca puede descifrar su tráfico. Sólo reenvía a ciegas tráfico ya cifrado de un nodo a otro". Un relay ve el texto cifrado y ve qué nodo se comunica con cuál.

Los relays también transportan los primeros paquetes de la mayoría de las conexiones. Encontrar una ruta directa tarda un momento, por lo que una sesión suele comenzar mediante un relay y cambiar a una ruta directa cuando los dos nodos se localizan. Puede observar ese cambio.

tailscale ping db-1

Las primeras respuestas vuelven mediante via DERP(fra); después, una línea informa de algo parecido a via 198.51.100.24:41641. Ese cambio indica la actualización a un túnel directo. Si nunca cambia, ejecute tailscale netcheck en ambos extremos. Una ruta mediante relay sigue funcionando. Añade latencia porque cada paquete pasa por un tercer equipo. Si lo que ha observado son transferencias lentas y no una conexión interrumpida, por qué una conexión Tailscale mediante relay es mucho más lenta que una directa mide la diferencia y muestra cómo conseguir que una VPS use una ruta directa.

Unir un VPS a su tailnet

El script de instalación es compatible con Ubuntu y Debian.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

sudo tailscale up muestra una URL. Ábrala, autentíquese y el nodo aparecerá en la consola de administración. Después, confirme que el daemon vuelve a iniciarse tras un reinicio, porque este es el paso que se suele omitir.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled debe mostrar enabled, y tailscale status debe incluir el nodo nuevo con su dirección 100.x. En un servidor creado mediante un script, una URL interactiva no sirve. Genere una clave de autenticación en la consola de administración y pásela junto con una etiqueta que indique qué tipo de máquina es.

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

Un nodo etiquetado pertenece a la etiqueta y no a la persona que ejecutó el comando. Por tanto, sigue funcionando aunque la cuenta de esa persona desaparezca. La etiqueta debe declararse primero en el archivo de políticas, bajo tagOwners, o el comando se rechaza. Las etiquetas también cambian cómo cuenta la máquina para el plan, porque un recurso etiquetado se factura por separado de los dispositivos propios de una persona. La cobertura real del nivel gratuito explica cuáles son esos límites.

Hay dos ajustes importantes para una flota. De forma predeterminada, las claves de nodo caducan después de 180 días (a fecha de octubre de 2026). Cuando una clave caduca, "las conexiones hacia y desde el extremo indicado dejan de funcionar" hasta que el dispositivo vuelve a autenticarse. Un administrador puede elegir Temporarily extend key en una máquina caducada desde la consola de administración. Esto concede 30 minutos para iniciar sesión de nuevo o desactivar la caducidad. De forma predeterminada, la caducidad de la clave está desactivada en un nodo autenticado con una etiqueta, como el anterior. En cualquier otro servidor desatendido, abra la fila de la máquina en la consola de administración y elija Disable Key Expiry. MagicDNS, habilitado de forma predeterminada para las tailnets creadas a partir del 20 de octubre de 2022, asigna a cada nodo un nombre como db-1.yak-bebop.ts.net. Un resolvedor auxiliar en 100.100.100.100 resuelve esos nombres. Use los nombres en lugar de las direcciones, porque un nodo reconstruido obtiene una dirección nueva y conserva su nombre.

Si la instalación falla en apt o en el repositorio, los errores habituales de instalación de Tailscale en Ubuntu explica cómo corregirlos.

Acceder a un servicio vinculado a localhost

Aquí es donde tailnet resulta útil y donde suelen aparecer problemas. Unirse a tailnet no hace que un servicio de loopback sea accesible.

ss -tlnp | grep 3000

Si muestra 127.0.0.1:3000, el socket sólo acepta paquetes cuyo destino es 127.0.0.1. Una petición de otro nodo llega dirigida a la dirección 100.x de este nodo, por lo que el kernel no tiene ningún proceso escuchando en ella y responde con un restablecimiento TCP. El cliente muestra Connection refused. El túnel funciona correctamente. El problema está en el proceso que escucha.

Hay dos soluciones válidas. Vincule el servicio a la dirección de tailnet del nodo. Así seguirá fuera de la interfaz pública y no habrá ningún proxy intermedio: pase --bind 100.101.102.104 o la opción equivalente en la configuración. Para un contenedor, publique el puerto como -p 100.101.102.104:3000:3000. Como alternativa, deje el servicio en loopback y coloque Tailscale delante de él.

tailscale serve 3000

Esto redirige las peticiones a http://127.0.0.1:3000 y las sirve dentro de tailnet mediante un nombre ts.net a través de HTTPS, una vez habilitados los certificados HTTPS para tailnet. El servicio seguirá siendo privado para sus nodos. La versión pública de esta misma idea es Funnel. Tailscale serve frente a Funnel explica cuál debe usar.

Hay dos tareas relacionadas con páginas propias. Para acceder a una red privada completa que no tiene Tailscale instalado, necesita un enrutador de subred en un VPS. Para enviar el tráfico saliente de Internet de un nodo a través de otro nodo, necesita un nodo de salida.

Cerrar los puertos que ya no necesita

Cuando todos los administradores accedan al servidor mediante tailnet, el puerto público 22 ya no tendrá ninguna función. Esa es la ventaja práctica: un puerto cerrado no puede ser objeto de ataques de fuerza bruta y los registros dejan de llenarse de intentos.

El orden es importante. Añada el acceso desde tailnet, confirme que puede iniciar sesión a través de él desde una segunda sesión y sólo entonces elimine la regla pública.

sudo ufw allow in on tailscale0
sudo ufw status verbose

Después, elimine la regla pública de SSH y vuelva a conectarse mediante el nombre de MagicDNS. Tenga en cuenta qué hace realmente ufw allow in on tailscale0: confía en todo lo que llega por el túnel, por lo que el archivo de políticas de Tailscale pasa a controlar el acceso en lugar de ufw. Escriba la política teniendo esto en cuenta.

Una advertencia para quienes ejecutan contenedores. Un puerto publicado de Docker instala sus propias reglas NAT y omite ufw, por lo que un ufw deny no lo cierra. Puertos publicados de Docker que omiten ufw explica el mecanismo. Publicar en la dirección de tailnet, como se indicó antes, evita este problema. Si la aplicación se ejecuta mediante Docker Compose, un sidecar de Tailscale en la pila de Compose va un paso más allá y elimina por completo el puerto publicado, de modo que el contenedor sólo sea accesible mediante su nombre de tailnet.

Qué protege Tailscale y qué no

Conviene decirlo claramente, porque la versión de marketing difumina la diferencia.

Protegido: el tráfico entre dos nodos se cifra de extremo a extremo con WireGuard, y ningún relay intermedio puede leerlo. Las claves privadas nunca salen del equipo que las generó. Los nodos no necesitan ningún puerto público entrante, por lo que no hay nada en 22 o 5432 que Internet pueda analizar. El acceso entre nodos se decide mediante un archivo de políticas, no mediante quien conozca una dirección.

No protegido: el servidor de coordinación ve el grafo de dispositivos. Esos metadatos son sensibles por sí mismos, porque los nombres de las máquinas, sus propietarios, sus direcciones y sus horas de conexión describen su infraestructura. Además, el servidor distribuye claves, que es el riesgo más importante. Tailscale lo dice directamente: "Si Tailscale fuera malicioso e insertara nuevos nodos sigilosamente en su red, podría enviar o recibir tráfico de sus nodos existentes en texto plano." Su proveedor de inicio de sesión único se encuentra en la misma cadena de confianza, porque quien pueda emitir una identidad allí puede añadir un nodo. Además, un nodo comprometido es un par dentro del tailnet, por lo que lo que alcance después dependerá de lo que permita su política. Que esto constituya un riesgo aceptable depende de contra quién se defienda, y el modelo de confianza completo analiza cada uno de esos casos, incluido lo que realmente puede hacer una cuenta de identidad robada.

Hay dos respuestas al riesgo de distribución de claves. La primera es tailnet lock, que exige que los nodos de confianza existentes firmen criptográficamente un nodo nuevo antes de que los demás nodos lo acepten. Un plano de control que añada un nodo sin una firma válida se ignora. La consola de administración genera la línea exacta tailscale lock init para los nodos firmantes, y cada nodo puede confirmar lo que recibe.

tailscale lock status

Todos los nodos deben informar del mismo conjunto de claves de firma de confianza. La segunda respuesta es ejecutar el plano de control usted mismo. Un servidor de coordinación Headscale autohospedado utiliza el mismo protocolo con los mismos clientes, de modo que el grafo de dispositivos y la distribución de claves pasan a estar en hardware que usted controla. También pasa a ser responsable de la disponibilidad de ese servidor. Si todavía está comparando planos de control autohospedados en lugar de decidirse por este, NetBird es una VPN de malla independiente cuyo servidor se ejecuta de extremo a extremo en un único VPS.

Hay un valor predeterminado que debe corregirse el primer día. Un tailnet nuevo se publica con permisos demasiado amplios: "el archivo de políticas predeterminado del tailnet permite la comunicación entre todos los dispositivos del tailnet". En cuanto añada una sección acls, el modelo cambia a denegar por defecto y sólo pasan las reglas definidas.

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

Esa política permite a los miembros del tailnet acceder a SSH en los servidores etiquetados y a ningún otro servicio. Añada una regla por servicio en lugar de dejar el comodín, porque el comodín permite que la clave de un portátil robado acceda a la base de datos.

Modos de fallo y cadenas que verá

tailscale status siempre muestra relay. Los dos nodos nunca establecieron una ruta directa. Ejecute tailscale netcheck en ambos extremos. UDP: false significa que UDP está bloqueado en las conexiones salientes, por lo que sólo puede funcionar un relay. MappingVariesByDestIP: true significa que hay un NAT restrictivo en el camino. Permitir UDP 41641 en las conexiones entrantes del lado que controla suele resolverlo.

Un nodo que funcionó durante meses desapareció. Una causa habitual es que la clave del nodo haya caducado al cumplirse el valor predeterminado de 180 días. Compruebe primero el equipo en la consola de administración. Si aparece como caducado, sudo tailscale up en el equipo lo reactiva. Deshabilitar la caducidad de claves en los servidores evita que vuelva a ocurrir. Si no está caducada, revise el archivo de políticas. Tailscale recomienda comprobar las reglas de acceso que impiden la conexión cuando un dispositivo no aparece en tailscale status.

Los peers aparecen en la lista, pero las conexiones agotan el tiempo de espera. Si tailscale ping recibe respuestas, la conectividad funciona y la causa probable es que la política deniega el tráfico. Compruebe la sección acls para encontrar una regla que cubra este origen, destino y puerto. Un paquete denegado se descarta en lugar de recibir una respuesta. Por eso se produce un tiempo de espera y no Connection refused.

Los nombres de MagicDNS no se resuelven. ping db-1 falla, mientras ping 100.101.102.104 funciona. Primero confirme que el cliente acepta la configuración DNS de Tailscale. Un nodo iniciado con --accept-dns=false nunca envía sus consultas al resolvedor auxiliar en 100.100.100.100. Después, revise cat /etc/resolv.conf y cualquier otro componente del equipo que escriba en ese archivo. En un sistema que usa systemd-resolved, normalmente el archivo es un enlace simbólico a /run/systemd/resolve/stub-resolv.conf. Que 100.100.100.100 no aparezca allí es lo esperado. Cuando tailscaled escribe directamente en el archivo, un cliente DHCP u otra herramienta que lo sobrescriba interrumpe MagicDNS. Si ninguna de estas causas lo explica, el problema también puede estar en la configuración DNS local o de la red. Es el mismo tipo de problema que DNS que falla dentro de un túnel de WireGuard.

tailscale up rechaza la etiqueta. La etiqueta no está declarada bajo tagOwners en el archivo de políticas. Añádala allí y vuelva a ejecutar el comando.

FAQ

¿Tailscale es una VPN o una red mesh?

Ambas palabras son correctas y describen capas diferentes. Los túneles usan WireGuard, por lo que forman una VPN. La topología es una malla porque cada nodo crea un túnel directamente con cada nodo con el que se comunica, en lugar de enviar todos los paquetes a través de un servidor central. El servidor de coordinación está en el plano de control, no en el plano de datos. Por eso, si deja de estar disponible, los túneles existentes siguen transportando tráfico. Durante la interrupción se detienen la incorporación de nodos nuevos y la aplicación de cambios en las claves o en las políticas. Sin embargo, no es una VPN de privacidad de forma predeterminada: los sitios web siguen viendo su propia dirección pública hasta que envía el tráfico a través de un nodo de salida, y lo que Tailscale oculta a los sitios web y a su ISP depende de cada configuración.

¿Puede Tailscale leer mi tráfico?

No puede leer su contenido. El tráfico se cifra de extremo a extremo entre los nodos mediante WireGuard, las claves privadas nunca salen de los nodos y un relé DERP reenvía paquetes que no puede descifrar. Tailscale sí ve metadatos: nombres de máquinas, propietarios, claves públicas, direcciones de endpoint y cuándo está conectado cada nodo. También distribuye claves, por lo que un servidor de coordinación comprometido podría intentar insertar un nodo que su infraestructura acabaría considerando confiable. Tailnet lock lo impide al exigir firmas de sus propios nodos de confianza, y Headscale elimina el plano de control alojado.

¿Necesito abrir puertos del firewall para Tailscale?

Casi nunca para conexiones entrantes. La recomendación de Tailscale es que "la mayoría de las veces no es necesario abrir puertos del firewall". Para las conexiones salientes, un nodo necesita TCP 443 hacia el servidor de coordinación y los relés, además de UDP 3478 para STUN. Los túneles directos usan UDP con un puerto de origen cuyo valor predeterminado es 41641. Permitir UDP 41641 en conexiones entrantes es opcional y sólo ayuda a que las conexiones directas funcionen en redes problemáticas.

¿Por qué otros nodos no pueden acceder a mi servicio en el puerto 3000?

Compruebe primero la dirección de enlace con ss -tlnp. Un listener en 127.0.0.1:3000 rechaza las conexiones dirigidas a la dirección tailnet 100.x del nodo porque ese socket sólo acepta el destino de loopback, y el cliente recibe Connection refused. Enlace el servicio a la dirección tailnet o ejecute tailscale serve 3000 para usarlo como proxy. Si el listener ya está en 0.0.0.0 y la conexión agota el tiempo de espera en lugar de ser rechazada, la dirección de enlace no es el problema. Revise primero las reglas de política y los firewalls del host. Después, compruebe los firewalls de red y si la autenticación de alguno de los dos dispositivos ha caducado.

¿Debería ejecutar Headscale en lugar del servidor de coordinación de Tailscale?

Ejecute Headscale cuando el grafo de dispositivos o la distribución de claves deban permanecer en una infraestructura que usted controle, o cuando la tailnet deba funcionar sin depender de un servicio externo. Los clientes y el protocolo son los mismos. El coste es que ahora debe operar el servidor de coordinación. Si deja de estar disponible, se detiene la incorporación de nodos nuevos y la aplicación de cambios de política. En una infraestructura pequeña, el plano de control alojado con tailnet lock habilitado suele ofrecer una mejor relación entre costes y beneficios.