Como configurar um subnet router do Tailscale em VPS

O que faz um subnet router do Tailscale

Um subnet router do Tailscale é uma máquina que anuncia um intervalo completo de endereços IP privados à sua tailnet, para que todos os dispositivos da tailnet possam aceder a endereços nesse intervalo, mesmo que nenhum dispositivo dessa rede execute o Tailscale. A sua tailnet é a sua rede privada do Tailscale: o conjunto de dispositivos autenticados numa conta ou organização. Um exit node é a funcionalidade que costuma ser confundida com um subnet router, mas faz o trabalho oposto. Envia todo o tráfego de um dispositivo através do VPS, fazendo do VPS a rota desse dispositivo para a Internet pública.

Uma frase para cada caso. Um subnet router torna uma rede privada acessível a partir da tailnet. Um exit node altera o local de onde o tráfego público sai para a Internet. Se pretende a segunda opção, leia como executar um exit node do Tailscale num VPS. São flags independentes, e um VPS pode executar as duas funções ao mesmo tempo, mas resolvem problemas diferentes e falham de formas diferentes.

Quando um VPS precisa de atuar como router de sub-rede

O caso comum é uma rede privada que o fornecedor já lhe disponibilizou. O VPS tem um endereço público e uma segunda interface num segmento privado, enquanto os outros servidores desse segmento não têm qualquer endereço público: uma base de dados em 10.0.0.20 e um destino de cópias de segurança em 10.0.0.30. Instale Tailscale num VPS, anuncie 10.0.0.0/24 e o seu portátil poderá aceder diretamente a esses endereços privados. Nada mais muda no segmento e a base de dados continua sem endereço público. Se a única coisa de que precisa nesse segmento for uma aplicação Web numa única porta, anunciar todo o intervalo é mais do que necessário, e Tailscale serve coloca HTTPS nessa única porta. O mesmo raciocínio aplica-se a um daemon que fica deliberadamente ligado apenas a localhost, como dsh a executar sem interface sob systemd, em que um endereço da tailnet nesse VPS substitui o túnel SSH que teria de manter aberto para aceder à respetiva interface.

O outro caso é uma rede do outro lado do VPS. Pode ser uma LAN (rede local) de casa ou do escritório atrás do seu próprio router, ou um conjunto de equipamentos que não podem executar Tailscale, como um switch gerido ou um NAS antigo com firmware bloqueado. Um equipamento Linux nessa rede torna-se o router de sub-rede de todos os restantes equipamentos. Em casa, esse equipamento é muitas vezes uma VM num hypervisor que já utiliza, e a comparação de custos entre um host Proxmox em casa e um VPS alugado é o ponto que deve resolver antes de decidir em que extremidade do túnel os seus serviços devem ficar.

Os dois casos têm um requisito em comum. O router de sub-rede já tem de conseguir alcançar o intervalo que anuncia, utilizando a sua própria tabela de encaminhamento e a sua própria firewall. Tailscale não cria essa ligação. Transporta o tráfego até ao router e entrega-o ao kernel para encaminhamento.

Instale o Tailscale e verifique primeiro a rota local

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

O script deteta a distribuição, adiciona o repositório de pacotes do Tailscale, instala o comando tailscale e o daemon tailscaled e ativa o serviço. Confirme com systemctl is-active tailscaled. O comando deve apresentar active.

Antes de qualquer outra ação, confirme que o VPS consegue alcançar a rede que pretende anunciar.

ip route show
ping -c3 10.0.0.20

ip route show deve listar o intervalo privado numa interface real, por exemplo 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. Se o ping falhar neste ponto, no próprio router, nenhuma flag do Tailscale resolverá o problema. A causa está na configuração de rede do VPS ou numa firewall no host de destino. Corrija-a primeiro, porque todos os testes seguintes dependem disso.

Ative o encaminhamento IP e faça-o persistir após um reboot

Uma máquina Linux descarta qualquer pacote que não seja destinado a si própria, a menos que o encaminhamento esteja ativado. Encaminhar pacotes de outras máquinas é a função principal de um router de sub-rede, por isso este passo é obrigatório.

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

