WireGuard, Tailscale ou Headscale: qual escolher?

WireGuard vs Tailscale: a resposta curta

WireGuard vs Tailscale não é uma escolha entre dois protocolos, porque o Tailscale é WireGuard. O Tailscale usa a mesma encriptação e o mesmo túnel e acrescenta um plano de controlo: um servidor de coordenação que troca chaves públicas, atribui endereços, atravessa NAT (network address translation) e aplica uma política de acesso. Está a escolher quanto dessa coordenação quer gerir por si próprio.

Há três respostas honestas. Use WireGuard simples quando tem um servidor e um pequeno número de clientes que estabelecem ligação com ele. Use Tailscale quando quer que todas as máquinas alcancem todas as outras sem manter um ficheiro de configuração. Use Headscale quando quer essa malha, mas não quer que um terceiro mantenha a lista de nós.

O que o control plane oferece na prática

O WireGuard puro não tem descoberta. Cada peer é um bloco de texto escrito manualmente: uma chave pública, uma linha AllowedIPs e um Endpoint se esse peer for alcançável. Adicionar uma máquina a uma rede com dez máquinas significa editar dez ficheiros de configuração, porque cada lado precisa da chave do outro. É por isso que quase todas as configurações de WireGuard autoalojadas usam uma topologia hub-and-spoke: um servidor com um IP público e clientes que comunicam exclusivamente com ele.

Um control plane elimina essa edição manual. Cada nó regista-se uma vez, recebe um endereço do intervalo 100.64.0.0/10 CGNAT (carrier grade NAT) e recebe as chaves públicas dos nós aos quais pode aceder. O túnel continua a ser uma ligação WireGuard direta entre dois peers, e o seu tráfego nunca passa pelo servidor de coordenação. O servidor transporta apenas metadados: quais nós existem, qual chave pertence a cada um e quem pode comunicar com quem.

Isto produz três resultados concretos.

Travessia de NAT. Dois portáteis atrás de dois routers domésticos não têm um IP público que permita a comunicação direta. O Tailscale usa STUN (session traversal utilities for NAT) para descobrir o endereço e a porta externos de cada lado. Depois, ambos enviam pacotes ao mesmo tempo, para que cada router veja primeiro um fluxo de saída e aceite a resposta. Quando isso falha, o tráfego recorre a um relay DERP, que é um relay cifrado operado pelo Tailscale. Os seus dados continuam cifrados de ponta a ponta através do relay, porque o relay nunca tem acesso às chaves. Execute tailscale status e a linha de cada peer indicará direct ou relay. Execute tailscale netcheck para ver qual relay está mais próximo e se a sua rede permite UDP.

Rotação de chaves com expiração. As chaves do WireGuard nunca expiram. Uma chave emitida há três anos continua a funcionar indefinidamente, a menos que elimine manualmente o bloco do peer. O Tailscale faz expirar as chaves dos nós. Em julho de 2026, o período de expiração predefinido numa nova tailnet é de 180 dias. Uma máquina que não volte a autenticar-se deixa de estabelecer ligações. Pode desativar a expiração por dispositivo para um servidor ou um router de sub-rede no qual ninguém estará disponível para iniciar sessão.

Políticas em vez de encaminhamento. No WireGuard puro, AllowedIPs é simultaneamente a tabela de encaminhamento e a lista de controlo de acesso. Por isso, a regra "alice pode aceder à base de dados" tem de ser expressa como um intervalo de IPs. O Tailscale mantém um ficheiro de políticas separado, no qual as regras identificam utilizadores, grupos e tags. Uma regra pode indicar que tag:laptop pode aceder a tag:db na porta 5432 e a mais nada. Essa regra mantém-se mesmo que uma máquina receba um novo endereço.

O custo do plano de controlo

