Tailscale lento: relay DERP o conexión directa

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

Tailscale es lento cuando la conexión se retransmite a través de uno de sus servidores DERP compartidos, y se acerca a la velocidad 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 pueden soportar 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 de su ancho de banda que se le asigna. El coste depende del relay. Tailscale describe sus servidores DERP como «generalmente más lentos que las conexiones directas», mientras que un relay entre pares que administre usted mismo es «normalmente más rápido que DERP» y, en las primeras pruebas de Tailscale, alcanzó un rendimiento «cercano al de una conexión directa». La página de rendimiento de Tailscale resume la regla general 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 presenta retraso. Por tanto, el primer paso es determinar qué tipo de conexión tiene. Dos comandos responden a esta pregunta en menos de un minuto; después, sólo queda corregir la causa. Conviene conocer la parte de 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 en modo relay, y el primero es el bloqueo de UDP. Consulte directamente la máquina:

tailscale netcheck

El informe está 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 la pista más clara que obtendrá. Significa que la máquina no pudo enviar un paquete UDP a los servidores de prueba de Tailscale. La referencia de la CLI de Tailscale indica que, en ese caso, «es poco probable que Tailscale pueda establecer conexiones punto a punto». El tráfico se transporta entonces mediante DERP sobre el puerto TCP 443. Este mecanismo alternativo explica por qué la máquina sigue pareciendo completamente operativa: está conectada, es accesible y todos los bytes se retransmiten. netcheck describe la red, no una conexión concreta. Por eso, confirme la ruta que usa realmente un peer con tailscale status o tailscale ping antes de cambiar reglas.

Hay dos reglas de salida documentadas. «Permita que sus dispositivos internos inicien tráfico UDP desde :41641 hasta *:*», que corresponde al tráfico de WireGuard, y «Permita que sus dispositivos internos inicien tráfico UDP hacia *:3478», que corresponde a STUN (utilidades de traversal 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 relay con el tiempo, y una lista de direcciones escrita manualmente 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. Puede proceder de una imagen reforzada heredada o aplicarla el proveedor en un nivel superior de la red. Revise primero la política de salida predeterminada:

sudo ufw status verbose
sudo nft list ruleset

Default: deny (incoming), allow (outgoing) es correcto y no es el problema. Una política de salida predeterminada de deny, con una lista corta que sólo permite TCP 443 y DNS, mantiene exactamente este tipo de servidor en un relay de forma permanente. La ruta DERP sobre TCP 443 atraviesa ese acceso, pero 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 un VPS tiene una dirección IP pública y, por tanto, puede ser la mitad accesible de la conexión. Si su firewall acepta tráfico UDP entrante en el puerto en el que escucha tailscaled, los peers situados detrás de routers domésticos problemáticos pueden alcanzarlo sin configuraciones especiales. Busque el puerto que se está usando realmente:

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

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

Causa 2: NAT simétrico en uno o ambos extremos

La segunda causa documentada es el NAT simétrico. NAT (traducción de direcciones de red) es lo que hace un router cuando reescribe la dirección privada para convertirla en pública. Un router compatible mantiene el mismo puerto público para un socket interno determinado, independientemente del destino, lo que se denomina asignación independiente del extremo. Un NAT simétrico 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 podrá usar un nodo remoto. Tailscale informa de esto en netcheck como MappingVariesByDestIP: true.

Un NAT simétrico es tolerable. Si el otro extremo tiene un endpoint público estable, la máquina situada detrás del NAT simétrico todavía puede iniciar la conexión y establecerse la ruta. El problema aparece cuando hay dos NAT simétricos a la vez, porque ninguno de los dos extremos puede predecir el puerto con el que aparecerá el otro.

En un VPS con una dirección IPv4 pública, este campo normalmente debería mostrar false. Una dirección pública no siempre significa que no exista traducción: AWS, por ejemplo, documenta que su gateway de Internet realiza un NAT uno a uno entre la dirección IPv4 pública de una instancia y su dirección privada. Una asignación estática uno a uno como esa mantiene el mismo puerto independientemente del destino, por lo que no es NAT simétrico y el campo sigue mostrando false. Si muestra true en un servidor alquilado, algo en la red del proveedor asigna un puerto diferente para cada destino. Ninguna regla de firewall dentro de la máquina puede cambiarlo. Puede configurar un relay de pares en una máquina que sí tenga un endpoint público directo o trasladar la carga de trabajo. Este también es el caso en el que anunciar sus rangos privados desde un router de subred resulta útil, porque entonces necesita una sola ruta adecuada hacia la red, en lugar de una ruta adecuada 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 Tailscale es directa o retransmitida?

Ejecute tailscale status y lea el final de la línea del par. direct 203.0.113.9:41641 es una conexión directa, relay "tor" significa que cada paquete pasa por ese servidor DERP, y peer-relay significa que los paquetes pasan a través de una máquina en su propia tailnet. Para una segunda opinión, ejecute tailscale ping <peer>: una ruta saludable comienza en DERP y luego imprime un pong con una dirección y puerto planos, mientras que una ruta retransmitida imprime pongs de DERP hasta que la ejecución termina con direct connection not established. Envíe algo de tráfico al par primero, ya que Tailscale solo construye una ruta bajo demanda.

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

Ejecute tailscale netcheck en el VPS. Si imprime UDP: false, el tráfico UDP saliente no está saliendo, generalmente debido a un firewall de salida, y Tailscale indica que una conexión punto a punto es improbable en ese caso. Confirme con tailscale status o tailscale ping que el par está en DERP, el cual funciona sobre TCP 443 y es la razón por la que la máquina aún parece conectada. Permita el tráfico UDP saliente desde el puerto 41641 a cualquier destino y el tráfico UDP saliente a cualquier destino en el puerto 3478. Verifique el firewall de red de su proveedor además del que está dentro del servidor, ya que son controles separados y una regla de ufw no afecta a la del proveedor.

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

No. Un servidor DERP reenvía paquetes de WireGuard que no puede descifrar, porque las claves de cifrado se generan en sus dispositivos y nunca salen de ellos. El costo de una retransmisión es la latencia y el rendimiento, no la confidencialidad. Lo que el servidor de coordinación sí controla es qué dispositivos se conocen entre sí, y la separación entre el material de claves y los metadatos de conexión es algo que vale la pena comprender antes de decidir cuánto de esto desea alojar usted mismo.

¿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 para otras, lo que significa nodos de salida y enrutadores de subred. Una computadora portátil o un servidor que solo se comunica con sus propios pares no obtiene ninguna ventaja. También requiere Tailscale 1.54 o posterior y el kernel de Linux 6.2 o posterior, así que verifique tailscale version y uname -r primero, y recuerde que ethtool -K se restablece al reiniciar a menos que lo haga persistente.

¿Es Tailscale más lento que WireGuard simple?

Ambos utilizan WireGuard para cifrar su tráfico. Tailscale añade la configuración de conexión que WireGuard simple le deja hacer manualmente, y esa configuración es la que a veces le hace terminar en una retransmisión. WireGuard simple no tiene ninguna retransmisión en la que terminar: se conecta directamente o no logra conectarse en absoluto. Por lo tanto, compare elementos equivalentes y solo realice pruebas de rendimiento de Tailscale cuando tailscale status indique direct. Si desea la versión configurada manualmente para comparar, un servidor WireGuard que usted mismo construye requiere unas cuarenta líneas de configuración, y el intercambio que está realizando se cubre en la comparación de ambos enfoques.