A Tailscale é segura? Entenda o modelo de confiança

A Tailscale é segura? A resposta curta

A Tailscale é segura? Naquilo que mais preocupa a maioria das pessoas, sim: o servidor de coordenação que gere a sua tailnet nunca detém as chaves privadas que encriptam o seu tráfego, por isso não consegue ler o que os seus dispositivos enviam entre si. A página de segurança da 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 inscrever 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 indica o controlo que limita essa capacidade. Se o produto ainda lhe for desconhecido, comece por o que é a 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 autoalojado. 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 depósito partilhada para chaves públicas" e afirma: "A chave privada nunca, em circunstância alguma, sai do respetivo nó."

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

Mantenha estes dois planos separados e todas as questões de segurança aqui 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 indica quem pode ser um peer.

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

Não poderia desencriptar o seu tráfego. As chaves que executam a encriptação são geradas nos seus dispositivos e nunca são carregadas, pelo que 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 com as 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 indicou que essa chave pertence à tailnet.

Poderia alterar os destinos que os seus dispositivos estão autorizados a 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."

Veria 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 estritamente qualquer informação sobre as operações dos clientes ou o conteúdo do tráfego de rede". Assim, o plano de controlo pode saber quais dos seus dispositivos comunicaram entre si e quando. Não sabe o que foi dito.

Apenas um item dessa lista está relacionado com a encriptação. Os restantes dizem respeito a quem é membro e ao que a política determina. Por isso, os controlos que merecem a sua atenção são os que regulam a inscrição de nós.

O seu fornecedor 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 fornecedor de identidade (IdP): Apple, Google, GitHub, Microsoft, Okta, OneLogin ou um fornecedor 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 autenticação multifator (MFA) é a que o IdP aplicar. O processo de remoção de acessos é o que o IdP executar quando uma pessoa sair da organização. Uma conta do IdP comprometida por phishing torna-se uma conta da tailnet, e o atacante nunca precisa de atacar o WireGuard: basta adicionar um dispositivo e receber as permissões que a sua política atribuir a esse utilizador.

Dois controlos separam uma conta de identidade roubada de um dispositivo funcional dentro da sua tailnet: a aprovação do dispositivo e a expiração da chave. O Tailnet lock é 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 IT admin pode aprovar. Um novo dispositivo apresenta o indicador “Needs approval” na página Machines até alguém agir sobre ele.

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, enquanto um indicador na consola de administração 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 outra forma de entrada, por isso devem ser tratadas como credenciais. A documentação do Tailscale é clara sobre o tipo mais arriscado: “Tenha muito cuidado com chaves reutilizáveis! Podem ser muito perigosas se forem roubadas. O ideal é mantê-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. Se a expiração não for especificada, o valor predefinido é o máximo de 90 dias. Prefira chaves de utilização única, marque-as como ephemeral para máquinas que entram e saem, e mantenha qualquer chave reutilizável encriptada com Ansible Vault ou num gestor de segredos, em vez de a guardar num script de shell.

Expiração da chave: 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, "By default, new domains are set with an expiry period of 180 days", e que "If reauthentication does not occur, keys expire and connections to/from the given endpoint will stop working." Pode reautenticar um dispositivo manualmente:

tailscale up --force-reauth

A documentação avisa que isto "might bring down the tailnet connection and thus should not be done remotely over SSH or RDP without an alternate means to log in if the connection is lost." Execute o comando com acesso à consola aberto ou a partir de um segundo caminho para entrar na máquina, porque está prestes a interromper a rede que está a utilizar.

Os servidores são onde este controlo costuma ser alterado. Uma máquina que tenha de ser reautenticada a cada 180 dias sairá da tailnet às 3h, quando ninguém estiver a monitorizar, por isso os administradores desativam a expiração das chaves nesse equipamento. Isso remove o temporizador que acabaria por invalidar uma chave roubada. Para um servidor, a melhor resposta é usar um dispositivo com tag, porque a tag identifica a máquina em vez de uma pessoa. Assim, a máquina continua a funcionar mesmo que essa pessoa deixe a empresa. Seja qual for a decisão, mantenha uma lista das máquinas com a expiração desativada: essas chaves permanecem válidas até eliminar o dispositivo.

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

O Tailnet lock aborda diretamente o problema da inscrição. A documentação do tailnet lock da Tailscale explica o mecanismo: "Quando um novo nó entra no tailnet, a chave pública do nó precisa de uma assinatura de uma chave do Tailnet Lock. O servidor de coordenação distribui a chave pública do nó assinada aos nós pares." Os dispositivos existentes verificam essa assinatura antes de aceitar 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, você nomeia os nós de assinatura. A 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 representa um custo operacional real: adicionar um telefone significa executar um comando num laptop.

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

