Tailscale lento: conexão relay ou direta?

Por que o Tailscale está lento: conexão retransmitida em vez de direta

O Tailscale fica lento quando a conexão é retransmitida e aproxima-se da velocidade máxima da ligação quando a conexão é direta. Uma conexão direta transporta pacotes WireGuard encriptados diretamente de uma máquina para a outra. Por isso, funciona à velocidade que as duas ligações à Internet conseguem fornecer. Uma conexão retransmitida envia primeiro cada pacote através de uma terceira máquina. Por isso, herda a latência dessa máquina e a parte da largura de banda que ela disponibiliza. A própria página de desempenho do Tailscale resume isto numa frase: "As conexões diretas quase sempre resultam em menor latência e maior débito."

Nada na sua aplicação mostra esta diferença. A cópia de ficheiros fica simplesmente lenta e a sessão SSH apresenta simplesmente atrasos. Por isso, o primeiro passo é descobrir que tipo de conexão já tem. Dois comandos respondem a essa questão em menos de um minuto. Tudo o que vem depois consiste em corrigir a causa. Vale a pena conhecer esta parte da configuração antes de começar, porque o servidor de coordenação e o plano de dados WireGuard são sistemas separados e apenas o plano de dados transporta os seus bytes.

Os dois comandos que distinguem uma ligação direta de uma ligação retransmitida

Envie algum tráfego para o peer antes de medir qualquer coisa. O Tailscale cria um caminho conforme necessário. Por isso, um peer com o qual não comunicou hoje pode ainda não ter negociado um caminho, e o resultado lido pode estar desatualizado. Um ping ou um curl para o endereço tailnet do peer é suficiente.

tailscale status

A resposta aparece no fim da linha 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 um endereço e de uma porta significa que os pacotes estão a ser enviados diretamente para esse endereço. relay "tor" identifica um servidor DERP (designated encrypted relay for packets), que é uma das máquinas de retransmissão do Tailscale. Nesse caso, todos os pacotes para esse peer passam por esse servidor. Um terceiro valor, peer-relay, é explicado na secção seguinte.

tailscale ping device-b

Uma ligação saudável começa retransmitida e depois muda. Os primeiros pacotes passam pelo servidor DERP mais próximo enquanto as duas máquinas negoceiam. Depois, o caminho é alterado:

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

A execução termina nesse ponto porque --until-direct tem o valor predefinido true. Uma ligação que não consegue passar para uma ligação direta aparece assim e termina com uma frase, não com um 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

Essa última linha é o resultado. Significa que o Tailscale enviou todas as sondas previstas e nunca obteve um caminho direto. Para continuar a monitorizar um caminho retransmitido em vez de parar na primeira ligação direta, execute tailscale ping --until-direct=false -c 20 device-b e analise a variação da latência. Um caminho retransmitido normalmente apresenta valores mais altos e maior variação, porque combina dois caminhos de Internet através de uma máquina que não controla.

O que significa peer-relay no status do Tailscale?

Um peer relay é uma máquina na sua própria tailnet que retransmite o tráfego de outros membros quando não é possível estabelecer uma ligação direta. A máquina escuta numa porta UDP à sua escolha, e o daemon dá-lhe preferência em relação ao DERP. tailscale status marca uma ligação deste tipo peer-relay, e tailscale ping apresenta o endpoint do 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

Leia essa saída com atenção. A ligação continua a não ser direta, por isso a execução termina com direct connection not established. O que mudou foi a máquina que retransmite o tráfego. Uma VPS com um endereço IP público e uma franquia de largura de banda generosa é um relay muito melhor para o seu próprio tráfego do que um nó DERP partilhado. É por isso que esta opção é importante para quem aluga um servidor. Ative-a na máquina que tem o endpoint público acessível:

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

Uma porta com o valor 0 escolhe uma porta livre aleatória, e uma string vazia desativa o servidor relay. Depois, dê aos dispositivos cliente permissão para a utilizar, com a capacidade tailscale.com/cap/relay no ficheiro de política da sua tailnet:

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