O servidor de coordenação conhece a sua rede. Guarda a chave pública de cada nó, o nome de cada nó, os endereços atribuídos e a política. Com o Tailscale alojado, esse servidor pertence a uma empresa fora do seu controlo. Os seus pacotes não são legíveis para essa empresa, porque as chaves privadas WireGuard permanecem nas suas máquinas. No entanto, a topologia da sua rede fica visível para ela, e a sua capacidade de estabelecer ligações depende de o serviço estar disponível e de a sua conta estar em situação regular. A importância deste risco depende do que um servidor de coordenação comprometido ou uma conta de identidade roubada poderia realmente fazer com os dados que possui. Por isso, vale a pena ler na íntegra o modelo de confiança do Tailscale.

Existe um segundo custo que é fácil não considerar. O Tailscale é um daemon em cada máquina. Por isso, passa a ser necessário manter o software atualizado e corrigido em todas as máquinas. O WireGuard simples no Ubuntu 24.04 é um módulo do kernel fornecido pela distribuição e atualizado juntamente com o kernel.

O terceiro custo é a faturação. Em julho de 2026, o plano Personal é gratuito e permite dispositivos ilimitados para até 6 utilizadores, o Standard custa $8 por utilizador por mês e o Premium custa $18 por utilizador por mês. Um agregado familiar continua a usar o serviço gratuitamente. Uma equipa de dez pessoas não. A passagem desse limite depende do número de utilizadores, não do número de dispositivos. Por isso, vale a pena ler o que o plano gratuito realmente inclui antes de convidar o sétimo utilizador.

Quando o WireGuard simples é a escolha certa

Escolha o WireGuard simples quando a topologia for realmente hub-and-spoke. Um VPS com um IP público, três ou quatro dispositivos que se ligam a ele e nenhuma necessidade de esses dispositivos comunicarem entre si. A configuração cabe num ecrã, não há nenhum daemon para atualizar, nenhuma conta que possa perder e nenhum serviço externo entre si e o servidor.

Também é a escolha certa quando quer compreender a camada sobre a qual tudo o resto é construído. Alojar uma VPN WireGuard num VPS explica a geração de chaves, wg0.conf, o encaminhamento IP, o NAT e as falhas do handshake. Todos esses mecanismos continuam a funcionar por baixo de uma tailnet. Se ainda estiver a considerar a opção mais antiga, WireGuard vs OpenVPN apresenta os quatro casos em que o OpenVPN mantém uma vantagem.

A instalação é curta:

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

O WireGuard simples deixa de ser prático assim que todos os dispositivos têm de alcançar todos os outros. Uma malha completa com N nós precisa de N vezes N menos um blocos de peers. Com seis dispositivos, são trinta blocos que têm de ser mantidos manualmente em sincronia. Uma entrada AllowedIPs duplicada desvia silenciosamente o tráfego do peer que a tinha primeiro, sem apresentar qualquer erro.

Quando Tailscale é a escolha certa

Escolha Tailscale quando as máquinas mudam de rede. Portáteis em redes de hotéis, um telemóvel em dados móveis ou um servidor doméstico atrás de um router que não controla. Estes são precisamente os casos que o WireGuard simples trata mal, porque nenhum dos lados tem um endpoint público estável para colocar em Endpoint.

A instalação do cliente é feita com um comando do instalador oficial:

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

tailscale up imprime um URL. Abra-o, inicie sessão e a máquina entra na rede. Não há nenhuma chave para copiar nem nenhuma porta de entrada para abrir, porque o daemon estabelece uma ligação de saída ao servidor de coordenação e mantém-na aberta. É também por isso que um nó Tailscale funciona numa rede em que não controla firewall nenhuma.

Depois disso, duas definições fazem a maior parte do trabalho útil. Um router de sub-rede anuncia uma LAN inteira na rede, para que não tenha de instalar o cliente em todos os dispositivos:

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
sudo tailscale set --advertise-routes=192.0.2.0/24