Verifique o estado com sysctl net.ipv4.ip_forward. O comando deve apresentar net.ipv4.ip_forward = 1.

É comum configurar este passo apenas pela metade. sudo sysctl -w net.ipv4.ip_forward=1 funciona imediatamente, mas desaparece no próximo boot. Assim, o router de sub-rede funciona durante semanas e deixa de encaminhar tráfego na manhã seguinte a um reboot causado por uma atualização do kernel. A parte confusa é que nada parece estar avariado. tailscale status continua a mostrar o nó online, a consola de administração continua a mostrar a rota aprovada e os clientes continuam a ter a rota instalada. Os pacotes chegam ao VPS, mas o kernel descarta-os sem registar nada. Escrever os valores em /etc/sysctl.d/99-tailscale.conf é o que faz com que sejam restaurados após um reboot.

Se anunciar rotas com o encaminhamento ainda desativado, tailscale up avisa nesse momento, com uma linha semelhante a Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly.. Leia a saída desse comando em vez de a ignorar.

Anuncie as rotas

sudo tailscale up --advertise-routes=10.0.0.0/24

Num VPS que já está autenticado na sua tailnet, altere a configuração diretamente:

sudo tailscale set --advertise-routes=10.0.0.0/24

Use tailscale set para todas as alterações posteriores. Executar novamente tailscale up com apenas uma flag repõe as flags que não foram repetidas, e a CLI interrompe o comando com um erro a indicar que, para alterar as configurações desta forma, é necessário mencionar todas as flags não predefinidas. tailscale set altera uma configuração e mantém as restantes.

É possível indicar vários intervalos numa única lista separada por vírgulas, sem espaços: --advertise-routes=10.0.0.0/24,192.168.50.0/24. Cada entrada deve ser um endereço de rede em notação CIDR (classless inter-domain routing, no formato 10.0.0.0/24). Se indicar por engano o endereço do próprio host, 10.0.0.5/24, o comando é rejeitado porque os bits depois do prefixo não são zero, e o erro indica o prefixo que provavelmente pretendia usar. Para deixar de anunciar rotas, defina uma lista vazia com sudo tailscale set --advertise-routes=.

Aprovar a rota na consola de administração

Anunciar uma rota é um pedido, não uma alteração. Enquanto um administrador não a aprovar, nenhum cliente recebe a rota e nada nesse intervalo fica acessível. Isto é intencional, porque uma máquina que possa adicionar-se à tabela de encaminhamento de todos pode capturar tráfego de qualquer intervalo que escolha.

Aprove-a na página Machines da consola de administração. O VPS aparece com um identificador de subnet. Abra a respetiva linha, localize a secção de subnets, edite as definições da rota, selecione a rota e guarde.

A aprovação é feita por prefixo. Anuncie 10.0.0.0/24 hoje e 192.168.50.0/24 no próximo mês. O novo prefixo fica por aprovar, enquanto o antigo continua a funcionar. Para o VPS, uma rota aprovada e uma rota ignorada têm o mesmo aspeto. Por isso, consulte a consola antes de investigar qualquer outra coisa.

Pode ignorar o passo manual com um bloco autoApprovers no ficheiro de política do tailnet:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

Depois, inicie o nó com essa tag, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router. A rota será aprovada no momento em que for anunciada. A tag tem de existir primeiro na secção tagOwners do mesmo ficheiro de política. Vale a pena configurar isto se reconstruir o VPS através de um script, porque um nó reconstruído é um nó novo e as respetivas rotas voltam a ficar por aprovar.

Por que os clientes Linux ignoram a rota sem --accept-routes

A rota já foi anunciada e aprovada. O seu telefone e o seu Mac conseguem alcançar 10.0.0.20. O seu portátil Linux não consegue, e nada na consola de administração indica um problema.