Tanto o dispositivo relay como os dispositivos cliente precisam do Tailscale 1.86 ou posterior. Por isso, confirme a versão com tailscale version em cada dispositivo antes de perder uma hora a editar o ficheiro de política. Vale a pena memorizar a ordem das tentativas do daemon. Primeiro, tenta estabelecer uma ligação direta. Se falhar, procura um peer relay que possa utilizar. Se não existir nenhum, recorre ao DERP. O DERP nunca fica totalmente fora do processo, porque também é o canal através do qual as duas máquinas negoceiam inicialmente.

Causa 1: um firewall de saída que bloqueia UDP

A documentação do Tailscale indica duas razões para uma ligação permanecer em relay, e a primeira é o UDP bloqueado. Consulte diretamente a máquina:

tailscale netcheck

O relatório está truncado aqui, e o campo superior é o que determina tudo:

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

UDP: false é a resposta completa quando esse valor aparece. A máquina não consegue enviar um pacote UDP para os servidores de teste do Tailscale. Por isso, não é possível estabelecer um caminho direto, e o daemon recorre a DERP através da porta TCP 443. É por isso que a máquina continua a parecer perfeitamente saudável: está ligada, está acessível e todos os bytes são encaminhados pelo relay.

A documentação descreve duas regras de saída. "Permitir que os dispositivos internos iniciem UDP de :41641 para *:*", que corresponde ao próprio tráfego WireGuard, e "Permitir que os dispositivos internos iniciem UDP para *:3478", que corresponde ao STUN (session traversal utilities for NAT), o protocolo usado pela máquina para descobrir o seu próprio endereço e porta públicos. Use wildcards nos destinos. O Tailscale adiciona servidores de relay ao longo do tempo, e uma lista de endereços escrita manualmente ficará incorreta dentro de um ano.

Num servidor alugado, a causa habitual é uma política de saída restritiva, herdada de uma imagem reforçada ou aplicada pelo fornecedor na rede upstream. Consulte primeiro a política de saída predefinida:

sudo ufw status verbose
sudo nft list ruleset

Default: deny (incoming), allow (outgoing) está correto e não é o problema. Um valor predefinido de saída deny, com uma lista curta que permite TCP 443 e DNS, mantém exatamente um servidor num relay permanentemente, porque o caminho DERP através de TCP 443 passa por essa abertura, mas o caminho direto não. O local efetivo dessas regras depende de o sistema usar iptables ou nftables internamente, e editar o componente errado é uma forma comum de não alterar nada.

O tráfego de entrada também é importante, porque um VPS tem um endereço IP público e pode, por isso, ser a metade mais simples do par. Se o firewall aceitar UDP de entrada na porta em que tailscaled está a escutar, os peers atrás de routers domésticos problemáticos podem alcançá-lo sem soluções adicionais. Descubra a porta efetivamente utilizada:

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

41641 é a porta estática predefinida. Numa tailnet com a definição randomizeClientPort ativada, os clientes escolhem uma porta aleatória. Nesse caso, use o número real apresentado pela saída de ss, e não o valor desta página. Em seguida, verifique o painel de controlo do fornecedor. A maioria dos hosts utiliza um firewall de rede separado do firewall dentro do servidor, e uma regra adicionada com ufw não tem qualquer efeito sobre esse firewall.

Causa 2: NAT rígido numa ou em ambas as extremidades

A segunda causa documentada é o NAT rígido. NAT (tradução de endereços de rede) é o que um router faz quando reescreve o seu endereço privado para o endereço público. Um router compatível mantém a mesma porta pública para um determinado socket interno, independentemente do destino da comunicação. Isto chama-se mapeamento independente do endpoint. Um NAT rígido atribui uma porta pública diferente para cada destino. Por isso, o endereço que a máquina obtém de um servidor STUN não é necessariamente o endereço que um peer poderá usar. O Tailscale apresenta esta situação em netcheck como MappingVariesByDestIP: true.

Um único NAT rígido pode ser contornado. Se o outro lado tiver um endpoint público estável, a máquina atrás do NAT rígido ainda poderá aceitar ligações e o caminho será estabelecido. Dois NATs rígidos em simultâneo causam a falha, porque nenhum dos lados consegue prever a porta em que o outro irá aparecer.

