O Tailscale é seguro? Entenda o modelo de confiança

O Tailscale é seguro? A resposta curta

O Tailscale é seguro? Para a principal preocupação da maioria das pessoas, sim: o servidor de coordenação que executa a sua tailnet nunca armazena as chaves privadas que encriptam o seu tráfego, por isso não consegue ler o que os seus dispositivos enviam uns aos outros. A página de segurança do Tailscale afirma isso diretamente: "As chaves privadas nunca saem do dispositivo. Todo o tráfego é encriptado de ponta a ponta, sempre." A pergunta útil é outra. Um servidor de coordenação comprometido ou sujeito a uma ordem judicial não precisa de ler os seus pacotes. Ele decide em que chaves públicas os seus dispositivos confiam, por isso poderia registar um dispositivo que nunca aprovou.

Esse é o modelo de confiança numa frase: a encriptação protege os dados, e o plano de controlo decide quem pertence à rede. Cada secção abaixo identifica uma entidade em que tem de confiar, explica o que essa entidade pode realmente fazer e apresenta o controlo que limita essa capacidade. Se o produto ainda é novo para si, comece por o que é o Tailscale e como funciona a sua rede mesh.

O plano de controlo e o plano de dados são separados

O Tailscale é uma VPN mesh (rede privada virtual) baseada no WireGuard, o mesmo protocolo que configuraria manualmente num VPS WireGuard autogerido. Cada dispositivo gera localmente o seu próprio par de chaves WireGuard. O artigo como funciona do Tailscale chama ao servidor de coordenação «uma caixa de entrega partilhada para chaves públicas» e afirma: «A chave privada nunca, em circunstância alguma, sai do seu nó.»

O plano de dados é o tráfego encriptado entre os seus dispositivos. O tráfego percorre diretamente o caminho entre os dispositivos sempre que a rede o permite. O plano de controlo é tudo o resto: quais dispositivos pertencem à tailnet, que chave pública corresponde a cada dispositivo, a política de acesso, as definições de DNS e a lista de relays. O Tailscale fornece o plano de controlo como um serviço alojado. O plano de dados é executado nas suas próprias máquinas.

Mantenha os dois planos separados e todas as questões de segurança deste contexto tornam-se respondíveis. A encriptação é uma propriedade do plano de dados. A pertença é uma decisão do plano de controlo. Nenhum nível de encriptação lhe diz quem tem permissão para ser um peer.

O que um servidor de coordenação comprometido poderia fazer?

Não pode desencriptar o seu tráfego. As chaves que fazem a encriptação são geradas nos seus dispositivos e nunca são carregadas, portanto não há nada para apreender ou divulgar que permita abrir o túnel. Isto também se aplica ao tráfego retransmitido, abordado mais abaixo.

Poderia inscrever um nó. Quando a Tailscale anunciou o tailnet lock, a empresa descreveu o risco nas suas próprias palavras: um servidor malicioso poderia “usar um nó adicionado secretamente para enviar ou receber tráfego dos seus nós existentes” e, nesse momento, “não importaria que o tráfego estivesse encriptado, porque o próprio peer seria malicioso”. O seu dispositivo confia num peer porque o plano de controlo lhe disse que essa chave pertence à tailnet.

Poderia alterar os destinos que os seus dispositivos podem alcançar. A política de acesso reside no plano de controlo e é distribuída pelos nós. O white paper do tailnet lock da Tailscale afirma que o tailnet lock “não impede que um plano de controlo comprometido interrompa a conectividade na sua rede, por exemplo, ao não distribuir novas chaves de nós ou ao distribuir uma política de controlo de acesso que negue o acesso a todos os nós”.

Vê os metadados das ligações em qualquer caso. Os logs de fluxo de rede da Tailscale registam eventos de abertura e fecho para cada ligação entre máquinas. A documentação afirma que esses logs “não contêm rigorosamente qualquer informação sobre as operações dos clientes ou o conteúdo do tráfego de rede”. Portanto, o plano de controlo pode saber quais dos seus dispositivos comunicaram entre si e quando. Não sabe o que disseram.

Apenas um item dessa lista está relacionado com a encriptação. Os restantes dizem respeito a quem é membro e ao que a política permite, razão pela qual os controlos que merecem a sua atenção são os que regulam a inscrição.

O seu provedor de identidade é a raiz de confiança da tailnet

O Tailscale não mantém uma base de dados de palavras-passe própria. A documentação afirma claramente que não existem palavras-passe do Tailscale e que o início de sessão é delegado a um provedor de identidade (IdP): Apple, Google, GitHub, Microsoft, Okta, OneLogin ou um provedor OpenID Connect personalizado.

