Como funciona Tailscale y que es realmente

¿Qué es Tailscale?

Tailscale es una VPN que conecta sus máquinas directamente entre sí en lugar de enrutar todo el tráfico a través de una puerta de enlace gestionada por usted. Cada nodo ejecuta WireGuard, por lo que los paquetes viajan cifrados de un servidor a otro y nada en la ruta puede leerlos. Un servidor de coordinación alojado se encarga de las presentaciones. Este almacena y distribuye claves públicas e indica a cada nodo dónde están los demás. También aplica las reglas de acceso que usted haya definido.

Esa separación constituye todo el diseño. El plano de datos es entre pares (peer-to-peer) y está cifrado entre nodos. El plano de control es un servicio que Tailscale ejecuta para usted. Cualquier pregunta relevante sobre Tailscale, incluidas las incómodas sobre la confianza, se deriva de esos dos hechos. Si ya ha configurado una VPN WireGuard manualmente en un VPS, Tailscale es ese mismo túnel, pero con la distribución de claves y el cruce de cortafuegos automatizados para usted.

¿Cómo funciona Tailscale?

Su red privada de nodos se denomina tailnet. Cuatro cosas ocurren cuando una máquina se une a una.

1. El demonio tailscaled se inicia, genera un par de claves WireGuard y mantiene su estado en /var/lib/tailscale/tailscaled.state. La clave privada permanece en esa máquina. La terminología de Tailscale es directa: "la clave privada nunca, bajo ninguna circunstancia, abandona su nodo".
2. El nodo inicia sesión en el servidor de coordinación y sube su clave pública, además de las direcciones donde cree que puede ser contactado. 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 la tailnet, el nombre de la máquina y los puntos finales candidatos de cada nodo al que este tiene permitido acceder.
4. Cada par de nodos intenta entonces establecer un túnel WireGuard directo entre ellos. Cuando esto falla, envían los paquetes a través de un relé.

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

La implementación de WireGuard reside dentro de tailscaled en el espacio de usuario, no en el módulo del kernel. Es por eso que Tailscale se inicia en 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 menor que el de WireGuard en el kernel, lo cual es uno de los compromisos que detalla Tailscale frente a WireGuard estándar.

Dos comandos le indican su situación actual.

tailscale ip -4
tailscale status

tailscale status imprime una línea por nodo, y la última columna es la que importa.

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 el tráfico es punto a punto. relay "fra" significa que está pasando a través de un relé de Tailscale en Frankfurt. Un - significa que no hay una sesión activa con ese nodo en este momento, lo cual es normal.

Lo que el servidor de coordinación puede y no puede ver

El servidor de coordinación almacena claves públicas y metadatos. Conoce los nombres de sus máquinas, qué usuario o etiqueta posee cada nodo, la dirección de cada nodo en la tailnet, las direcciones públicas en las que sus nodos son accesibles, cuándo se conectó cada uno por última vez y el archivo de políticas que usted redactó. Eso constituye un mapa completo de su infraestructura.

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, ya sea alojado por terceros o autogestionado, tiene la confianza de indicar a sus nodos qué claves públicas pertenecen a la tailnet. Ese es el punto crítico del modelo de amenazas que se detalla más adelante, y la razón por la que existe Headscale, un servidor de coordinación de código abierto que usted mismo aloja.

Cómo se comunican directamente dos servidores tras diferentes firewalls

NAT (traducción de direcciones de red) es lo que permite que muchas máquinas compartan una única dirección pública. Su VPS suele tener su propia dirección pública, pero las otras máquinas que desea 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 utilizando técnicas basadas en los estándares STUN (utilidades de sesión para NAT) e ICE. Cada nodo envía un pequeño paquete UDP a un servidor STUN y obtiene la dirección pública y el puerto que su router asignó a ese socket. Ambos nodos informan de esos candidatos al servidor de coordinación, que los transmite al otro extremo. Luego, ambos nodos comienzan a enviarse paquetes simultáneamente. Cada router ve primero un paquete saliente, por lo que crea un mapeo y acepta la respuesta que llega desde esa misma dirección. Ninguno de los lados necesitó una regla de firewall de entrada.

Los puertos son específicos. Los túneles WireGuard directos utilizan UDP con un puerto de origen que, por defecto, es 41641. STUN se ejecuta sobre UDP 3478 hacia los servidores de retransmisión de Tailscale. La conexión de control y cualquier dato retransmitido utilizan HTTPS sobre TCP 443. La mayor parte del tiempo no es necesario abrir nada de entrada, aunque en una red con un NAT restrictivo, permitir UDP 41641 de entrada hace que una conexión directa sea más probable.

