Tailscale no Ubuntu Server: VPN mesh passo a passo

Abrir porta no roteador para acessar um servidor remoto é a parte da VPN que mais quebra: NAT duplo, IP dinâmico do provedor, firewall corporativo bloqueando a porta. O Tailscale resolve isso por baixo com WireGuard e um serviço de coordenação que faz os dispositivos se encontrarem sozinhos, sem port forward e sem IP fixo. Neste guia, a instalação em um servidor Ubuntu/Debian, a configuração como subnet router para expor toda a rede interna e o controle de acesso por tags — passo a passo, com os comandos reais.

Como o Tailscale funciona por baixo

Cada máquina roda o cliente tailscaled, que sobe um túnel WireGuard ponto a ponto com as demais. Um servidor de coordenação (o control plane da Tailscale, ou um Headscale auto-hospedado) só troca as chaves públicas e ajuda a negociar o caminho direto entre os peers — o tráfego não passa por ele. Quando o NAT de nenhum dos dois lados permite conexão direta, a Tailscale usa um relay (DERP) como último recurso, com throughput menor.

O plano Personal é gratuito e cobre até 6 usuários, dispositivos ilimitados, 50 recursos com tag e 3 grupos de ACL — suficiente para uma rede doméstica ou um laboratório de infraestrutura. A partir do sétimo usuário, o tailnet inteiro migra para um plano pago.

Instalando o Tailscale no Ubuntu Server

1. Instale o cliente pelo script oficial, que detecta a distribuição e configura o repositório:

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

2. Suba o serviço e autentique o dispositivo:

   sudo tailscale up

   O comando imprime uma URL de autenticação. Abra em qualquer navegador logado na sua conta (Google, Microsoft, GitHub ou e-mail) e aprove o dispositivo.

3. Confirme que o túnel subiu e veja o IP atribuído (faixa 100.x.y.z, fixo por dispositivo):

   tailscale ip -4
   tailscale status

A partir daqui, qualquer outro dispositivo com Tailscale instalado (Linux, Windows, macOS, iOS, Android) já enxerga esse servidor pelo IP 100.x ou pelo nome via MagicDNS, sem nenhuma regra de firewall aberta para a internet.

Configurando um subnet router para expor a rede interna

Instalar o cliente em cada máquina nem sempre é viável — impressoras, NAS, switches de gerência. O subnet router resolve isso: um único servidor Linux dentro da rede local anuncia a sub-rede inteira para o tailnet, funcionando como gateway.

1. Habilite o encaminhamento de pacotes IPv4 e IPv6 de forma persistente:

   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 isso o servidor recebe o pacote mas não o repassa — o erro mais comum ao montar subnet router.

2. Suba o túnel já anunciando a sub-rede local:

   sudo tailscale up --advertise-routes=192.168.1.0/24 --accept-dns=false

   Troque 192.168.1.0/24 pela faixa real da sua LAN. O --accept-dns=false evita que esse servidor específico troque seu DNS local pelo MagicDNS, útil quando ele já resolve nomes internos.

3. A rota fica anunciada mas inativa até ser aprovada manualmente — trava de segurança proposital. No painel administrativo (Machines → selecione o dispositivo → Edit route settings), habilite a sub-rede anunciada.
4. Nos clientes que vão consumir a rota, ative o recebimento automático de rotas anunciadas:

   sudo tailscale up --accept-routes

   No Windows e macOS essa opção já vem marcada por padrão na interface gráfica.

Resultado prático: um notebook em qualquer rede, com Tailscale ativo, passa a alcançar toda a faixa 192.168.1.0/24 através do servidor que virou subnet router — sem VPN tradicional, sem IP público, sem porta aberta.

Controlando acesso com tags e ACLs

Sem regra nenhuma, todo dispositivo do tailnet enxerga todos os outros — aceitável em um laboratório, arriscado quando o subnet router expõe produção. Tags separam a identidade do dispositivo do usuário que o cadastrou, e o arquivo de política (ACL) decide quem fala com quem.

1. No painel, em Access Controls, defina a tag e quem pode aplicá-la:

   "tagOwners": {
     "tag:subnet-router": ["autogroup:admin"]
   }

2. Aplique a tag ao subir o servidor (substitui o dono humano pela identidade de serviço):

   sudo tailscale up --advertise-routes=192.168.1.0/24 --advertise-tags=tag:subnet-router

3. Restrinja quem acessa a sub-rede exposta:

   "acls": [
     {
       "action": "accept",
       "src":    ["group:infra"],
       "dst":    ["tag:subnet-router:*", "192.168.1.0/24:*"]
     }
   ]

Com a ACL publicada, só quem está no grupo infra alcança a rede atrás do subnet router — o restante do tailnet continua isolado dele, mesmo estando na mesma organização.

Perguntas frequentes

Preciso de IP público ou porta aberta no roteador?
Não. O NAT traversal do WireGuard resolve a maioria dos casos; quando não resolve, o tráfego passa por um relay da própria Tailscale (DERP), sem exigir nenhuma configuração no roteador.

O tráfego passa pelos servidores da Tailscale?
Só o handshake de coordenação. Sempre que os dois lados conseguem se enxergar diretamente, a conexão é peer-to-peer; o relay só entra quando a conexão direta não é possível.

Dá para auto-hospedar o control plane?
Sim, com o Headscale, um servidor de coordenação open source compatível com o protocolo — útil para quem não quer depender da infraestrutura da Tailscale, ao custo de perder alguns recursos do painel oficial.

Um subnet router aguenta produção?
Aguenta o volume de uma rede pequena a média; para links de alto throughput sustentado, o overhead do encapsulamento WireGuard e o encaminhamento via userspace merecem teste de carga antes de depender dele como caminho único.

Substitui o firewall perimetral?
Não. O Tailscale cuida do acesso remoto ponto a ponto; regras de borda, segmentação de VLAN e um firewall como o FortiGate ou o pfSense continuam sendo a camada que filtra o que entra na rede por fora do tailnet.

Conclusão

Para acesso remoto administrativo — gerência de servidor, painel interno, backup fora do site — o Tailscale corta o trabalho de manter VPN tradicional viva: sem certificado para renovar, sem porta para expor, sem IP dinâmico para rastrear. Comece por um único servidor como subnet router, valide o acesso com uma ACL restrita e só depois estenda a outros segmentos da rede.