Tailscale lento: relay o conexión directa

Por qué Tailscale es lento: usa una conexión retransmitida en lugar de una directa

Tailscale es lento cuando la conexión usa un relay y funciona casi a la velocidad máxima de la línea cuando la conexión es directa. Una conexión directa transporta paquetes WireGuard cifrados directamente de una máquina a otra, por lo que funciona a la velocidad que permiten las dos conexiones a Internet. Una conexión retransmitida envía primero cada paquete a través de una tercera máquina, por lo que hereda la latencia de esa máquina y la parte del ancho de banda que tenga disponible. La propia página de rendimiento de Tailscale lo resume en una línea: "Las conexiones directas casi siempre ofrecen menor latencia y mayor rendimiento".

Nada dentro de la aplicación muestra la diferencia. La copia de archivos simplemente es lenta y la sesión SSH simplemente tiene retraso. Por eso, lo primero es determinar qué tipo de conexión tiene actualmente. Dos comandos permiten comprobarlo en menos de un minuto. A partir de ahí, hay que corregir la causa. Conviene conocer la configuración antes de empezar, porque el servidor de coordinación y el plano de datos de WireGuard son sistemas independientes y sólo el plano de datos transporta los bytes.

Los dos comandos que indican si la conexión es directa o está retransmitida

Envíe tráfico al peer antes de medir nada. Tailscale crea la ruta cuando es necesario, por lo que es posible que un peer con el que no se haya comunicado hoy todavía no haya negociado ninguna ruta. En ese caso, leería una respuesta obsoleta. Basta con ejecutar un ping o un curl hacia la dirección tailnet del peer.

tailscale status

La respuesta aparece al final de la línea de cada peer.

100.113.160.82 device-a  tagged-devices linux   active; offers exit node; direct 203.0.113.9:41641
100.104.93.78  device-b  you@           android active; relay "tor"

direct seguido de una dirección y un puerto indica que los paquetes van directamente a esa dirección. relay "tor" identifica un servidor DERP (relay cifrado designado para paquetes), que es uno de los equipos de relay de Tailscale. Todos los paquetes destinados a ese peer pasan por él. Un tercer valor, peer-relay, se explica en la sección siguiente.

tailscale ping device-b

Una conexión en buen estado empieza retransmitida y después cambia. Los primeros paquetes pasan por el servidor DERP más cercano mientras las dos máquinas negocian. Después, la ruta cambia:

pong from device-b (100.113.160.82) via DERP(tor) in 51ms
pong from device-b (100.113.160.82) via DERP(tor) in 48ms
pong from device-b (100.113.160.82) via 203.0.113.9:41641 in 35ms

La ejecución se detiene ahí porque --until-direct tiene el valor predeterminado true. Una conexión que no puede pasar a una ruta directa se muestra así y termina con una frase en lugar de un pong:

pong from device-b (100.104.93.78) via DERP(tor) in 53ms
pong from device-b (100.104.93.78) via DERP(tor) in 60ms
direct connection not established

Esa última línea es el resultado. Significa que Tailscale envió todas las sondas previstas y nunca obtuvo una ruta directa. Para seguir supervisando una ruta retransmitida en lugar de detenerse en la primera ruta directa, ejecute tailscale ping --until-direct=false -c 20 device-b y observe la variación de la latencia. Una ruta retransmitida suele mostrar valores más altos y también más variación, porque combina dos rutas de Internet a través de un equipo que usted no controla.

¿Qué significa peer-relay en tailscale status?

Un peer relay es una máquina de tu propio tailnet que retransmite el tráfico de otros miembros cuando no es posible establecer una conexión directa. Escucha en un puerto UDP que eliges, y el daemon lo utiliza antes que DERP. tailscale status marca una conexión de este tipo peer-relay, y tailscale ping muestra el endpoint del relay:

pong from device-b (100.97.143.93) via peer-relay(203.0.113.42:40000:vni:1) in 4ms
direct connection not established

Lee esto con atención. La conexión sigue sin ser directa, por lo que la ejecución todavía termina con direct connection not established. Lo que cambia es quién retransmite el tráfico. Una VPS con una dirección IP pública y una asignación de ancho de banda generosa es un relay mucho mejor para tu propio tráfico que un nodo DERP compartido. Por eso esto es importante para cualquiera que alquile un servidor. Habilítalo en la máquina que tenga el endpoint público adecuado:

sudo tailscale set --relay-server-port=40000

