Que problema ele resolve

O cenário típico: você tem algumas VPS na nuvem, um NAS em casa e uma Raspberry Pi, e quer que eles se acessem — por exemplo, fazer SSH de uma VPS direto para uma máquina em casa. A proposta do Tailscale é: instalar um cliente em cada máquina, fazer login na mesma conta, entrar na mesma rede (chamada oficialmente de tailnet), e cada máquina recebe um endereço IPv4/IPv6 do Tailscale. Depois disso as máquinas conseguem se acessar mutuamente, sem precisar abrir portas na internet para isso.

Dois esclarecimentos: conseguir acessar um serviço específico em uma máquina ainda depende das políticas de acesso no console de administração, do firewall da própria máquina e de o serviço estar escutando; este artigo cobre apenas a instalação e a configuração comum do cliente Linux.

Instalação

O script oficial de uma linha funciona em Ubuntu/Debian e derivados, RHEL/CentOS/Fedora e derivados, Raspberry Pi OS, Amazon Linux, openSUSE/SLE, Oracle Linux, entre outros:

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

Se você não quer usar curl | sh, configure o repositório manualmente conforme a página pkgs.tailscale.com/stable. Usando o Ubuntu 26.04 (Resolute) como exemplo, todos os comandos a seguir exigem sudo:

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/resolute.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/resolute.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update && sudo apt-get install tailscale

No Debian 13 (trixie) o procedimento é o mesmo, trocando ubuntu/resolute na URL por debian/trixie. No Fedora, use dnf:

sudo dnf config-manager --add-repo https://pkgs.tailscale.com/stable/fedora/tailscale.repo
sudo dnf install tailscale
sudo systemctl enable --now tailscaled

Um detalhe: a página oficial stable não inclui systemctl enable --now tailscaled nas seções de Ubuntu e Debian, apenas a seção do Fedora exige explicitamente. Para saber se o serviço já está habilitado após a instalação em outras distribuições, guie-se pela saída deste comando:

systemctl status tailscaled

Se não estiver em execução, habilite manualmente:

sudo systemctl enable --now tailscaled

Arch Linux e NixOS têm guias próprios na documentação oficial; outras distribuições não listadas podem usar os binários estáticos, veja a página stable.

Login e verificação

sudo tailscale up

A saída do comando fornece uma URL de autenticação; complete a autenticação no navegador. Em servidores sem navegador, copie a URL e abra no navegador de uma máquina local. Depois, confirme no console de administração, página Machines, que o dispositivo aparece. Para verificar o status localmente:

tailscale ip
tailscale status

Eles mostram, respectivamente, o endereço IPv4/IPv6 do Tailscale da máquina local e o estado das conexões. Para forçar reautenticação após a expiração da chave do dispositivo:

sudo tailscale up --force-reauth

Máquinas sem atendimento humano: chaves de autenticação

Servidores na nuvem e Raspberry Pi, sem navegador e nos quais você não quer intervenção manual no login, registram-se com uma chave de autenticação:

sudo tailscale up --auth-key=tskey-abcdef1432341818

A chave diferencia maiúsculas de minúsculas. Escrever a chave real na linha de comando pode deixá-la no histórico do shell, em scripts ou em gravações de terminal; não a coloque em scripts ou anotações compartilháveis. Dispositivos autenticados com uma chave assumem a identidade do usuário que a gerou; quando a chave tem uma tag, o dispositivo recebe a identidade da tag.

Tipos de chave: descartáveis (revogadas automaticamente após um uso), reutilizáveis, efêmeras (dispositivo removido automaticamente ao ficar offline), pré-aprovadas, com tag, além de chaves pré-assinadas usadas para habilitar o Tailnet Lock na rede (exigem tailscale lock sign). A validade vai de 1 a 90 dias; sem especificar, o padrão é 90 dias.

Há duas camadas de validade a distinguir: uma chave expirada não pode mais autenticar novos dispositivos; dispositivos já autorizados por ela permanecem autorizados até expirar sua própria chave de nó, cujo padrão é 180 dias. Dispositivos com tag têm a expiração de chave desativada por padrão.

Implicação de segurança: se uma chave reutilizável for roubada, qualquer pessoa que a obtiver poderá registrar dispositivos na sua rede; guarde-a em um cofre de segredos dedicado. Revogar a chave não invalida os nós que já a usaram — para limpá-los, é preciso removê-los um a um na página Machines. As permissões de gerar e revogar são exclusivas de Owner, Admin, IT admin e Network admin, e cada um só pode revogar as próprias chaves.

Tailscale SSH

No servidor que receberá conexões, execute (exige root):

sudo tailscale set --ssh

Exige Tailscale v1.24 ou superior, é necessário apenas uma vez por host, e gera um par de chaves de host SSH. Dois avisos: depois de executar, as conexões SSH existentes para o IP do Tailscale desse host travam; se você administra a máquina por uma sessão assim, troque antes para o console do provedor de nuvem ou outro canal de administração, e só então execute o comando de habilitação.

Ele usa a identidade do Tailscale para autenticar, sem precisar gerar chaves no cliente e copiar a pública para o servidor; intercepta apenas o tráfego que chega à porta 22 pelo tailnet, /etc/ssh/sshd_config e ~/.ssh/authorized_keys não são alterados, e conexões SSH comuns que não passam pelo Tailscale continuam funcionando. O custo: qualquer usuário de sistema na máquina cliente pode iniciar conexões pelo Tailscale, não há par de chaves no lado local, e o controle de acesso fica inteiramente a cargo das políticas do servidor.