• Se perder o segredo de desativação, não existe recuperação. A documentação diz: "Se perder os seus segredos de desativação e não tiver fornecido um deles ao suporte da Tailscale, o tailnet não poderá ser recuperado."
• A chave de assinatura fica num dispositivo que você controla e herda a segurança desse dispositivo. A documentação é explícita: "Se o dispositivo for comprometido, a chave poderá ser obtida."
• Não é possível executar ambos os controlos. A Tailscale afirma que o tailnet lock e a aprovação de dispositivos são mutuamente exclusivos. Ativar um significa abdicar do outro.
• É uma abordagem de confiança no primeiro uso (TOFU). A configuração inicial ainda passa 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 pertença à rede. Não protege a disponibilidade, e o white paper afirma isso.

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

Não. Quando dois dispositivos não conseguem comunicar diretamente, o tráfego recorre a um servidor DERP (Designated Encrypted Relay for Packets). A documentação do Tailscale afirma esta propriedade sem ressalvas: "Como as chaves privadas do Tailscale nunca saem do dispositivo local que as gerou, é impossível um servidor DERP desencriptar 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 do que passa entre eles. Descubra que tipo de conexão tem:

tailscale status
tailscale netcheck

tailscale status classifica cada peer como direto, apresentado como direct 203.0.113.10:41641, ou retransmitido, apresentado como relay seguido do nome do relay, com os contadores de bytes depois. Um peer que permanece num relay indica que as duas extremidades não conseguiram estabelecer um caminho direto. Normalmente, isto acontece porque o UDP está bloqueado em algum ponto ou porque ambos os lados 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 a latência até aos relays mais próximos. Estes dados mostram qual das duas causas está a ocorrer. Se um peer já está numa ligação direta e o débito continua abaixo do esperado, o relay não é o problema. Uma incompatibilidade de MTU do caminho é normalmente a causa do WireGuard lento.

Um exit node desloca o ponto de saída, mas não o elimina

Um exit node 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 essa capacidade, e cada cliente opta por utilizá-la:

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 exit node 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 o poder utilizar. Ambos os passos são intencionais: uma máquina não aprovada não pode tornar-se silenciosamente a saída de toda a sua tailnet. A mesma aprovação aplica-se às rotas de sub-rede. Assim, uma máquina que anuncie um intervalo privado permanece inativa até um administrador o aceitar. Esse é o primeiro obstáculo para anunciar uma rede privada à sua tailnet a partir de um VPS.

Agora, a questão da confiança. O tráfego é encriptado entre o seu laptop e o exit node. Depois, sai dessa máquina como tráfego normal de Internet e usa o endereço IP dessa máquina. Por isso, o operador do exit node vê os seus destinos. O mesmo acontece com o fornecedor de alojamento dessa máquina e com a rede a montante. Transferiu o ponto de observação, mas não o eliminou. Esta é uma boa troca quando controla a extremidade remota, que é o motivo para executar o seu próprio exit node num VPS, e uma opção fraca quando não a controla.

A política padrão é uma rede plana

Uma tailnet nova é permissiva por padrão. A documentação de controlo de acesso do Tailscale afirma que o ficheiro de política padrão “ativa a comunicação entre todos os dispositivos da tailnet”. Cada dispositivo consegue alcançar todos os outros em todas as portas. Isto é uma rede plana. Colocá-la dentro do túnel ajuda contra ligações externas, 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 os grants mais recentes. Ambos 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 nega tudo o resto por omissão. O Tailscale indica quais destinos de regras estão disponíveis em cada plano. Consulte essa informação antes de basear o desenho em tags ou autogroups e veja o que o plano gratuito inclui efetivamente. Para um dispositivo que nunca deve aceitar ligações recebidas, como um telefone pessoal, tailscale set --shields-up bloqueia-as no cliente.

O que muda ao alojar o plano de controlo com Headscale

Headscale é "Uma implementação open source e autoalojada do servidor de controlo 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 organização open source pequena." A lista de funcionalidades inclui ACLs e grants, routers de sub-rede, nós de saída, um servidor DERP integrado, Tailscale SSH e Taildrop. Se esse âmbito restrito for o problema, o NetBird é a outra mesh que disponibiliza um plano de controlo autoalojável, e executar o servidor NetBird na sua própria VPS transfere a mesma decisão de inscrição para hardware que controla.

O que muda é a identidade da entidade que poderia inscrever um nó não autorizado. Com o Headscale, o diretório de chaves e a política ficam no seu servidor. Nenhuma entidade externa detém a lista das chaves públicas dos seus dispositivos e nenhuma entidade externa pode ser obrigada a entregar uma chave ou a assinar uma.

