O que é Tailscale e como ele funciona?

O que é o Tailscale?

O Tailscale é uma VPN que liga diretamente as suas máquinas, em vez de encaminhar todo o tráfego através de um gateway que teria de gerir. Cada nó executa WireGuard. Assim, os pacotes viajam encriptados de um servidor para outro e nenhum dispositivo no percurso os consegue ler. Um servidor de coordenação alojado trata das apresentações entre os nós. Armazena e distribui as chaves públicas e informa cada nó sobre a localização dos restantes. Também distribui as regras de acesso que configurou.

Esta separação define toda a arquitetura. O plano de dados é peer-to-peer e está encriptado entre os nós. O plano de controlo é um serviço que o Tailscale executa por si. Todas as questões importantes sobre o Tailscale, incluindo as questões incómodas relacionadas com confiança, resultam destes dois factos. Se já configurou uma VPN WireGuard manualmente num VPS, o Tailscale fornece o mesmo túnel, mas trata da distribuição de chaves e da travessia de firewalls.

Como o Tailscale funciona?

A sua rede privada de nós chama-se tailnet. Quando uma máquina entra numa tailnet, acontecem quatro coisas.

1. O daemon tailscaled é iniciado, gera um par de chaves WireGuard e mantém o seu estado em /var/lib/tailscale/tailscaled.state. A chave privada permanece nessa máquina. A própria documentação do Tailscale é explícita: "a chave privada nunca, em circunstância alguma, sai do seu nó."
2. O nó inicia sessão no servidor de coordenação e carrega a sua chave pública, além dos endereços onde acredita que pode ser contactado. O Tailscale descreve esse servidor como "um diretório partilhado de chaves públicas."
3. O servidor de coordenação devolve um mapa de rede: a chave pública, o endereço da tailnet, o nome da máquina e os endpoints candidatos de todos os nós aos quais este nó tem autorização para aceder.
4. Cada par de nós tenta criar um túnel WireGuard direto entre si. Quando isso falha, os pacotes são encaminhados através de um relay.

Cada nó recebe um endereço estável do intervalo 100.64.0.0/10, o intervalo de NAT de operadoras que vai de 100.64.0.0 a 100.127.255.255. O Tailscale usa esse intervalo porque está reservado para a infraestrutura dos fornecedores, pelo que raramente entra em conflito com os endereços privados já utilizados pelos seus servidores. No Linux, o túnel aparece como uma interface chamada tailscale0.

A implementação WireGuard funciona dentro de tailscaled em userspace, e não no módulo do kernel. Por isso, o Tailscale é iniciado em ambientes de virtualização de contentores onde sudo modprobe wireguard falha com Operation not supported. Isto também significa que o limite de débito num determinado sistema é inferior ao do WireGuard no kernel. Essa é uma das contrapartidas abordadas em Tailscale face ao WireGuard simples.

Dois comandos mostram o estado atual.

tailscale ip -4
tailscale status

tailscale status apresenta uma linha por nó, e a última coluna é a 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 um endereço e de uma porta significa que as duas máquinas encontraram um caminho entre si e que o tráfego é peer-to-peer. relay "fra" significa que o tráfego está a passar por um relay do Tailscale em Frankfurt. Um - significa que não existe uma sessão ativa com esse nó neste momento, o que é normal.

O que o servidor de coordenação pode e não pode ver

O servidor de coordenação armazena chaves públicas e metadados. Ele conhece os nomes das suas máquinas, o utilizador ou a etiqueta a que cada nó pertence, o endereço tailnet de cada nó, os endereços públicos através dos quais os seus nós podem ser alcançados, quando cada um esteve online pela última vez e o ficheiro de políticas que escreveu. Isto constitui um mapa completo da sua frota.

Ele não armazena nenhuma chave privada, por isso não pode desencriptar o tráfego entre dois nós. A encriptação é feita de ponta a ponta entre os peers WireGuard, e o servidor de coordenação não é um peer.