O acesso exige duas regras: uma regra de rede permitindo a origem acessar a porta 22 do destino, e uma regra ssh. Exemplo oficial:

{
  "action": "accept",
  "dst": ["autogroup:self"],
  "src": ["autogroup:member"],
  "users": ["autogroup:nonroot"]
}

Essa regra permite que membros façam SSH como usuário não root nos próprios dispositivos. Detalhes: só é possível usar contas já existentes no host, o Tailscale não cria contas; apenas a porta 22 é suportada e não pode ser alterada; src e dst não aceitam * isolado; regras check são avaliadas antes das regras accept; a política padrão, não modificada, permite que o usuário faça SSH no modo check para os próprios dispositivos.

Se você ampliar o dst para além de autogroup:self (por exemplo, mudar para alguma tag), repense o autogroup:nonroot em users — mantido como está, todos que o src permite poderão entrar com qualquer usuário não root da máquina de destino. Esse é o ponto que mais exige reflexo ao habilitar o Tailscale SSH.

O modo check exige reautenticação antes de conectar (podendo disparar MFA); o checkPeriod padrão é de 12 horas, configurável de 1 minuto a 168 horas, ou "always". Ele vale apenas para o Tailscale SSH e não pode ser usado em regras cuja origem seja dispositivos com tag. Definir "always" quebra ferramentas de automação como Ansible, que abrem muitas conexões rapidamente.

Limitações: o lado servidor suporta apenas Linux e o tailscaled open source do macOS, sem suporte a Synology ou QNAP; reiniciar o tailscaled (por exemplo, em upgrades) encerra sessões em andamento; mudanças de política surtem efeito em poucos segundos e encerram as sessões existentes daquele usuário, e outras formas de acesso (como chaves SSH) precisam ser removidas à parte. A própria documentação considera que ele não é muito adequado para máquinas multiusuário com permissões variadas, nem para máquinas que usam authorized_keys para restringir comandos remotos. Para rotacionar:

sudo tailscale up --ssh --force-reauth

Isso gera uma nova chave de nó e uma nova chave de host SSH.

Roteamento de sub-rede

O roteamento de sub-rede permite que máquinas no tailnet acessem dispositivos da faixa de rede que não têm o Tailscale instalado — por exemplo, instalar o cliente apenas no gateway (Raspberry Pi ou NAS) já dá acesso a toda a rede interna. São quatro passos.

Primeiro, habilite o encaminhamento de IP (quando /etc/sysctl.d existir):

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

Sem /etc/sysctl.d, acrescente as duas linhas de configuração a /etc/sysctl.conf e execute sudo sysctl -p. Depois de habilitar o encaminhamento, mantenha o firewall negando encaminhamentos por padrão (ufw e firewalld fazem isso por padrão). Se o firewalld estiver em execução, pode ser necessário, por um problema conhecido:

sudo firewall-cmd --permanent --add-masquerade

Segundo, declare as rotas na máquina que atuará como roteador de sub-rede:

sudo tailscale set --advertise-routes=192.0.2.0/24,198.51.100.0/24

Troque pelas suas próprias sub-redes; há suporte a IPv4 e IPv6; as rotas padrão 0.0.0.0/0 e ::/0 são para o caso de uso de exit node e não se declaram com roteamento de sub-rede.

Terceiro, aprove no console de administração, página Machines: localize o dispositivo com a marcação Subnets, na seção Subnets clique em Edit, marque e salve (se autoApprovers já cobre, pode pular). A aprovação de rotas e as regras de acesso são coisas separadas — a política também precisa permitir o tráfego para essas sub-redes, senão o tráfego continua sendo negado.

Quarto, o cliente Linux por padrão só descobre endereços do Tailscale; em cada máquina Linux que vai acessar a sub-rede, execute:

sudo tailscale set --accept-routes

Nas outras plataformas as novas rotas são recebidas automaticamente.

A armadilha da alta disponibilidade: quando vários roteadores de sub-rede redundantes declaram as mesmas rotas, não habilite --accept-routes neles, senão o roteador de backup pode receber rotas do roteador principal e desviar o tráfego; na maioria dos cenários de alta disponibilidade usa-se apenas --advertise-routes.

Solução de problemas e observações

  • Conexão não funciona: rode tailscale status nas duas pontas primeiro e confirme que os dispositivos estão online e os endereços estão corretos.
  • Dispositivo caiu da rede: considere se a chave de nó expirou (padrão de 180 dias); reautentique com sudo tailscale up --force-reauth.
  • Roteamento de sub-rede não funciona, verifique em ordem: se o encaminhamento de IP está ativo (sysctl net.ipv4.ip_forward), se o console aprovou as rotas, se o cliente Linux executou --accept-routes, se a política permite o tráfego para a sub-rede de destino.
  • Tailscale SSH não conecta: verifique se as duas regras existem e se a conta de destino realmente existe no servidor.
  • Nota oficial: desativar logs (definir TS_NO_LOGS_NO_SUPPORT=true ou usar --no-logs-no-support) pode impedir o recebimento de suporte técnico. Além disso, a documentação oficial não fornece mais detalhes.

Todos os comandos e configurações acima vêm da documentação oficial em tailscale.com/kb e da página de instalação pkgs.tailscale.com/stable; a página kb/1031 consultada indica data de verificação de 5 de janeiro de 2026 — se a saída da sua instalação ou a interface do console divergirem do que está aqui, prevalece a versão atual da documentação oficial.