Aceitar uma rota de subnet significa escrever entradas na tabela de encaminhamento do cliente. No Android, iOS, macOS, tvOS e Windows, o cliente Tailscale faz isso por si. No Linux, isso não acontece porque uma máquina Linux é frequentemente um servidor ou router cuja tabela de encaminhamento foi configurada deliberadamente, e inserir silenciosamente uma /24 aprendida da rede pode interromper o tráfego que essa máquina já trata. Por isso, no Linux, tem de ativar esta opção em cada cliente:

sudo tailscale set --accept-routes

Depois, confirme onde a rota foi instalada:

ip route show table 52
ip route get 10.0.0.20

O Tailscale no Linux não coloca as rotas aceites na tabela de encaminhamento principal. Coloca-as na tabela de encaminhamento 52 e instala regras de política, visíveis com ip rule show no intervalo de prioridades de 5210 a 5270, que encaminham os pacotes sem correspondência para essa tabela. Por isso, ip route show, por si só, nunca apresenta 10.0.0.0/24, e quem verificar apenas esse comando conclui que --accept-routes não fez nada. ip route show table 52 é o comando que mostra o estado real e deve apresentar o intervalo anunciado em tailscale0.

É importante conhecer uma exceção. Se este nó Linux for também um segundo router de subnet da sua própria rede local, --accept-routes faz com que envie o tráfego destinado à sua própria subnet diretamente ligada através do outro router, em vez de o enviar pela sua própria interface. Num router de reserva num par de alta disponibilidade, mantenha --accept-routes desativado e anuncie apenas.

Modo de falha: dois routers a anunciar intervalos sobrepostos

Dois routers de sub-rede não devem anunciar intervalos idênticos. São permitidos intervalos sobrepostos com comprimentos de prefixo diferentes, e o Tailscale escolhe a correspondência mais específica. Com o router A a anunciar 10.0.0.0/24 e o router B a anunciar 10.0.0.0/16, o tráfego para 10.0.0.20 segue para A.

O que surpreende é o comportamento quando A fica offline. O Tailscale não recorre à rota menos específica. O tráfego para 10.0.0.20 para, enquanto o tráfego para 10.1.0.20 continua a funcionar através de B. O sintoma parece indicar que metade da rede privada está indisponível, mas a causa é um nó offline que mantém o prefixo mais específico. Se quiser failover, faça também o router com o intervalo mais amplo anunciar os prefixos mais estreitos, para que ambos cubram os mesmos endereços.

A outra sobreposição ocorre mais perto do cliente. Se estiver numa rede de hotel em 192.168.1.0/24 enquanto o seu router de sub-rede anuncia 192.168.1.0/24, os dois competem pelos mesmos destinos, e o vencedor depende da plataforma. No Linux, instale uma regra antes da regra do próprio Tailscale para que os endereços locais usem a tabela principal:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

Essa regra não é persistente e desaparece no próximo boot. A correção real é escolher um intervalo privado que não encontre noutras redes. 192.168.0.0/24 e 192.168.1.0/24 são os valores predefinidos na maioria dos routers domésticos, por isso escolha algo dentro de 10.0.0.0/8 de forma deliberada. O mesmo conflito interrompe uma VPN WireGuard simples configurada manualmente, pelo mesmo motivo: a rota local mais específica vence, portanto o tráfego nunca entra no túnel.

Modo de falha: o DNS resolve para um endereço que nenhuma rota abrange

Este caso é difícil de depurar porque nada comunica um erro. O nome é resolvido. A ligação excede o tempo limite.

Suponha que db.internal.example.com seja resolvido para 10.0.5.20 através do seu nameserver privado e que tenha anunciado 10.0.0.0/24. A consulta é bem-sucedida porque a resolução do DNS (domain name system) e o encaminhamento IP são etapas separadas, e nenhuma verifica a outra. Em seguida, o pacote destinado a 10.0.5.20 não encontra uma rota correspondente na tailnet, sai pelo gateway predefinido do cliente e desaparece.

Dois comandos separam as duas partes:

nslookup db.internal.example.com
ip route get 10.0.5.20

Se a consulta devolver um endereço, mas ip route get não responder com dev tailscale0, o nome está correto e falta a rota. Anuncie um intervalo que abranja o endereço, usando 10.0.0.0/16 ou um segundo prefixo explícito, e depois aprove o novo prefixo na consola.