Un puerto 0 selecciona un puerto libre al azar, y una cadena vacía deshabilita el servidor relay. Después, concede a los dispositivos cliente permiso para usarlo mediante la capacidad tailscale.com/cap/relay en el archivo de políticas de tu tailnet:

{
  "grants": [
    {
      "src": ["tag:us-east-vpc"],
      "dst": ["tag:us-east-relays"],
      "app": {
        "tailscale.com/cap/relay": []
      }
    }
  ]
}

Tanto el dispositivo relay como los dispositivos cliente necesitan Tailscale 1.86 o posterior. Comprueba tailscale version en cada uno antes de dedicar una hora al archivo de políticas. Conviene memorizar el orden en que lo intenta el daemon. Primero intenta establecer una conexión directa. Si falla, busca un peer relay que tenga permiso para usar. Si no hay ninguno, recurre a DERP. DERP nunca desaparece por completo, porque también es el canal mediante el que las dos máquinas negocian la conexión inicialmente.

Causa 1: un firewall de salida que bloquea UDP

Tailscale documenta dos motivos por los que una conexión permanece retransmitida, y el primero es el bloqueo de UDP. Consulte directamente la máquina:

tailscale netcheck

El informe aparece recortado aquí, y el campo superior es el que determina todo:

Report:
  * UDP: true
  * IPv4: yes, 203.0.113.9:41641
  * IPv6: no
  * MappingVariesByDestIP: false
  * PortMapping:
  * Nearest DERP: Dallas

UDP: false es toda la respuesta cuando aparece. La máquina no puede enviar un paquete UDP a los servidores de sondeo de Tailscale, por lo que no se puede establecer una ruta directa y el daemon vuelve a DERP mediante TCP en el puerto 443. Este fallback explica por qué la máquina sigue pareciendo completamente saludable: está conectada, es accesible y todos los bytes se retransmiten.

Hay dos reglas de salida documentadas. "Permita que los dispositivos internos inicien UDP desde :41641 hasta *:*", que corresponde al tráfico de WireGuard, y "Permita que los dispositivos internos inicien UDP hacia *:3478", que corresponde a STUN (utilidades de recorrido de sesiones para NAT), el protocolo que usa la máquina para conocer su propia dirección y puerto públicos. Use comodines para los destinos. Tailscale añade servidores de retransmisión con el tiempo, y una lista escrita manualmente con direcciones dejará de ser válida en menos de un año.

En un servidor alquilado, el culpable habitual es una política de salida restrictiva, ya sea heredada de una imagen reforzada o aplicada por el proveedor en un nivel superior. Revise primero la política predeterminada de salida:

sudo ufw status verbose
sudo nft list ruleset

Default: deny (incoming), allow (outgoing) es correcto y no es el problema. Una salida predeterminada de deny con una lista corta que sólo permite TCP 443 y DNS mantiene exactamente al servidor en una retransmisión permanente, porque la ruta DERP mediante TCP 443 pasa por esa excepción y la ruta directa no. La ubicación real de esas reglas depende de si el sistema usa iptables o nftables internamente, y editar la herramienta incorrecta es una forma habitual de no cambiar nada.

El tráfico entrante también importa, porque una VPS tiene una dirección IP pública y, por tanto, puede ser la mitad fácil del par. Si su firewall acepta UDP entrante en el puerto en el que escucha tailscaled, los peers situados detrás de routers domésticos problemáticos pueden alcanzarla sin configuraciones especiales. Busque el puerto que está realmente en uso:

sudo ss -lunp | grep tailscaled
sudo ufw allow 41641/udp

41641 es el puerto estático predeterminado. En un tailnet con el ajuste randomizeClientPort activado, los clientes eligen un puerto aleatorio. En ese caso, use el número real de la salida de ss en lugar del que aparece en esta página. Después, revise el panel de control del proveedor. La mayoría de los hosts ejecutan un firewall de red independiente del firewall del servidor, y una regla añadida con ufw no tiene ningún efecto sobre él.

Causa 2: NAT estricto en uno o ambos extremos

La segunda causa documentada es el NAT estricto. NAT (traducción de direcciones de red) es lo que hace un router cuando reescribe la dirección privada y la convierte en pública. Un router compatible mantiene el mismo puerto público para un socket interno determinado, independientemente del destino de la conexión. Esto se denomina mapeo independiente del extremo. Un NAT estricto asigna un puerto público diferente para cada destino. Por tanto, la dirección que la máquina obtiene de un servidor STUN no es la dirección que un peer podrá utilizar. Tailscale informa de este estado en netcheck como MappingVariesByDestIP: true.