O que ele pode fazer é distribuir chaves. Qualquer servidor de coordenação, alojado por terceiros ou gerido por si, tem de ser confiado para indicar aos seus nós quais as chaves públicas que pertencem à tailnet. Esse é o ponto central do modelo de ameaças explicado mais abaixo e a razão pela qual existe o Headscale, um servidor de coordenação open source que aloja por conta própria.

Como dois servidores atrás de firewalls diferentes comunicam diretamente

NAT (tradução de endereços de rede) permite que várias máquinas partilhem um endereço público. Normalmente, o seu VPS tem um endereço público próprio, mas as outras máquinas que pretende adicionar à tailnet muitas vezes não têm: um servidor doméstico, um executor de builds numa rede de escritório ou uma máquina atrás de um firewall do fornecedor que não pode editar.

O Tailscale encontra um caminho com técnicas baseadas nas normas STUN (utilitários de travessia de sessões para NAT) e ICE. Cada nó envia um pequeno pacote UDP para um servidor STUN e descobre o endereço público e a porta que o router atribuiu a esse socket. Ambos os nós comunicam esses candidatos ao servidor de coordenação, que os transmite ao outro lado. Em seguida, ambos os nós começam a enviar pacotes entre si ao mesmo tempo. Cada router vê primeiro um pacote de saída, cria um mapeamento e aceita a resposta que chega desse mesmo endereço. Nenhum dos lados precisou de uma regra de entrada no firewall.

As portas são específicas. Os túneis WireGuard diretos usam UDP com uma porta de origem cujo valor predefinido é 41641. O STUN usa UDP 3478 para os servidores de retransmissão do Tailscale. A ligação de controlo e todos os dados retransmitidos usam HTTPS na porta TCP 443. Na maioria dos casos, não é necessário abrir nenhuma porta de entrada, embora, numa rede com NAT problemático, permitir UDP 41641 de entrada torne mais provável uma ligação direta.

tailscale netcheck

Leia duas linhas desse relatório. UDP: true significa que o UDP sai da máquina, e UDP: false significa que todas as ligações deste nó serão retransmitidas. MappingVariesByDestIP: true significa que o router atribui uma porta pública diferente por destino. Nesse caso, a previsão de endereço acima não funciona e esses nós normalmente permanecem em modo retransmitido.

Quando o Tailscale usa um relay DERP

DERP (designated encrypted relay for packets) é o mecanismo de fallback. O Tailscale mantém relays em várias regiões, acessíveis através de TCP 443. Um nó que não consegue obter um caminho direto envia os seus pacotes WireGuard através de um relay.

Os pacotes continuam cifrados. O Tailscale afirma isso claramente: "there is never a way for a DERP server to decrypt your traffic. It just blindly forwards already-encrypted traffic from one node to another." Um relay vê o texto cifrado e vê qual nó comunica com qual.

Os relays também transportam os primeiros pacotes da maioria das ligações. Encontrar um caminho direto demora algum tempo. Por isso, uma sessão começa muitas vezes através de um relay e é atualizada no mesmo local assim que os dois nós se encontram. Pode monitorizar esse processo.

tailscale ping db-1

As primeiras respostas regressam através de via DERP(fra). Depois, uma linha posterior indica algo semelhante a via 198.51.100.24:41641. Essa alteração corresponde à atualização para um túnel direto. Se o estado nunca mudar, execute tailscale netcheck em ambas as extremidades. Um caminho através de relay continua a funcionar. A latência aumenta porque cada pacote faz um desvio através de uma terceira máquina.

Aderir uma VPS à sua tailnet

O script de instalação suporta Ubuntu e Debian.

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

sudo tailscale up imprime um URL. Abra-o, autentique-se e o nó aparece na consola de administração. Depois, confirme que o daemon volta a iniciar depois de um reboot, porque esse é o passo que muitas pessoas ignoram.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled deve imprimir enabled, e tailscale status deve listar o novo nó com o respetivo endereço 100.x. Num servidor criado a partir de um script, um URL interativo não é útil. Gere uma auth key na consola de administração e transmita-a com uma tag que indique o tipo de máquina.

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