Numa VPS com um endereço IPv4 público, este campo deve apresentar false, porque não existe nenhum dispositivo a traduzir esse endereço. Se apresentar true num servidor que aluga, o endereço está a ser traduzido algures na rede do fornecedor. Nenhuma regra de firewall dentro da máquina irá alterar isso. As opções são colocar um relay de peers numa máquina que tenha um endpoint público direto ou mover a carga de trabalho. Este também é o caso em que anunciar os seus intervalos privados a partir de um subnet router é útil, porque passa a precisar de um caminho funcional para entrar na rede, em vez de um caminho funcional para cada dispositivo dessa rede.

Por que um exit node faz o Tailscale parecer mais lento do que realmente é

Um exit node adiciona um segundo salto, e os utilizadores atribuem esse atraso ao túnel. Com um exit node selecionado, um pedido sai do seu portátil, atravessa o túnel até ao VPS, sai do VPS para a Internet pública e a resposta faz o caminho inverso. Mesmo uma ligação perfeitamente direta a esse VPS não pode tornar o percurso total mais rápido do que a ligação ascendente do próprio VPS. A distância adicional também aparece no carregamento de cada página.

Meça as duas partes separadamente. Desative o exit node e teste apenas o túnel contra o endereço tailnet do VPS:

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

Execute iperf3 -c 100.113.160.82 no cliente contra esse endereço tailnet. Esse valor corresponde ao seu túnel. Agora volte a ativar o exit node com sudo tailscale set --exit-node=100.113.160.82 e execute um teste de velocidade normal para a Internet pública. Esse valor corresponde ao túnel mais a ligação ascendente do VPS. Se o primeiro valor for bom e o segundo for mau, o Tailscale não é o problema. Nesse caso, deve verificar a própria rede e o dimensionamento do exit node. tailscale exit-node list mostra os exit nodes disponíveis quando não tiver a certeza de qual selecionou.

A CPU é a outra parte do limite de desempenho de um exit node. As recomendações do Tailscale dão preferência a uma geração recente de CPU com uma velocidade de relógio mais elevada, em vez de uma maior quantidade de cores. Por isso, um plano com mais vCPUs não é automaticamente mais rápido neste caso. Num host partilhado sobrecarregado, a CPU prometida pode não ser a CPU que recebe. O steal time causado por um vizinho ruidoso aparece como um débito variável ao longo do dia, sem qualquer alteração do seu lado.

O único parâmetro de ajuste: rx-udp-gro-forwarding

A documentação do Tailscale indica uma única definição do Linux, aplicável a máquinas que encaminham tráfego, ou seja, exit nodes e subnet routers. Um cliente comum não obtém benefícios. É necessário usar Tailscale 1.54 ou posterior e um kernel Linux 6.2 ou posterior. Confirme ambos antes de alterar qualquer definição:

tailscale version
uname -r

Com esses requisitos cumpridos, ative o encaminhamento UDP GRO (generic receive offload) na interface ligada à 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

Confirme se a alteração foi aplicada:

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

Deverá ver rx-udp-gro-forwarding: on e rx-gro-list: off. Isto ajuda porque o tráfego do Tailscale usa UDP. Ao permitir que o kernel mantenha pequenos pacotes UDP agregados ao longo do caminho de encaminhamento, o daemon processa menos segmentos maiores para o mesmo número de bytes. ethtool -K não sobrevive a um reboot, por isso deve torná-lo persistente. Num 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

Execute o script manualmente uma vez e confirme que o código de saída é 0. Um nó de encaminhamento também precisa de ter o encaminhamento IP ativado. Trata-se de uma definição separada e de uma falha 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

Qual é o MTU usado pela sua interface tailscale0?

Não faça estimativas. Leia o valor diretamente na máquina:

ip link show tailscale0

O valor de mtu nessa saída é o que o túnel realmente usa. Ele é inferior aos 1500 informados pela sua interface Ethernet. Isso é intencional, não um erro. Cada pacote enviado dentro do túnel é encapsulado: um cabeçalho IP externo de 20 bytes para IPv4 ou 40 bytes para IPv6, um cabeçalho UDP de 8 bytes e o enquadramento do WireGuard com uma tag de autenticação de 32 bytes. Tudo isso precisa caber no tamanho máximo que o caminho real consegue transportar. O Tailscale escolhe então um valor suficientemente baixo para funcionar em ligações que transportam menos de um pacote completo de 1500 bytes, incluindo ligações PPPoE, algumas redes móveis e túneis IPv6.