Un NAT estricto es tolerable si sólo está presente en un extremo. Si el otro extremo tiene un endpoint público estable, la máquina situada detrás del NAT estricto todavía puede iniciar la conexión y se establece la ruta. Dos NAT estrictos al mismo tiempo provocan el fallo, porque ninguno de los dos extremos puede predecir el puerto en el que aparecerá el otro.

En un VPS con una dirección IPv4 pública, este campo debería mostrar false, porque ningún dispositivo está traduciendo esa dirección. Si muestra true en un servidor alquilado, la dirección se está traduciendo en algún punto de la red del proveedor. Ninguna regla de firewall dentro de la máquina puede cambiarlo. Puede colocar un relay entre peers en una máquina que sí tenga un endpoint público limpio, o trasladar la carga de trabajo. Este también es el caso en el que anunciar los rangos privados desde un subnet router resulta útil, porque sólo necesita una ruta correcta hacia la red, en lugar de una ruta correcta hacia cada dispositivo de la red.

Por qué un nodo de salida hace que Tailscale parezca más lento de lo que es

Un nodo de salida añade un segundo salto, y muchos usuarios atribuyen ese retraso al túnel. Con un nodo de salida seleccionado, la petición sale del portátil, atraviesa el túnel hasta el VPS, sale del VPS hacia Internet pública y la respuesta vuelve por el mismo camino. Incluso una conexión perfectamente directa con ese VPS no puede hacer que el tiempo total sea inferior al que permite la propia conexión ascendente del VPS. La distancia adicional se refleja en cada carga de página.

Mida las dos partes por separado. Desactive el nodo de salida y pruebe el túnel por sí solo contra la dirección de tailnet del VPS:

sudo tailscale set --exit-node=
sudo apt install -y iperf3
iperf3 -s

Ejecute iperf3 -c 100.113.160.82 desde el cliente contra esa dirección de tailnet. Ese valor corresponde al túnel. Vuelva a activar el nodo de salida con sudo tailscale set --exit-node=100.113.160.82 y ejecute una prueba de velocidad normal hacia Internet pública. Ese valor corresponde al túnel más la conexión ascendente del VPS. Si el primer valor es bueno y el segundo es malo, Tailscale no es el problema. Revise la red y el dimensionamiento del propio nodo de salida. tailscale exit-node list muestra qué opciones están disponibles si no sabe qué nodo seleccionó.

La CPU es la otra limitación de un nodo de salida. La recomendación de Tailscale es preferir una generación reciente de CPU con una frecuencia de reloj más alta frente a un mayor número de núcleos. Por tanto, un plan con más vCPU no es automáticamente más rápido en este caso. En un host compartido con mucha carga, la CPU prometida no siempre es la CPU que recibe. El steal time causado por un vecino ruidoso se refleja en un rendimiento que varía según la hora sin que haya cambios en su lado.

El único ajuste: rx-udp-gro-forwarding

Tailscale documenta un único ajuste de Linux, y se aplica a las máquinas que reenvían tráfico, es decir, exit nodes y subnet routers. Un cliente normal no obtiene ningún beneficio. Requiere Tailscale 1.54 o posterior y un kernel de Linux 6.2 o posterior, así que confirme ambos requisitos antes de cambiar nada:

tailscale version
uname -r

Con estos requisitos cumplidos, active el reenvío de UDP GRO (generic receive offload) en la interfaz orientada a Internet:

NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

Compruebe que el cambio se haya aplicado:

ethtool -k $NETDEV | grep -E 'rx-udp-gro-forwarding|rx-gro-list'

Debería ver rx-udp-gro-forwarding: on y rx-gro-list: off. Esto ayuda porque el tráfico de Tailscale usa UDP. Si el kernel mantiene coalescidos los paquetes UDP pequeños durante el reenvío, el daemon procesa menos segmentos y de mayor tamaño para la misma cantidad de bytes. ethtool -K no sobrevive a un reinicio, por lo que debe hacerlo persistente. En un sistema que usa networkd-dispatcher:

printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

Ejecute el script manualmente una vez y compruebe que su estado de salida sea 0. Un nodo que reenvía tráfico también necesita tener habilitado el reenvío IP. Es un ajuste independiente y puede producir un fallo diferente:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

¿Qué MTU utiliza la interfaz tailscale0?

No adivine este valor. Léalo directamente del equipo:

ip link show tailscale0