Interprete isto como uma declaração de segurança, porque é exatamente isso. Quem conseguir iniciar sessão na sua conta Google ou Microsoft conseguirá iniciar sessão na sua tailnet. A sua autenticação multifator (MFA) é a que o IdP impõe. O seu processo de remoção de acessos é o que o IdP executa quando uma pessoa sai da organização. Uma conta do IdP comprometida por phishing torna-se uma conta da tailnet, e o atacante não precisa de atacar o WireGuard: basta adicionar um dispositivo e herdar tudo o que a sua política concede a esse utilizador.

Dois controlos ficam entre uma conta de identidade roubada e um dispositivo funcional dentro da sua tailnet: aprovação do dispositivo e expiração da chave. O bloqueio da tailnet é um terceiro controlo e atua no plano de controlo, não na conta.

Aprovação de dispositivos: nada entra até alguém autorizar

A documentação do Tailscale descreve a aprovação de dispositivos como uma funcionalidade que “permite aos administradores da rede Tailscale rever e aprovar novos dispositivos antes de estes poderem entrar na sua rede Tailscale”. Um Owner, Admin ou administrador de IT pode aprovar. Um dispositivo novo apresenta o indicador “Needs approval” na página Machines até alguém agir.

Ative esta funcionalidade e o cenário de uma conta roubada muda. O atacante inicia sessão, o dispositivo é registado e fica à espera, sem conseguir aceder a nada, ao lado de um indicador na consola de administração que informa que uma máquina desconhecida está a pedir para entrar. A automatização continua a funcionar, porque uma auth key pode ser marcada como pré-aprovada quando é gerada, e os dispositivos podem ser aprovados através da API.

As auth keys são a outra forma de entrada, por isso devem ser tratadas como credenciais. A documentação do Tailscale é clara quanto ao tipo de maior risco: “Tenha muito cuidado com chaves reutilizáveis! Podem ser muito perigosas se forem roubadas. O melhor é guardá-las num produto de cofre de chaves concebido especificamente para esse fim.” Em agosto de 2026, o intervalo documentado para a expiração das chaves é de 1 a 90 dias, e uma expiração não especificada usa o máximo de 90 dias. Prefira chaves de utilização única, marque-as como ephemeral para máquinas temporárias e mantenha qualquer chave reutilizável encriptada com o Ansible Vault ou num gestor de secrets, em vez de a guardar num shell script.

Expiração de chaves: o temporizador que limita todos os outros erros

As chaves dos nós expiram, o que transforma um dispositivo roubado ou esquecido num problema temporário. A documentação do Tailscale afirma que, “por predefinição, os novos domínios são configurados com um período de expiração de 180 dias” e que, “se não ocorrer uma nova autenticação, as chaves expiram e as ligações de e para o endpoint indicado deixam de funcionar”. Pode voltar a autenticar um dispositivo manualmente:

tailscale up --force-reauth

A documentação avisa que isto “pode interromper a ligação do tailnet e, por isso, não deve ser feito remotamente através de SSH ou RDP sem um método alternativo de início de sessão caso a ligação seja perdida”. Execute o comando com acesso à consola aberto ou através de um segundo caminho para a máquina, porque está prestes a interromper a rede que está a utilizar.

É nos servidores que este controlo costuma ser alterado. Uma máquina que tenha de voltar a autenticar-se a cada 180 dias ficará desligada do tailnet às 3 da manhã, quando ninguém estiver a monitorizar, pelo que os administradores desativam a expiração das chaves. Isso remove o temporizador que acabaria por invalidar uma chave roubada. Para um servidor, um dispositivo identificado por uma tag é uma opção melhor, porque a tag associa a máquina em vez de uma pessoa, permitindo que a máquina continue a funcionar quando essa pessoa sair da empresa. Seja qual for a decisão, mantenha uma lista das máquinas que têm a expiração desativada: essas chaves continuam válidas até o dispositivo ser eliminado.

Tailnet lock: retirando o servidor de coordenação da cadeia de confiança

O Tailnet lock ataca diretamente o problema do registo de dispositivos. A documentação do tailnet lock do Tailscale explica o mecanismo: "Quando um novo nó entra no tailnet, a respetiva chave pública de nó requer uma assinatura de uma chave do Tailnet Lock. O servidor de coordenação distribui a chave pública de nó assinada pelos nós pares." Os dispositivos existentes verificam essa assinatura antes de aceitarem um peer. Por isso, uma chave de nó que o plano de controlo tenha criado por conta própria é recusada.

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init ativa a funcionalidade, e é nesse momento que indica os nós de assinatura. O Tailscale exige pelo menos dois nós de assinatura na inicialização e permite no máximo 20 num tailnet. Depois disso, cada novo dispositivo precisa de uma assinatura de um deles. Isto cria um custo operacional real: adicionar um telemóvel implica executar um comando num portátil.