A rota permanece inativa até ser aprovada na consola de administração. Isto é intencional: um nó não pode injetar uma rota na sua rede por iniciativa própria. Os clientes Linux também precisam de sudo tailscale set --accept-routes, porque o Linux não aceita rotas anunciadas por predefinição. Por isso, uma rota que parece aprovada no lado do servidor continua sem efeito num portátil Linux até definir essa opção. Se é esse o cenário pretendido, executar um router de sub-rede num VPS explica o processo de aprovação e as definições de encaminhamento na ordem que evita uma rota parcialmente funcional.

Um nó de saída envia todo o tráfego de um cliente através de uma máquina, que é o comportamento de túnel completo normalmente associado a "uma VPN":

sudo tailscale set --advertise-exit-node

Essa flag é a parte simples. transformar um VPS num nó de saída explica o que vem depois: aprovar a rota na consola de administração e corrigir o comportamento de DNS e IPv6 que, de outro modo, faz com que o tráfego saia pelo caminho errado. Se pretende aceder a um único serviço Web em vez de uma rede inteira, serve e funnel coloca HTTPS à frente de uma única porta local, apenas na tailnet ou aberta à Internet pública.

Quando o Headscale é a escolha certa

O Headscale é uma implementação open source do servidor de coordenação e é executado numa VPS que lhe pertence. Os clientes oficiais do Tailscale ligam-se a ele em vez de utilizarem o serviço alojado:

sudo tailscale up --login-server https://headscale.example.com

Tudo o que diz respeito ao caminho dos dados permanece igual. Continua a ser WireGuard e continua a existir ligação direta entre pares quando a rede o permite. O que muda é que a lista de nós, as chaves e a política ficam num ficheiro SQLite num disco que lhe pertence. Ninguém no exterior pode ver a topologia da sua rede, desativar a sua conta ou cobrar-lhe por utilizador.

A contrapartida exige trabalho real. Passa a gerir um serviço HTTPS público, o que implica um nome DNS, um certificado e um reverse proxy que encaminhe corretamente as atualizações para WebSocket. A disponibilidade passa a ser da sua responsabilidade, e um servidor de coordenação indisponível impede o registo de novos nós e impede que os nós existentes tomem conhecimento de alterações. O Headscale também está abaixo da versão 1.0, e as versões minor têm incluído alterações incompatíveis, por isso consulte o changelog antes de cada atualização. Executar o Headscale como o seu próprio servidor de controlo do Tailscale aborda a instalação, config.yaml, as chaves de pré-autenticação e as portas que deve abrir.

Há uma limitação que muitas pessoas só percebem tarde. O Headscale não inclui a rede global de relays do Tailscale. Quando dois pares não conseguem estabelecer uma ligação direta, tem de ativar o relay integrado no seu próprio servidor ou indicar outro na configuração. Esse relay fica num único servidor, numa única região, em vez de estar distribuído por uma frota mundial. Os pares que estão do outro lado do planeta sentem essa diferença. Se preferir não montar essa componente, alojar o NetBird localmente é a outra forma de manter o plano de controlo na sua infraestrutura, porque o quickstart inicia em conjunto os serviços de gestão, sinalização e relay numa única VPS.

Como decidir de uma só vez

Pergunte quantas máquinas precisam de comunicar entre si. Se a resposta for que todas apenas comunicam com o servidor, o WireGuard simples é uma solução com menos software para obter o mesmo resultado.

Pergunte se as máquinas têm endereços públicos estáveis. Se a maioria estiver atrás de NAT que não controla, precisa de um plano de controlo, porque atravessar NAT é a parte difícil e não vale a pena recriá-la.

Pergunte quem pode conhecer a topologia da sua rede. Se a resposta excluir empresas externas, ou se o número de utilizadores tornar a faturação por utilizador demasiado onerosa, execute o Headscale e aceite que passará a operar o servidor de controlo. Se a faturação for o fator decisivo, faça as contas antes de iniciar a migração, porque o que uma equipa do seu tamanho realmente paga depende de quantas pessoas têm contas, e não de quantas máquinas executa, e esses dois números raramente são próximos.