O que não muda é o plano de dados. Continua a ser o mesmo WireGuard, com a mesma encriptação de ponta a ponta e o mesmo fallback para relay quando não é possível estabelecer um caminho direto. Também passa a assumir as tarefas que o Tailscale executava: disponibilidade, aplicação de patches, cópias de segurança e segurança física do equipamento. Se esse equipamento for um VPS alugado, esta última responsabilidade depende da garantia de terceiros, e não do seu controlo, porque o hypervisor pode ler a memória da sua máquina convidada e, com isso, o diretório de chaves, a menos que o hardware suporte memória encriptada que possa ser atestada. Um host Headscale comprometido dá a um atacante exatamente o que daria um servidor de coordenação comprometido: a capacidade de registar um node e distribuir políticas. Tailnet lock não faz parte da lista de funcionalidades do Headscale, portanto o controlo compensatório para esse risco específico não está disponível nesse sistema. O custo também leva alguns tailnets na mesma direção, porque o Tailscale cobra por utilizador, e não por dispositivo e essa conta muda assim que uma equipa pequena ultrapassa o plano gratuito. Se a questão da posse for o fator decisivo, o self-hosting do plano de controlo com Headscale apresenta o procedimento de configuração.

Contra o que o Tailscale protege

• Portas públicas em escuta. Um serviço associado a um endereço da tailnet não fica acessível a partir da Internet, por isso os scanners que contactam todas as VPS na porta 22 nunca o veem. A exceção é ativada por si, porque o Funnel publica deliberadamente um serviço da tailnet na Internet aberta. Por isso, é importante 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 publicada pelo Docker 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. Esta é uma posição mais segura do que aplicar limitação de taxa numa porta aberta, embora o fail2ban no Ubuntu 24.04 continue a ser recomendável em qualquer serviço que tenha de permanecer público.
• Redes não fidedignas no percurso. O tráfego entre as suas máquinas é cifrado de ponta a ponta através da rede de um café ou da LAN partilhada de um fornecedor. Também permanece cifrado quando é encaminhado por um relay.
• Distribuição manual de chaves. Cada peer adicionado manualmente a uma configuração do WireGuard pode levar à reutilização de um endereço ou à introdução da chave errada. A malha gere essa informação por si. Esta é a principal diferença prática entre WireGuard e 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 política conceder a esse utilizador. Esta é a maior lacuna, e nenhuma VPN a elimina.
• Um administrador malicioso ou descuidado. Qualquer pessoa que possa editar o ficheiro de política pode conceder a si própria acesso a qualquer recurso. O mesmo se aplica a quem conseguir assumir a conta de identidade de um Owner. 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 do momento e do volume. Os logs de fluxo do Tailscale mostram quais peers comunicaram e quando. Nenhum dos dois vê o conteúdo, mas o facto de existir uma ligação não fica oculto. Por isso, leia como 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 recurso lento, com um padrão de 180 day. Remover o dispositivo na consola de administração é a opção rápida. Saiba onde está esse botão antes de precisar dele.

Verifique a sua tailnet

1. Execute tailscale status num dispositivo e leia a lista de peers. 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 e 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, bem como todas as chaves de autenticação reutilizáveis que ainda existam. Ambas são credenciais sem temporizador.
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, e um portátil infetado alcança todos eles.

A reputação da Tailscale baseia-se no plano de dados, em que o desenho não dá ao operador qualquer forma de ler o seu tráfego. Considere essa afirmação conforme documentada pelo fornecedor e audite as partes que estão sob a sua responsabilidade: as contas de identidade, a configuraçã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. Isto é uma evidência sobre o processo da empresa, não uma afirmação sobre a sua configuração.

FAQ

O Tailscale consegue 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. A infraestrutura do Tailscale vê metadados: quais dispositivos existem, quais se ligaram entre si e quando.

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

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

Um exit node oculta a minha navegação do meu ISP?

Oculta os destinos da rede onde está ligado, incluindo o ISP de casa ou do café, porque tudo sai do seu dispositivo como tráfego cifrado endereçado ao exit node. Isto não o torna anónimo. O exit node 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 exit node. 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 estritamente mais segura. Com o Headscale, controla 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 fica responsável por executar esse servidor: aplicar patches, garantir disponibilidade, fazer backups e proteger o próprio host. Um host Headscale comprometido oferece a um atacante o mesmo poder de inscrição que um servidor de coordenação comprometido ofereceria. 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 continua 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 suas próprias regras e pode expor uma porta que julgava estar fechada.