As limitações estão documentadas e são mais importantes do que a descrição da funcionalidade:

• Perca o segredo de desativação e não existe recuperação. A documentação afirma: "Se perder os seus segredos de desativação e não tiver fornecido um deles ao suporte do Tailscale, o tailnet não poderá ser recuperado."
• A chave de assinatura fica num dispositivo que controla, por isso herda a segurança desse dispositivo. A documentação é explícita: "Se o dispositivo for comprometido, a chave pode ser obtida."
• Não pode executar os dois controlos em simultâneo. O Tailscale afirma que o tailnet lock e a aprovação de dispositivos são mutuamente exclusivos. Ativar um implica abdicar do outro.
• É um modelo de confiança na primeira utilização (TOFU). A configuração inicial continua a passar pelo plano de controlo. A âncora de confiança só passa para a sua própria rede depois desse primeiro passo.

O Tailnet lock protege a adesão ao tailnet. Não protege a disponibilidade, e o white paper afirma isso.

Uma ligação retransmitida expõe o meu tráfego?

Não. Quando dois dispositivos não conseguem comunicar diretamente, o tráfego passa por um servidor DERP (Designated Encrypted Relay for Packets). A documentação do Tailscale descreve esta propriedade de forma clara: "Como as chaves privadas do Tailscale nunca saem do dispositivo local que as gerou, é impossível que um servidor DERP desencripte o seu tráfego. Um servidor DERP encaminha cegamente tráfego já encriptado de um dispositivo para outro."

Um relay reduz a velocidade e observa metadados: dois endpoints encriptados, além do momento e do volume dos dados que passam entre eles. Descubra que tipo de ligação tem:

tailscale status
tailscale netcheck

tailscale status marca cada peer como direto, apresentado como direct 203.0.113.10:41641, ou retransmitido, apresentado como relay seguido do nome do relay e dos contadores de bytes. Um peer que permanece num relay indica que os dois extremos não conseguiram estabelecer um caminho direto, normalmente porque o UDP está bloqueado em algum ponto ou porque ambos estão atrás de NAT restrito (network address translation). tailscale netcheck indica se o UDP funciona nessa máquina, como o NAT mapeia as portas e qual é a latência até aos relays mais próximos. Estes dados mostram qual das duas causas está a ocorrer.

Um nó de saída desloca o ponto de saída; não o elimina

Um nó de saída encaminha todo o tráfego público de Internet de um dispositivo através de outro dispositivo na tailnet, usando as rotas predefinidas 0.0.0.0/0 e ::/0. No Linux, a máquina que disponibiliza o serviço anuncia-o, e cada cliente opta por utilizá-lo:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

Um nó de saída tem de ser aprovado por um Owner, Admin ou Network admin na consola de administração, e a sua política tem de conceder autogroup:internet antes de um cliente poder utilizá-lo. Ambos os passos são deliberados: uma máquina não aprovada não pode tornar-se silenciosamente a saída de toda a sua tailnet.

Agora, a questão da confiança. O tráfego é encriptado entre o seu portátil e o nó de saída. Depois, sai dessa máquina como tráfego normal de Internet e transporta o endereço IP dessa máquina. Por isso, o operador do nó de saída vê os seus destinos. O mesmo acontece com o fornecedor de alojamento dessa máquina e com a rede a montante. Deslocou o ponto de observação, em vez de o eliminar. Isto é uma boa troca quando controla a outra extremidade, que é o argumento para executar o seu próprio nó de saída numa VPS, e uma má escolha quando não controla.

A política padrão é uma rede plana

Uma tailnet nova é criada com permissões amplas. A documentação de controlo de acesso do Tailscale diz que o ficheiro de política padrão “ativa a comunicação entre todos os dispositivos dentro da tailnet”. Cada dispositivo pode alcançar todos os outros dispositivos em todas as portas. Isso é uma rede plana. Colocá-la dentro do túnel ajuda contra agentes externos, mas não protege contra um portátil que seja infetado.

Restrinja o acesso no ficheiro de política da tailnet. O ficheiro aceita listas de controlo de acesso (ACLs) ou as grants mais recentes. Ambas usam um dialeto JSON que permite comentários:

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