Um nó com tag pertence à tag, e não à pessoa que executou o comando. Assim, continua a funcionar depois de a conta dessa pessoa ser removida. A tag tem de ser declarada primeiro no ficheiro de políticas, em tagOwners, ou o comando é recusado. A utilização de tags também altera a forma como a máquina é contabilizada no seu plano, porque um recurso com tag é faturado separadamente dos dispositivos próprios de uma pessoa. O que o nível gratuito cobre efetivamente explica os limites aplicáveis.

Há duas definições importantes para uma frota. Por predefinição, as chaves dos nós expiram após 180 dias (em agosto de 2026). Quando uma chave expira, "as ligações de e para o endpoint indicado deixam de funcionar" até alguém iniciar sessão novamente. Por isso, abra a linha da máquina na consola de administração e selecione Disable Key Expiry nos servidores sem interação. O MagicDNS, ativado por predefinição para tailnets criadas em ou depois de 20 de outubro de 2022, atribui a cada nó um nome como db-1.yak-bebop.ts.net, resolvido por um stub resolver em 100.100.100.100. Use os nomes em vez dos endereços, porque um nó recriado recebe um novo endereço, mas mantém o nome.

Se a própria instalação falhar no apt ou no repositório, Os erros comuns de instalação do Tailscale no Ubuntu apresenta as correções.

Aceder a um serviço associado a localhost

É aqui que uma tailnet se torna útil e onde muitos utilizadores ficam bloqueados. A adesão à tailnet não torna um serviço de loopback acessível.

ss -tlnp | grep 3000

Se esse comando mostrar 127.0.0.1:3000, o socket aceita apenas pacotes cujo destino seja 127.0.0.1. Um pedido de outro nó chega endereçado ao endereço 100.x deste nó. Por isso, o kernel não encontra nenhum processo à escuta nesse endereço e responde com um TCP reset. O cliente apresenta Connection refused. O túnel está a funcionar. O problema está no processo à escuta.

Há duas soluções corretas. Associe o serviço ao endereço da tailnet do nó. Assim, o serviço continua fora da interface pública e não há nenhum proxy no caminho. Passe --bind 100.101.102.104 ou a opção equivalente na configuração. Num contentor, publique a porta como -p 100.101.102.104:3000:3000. Em alternativa, mantenha o serviço em loopback e coloque o Tailscale à frente dele.

tailscale serve 3000

Isso encaminha os pedidos para http://127.0.0.1:3000 e disponibiliza-os dentro da sua tailnet através de um nome ts.net, usando HTTPS depois de ativar os certificados HTTPS para a tailnet. O serviço continua privado para os seus nós. A versão pública da mesma abordagem é o Funnel. A página Tailscale serve com funnel explica qual deve utilizar.

Duas tarefas relacionadas têm páginas próprias. Para aceder a uma rede privada completa onde o Tailscale não está instalado, precisa de um router de sub-rede num VPS. Para encaminhar o tráfego de Internet de saída de um nó através de outro nó, precisa de um nó de saída.

Fechar as portas de que já não precisa

Depois de todos os administradores acederem ao servidor através da tailnet, a porta pública 22 já não tem utilidade. Esse é o benefício prático: uma porta fechada não pode ser alvo de ataques de força bruta, e os logs deixam de ser preenchidos com tentativas.

A ordem é importante. Adicione o acesso pela tailnet, confirme que consegue iniciar sessão através dele a partir de uma segunda sessão e só depois remova a regra pública.

sudo ufw allow in on tailscale0
sudo ufw status verbose

Depois disso, elimine a regra pública do SSH e volte a ligar-se usando o nome MagicDNS. Tenha em atenção o que ufw allow in on tailscale0 realmente faz: confia em tudo o que chega através do túnel, por isso o ficheiro de políticas do Tailscale passa a controlar o acesso em vez do ufw. Escreva a política tendo isso em conta.