tailscale netcheck

Lea dos líneas de ese informe. UDP: true significa que el tráfico UDP sale de la máquina, y UDP: false significa que cada conexión desde este nodo será retransmitida. MappingVariesByDestIP: true significa que el router asigna un puerto público diferente por destino, por lo que la predicción de direcciones mencionada arriba no puede funcionar y esos nodos generalmente permanecen retransmitidos.

Cuando Tailscale utiliza un relé DERP en su lugar

DERP (por sus siglas en inglés, relé cifrado designado para paquetes) es el mecanismo de respaldo. Tailscale opera relés en muchas regiones, accesibles a través del puerto TCP 443, y cualquier nodo que no pueda establecer una ruta directa envía sus paquetes WireGuard a través de uno de ellos.

Los paquetes permanecen cifrados. Tailscale lo afirma claramente: "no hay forma de que un servidor DERP descifre su tráfico. Simplemente reenvía a ciegas tráfico ya cifrado de un nodo a otro". Un relé solo ve texto cifrado y qué nodo se comunica con cuál.

Los relés también transportan los primeros paquetes de la mayoría de las conexiones. Encontrar una ruta directa toma un momento, por lo que una sesión a menudo comienza siendo retransmitida y se actualiza automáticamente una vez que ambos nodos se localizan. Puede observar este proceso.

tailscale ping db-1

Las primeras respuestas llegan como via DERP(fra), y luego una línea posterior informa algo como via 198.51.100.24:41641. Ese cambio es la actualización a un túnel directo. Si nunca cambia, ejecute tailscale netcheck en ambos extremos. Una ruta retransmitida sigue funcionando. Esto conlleva latencia, ya que cada paquete realiza un desvío a través de una tercera máquina.

Unir un VPS a su tailnet

El script de instalación cubre Ubuntu y Debian.

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

sudo tailscale up imprime una URL. Ábrala, autentíquese y el nodo aparecerá en su consola de administración. Luego confirme que el daemon se reinicia tras un reinicio del sistema, ya que es el paso que la gente suele omitir.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled debería imprimir enabled, y tailscale status debería listar el nuevo nodo con su dirección 100.x. Para un servidor configurado mediante un script, una URL interactiva no es útil. Genere una clave de autenticación (auth key) en la consola de administración y utilícela junto con una etiqueta que registre 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 en lugar de a la persona que ejecutó el comando, por lo que sigue funcionando después de que la cuenta de esa persona sea eliminada. La etiqueta debe declararse primero en su archivo de políticas bajo tagOwners, de lo contrario el comando será rechazado. El etiquetado también cambia cómo cuenta la máquina en su plan, ya que un recurso etiquetado se factura de forma distinta a los dispositivos personales, y lo que cubre realmente el nivel gratuito detalla dónde se encuentran esos límites.

Dos configuraciones son importantes para una flota. Las claves de nodo caducan después de 180 días de forma predeterminada (a fecha de agosto de 2026), y cuando una clave caduca, "las conexiones hacia/desde el endpoint dado dejarán de funcionar" hasta que alguien inicie sesión de nuevo; por lo tanto, abra la fila de la máquina en la consola de administración y seleccione Disable Key Expiry en servidores desatendidos. MagicDNS, habilitado por defecto para tailnets creadas a partir del 20 de octubre de 2022, asigna a cada nodo un nombre como db-1.yak-bebop.ts.net, resuelto por un stub resolver en 100.100.100.100. Utilice los nombres en lugar de las direcciones, ya que un nodo reconstruido obtiene una dirección nueva pero conserva su nombre.

Si la instalación falla en apt o en el repositorio, los errores comunes de instalación de Tailscale en Ubuntu cubren las soluciones.

Acceder a un servicio vinculado a localhost

Aquí es donde una tailnet resulta útil y donde los usuarios suelen quedarse atascados. Unirse a la tailnet no hace que un servicio de loopback sea accesible.

ss -tlnp | grep 3000

Si esto devuelve 127.0.0.1:3000, el socket solo acepta paquetes cuyo destino sea 127.0.0.1. Una solicitud desde otro nodo llega dirigida a la dirección 100.x de este nodo, por lo que el kernel no tiene nada escuchando para esa dirección y responde con un TCP reset. El cliente informa de Connection refused. El túnel funciona correctamente. El problema es el listener.