Essa política permite que um grupo aceda por SSH aos servidores de produção, permite que os membros utilizem um exit node e bloqueia todo o restante por omissão. O Tailscale indica quais alvos de regras estão disponíveis em cada plano. Consulte essa informação antes de criar uma configuração baseada em tags ou autogroups e veja o que o plano gratuito inclui efetivamente. Para um dispositivo que nunca deve aceitar ligações de entrada, como um telemóvel pessoal, tailscale set --shields-up bloqueia essas ligações no cliente.

O que muda ao alojar o control plane com Headscale

Headscale é uma "implementação open source e self-hosted do servidor de controlo do Tailscale". O README define o âmbito de forma clara: "Implementa um âmbito restrito, uma única rede Tailscale (tailnet), adequada para uso pessoal ou para uma pequena organização open source." A lista de funcionalidades inclui ACLs e grants, subnet routers, exit nodes, um servidor DERP integrado, Tailscale SSH e Taildrop. Se esse âmbito restrito for o fator decisivo, o NetBird é a outra mesh que disponibiliza um control plane self-hostable, e executar o servidor NetBird na sua própria VPS transfere a mesma decisão de inscrição para hardware que lhe pertence.

O que muda é a identidade da entidade que poderia inscrever um node malicioso. Com o Headscale, o diretório de chaves e a política ficam no seu servidor. Nenhum terceiro guarda a lista das chaves públicas dos seus dispositivos, e nenhum terceiro pode ser obrigado a entregar uma dessas chaves ou a assinar uma chave.

O que não muda é o data plane. Continua a ser o mesmo WireGuard, com a mesma encriptação end-to-end e o mesmo fallback para relay quando não é possível estabelecer um caminho direto. Também passa a ter de assegurar as tarefas que o Tailscale executava: disponibilidade, aplicação de patches, backups e segurança física do equipamento. Um host Headscale comprometido dá a um atacante exatamente o que daria um servidor de coordenação comprometido: a capacidade de inscrever um node e distribuir políticas. Tailnet lock não faz parte da lista de funcionalidades do Headscale, por isso esse controlo compensatório para esse risco específico não está disponível. Se a questão da posse for a que determina a sua decisão, alojar o control plane com Headscale explica o processo de configuração.

O que o Tailscale protege

• Portas públicas em escuta. Um serviço associado a um endereço da tailnet não pode ser acedido a partir da Internet. Por isso, os scanners que contactam todas as VPS na porta 22 nunca o encontram. A exceção é ativada por si, porque o Funnel publica deliberadamente um serviço da tailnet na Internet pública. Por isso, convém saber onde termina o serve e começa o funnel antes de executar qualquer um dos comandos. Mantenha o firewall do host mesmo assim, porque uma porta Docker publicada cria as suas próprias regras e contorna o ufw na interface pública.
• Tentativas de adivinhar palavras-passe contra logins expostos. Não há nada para testar em massa quando a porta só responde dentro do túnel. Isto é mais seguro do que aplicar limitação de taxa numa porta aberta. Ainda assim, o fail2ban no Ubuntu 24.04 continua a ser útil em qualquer serviço que tenha de permanecer público.
• Redes não confiáveis no caminho. O tráfego entre as suas máquinas é encriptado de ponta a ponta através da rede de um café ou da LAN partilhada de um fornecedor. Também permanece encriptado quando é encaminhado por um relay.
• Distribuição manual de chaves. Cada peer adicionado manualmente a uma configuração WireGuard é uma oportunidade para reutilizar um endereço ou colar a chave errada. A malha trata dessa gestão por si. Esta é a principal diferença prática em WireGuard face ao Tailscale.

O que o Tailscale não protege

• Um endpoint comprometido. A tailnet confia nos dispositivos. Um malware num portátil aprovado obtém o túnel, os endereços da tailnet e tudo o que a sua política concede a esse utilizador. Esta é a maior lacuna, e nenhuma VPN a elimina.
• Um administrador mal-intencionado ou descuidado. Qualquer pessoa que possa editar o ficheiro de política pode conceder a si própria acesso a qualquer recurso. Qualquer pessoa que consiga assumir a conta de identidade de um Owner pode fazer o mesmo. Reveja as alterações à política da mesma forma que revê código.
• Análise de tráfego. O seu ISP (internet service provider) vê tráfego UDP encriptado para um endpoint, além dos tempos e do volume. Os logs de fluxo do Tailscale mostram quais peers comunicaram e quando. Nenhum deles vê o conteúdo, mas o facto de existir uma ligação não fica oculto. Leia como o Tor e uma VPN diferem antes de escolher uma ferramenta para essa finalidade.
• Um dispositivo que já perdeu. A expiração da chave é uma proteção de retaguarda lenta, com um padrão de 180 day. Remover o dispositivo na consola de administração é a opção rápida. Saiba onde fica esse botão antes de precisar dele.