O sintoma de um problema de MTU é específico. Não o diagnostique apenas com base na lentidão. O SSH responde, ping funciona e, depois, transferências grandes ou páginas HTTPS extensas ficam totalmente bloqueadas, em vez de apenas lentas. Esse padrão indica que pacotes demasiado grandes estão a ser descartados algures, sem que uma mensagem ICMP consiga chegar ao remetente. Aumentar o MTU de tailscale0 para um valor próximo de 1500 piora o problema, porque os pacotes que já não cabem ficam ainda maiores. A correção é encontrar o MTU funcional do caminho por bisseção e limitar o MSS do TCP no router que encaminha o tráfego. O tipo de ligação não altera este comportamento: um caminho relay e um caminho direto usam o mesmo MTU de interface.

FAQ

Como sei se a minha ligação Tailscale é direta ou retransmitida?

Execute tailscale status e leia o final da linha do peer. direct 203.0.113.9:41641 indica uma ligação direta, relay "tor" significa que todos os pacotes passam por esse servidor DERP e peer-relay significa que os pacotes passam por uma máquina da sua própria tailnet. Para obter uma segunda confirmação, execute tailscale ping <peer>: um caminho saudável começa em DERP e depois apresenta um pong com um endereço e uma porta simples, enquanto um caminho retransmitido apresenta pongs DERP até terminar com direct connection not established. Envie primeiro algum tráfego para o peer, porque o Tailscale só cria um caminho quando é necessário.

Por que motivo o meu VPS nunca estabelece uma ligação direta?

Execute tailscale netcheck no VPS. Se apresentar UDP: false, uma firewall de saída está a descartar UDP de saída e o daemon recorreu a DERP através de TCP 443, razão pela qual a máquina continua a parecer ligada. Permita UDP de saída da porta 41641 para qualquer destino e UDP de saída para qualquer destino na porta 3478. Verifique a firewall de rede do fornecedor e a firewall dentro do servidor, porque são controlos separados e uma regra ufw não afeta a firewall do fornecedor.

Uma ligação Tailscale retransmitida é menos segura do que uma ligação direta?

Não. Um servidor DERP encaminha pacotes WireGuard que não consegue desencriptar, porque as chaves de encriptação são geradas nos seus dispositivos e nunca saem deles. O custo de um relay é latência e débito, não confidencialidade. O que o servidor de coordenação controla é quais os dispositivos que ficam a conhecer-se, e a separação entre o material de chaves e os metadados de ligação é importante compreender antes de decidir quanto dessa infraestrutura quer alojar localmente.

A definição rx-udp-gro-forwarding ajuda todas as máquinas?

Não. Está documentada para máquinas Linux que encaminham tráfego para outras, ou seja, exit nodes e routers de sub-rede. Um portátil ou servidor que comunica apenas com os seus próprios peers não obtém qualquer benefício. Também requer Tailscale 1.54 ou posterior e Linux kernel 6.2 ou posterior, por isso verifique primeiro tailscale version e uname -r e lembre-se de que ethtool -K é reposta no reboot, a menos que a torne persistente.

O Tailscale é mais lento do que o WireGuard simples?

Ambos usam WireGuard para encriptar o tráfego. O Tailscale acrescenta a configuração da ligação que o WireGuard simples deixa a cargo do administrador, e é essa configuração que, por vezes, coloca a ligação num relay. O WireGuard simples não tem um relay para o qual possa recorrer: liga diretamente ou falha completamente a ligação. Compare, portanto, situações equivalentes e faça o benchmark do Tailscale apenas quando tailscale status indicar direct. Se quiser a versão configurada manualmente para comparação, um servidor WireGuard que configure por conta própria requer cerca de quarenta linhas de configuração, e o compromisso envolvido é explicado em a comparação entre as duas abordagens.