Um aviso para quem executa contentores. Uma porta publicada pelo Docker instala as suas próprias regras NAT e contorna o ufw, por isso um ufw deny não a fecha. Portas publicadas pelo Docker que contornam o ufw explica o mecanismo. Publicar no endereço da tailnet, como acima, evita esse comportamento.

O que o Tailscale protege e o que não protege

É importante dizer isto claramente, porque a versão de marketing mistura os limites.

Protegido: o tráfego entre dois nós é cifrado de ponta a ponta com WireGuard, e nenhum relay intermédio consegue lê-lo. As chaves privadas nunca saem da máquina que as gerou. Os nós não precisam de uma porta pública de entrada, portanto não há nada nas portas 22 ou 5432 para a internet analisar. O acesso entre nós é decidido por um ficheiro de política, e não por quem conhece um endereço.

Não protegido: o servidor de coordenação vê o grafo dos seus dispositivos. Esses metadados são sensíveis por si só, porque os nomes das máquinas, os proprietários, os endereços e os períodos online descrevem a sua infraestrutura. O servidor também distribui chaves, o que representa o risco mais grave. O Tailscale diz isso diretamente: "Se o Tailscale fosse malicioso e inserisse discretamente novos nós na sua rede, poderia enviar ou receber tráfego dos seus nós existentes em texto simples." O seu fornecedor de single sign-on está no mesmo caminho de confiança, porque quem conseguir emitir uma identidade nesse fornecedor pode adicionar um nó. E um nó comprometido é um peer dentro do tailnet, portanto aquilo que ele conseguir alcançar a seguir será tudo o que a sua política permitir. A questão de isso representar um risco aceitável depende de quem está a tentar impedir, e o modelo de confiança completo analisa cada um desses casos, incluindo o que uma conta de identidade roubada pode realmente fazer.

Existem duas respostas para o risco da distribuição de chaves. A primeira é o tailnet lock, que exige que os nós confiáveis existentes assinem criptograficamente um novo nó antes de os outros nós o aceitarem. Um control plane que adicione um nó sem uma assinatura válida é ignorado. A consola de administração gera a linha tailscale lock init exata para os seus nós de assinatura, e cada nó pode confirmar aquilo que recebe.

tailscale lock status

Todos os nós devem comunicar o mesmo conjunto de chaves de assinatura confiáveis. A segunda resposta é executar o control plane por sua conta. Um servidor de coordenação Headscale alojado por si fala o mesmo protocolo com os mesmos clientes, transferindo o grafo dos dispositivos e a distribuição das chaves para hardware que lhe pertence. Nesse caso, também fica responsável pela disponibilidade desse servidor. Se ainda estiver a comparar control planes alojados por si em vez de escolher este, o NetBird é uma VPN mesh separada cujo servidor pode executar de ponta a ponta numa única VPS.

Há uma predefinição para corrigir no primeiro dia. Um tailnet novo é disponibilizado com permissões amplas: "o ficheiro de política predefinido do tailnet permite a comunicação entre todos os dispositivos dentro do tailnet". Assim que adicionar uma secção acls, o modelo passa a negar o acesso por predefinição e apenas as suas regras são permitidas.

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

Essa política permite que os membros do tailnet acedam a SSH nos servidores etiquetados e a mais nada. Adicione uma regra por serviço em vez de deixar o wildcard, porque o wildcard significa que uma chave de portátil roubada consegue alcançar a sua base de dados.

Modos de falha e mensagens apresentadas

tailscale status apresenta sempre relay. Os dois nós nunca estabeleceram um caminho direto. Execute tailscale netcheck em ambas as extremidades. UDP: false significa que o tráfego UDP de saída está bloqueado, pelo que apenas um relay pode funcionar. MappingVariesByDestIP: true significa que existe uma NAT restritiva no caminho. Permitir ligações UDP de entrada na porta 41641 no lado que controla costuma resolver o problema.

Um nó que funcionou durante meses desapareceu. A chave do nó expirou ao fim do período predefinido de 180 dias. A máquina aparece como expirada na consola de administração, e sudo tailscale up no sistema repõe o acesso. Desative a expiração de chaves nos servidores para evitar que o problema se repita.

