O que é o 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 esteja a executar. Cada nó executa WireGuard, por isso os pacotes viajam cifrados de um servidor para outro e nenhum sistema no caminho consegue lê-los. Um servidor de coordenação alojado trata das apresentações entre os nós. Armazena e distribui chaves públicas e informa cada nó sobre a localização dos restantes. Também envia para os nós as regras de acesso que definiu.

Essa separação é a base de todo o desenho. O plano de dados é ponto a ponto e cifrado 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 mais delicadas sobre confiança, resultam destes dois factos. Se já criou uma VPN WireGuard manualmente num VPS, o Tailscale fornece esse mesmo túnel, mas trata da distribuição de chaves e da travessia de firewalls por si.

Como funciona o Tailscale?

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

1. O daemon tailscaled inicia, gera um par de chaves WireGuard e mantém o estado em /var/lib/tailscale/tailscaled.state. A chave privada permanece nessa máquina. A formulação do próprio Tailscale é direta: "a chave privada nunca, em circunstância alguma, sai do seu nó."
2. O nó inicia sessão no servidor de coordenação e envia a sua chave pública, além dos endereços pelos quais acredita que pode ser alcançado. O Tailscale descreve esse servidor como "uma caixa de depósito partilhada para 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 que este nó pode alcançar.
4. Cada par de nós tenta então criar entre si um túnel WireGuard direto. Quando isso falha, encaminha os pacotes através de um relay.

Cada nó recebe um endereço estável de 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 à infraestrutura de fornecedores, pelo que raramente entra em conflito com os endereços privados que os seus servidores já utilizam. No Linux, o túnel aparece como uma interface chamada tailscale0.

A implementação WireGuard funciona dentro de tailscaled no espaço de utilizador, e não no módulo do kernel. Por isso, o Tailscale arranca em ambientes de virtualização de contentores onde sudo modprobe wireguard falha com Operation not supported. Isto também significa que o limite de throughput numa determinada máquina é inferior ao do WireGuard no kernel. Este é um dos compromissos abordados em Tailscale em comparação com WireGuard simples.

Dois comandos mostram a situação atual.

tailscale ip -4
tailscale status

tailscale status imprime uma linha por nó, e a última coluna é a mais importante.

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. - 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 associada a cada nó, 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 nó esteve online pela última vez e o ficheiro de políticas que escreveu. Isto fornece um mapa completo da sua infraestrutura.

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 administrado por si, é considerado confiável para informar os seus nós sobre quais chaves públicas pertencem à tailnet. Esse é o ponto central do modelo de ameaças explicado mais adiante e o motivo pelo qual existe Headscale, um servidor de coordenação open source que pode alojar por si.

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. O seu VPS normalmente 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 build runner numa rede de escritório ou uma máquina atrás de uma firewall do fornecedor que não pode editar.

O Tailscale encontra um caminho usando 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 um para o outro 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 firewall de entrada.

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 comunicar com os servidores de relay 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 portas de entrada, embora, numa rede com NAT difícil, 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 efetivamente 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 para cada destino. Nesse caso, a previsão de endereço acima não funciona e esses nós normalmente permanecem retransmitidos.

Quando o Tailscale usa um relay DERP

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

Os pacotes continuam encriptados. O Tailscale afirma 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 node 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 muda para um caminho direto assim que os dois nodes se encontram. Pode observar esse processo.

tailscale ping db-1

As primeiras respostas regressam através de via DERP(fra). Mais tarde, outra linha indica algo como via 198.51.100.24:41641. Essa alteração corresponde à mudança para um túnel direto. Se 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. Se o que observou foram transferências lentas, e não uma ligação interrompida, porque uma ligação Tailscale através de relay é muito mais lenta do que uma ligação direta mede a diferença e mostra como colocar um VPS num caminho direto.

Associar uma VPS à sua tailnet

O script de instalação é compatível com 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 arrancar após um reboot, porque essa é a etapa 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 por um script, um URL interativo não é útil. Gere uma chave de autenticação na consola de administração e passe-a juntamente 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 uma tag pertence à tag, e não à pessoa que executou o comando. Por isso, 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 atribuição de uma tag 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 realmente inclui explica os limites aplicáveis.

Duas definições são 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 escolha Disable Key Expiry nos servidores sem supervisão. O MagicDNS, ativado por predefinição para tailnets criadas em ou após 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 mesmo nome.

Se a instalação falhar no apt ou no repositório, os erros comuns de instalação do Tailscale no Ubuntu explica as correções. Se a máquina que está a adicionar for um PC com Windows, o Tailscale deixa de funcionar por predefinição quando a sessão do utilizador termina, e o que ajustar no Tailscale para Windows depois de instalar explica o modo unattended, a expiração da chave e a regra da firewall para o ping.

Aceder a um serviço ligado a localhost

É aqui que uma tailnet se torna útil e onde surgem mais problemas. A entrada na 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 é 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 reset TCP. O cliente mostra Connection refused. O túnel está a funcionar. O problema está no listener.

Existem duas soluções corretas. Ligue o serviço ao endereço da tailnet do nó. Assim, o serviço continua fora da interface pública e não precisa de um proxy: 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 à sua frente.

tailscale serve 3000

Isto encaminha os pedidos para http://127.0.0.1:3000 e disponibiliza-os dentro da sua tailnet através de um nome ts.net em HTTPS, depois de ativar os certificados HTTPS para a tailnet. O serviço continua privado e acessível apenas aos seus nós. A versão pública da mesma funcionalidade é o Funnel. Tailscale serve e funnel explica qual deve utilizar.