Verifique a sua própria tailnet

1. Execute tailscale status num dispositivo e leia a lista de pares. Uma máquina que não consegue identificar é precisamente a situação que a aprovação de dispositivos existe para impedir.
2. Execute tailscale lock status para verificar se o tailnet lock está ativado. Depois, decida se o custo de assinar cada dispositivo novo compensa para a sua tailnet.
3. Abra a consola de administração e registe todas as máquinas com a expiração de chaves desativada, além de todas as chaves de autenticação reutilizáveis que ainda existam. Ambos são credenciais sem prazo de expiração.
4. Leia o seu ficheiro de políticas. Se ainda for o ficheiro predefinido, todos os dispositivos podem alcançar todos os outros dispositivos em todas as portas. Um portátil infetado consegue então alcançar todos os restantes.

A reputação da Tailscale é sobretudo conquistada no plano de dados, onde o design não dá ao operador qualquer forma de ler o seu tráfego. Considere essa afirmação conforme documentada pelo fornecedor e audite depois as partes que lhe pertencem: as contas de identidade, a definição de aprovação, a lista de expiração e o ficheiro de políticas. A página de segurança da Tailscale indica uma certificação SOC 2 Type II e trabalho contínuo de segurança com a Latacora. Isso é uma evidência sobre o processo da empresa, não uma afirmação sobre a sua configuração.

FAQ

O Tailscale pode ler o meu tráfego?

Não. O tráfego é cifrado com chaves WireGuard geradas nos seus dispositivos, e a página de segurança do Tailscale afirma que "as chaves privadas nunca saem do dispositivo. Todo o tráfego é cifrado de ponta a ponta, sempre." Isto também se aplica às ligações que usam um relay DERP, porque o relay "encaminha cegamente tráfego já cifrado de um dispositivo para outro" e não possui nenhuma chave que lhe permita decifrá-lo. O que a infraestrutura do Tailscale consegue ver são metadados: que dispositivos existem, quais se ligaram entre si e quando.

O que poderia fazer efetivamente um servidor de coordenação Tailscale comprometido?

Poderia inscrever um nó. O anúncio do tailnet lock do próprio Tailscale descreve o risco de um nó adicionado secretamente poder "enviar ou receber tráfego dos seus nós existentes", situação em que a cifragem não ajuda "porque o próprio peer seria malicioso". Um plano de controlo comprometido também poderia distribuir uma política que alterasse os recursos a que os seus dispositivos têm acesso. O white paper do tailnet lock indica ainda que poderia interromper a conectividade ao deixar de distribuir novas chaves de nós. O que não poderia fazer seria decifrar o tráfego entre os seus dispositivos existentes, porque nunca teve as respetivas chaves privadas.

Um nó de saída oculta a minha navegação do meu ISP?

Oculta os destinos da rede onde está ligado, incluindo o ISP de sua casa ou do café, porque tudo sai do seu dispositivo como tráfego cifrado endereçado ao nó de saída. Não o torna anónimo. O nó de saída passa a ver esses destinos, tal como o respetivo fornecedor de alojamento e a rede upstream, enquanto os sites que visita veem o endereço IP do nó de saída. Escolheu um observador diferente, por isso escolha um em que realmente confie.

O Headscale é mais seguro do que o servidor de coordenação do Tailscale?

É uma decisão de confiança diferente, não uma opção necessariamente mais segura. Com o Headscale, mantém o diretório de chaves e a política, pelo que nenhuma entidade externa pode ser obrigada a inscrever um dispositivo no seu tailnet. Também passa a ser responsável pela execução desse servidor: atualizações, disponibilidade, cópias de segurança e segurança do próprio host. Um host Headscale comprometido dá a um atacante o mesmo poder de inscrição que um servidor de coordenação comprometido teria. Além disso, o tailnet lock não faz parte da lista de funcionalidades do Headscale, por isso proteja esse host em conformidade.

Ainda preciso de uma firewall num VPS que está no meu tailnet?

Sim. A interface de rede pública continua a existir, e qualquer serviço associado a 0.0.0.0 permanece acessível a partir da internet, esteja ou não o Tailscale em execução. Associe os serviços ao endereço do tailnet, mantenha uma política de negação por predefinição na interface pública e verifique as portas publicadas dos seus contentores, porque o Docker insere as próprias regras e pode expor uma porta que julgava estar fechada.