Existen dos soluciones honestas. Vincular el servicio a la dirección de la tailnet del nodo, lo cual lo mantiene fuera de la interfaz pública sin un proxy de por medio: pase --bind 100.101.102.104 o la opción equivalente en su configuración, y para un contenedor, publique el puerto como -p 100.101.102.104:3000:3000. O bien, deje el servicio en loopback y coloque Tailscale delante de él.

tailscale serve 3000

Esto redirige las solicitudes a http://127.0.0.1:3000 y las sirve dentro de su tailnet bajo un nombre ts.net mediante HTTPS, una vez que los certificados HTTPS estén habilitados para la tailnet. Permanece privado para sus nodos. La versión pública de la misma idea es Funnel, y Tailscale serve frente a funnel cubre cuál de las dos opciones necesita.

Dos tareas relacionadas tienen sus propias páginas. Acceder a una red privada completa que no tiene Tailscale instalado requiere un router de subred en un VPS, y enviar el tráfico de internet saliente de un nodo a través de otro nodo requiere un exit node.

Cierre de los puertos que ya no necesita

Una vez que el administrador accede al servidor a través de la tailnet, el puerto 22 público deja de ser necesario. Esta es la ventaja práctica: un puerto cerrado no puede ser objeto de ataques de fuerza bruta y los registros dejan de llenarse con intentos de acceso.

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

sudo ufw allow in on tailscale0
sudo ufw status verbose

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

Una advertencia para quienes ejecutan contenedores. Un puerto publicado en 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 la tailnet, como se indicó anteriormente, evita este comportamiento.

Qué protege Tailscale y qué no

Vale la pena establecerlo con claridad, ya que la versión de marketing difumina la línea.

Protegido: el tráfico entre dos nodos está cifrado de extremo a extremo con WireGuard, y ningún nodo intermedio puede leerlo. Las claves privadas nunca abandonan la máquina que las generó. Los nodos no necesitan puertos públicos de entrada, por lo que no hay nada en el 22 o 5432 que Internet pueda escanear. El acceso entre nodos se decide mediante un archivo de políticas en lugar de por quién conoce una dirección.

No protegido: el servidor de coordinación ve el grafo de sus dispositivos. Esos metadatos son sensibles por sí mismos, ya que los nombres de las máquinas, los propietarios, las direcciones y los tiempos de conexión describen su infraestructura. También distribuye claves, lo cual representa un riesgo mayor. Tailscale lo dice directamente: "Si Tailscale fuera malintencionado e insertara nodos nuevos en su red de forma sigilosa, Tailscale podría enviar o recibir tráfico a sus nodos existentes en texto plano". Su proveedor de inicio de sesión único (SSO) se encuentra en la misma ruta de confianza, ya que quien pueda crear una identidad allí puede añadir un nodo. Además, un nodo comprometido es un par dentro de la tailnet, por lo que lo que alcance a continuación depende de lo que permitan sus políticas. Si esto constituye un riesgo aceptable depende de contra quién se esté defendiendo, y el modelo de confianza completo analiza cada uno de esos casos, incluyendo lo que puede hacer realmente una cuenta de identidad robada.

Existen dos respuestas al riesgo de distribución de claves. La primera es tailnet lock, que requiere que los nodos de confianza existentes firmen criptográficamente un nodo nuevo antes de que sus otros nodos lo acepten. Un plano de control que añade un nodo sin una firma válida es ignorado. La consola de administración genera la línea tailscale lock init exacta para sus nodos de firma, y cada nodo puede confirmar lo que ve.

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, lo que traslada el grafo de dispositivos y la distribución de claves a hardware de su propiedad. Usted también asume la responsabilidad del tiempo de actividad 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.

Un valor predeterminado que debe corregir el primer día. Una tailnet nueva se entrega con una configuración permisiva: "la política predeterminada de la tailnet permite la comunicación entre todos los dispositivos dentro de la misma". Tan pronto como añade una sección acls, el modelo cambia a denegar por defecto y solo se permiten sus reglas.

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

Esa política permite a los miembros de la tailnet acceder a SSH en servidores etiquetados y nada más. Añada una regla por servicio en lugar de dejar el comodín, porque el comodín significa que una clave de portátil robada puede alcanzar su base de datos.

Modos de fallo y cadenas que encontrará