El valor de mtu en esa salida es el que utiliza realmente el túnel, y es inferior al valor 1500 que informa la interfaz Ethernet. Es intencionado, no un error. Cada paquete que envía dentro del túnel se encapsula: una cabecera IP exterior de 20 bytes para IPv4 o de 40 bytes para IPv6, una cabecera UDP de 8 bytes y el entramado de WireGuard con su etiqueta de autenticación de 32 bytes. Todo debe caber dentro de lo que pueda transportar la ruta real. Tailscale elige entonces un valor suficientemente bajo para funcionar en enlaces que transportan menos de un paquete completo de 1500 bytes, como las conexiones PPPoE, algunas redes móviles y los túneles IPv6.

El síntoma de un problema de MTU es específico. No lo diagnostique sólo por la lentitud. SSH responde, ping funciona y, después, las transferencias grandes o las páginas HTTPS de gran tamaño se bloquean por completo en lugar de ejecutarse lentamente. Este patrón indica que los paquetes demasiado grandes se descartan en algún punto y que no vuelve ningún mensaje ICMP para informar al emisor. Aumentar el MTU de tailscale0 hacia 1500 empeora la situación, porque los paquetes que ya no caben se hacen más grandes. La solución real es encontrar por bisección la MTU operativa de la ruta y limitar el MSS de TCP en el router que reenvía el tráfico. El tipo de conexión no cambia nada de esto: una ruta retransmitida y una ruta directa utilizan la misma MTU de interfaz.

FAQ

¿Cómo sé si mi conexión de Tailscale es directa o está retransmitida?

Ejecute tailscale status y lea el final de la línea del par. direct 203.0.113.9:41641 indica una conexión directa, relay "tor" significa que todos los paquetes pasan por ese servidor DERP y peer-relay significa que los paquetes pasan por una máquina de su propia tailnet. Para obtener una segunda comprobación, ejecute tailscale ping <peer>: una ruta correcta comienza en DERP y después muestra un pong con una dirección y un puerto normales, mientras que una ruta retransmitida muestra pongs de DERP hasta que la ejecución termina con direct connection not established. Envíe primero algo de tráfico al par, porque Tailscale sólo crea una ruta cuando es necesario.

¿Por qué mi VPS nunca obtiene una conexión directa?

Ejecute tailscale netcheck en el VPS. Si muestra UDP: false, un firewall de salida está bloqueando el tráfico UDP saliente y el daemon ha cambiado a DERP mediante TCP 443. Por eso la máquina sigue apareciendo como conectada. Permita UDP saliente desde el puerto 41641 hacia cualquier destino y UDP saliente hacia cualquier destino en el puerto 3478. Compruebe tanto el firewall de red del proveedor como el del propio servidor, porque son controles independientes y una regla ufw no afecta al firewall del proveedor.

¿Una conexión de Tailscale retransmitida es menos segura que una directa?

No. Un servidor DERP reenvía los paquetes de WireGuard que no puede descifrar, porque las claves de cifrado se generan en sus dispositivos y nunca salen de ellos. El coste de una retransmisión es latencia y rendimiento, no confidencialidad. Lo que sí controla el servidor de coordinación es qué dispositivos obtienen información unos sobre otros, y la separación entre el material criptográfico y los metadatos de conexión es importante entenderla antes de decidir qué parte quiere alojar por su cuenta.

¿La configuración rx-udp-gro-forwarding ayuda a todas las máquinas?

No. Está documentada para máquinas Linux que reenvían tráfico de otros dispositivos, es decir, exit nodes y subnet routers. Un portátil o un servidor que sólo se comunica con sus propios pares no obtiene ningún beneficio. Además, requiere Tailscale 1.54 o posterior y Linux kernel 6.2 o posterior. Por tanto, compruebe primero tailscale version y uname -r, y recuerde que ethtool -K se restablece después de reiniciar, a menos que lo haga persistente.

¿Tailscale es más lento que WireGuard sin configuración adicional?

Ambos usan WireGuard para cifrar el tráfico. Tailscale añade la configuración de conexión que WireGuard sin configuración adicional le obliga a realizar manualmente, y esa configuración es la que a veces coloca la conexión en una retransmisión. WireGuard sin configuración adicional no tiene ninguna retransmisión en la que pueda terminar: se conecta directamente o no se conecta. Por tanto, compare opciones equivalentes y mida Tailscale sólo cuando tailscale status indique direct. Si quiere comparar con la versión configurada manualmente, un servidor de WireGuard que configure usted mismo requiere unas cuarenta líneas de configuración, y la diferencia entre ambos enfoques se explica en la comparación de los dos enfoques.