Existe uma armadilha semelhante no próprio nameserver. Se definir um nameserver global na consola de administração, num endereço privado como 10.0.0.53, esse endereço tem de estar dentro de uma rota aprovada. Caso contrário, os seus dispositivos não conseguem chegar ao resolver. Se ativar a opção que substitui os servidores DNS locais enquanto aponta para um resolver inacessível, todos os dispositivos da tailnet perdem a resolução de nomes ao mesmo tempo, incluindo os que funcionavam um segundo antes. Anuncie e aprove primeiro a rota para o resolver. Depois altere a configuração de DNS. Se o DNS dentro de um túnel for o problema que continua a enfrentar, a forma como o DNS falha através de um túnel WireGuard descreve o mesmo mecanismo sem a camada de coordenação adicional.

NAT de origem e ligações site-to-site

Por predefinição, o router de sub-rede reescreve o endereço de origem de cada pacote encaminhado para o seu próprio endereço privado. Isto é SNAT (source network address translation) e permite que as respostas funcionem sem alterações na rede privada: a base de dados em 10.0.0.20 responde ao VPS, que já sabe como chegar até ela. O custo é que a base de dados vê todas as ligações da tailnet como provenientes do VPS. Assim, as regras de firewall por origem e os logs de acesso não fornecem informação útil.

Desative-o no Linux quando quiser preservar o endereço tailnet real do cliente:

sudo tailscale set --snat-subnet-routes=false

Os hosts da rede privada precisam então de uma rota de retorno para 100.64.0.0/10, o intervalo que o Tailscale atribui aos dispositivos, apontando para o router de sub-rede. Sem essa rota de retorno, as respostas seguem para o gateway predefinido e nunca chegam ao destino. As ligações ficam bloqueadas depois do primeiro pacote. Adicione a rota estática ao gateway da rede privada ou mantenha o SNAT ativado.

Uma ligação site-to-site usa dois routers de sub-rede a fazer isto em simultâneo. Cada um anuncia a sua própria rede e aceita a rede do outro:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

Execute o comando correspondente no outro router, usando o intervalo desse router. Os dois intervalos têm de ser diferentes. Se as transferências grandes bloquearem enquanto ssh e ping funcionam corretamente, a causa é o MSS (maximum segment size), o maior bloco de dados transportado por um pacote TCP. A sobrecarga do túnel torna os pacotes encaminhados demasiado grandes para alguma ligação intermédia. O ajuste do MSS resolve o problema:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Guarde essa regra com iptables-persistent. Caso contrário, desaparecerá no próximo arranque.

Manutenção que mantém o serviço em funcionamento

A validade das chaves dos nós é de 180 dias por predefinição, desde August 2026. Quando a chave de um router de sub-rede expira, o nó termina a sessão e todo o intervalo anunciado fica inacessível, sem que exista qualquer alteração de configuração que explique o problema. Desative a expiração da chave para esta máquina na página Machines da consola de administração e registe que o fez.

O Tailscale prefere uma ligação direta entre pares e recorre aos seus servidores relay quando não consegue estabelecê-la. Os relays funcionam, mas acrescentam latência. Um VPS com um endereço público é o caso mais simples: permita a entrada de UDP 41641 e a maioria dos pares liga-se diretamente. Se o ufw gerir a firewall, as regras ufw de que um VPS realmente precisa explicam a sintaxe.

As regras de acesso são a outra metade. Numa tailnet predefinida, todos os seus dispositivos podem comunicar com todos os outros, pelo que uma rota aprovada funciona de imediato. Depois de criar uma política ACL, o destino de uma regra tem de indicar o intervalo privado, porque 10.0.0.20 não é um endereço de tailnet e não é abrangido por regras escritas com base em endereços IP de tailnet ou tags.