Os peers aparecem na lista, mas as ligações atingem o tempo limite. A conectividade está a funcionar e a política está a bloquear o tráfego. Verifique a secção acls para encontrar uma regra que abranja esta origem, este destino e esta porta. Um pacote bloqueado é descartado sem resposta. Por isso, obtém um timeout em vez de Connection refused.

Os nomes MagicDNS não são resolvidos. ping db-1 falha, enquanto ping 100.101.102.104 funciona. Algo substituiu /etc/resolv.conf, pelo que as consultas nunca chegam ao stub resolver em 100.100.100.100. Verifique cat /etc/resolv.conf à procura de 100.100.100.100 e analise também o que mais no sistema escreve nesse ficheiro. É o mesmo tipo de problema que falha do DNS dentro de um túnel WireGuard.

tailscale up rejeita a sua tag. A tag não está declarada em tagOwners no ficheiro de política. Adicione-a nesse local e execute novamente o comando.

FAQ

O Tailscale é uma VPN ou uma rede mesh?

As duas descrições estão corretas, mas referem-se a camadas diferentes. Os túneis usam WireGuard, por isso o Tailscale é uma VPN. A topologia é mesh porque cada nó cria um túnel diretamente para cada nó com que comunica, em vez de enviar todos os pacotes através de um servidor central. O servidor de coordenação está no plano de controlo, não no plano de dados. Se ficar inacessível, os túneis existentes continuam a transportar tráfego. Durante uma falha, o que deixa de funcionar é a entrada de novos nós e a aplicação de alterações às chaves ou à política.

O Tailscale consegue ler o meu tráfego?

Não consegue ler o conteúdo. O tráfego é cifrado de ponta a ponta entre os nós com WireGuard, as chaves privadas nunca saem dos nós e um relay DERP encaminha pacotes que não consegue decifrar. O Tailscale vê metadados: nomes das máquinas, proprietários, chaves públicas, endereços dos endpoints e quando cada nó está online. Também distribui chaves. Por isso, um servidor de coordenação comprometido poderia tentar inserir um nó que a sua fleet passaria a aceitar. O tailnet lock impede isso ao exigir assinaturas dos seus próprios nós de confiança. O Headscale remove o plano de controlo alojado da arquitetura.

Preciso de abrir portas na firewall para o Tailscale?

Quase nunca para ligações de entrada. A orientação do Tailscale é que "na maioria dos casos, não é necessário abrir portas na firewall". Para ligações de saída, um nó precisa de TCP 443 para o servidor de coordenação e para os relays, além de UDP 3478 para STUN. Os túneis diretos usam UDP com uma porta de origem que, por predefinição, é 41641. Permitir UDP 41641 para ligações de entrada é opcional. Isso apenas ajuda a estabelecer ligações diretas em redes com restrições específicas.

Porque é que os outros nós não conseguem aceder ao meu serviço na porta 3000?

Verifique primeiro o endereço de bind com ss -tlnp. Um listener em 127.0.0.1:3000 recusa ligações destinadas ao endereço tailnet 100.x do nó porque esse socket aceita apenas o destino loopback. O cliente recebe Connection refused. Faça o bind do serviço ao endereço tailnet ou execute tailscale serve 3000 para criar um proxy. Se o listener já estiver em 0.0.0.0 e a ligação exceder o tempo limite em vez de ser recusada, a causa é uma regra de política ou a firewall do host, não o endereço de bind.

Devo executar o Headscale em vez do servidor de coordenação do Tailscale?

Execute o Headscale quando o grafo de dispositivos ou a distribuição de chaves tiver de permanecer numa infraestrutura que controla, ou quando o tailnet tiver de funcionar sem depender de um serviço externo. Os clientes e o protocolo são os mesmos. O custo é passar a operar o servidor de coordenação. Se esse servidor ficar indisponível, deixa de ser possível adicionar novos nós e aplicar alterações à política. Numa fleet pequena, o plano de controlo alojado com o tailnet lock ativado costuma ser a melhor opção.