Duas tarefas relacionadas têm páginas próprias. Para aceder a uma rede privada inteira onde o Tailscale não está instalado, precisa de um router de sub-rede numa VPS. Para encaminhar o tráfego de saída de um nó para a Internet através de outro nó, precisa de um exit node. Se o dispositivo que quer ligar for uma televisão que reproduz conteúdo de um Jellyfin na VPS, que smart TVs conseguem executar o Tailscale indica os modelos compatíveis e explica porque é que um router de sub-rede não resolve esse caso.

Fechar as portas que já não são necessárias

Quando todos os administradores conseguirem aceder ao servidor através da tailnet, a porta pública 22 já não terá 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 numa segunda sessão que consegue iniciar sessão através dela 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, pelo que o ficheiro de políticas do Tailscale passa a ser o controlo de 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, pelo que um ufw deny não a fecha. As portas publicadas pelo Docker contornam o ufw explica o mecanismo. Publicar na interface da tailnet, como acima, evita esse problema. Se a aplicação for executada com Docker Compose, um sidecar do Tailscale na stack do Compose vai mais longe e elimina totalmente a porta publicada, deixando o contentor acessível apenas através do respetivo nome na tailnet.

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

É importante dizer isto claramente, porque a versão de marketing confunde 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 sondar. 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 horários em que estão online descrevem a sua infraestrutura. O servidor também distribui chaves, o que representa um risco maior. O Tailscale afirma-o diretamente: "Se o Tailscale fosse malicioso e inserisse furtivamente 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á determinado pelo que a sua política permitir. A avaliação desse risco 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.

Há 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 plano de controlo 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 plano de controlo por sua conta. Um servidor de coordenação Headscale alojado por si usa o mesmo protocolo com os mesmos clientes, transferindo o grafo dos dispositivos e a distribuição de chaves para hardware que lhe pertence. Também passa a ser responsável pela disponibilidade desse servidor. Se ainda estiver a comparar planos de controlo alojados por si em vez de escolher este, o NetBird é uma VPN mesh separada cujo servidor é executado integralmente por si numa VPS.

Há uma predefinição para corrigir no primeiro dia. Um tailnet novo é disponibilizado com permissões abertas: "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 por predefinição, e apenas as suas regras permitem o acesso.

{
  "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 com tags, e a mais nada. Adicione uma regra por serviço em vez de deixar o wildcard, porque o wildcard significa que a chave de um portátil roubado permite alcançar a sua base de dados.

Modos de falha e mensagens apresentadas

tailscale status indica sempre relay. Os dois nós nunca estabeleceram um caminho direto. Execute tailscale netcheck nas duas extremidades. UDP: false significa que o tráfego UDP de saída está bloqueado, por isso só pode funcionar através de um relay. MappingVariesByDestIP: true significa que existe um NAT restritivo no caminho, e permitir UDP 41641 de entrada 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 nessa máquina repõe o acesso. Desative a expiração de chaves nos servidores para evitar que o problema se repita.

Os peers estão listados, mas as ligações atingem o timeout. A conectividade está a funcionar e a política está a rejeitar o tráfego. Verifique a secção acls para encontrar uma regra que cubra esta origem, este destino e esta porta. Um pacote rejeitado é descartado sem resposta, razão pela qual ocorre 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. Algum componente substituiu /etc/resolv.conf, por isso as consultas nunca chegam ao stub resolver em 100.100.100.100. Verifique cat /etc/resolv.conf quanto a 100.100.100.100 e analise também o que mais escreve esse ficheiro na máquina. É o mesmo tipo de problema que a resolução DNS falha 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

Tailscale é uma VPN ou uma rede mesh?

As duas expressões estão corretas e descrevem camadas diferentes. Os túneis usam WireGuard, o que faz do Tailscale uma VPN. A topologia é mesh porque cada nó cria um túnel diretamente para cada nó com o qual comunica, em vez de enviar todos os pacotes através de um servidor central. O servidor de coordenação fica 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 indisponibilidade, deixam 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 desencriptar. O Tailscale vê metadados: nomes das máquinas, proprietários, chaves públicas, endereços dos endpoints e o momento em que cada nó está online. Também distribui chaves. Por isso, um servidor de coordenação comprometido poderia tentar inserir um nó que a sua frota passaria a considerar confiável. O tailnet lock impede isso ao exigir assinaturas dos seus próprios nós confiáveis. O Headscale elimina o plano de controlo alojado da arquitetura.

Preciso de abrir portas da firewall para o Tailscale?

Quase nunca é necessário abrir portas de entrada. A orientação do próprio Tailscale é que "na maior parte do tempo, 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 de entrada é opcional e apenas ajuda as ligações diretas a serem estabelecidas em redes com configurações problemáticas.

Por que motivo os outros nós não conseguem alcançar o 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 de loopback. O cliente recebe Connection refused. Configure o serviço para usar o endereço tailnet ou execute tailscale serve 3000 para fazer proxy. Se o listener já estiver em 0.0.0.0 e a ligação atingir o timeout 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. A indisponibilidade desse servidor impede a entrada de novos nós e a aplicação de alterações à política. Numa frota pequena, o plano de controlo alojado com o tailnet lock ativado costuma ser a melhor opção.