Como configurar um subnet router do Tailscale em VPS

O que um subnet router do Tailscale faz

Um subnet router do Tailscale é uma máquina que anuncia todo um intervalo de endereços IP privados ao seu tailnet. Assim, todos os dispositivos no tailnet podem aceder aos endereços desse intervalo, mesmo que nenhum dispositivo nesse intervalo execute o Tailscale. O seu 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 isto, 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 do tailnet. Um exit node altera o local de onde o seu tráfego público sai. Se pretende a segunda opção, leia como executar um exit node do Tailscale num VPS. São flags distintas, e um VPS pode desempenhar ambas as funções ao mesmo tempo, mas resolvem problemas diferentes e falham de formas diferentes.

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

O caso comum é uma rede privada que o fornecedor já disponibilizou. O VPS tem um endereço público e uma segunda interface num segmento privado. 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 o Tailscale num VPS, anuncie 10.0.0.0/24 e o seu portátil poderá aceder diretamente a esses endereços privados. Nada mais se altera no segmento, e a base de dados continua sem endereço público.

O outro caso é uma rede localizada para além do VPS. Pode ser uma LAN doméstica ou de escritório atrás do seu próprio router, ou um conjunto de dispositivos que não podem executar o Tailscale, como um switch gerido ou um NAS antigo com firmware bloqueado. Um sistema Linux nessa rede funciona como router de sub-rede para todos os restantes dispositivos.

Os dois casos têm um requisito em comum. O router de sub-rede já tem de conseguir aceder ao intervalo que anuncia, usando a sua própria tabela de encaminhamento e a sua própria firewall. O Tailscale não estabelece 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, que deve apresentar active.

Antes de mais, 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 apresentar o intervalo privado numa interface real, algo como 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. Se o ping falhar aqui, no próprio router, nenhuma opção do Tailscale o corrigirá. O problema está na configuração de rede do VPS ou numa firewall no host de destino. Corrija-o 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 os 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 com sysctl net.ipv4.ip_forward, que deve apresentar net.ipv4.ip_forward = 1.

É comum configurar este passo apenas parcialmente. sudo sysctl -w net.ipv4.ip_forward=1 funciona imediatamente, mas desaparece no arranque seguinte. Assim, o router de sub-rede funciona durante semanas e deixa de funcionar 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 e o kernel descarta-os sem registar nada. Escrever os valores em /etc/sysctl.d/99-tailscale.conf é o que os restaura após um reboot.

Se anunciar rotas com o encaminhamento ainda desativado, tailscale up avisa-o 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 uma única opção redefine as opções que não forem repetidas, e a CLI interrompe a operação com um erro informando que, para alterar as configurações desta forma, é necessário indicar todas as opções não padrão. tailscale set altera uma opção e mantém as restantes.

Vários intervalos são indicados 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 (roteamento entre domínios sem classes, no formato 10.0.0.0/24). Se indicar por engano o endereço do próprio host, 10.0.0.5/24, a operação será rejeitada porque os bits após o prefixo não são zero, e o erro indicará 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. Até um administrador 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 escolher.

Aprove-a na página Machines da consola de administração. O VPS aparece com um indicador de sub-rede. Abra a respetiva linha, localize a secção de sub-redes, 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 ficará por aprovar, enquanto o antigo continuará a funcionar. Para o VPS, uma rota aprovada e uma rota ignorada têm o mesmo aspeto. Por isso, consulte a consola antes de procurar outras causas.

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, ative o nó com essa tag, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, e 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 recriar o VPS a partir de um script, porque um nó recriado é 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á é 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 sub-rede 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 intencionalmente por alguém. Inserir silenciosamente uma /24 aprendida da rede pode interromper o tráfego que essa máquina já gere. Por isso, no Linux, tem de ativar esta opção em cada cliente:

sudo tailscale set --accept-routes

Em seguida, verifique onde a rota foi instalada:

ip route show table 52
ip route get 10.0.0.20

No Linux, o Tailscale 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. 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.

Há uma exceção que deve conhecer. Se este nó Linux for também um segundo router de sub-rede da sua própria rede local, --accept-routes fará com que o tráfego destinado à sub-rede diretamente ligada seja enviado através do outro router, em vez de sair pela sua própria interface. Num router de reserva de um 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. É permitido usar 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 é encaminhado pelo A.