Por fim, decida se aceita utilizar um servidor de coordenação que não é gerido por si. O plano de controlo do Tailscale é um serviço alojado. As suas chaves permanecem nas suas máquinas, mas a conta e o ficheiro de política ficam nesse serviço. O que alguém poderia realmente fazer com um plano de controlo comprometido ou com credenciais de início de sessão de uma identidade roubada é o aspeto que deve avaliar antes de lhe confiar uma rota para a sua rede privada, e o modelo de confiança do Tailscale delimita essa fronteira. O custo raramente é o motivo para abandonar o serviço, uma vez que o plano gratuito suporta até seis utilizadores com dispositivos próprios ilimitados, embora um router de sub-rede iniciado com uma tag seja contabilizado de forma diferente de um router com sessão iniciada como o utilizador. A partir desse limite, a fatura acompanha o número de pessoas e não o de máquinas, pelo que vale a pena calcular quanto paga efetivamente uma família ou uma equipa de cinco pessoas quando o plano gratuito termina antes de adicionar a conta que o faz ultrapassar o limite. Executar o Headscale, o servidor de controlo Tailscale autoalojado mantém esse componente no seu próprio VPS, mas exige que o mantenha. A outra resposta à mesma preocupação é deixar também de utilizar os clientes do Tailscale, e alojar automaticamente o servidor VPN NetBird coloca a camada de coordenação e os seus próprios clientes mesh numa máquina que controla. Se ainda estiver a decidir entre este modelo e uma configuração escrita manualmente, a comparação entre WireGuard e Tailscale explica o que a camada de coordenação oferece e qual é o custo.

FAQ

Qual é a diferença entre um roteador de sub-rede e um nó de saída?

Um roteador de sub-rede anuncia um intervalo de endereços privados, permitindo que os dispositivos da tailnet acedam a máquinas que não executam Tailscale. Um nó de saída anuncia-se como uma rota para toda a Internet, fazendo com que um dispositivo envie todo o seu tráfego através do endereço público desse nó. O mesmo VPS pode desempenhar as duas funções. São flags separadas, --advertise-routes e --advertise-exit-node, e cada uma requer a sua própria aprovação na consola de administração.

Por que o meu cliente Linux ignora a rota de sub-rede anunciada?

Os clientes Linux não aceitam rotas de sub-rede sem que isso seja explicitamente ativado. Execute sudo tailscale set --accept-routes no cliente. Em seguida, verifique com ip route show table 52, e não com ip route show. O Tailscale instala as rotas aceites na tabela de encaminhamento 52 e chega até elas através de regras de política. Por isso, a tabela principal nunca as lista e uma rota funcional pode parecer ausente.

A minha sub-rede deixou de funcionar depois de um reboot. O que falhou?

Provavelmente, o encaminhamento de IP. Um valor definido com sysctl -w não persiste após um reboot. Por isso, escreva-o em /etc/sysctl.d/99-tailscale.conf e confirme com sysctl net.ipv4.ip_forward. Se o encaminhamento estiver ativo e o intervalo continuar inacessível, consulte o nó na consola de administração. As chaves dos nós expiram após 180 dias por predefinição. Um roteador de sub-rede com a chave expirada parece apresentar uma falha de rede, e não um problema de conta.

Dois roteadores de sub-rede podem anunciar o mesmo intervalo?

Não se forem intervalos idênticos. Intervalos sobrepostos com comprimentos de prefixo diferentes são válidos, e o prefixo mais específico tem precedência. O failover requer atenção: quando o roteador que mantém o prefixo mais específico fica offline, o Tailscale não recorre à rota mais abrangente. Por isso, esse tráfego é interrompido. Para um par de standby real, configure ambos os roteadores para anunciar os mesmos prefixos específicos.

O hostname é resolvido, mas a ligação expira por timeout. Por quê?

A resolução DNS e o encaminhamento são etapas separadas. Um nome pode ser resolvido para um endereço que não é abrangido por nenhuma rota aprovada. Nesse caso, o pacote sai através do gateway predefinido do cliente. Execute ip route get <address> no cliente. Se a resposta não incluir dev tailscale0, anuncie um intervalo que abranja esse endereço e aprove o novo prefixo na consola de administração.