Pode mudar de decisão sem grandes custos. Como o plano de dados usa o mesmo protocolo nos três casos, passar do WireGuard simples para uma rede mesh coordenada exige apenas instalar o cliente, e passar do Tailscale para o Headscale exige voltar a registar cada nó noutro servidor de início de sessão.

O que nenhum dos três oferece

Nenhum dos três é uma firewall. Um túnel decide que pacotes são transportados, não que serviços ficam à escuta. Um servidor acessível pelo túnel continua acessível pela Internet em qualquer porta que tenha deixado aberta. Por isso, mantenha as regras da firewall UFW no VPS a funcionar. O ficheiro de políticas do Tailscale restringe o que outros nós podem alcançar, mas não controla a interface pública.

Nenhum dos três fornece autenticação por serviço. Nenhum dos três cria um registo de auditoria das ações de um utilizador depois de este se ligar. Trate os três como mecanismos de transporte e coloque as verificações de início de sessão na aplicação.

FAQ

O Tailscale é apenas WireGuard com etapas adicionais?

O Tailscale usa o protocolo WireGuard para o caminho de dados, por isso a encriptação e o túnel são os mesmos. O que acrescenta é a coordenação: troca de chaves, atribuição de endereços, travessia de NAT com relays STUN e DERP, expiração de chaves e um ficheiro de políticas que identifica utilizadores em vez de intervalos de IP. No WireGuard simples, estas tarefas ficam a seu cargo. São também as tarefas que se tornam difíceis quando as máquinas mudam de rede.

O meu tráfego passa pelos servidores do Tailscale?

Normalmente, não. Depois de o servidor de coordenação apresentar os peers, estes ligam-se diretamente entre si, e tailscale status mostra direct nessas linhas dos peers. Quando não é possível estabelecer um caminho direto, o tráfego recorre a um relay DERP e a linha apresenta relay. Mesmo nesse caso, o relay transporta pacotes encriptados e não tem as suas chaves privadas do WireGuard, por isso não consegue ler o conteúdo. Execute tailscale netcheck para verificar se a sua rede está a bloquear o UDP necessário para as ligações diretas.

Posso usar o Headscale com as aplicações oficiais do Tailscale?

Sim. O Headscale utiliza o mesmo protocolo de controlo, por isso os clientes oficiais entram com sudo tailscale up --login-server https://headscale.example.com. Também pode indicar um servidor de início de sessão personalizado nas aplicações para desktop e dispositivos móveis, embora a definição esteja num local diferente em cada plataforma. As aplicações móveis são as que têm maior probabilidade de exigir uma versão específica. Teste primeiro um telemóvel antes de migrar uma rede inteira.

Continuo a precisar de abrir portas para o Tailscale ou o Headscale?

Um cliente Tailscale não precisa de nenhuma porta de entrada, porque inicia a ligação para o servidor de coordenação e mantém essa ligação aberta. Um servidor Headscale autoalojado precisa de portas de entrada: 443 para o protocolo de controlo, 80 se utilizar um desafio de certificado HTTP-01 e 3478/udp apenas quando ativar o relay integrado. O WireGuard simples precisa que a sua porta UDP de escuta, normalmente 51820, esteja aberta no servidor e em qualquer firewall de rede separada fornecida pelo seu provedor.

Qual dos três é mais rápido?

O débito é igual, porque os três transportam pacotes com WireGuard. A diferença surge no estabelecimento da ligação e na qualidade do caminho. O WireGuard simples, com um Endpoint correto, liga-se diretamente todas as vezes. O Tailscale e o Headscale ligam-se diretamente na maioria dos casos e recorrem a um relay quando a rede bloqueia a travessia de NAT, e um caminho através de relay acrescenta latência. Meça o seu próprio caminho com tailscale ping <node>, que indica se a rota é direta ou através de relay, ou com iperf3 através do túnel. Se esse valor ficar muito abaixo da velocidade da sua ligação num caminho direto, o problema não é a escolha entre os três. A causa habitual é uma incompatibilidade de MTU do caminho, que se comporta da mesma forma com ou sem um plano de controlo.