O comportamento que costuma surpreender é o que acontece quando o 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 do 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, ambos 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 um intervalo dentro de 10.0.0.0/8 de forma deliberada. A mesma colisão também interrompe uma VPN WireGuard simples configurada manualmente, pelo mesmo motivo: a rota local mais específica ganha, por isso 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 servidor de nomes privado e que tenha anunciado 10.0.0.0/24. A consulta é bem-sucedida porque a resolução DNS (sistema de nomes de domínio) 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 permitem separar as duas etapas:

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 servidor de nomes. Se definir um servidor de nomes global na consola de administração com um 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 alcançar o resolvedor. Se ativar a opção que substitui os servidores DNS locais enquanto aponta para um resolvedor inacessível, todos os dispositivos da tailnet perdem a resolução de nomes de uma só vez, incluindo os que funcionavam um segundo antes. Anuncie e aprove primeiro a rota para o resolvedor. Depois altere a definição de DNS. Se o DNS dentro de um túnel for o problema que continua a tentar resolver, 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 a site

Por predefinição, o router de sub-rede reescreve o endereço de origem de todos os pacotes encaminhados para o seu próprio endereço privado. Isto é SNAT (tradução de endereços de rede de origem) e permite que as respostas funcionem sem alterar nada na rede privada: a base de dados em 10.0.0.20 responde ao VPS, que já sabe como alcançar. A desvantagem é que a base de dados vê todas as ligações da tailnet como se viessem do VPS. Assim, as regras de firewall por origem e os logs de acesso não fornecem informação útil.

Desative esta funcionalidade 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 a site usa dois routers de sub-rede 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 ficarem bloqueadas enquanto ssh e ping funcionam, a causa é o MSS (tamanho máximo do segmento), 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 corrige 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, desaparece no próximo boot.

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

As chaves dos nós expiram após 180 dias por predefinição, desde agosto de 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 desta 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 de 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 na porta 41641 e a maioria dos pares estabelecerá uma ligação direta. 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 parte. Numa tailnet predefinida, todos os seus dispositivos podem alcançar-se entre si, pelo que uma rota aprovada funciona imediatamente. 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 pretende utilizar um servidor de coordenação que não seja 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íticas ficam nesse serviço. Executar o Headscale, o servidor de controlo do Tailscale autoalojado mantém esses componentes no seu próprio VPS, mas exige que faça a respetiva manutenção. 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 quais são os seus custos.

FAQ

Qual é a diferença entre um subnet router e um exit node?

Um subnet router anuncia um intervalo de endereços privados, para que os dispositivos da tailnet possam alcançar máquinas que não executam Tailscale. Um exit node anuncia-se como rota para toda a Internet, para que um dispositivo envie todo o seu tráfego através do endereço público desse nó. Um VPS pode desempenhar ambas as funções. São flags separadas, --advertise-routes e --advertise-exit-node, e cada uma precisa da sua própria aprovação na consola de administração.

Por que motivo o meu cliente Linux ignora a rota de subnet anunciada?

Os clientes Linux não aceitam rotas de subnet sem que isso seja explicitamente solicitado. Execute sudo tailscale set --accept-routes no cliente. Depois, 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 parece estar em falta.

A minha subnet deixou de funcionar depois de um reboot. O que falhou?

Provavelmente, o encaminhamento IP. Um valor definido com sysctl -w não sobrevive a 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 por predefinição após 180 dias, e um subnet router com a chave expirada parece um problema de rede, não um problema de conta.

Dois subnet routers podem anunciar o mesmo intervalo?

Não podem anunciar intervalos idênticos. Intervalos sobrepostos com comprimentos de prefixo diferentes são válidos, e vence o mais específico. O failover exige atenção: quando o router que mantém o prefixo mais específico fica offline, o Tailscale não recorre à rota mais abrangente, por isso o tráfego é interrompido. Para ter um par de standby real, faça com que ambos os routers anunciem os mesmos prefixos específicos.

O hostname é resolvido, mas a ligação excede o tempo limite. Porquê?

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, e o pacote sai então 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.