tailscale status siempre indica relay. Los dos nodos nunca establecieron una ruta directa. Ejecute tailscale netcheck en ambos extremos. UDP: false significa que el tráfico UDP saliente está bloqueado, por lo que solo funcionará a través de un relay. MappingVariesByDestIP: true significa que existe una NAT restrictiva en el camino; permitir tráfico UDP 41641 entrante en el lado que usted controla suele solucionar el problema.

Un nodo que funcionaba desde hace meses ha desaparecido. Su clave de nodo expiró tras el periodo predeterminado de 180 días. La máquina aparece como expirada en la consola de administración y ejecutar sudo tailscale up en el equipo la reactiva. Deshabilite la expiración de claves en los servidores para evitar que esto se repita.

Los pares aparecen en la lista pero las conexiones agotan el tiempo de espera. La conectividad funciona, pero la política está denegando el tráfico. Revise la sección acls para verificar si existe una regla que cubra este origen, destino y puerto. Un paquete denegado se descarta en lugar de ser rechazado, por lo que se obtiene un tiempo de espera en lugar de Connection refused.

Los nombres de MagicDNS no se resuelven. ping db-1 falla mientras que ping 100.101.102.104 funciona. Algún proceso reemplazó /etc/resolv.conf, por lo que las consultas nunca llegan al stub resolver en 100.100.100.100. Revise cat /etc/resolv.conf para buscar 100.100.100.100 y compruebe qué otro proceso en el equipo modifica ese archivo. Es el mismo tipo de problema que en DNS fallando dentro de un túnel WireGuard.

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

FAQ

¿Es Tailscale una VPN o una red mesh?

Ambos términos son correctos y describen capas distintas. Los túneles utilizan WireGuard, lo que la convierte en una VPN. La topología es de tipo mesh, ya que cada nodo establece un túnel directo con los nodos con los que se comunica, en lugar de enviar cada paquete a través de un servidor central. El servidor de coordinación se sitúa en el plano de control, no en el plano de datos; por tanto, si deja de estar accesible, los túneles existentes siguen transmitiendo tráfico. Lo que se interrumpe durante una caída es la incorporación de nuevos nodos y la aplicación de cambios en claves o políticas.

¿Puede Tailscale leer mi tráfico?

No el contenido. El tráfico está cifrado de extremo a extremo entre nodos mediante WireGuard, las claves privadas nunca abandonan los nodos y un repetidor DERP reenvía paquetes que no puede descifrar. Tailscale sí tiene acceso a metadatos: nombres de máquinas, propietarios, claves públicas, direcciones de los puntos finales y el estado de conexión de cada nodo. También distribuye claves, por lo que un servidor de coordinación comprometido podría intentar insertar un nodo en el que su flota confiaría. Tailnet lock impide esto al requerir firmas de sus propios nodos de confianza, y Headscale elimina el plano de control alojado de la ecuación.

¿Necesito abrir puertos en el firewall para Tailscale?

Casi nunca para tráfico entrante. La guía oficial de Tailscale indica que "la mayor parte del tiempo, no necesita abrir ningún puerto en el firewall". Para tráfico saliente, un nodo requiere TCP 443 hacia el servidor de coordinación y los repetidores, además de UDP 3478 para STUN. Los túneles directos utilizan UDP con un puerto de origen que, por defecto, es 41641. Permitir UDP 41641 entrante es opcional y solo ayuda a que las conexiones directas tengan éxito en redes restrictivas.

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

Primero, verifique la dirección de enlace con ss -tlnp. Un proceso escuchando en 127.0.0.1:3000 rechaza las conexiones que llegan dirigidas a la dirección 100.x de la tailnet del nodo, ya que ese socket solo acepta el destino loopback, y el cliente recibe Connection refused. Enlace el servicio a la dirección de la tailnet o ejecute tailscale serve 3000 para usar un proxy. Si el servicio ya está escuchando en 0.0.0.0 y la conexión agota el tiempo de espera en lugar de ser rechazada, la causa es una regla de política o un firewall local, no la dirección de enlace.

¿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 infraestructura bajo su control, o cuando la tailnet deba funcionar sin dependencia de un servicio externo. Los clientes y el protocolo son los mismos. El coste es que usted pasa a operar el servidor de coordinación, y su caída impide la unión de nuevos nodos y la aplicación de cambios en las políticas. Para una flota pequeña, el plano de control alojado con tailnet lock activado suele ser la mejor opción.