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 lado remoto do VPS. Pode ser uma LAN (rede local) doméstica ou de escritório atrás do seu próprio router, ou um conjunto de equipamentos que não consegue executar 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 equipamentos. O router doméstico que está à frente desse sistema não precisa de nenhuma porta encaminhada para isto, e como o Tailscale atravessa o NAT sem abrir uma porta no router explica por que razão isto funciona e quando recorre a um relay. Em casa, esse sistema é frequentemente uma pequena 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 esclarecer 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 endereçado a si própria, exceto quando o encaminhamento está 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 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ã após um reboot provocado 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 como 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. No Linux, a mensagem é semelhante a Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.. 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 podem anunciar intervalos idênticos. É assim que funciona um par de alta disponibilidade: cada router anuncia exatamente os mesmos prefixos, e os clientes podem fazer failover de um para o outro. Também 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 recua para a rota menos específica, porque um router offline não consegue retirar o anúncio e os clientes continuam a preferir o prefixo mais específico. O tráfego para 10.0.0.20 para, enquanto o tráfego para 10.0.1.20, abrangido apenas por /16 de B, continua a funcionar através de B. O sintoma parece ser uma falha numa parte da rede privada, mas a causa é um nó offline que mantém o prefixo mais específico. Se quiser failover, faça com que o router com o intervalo mais abrangente anuncie também os prefixos mais estreitos, para que ambos cubram os mesmos endereços.

A outra sobreposição ocorre mais perto do cliente. Estar numa rede de hotel em 192.168.1.0/24 enquanto o router de sub-rede anuncia 192.168.1.0/24 significa que os dois competem pelos mesmos destinos, e o vencedor depende da plataforma. No Linux, instale uma regra antes da regra própria do 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. A mesma colisão também interrompe uma VPN WireGuard simples configurada manualmente, pelo mesmo motivo: a rota local mais específica vence, e 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 (domain name system) e o encaminhamento IP são etapas separadas, e nenhuma verifica a outra. Em seguida, o pacote para 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 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 neste cliente. Num cliente Linux, confirme primeiro se --accept-routes está ativado, porque, sem essa opção, nenhuma rota de sub-rede é instalada, mesmo quando um prefixo aprovado já abrange o endereço. Se estiver ativado e nenhum prefixo aprovado abranger o endereço, anuncie um intervalo que o abranja, usando 10.0.0.0/16 ou um segundo prefixo explícito. Em seguida, 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 para um endereço privado como 10.0.0.53, esse endereço tem de estar dentro de uma rota aprovada. Caso contrário, os dispositivos que não estão nessa rede privada 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 ao mesmo tempo, incluindo os que funcionavam um segundo antes. Anuncie e aprove primeiro a rota para o resolvedor. Só depois altere a configuração DNS. Se o DNS dentro de um túnel for a parte que continua a causar problemas, 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 ativo

A expiração da chave desta máquina depende da forma como iniciou sessão. Um nó configurado com uma tag, como no exemplo autoApprovers acima, tem a expiração da chave desativada por predefinição desde o momento em que recebe a tag e é autenticado pela primeira vez, por isso essa configuração não exige nenhuma ação aqui. Um nó que iniciou sessão como o utilizador segue o período de expiração de chaves do tailnet, que é de 180 dias por predefinição num tailnet novo e pode ser definido entre 1 e 180 dias, em outubro de 2026. Quando a chave de um router de sub-rede como esse expira, as ligações de e para ele param e todo o intervalo anunciado fica inacessível, sem que exista uma alteração de configuração que explique o problema. Para um router que iniciou sessão como utilizador, desative a expiração da chave no menu no fim da respetiva linha, 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 simples: permita a entrada de UDP na porta 41641 e a maioria dos pares estabelecerá ligações diretas. Quando o tráfego para o intervalo privado é mais lento do que a ligação ao VPS deveria permitir, verificar se o cliente chega diretamente ao router de sub-rede ou através de um relay é a primeira coisa a excluir. Se o ufw estiver a gerir a firewall, as regras ufw de que um VPS realmente precisa explicam a sintaxe.

As regras de acesso são a outra metade. Num tailnet predefinido, todos os seus dispositivos podem alcançar todos os outros, por isso uma rota aprovada funciona imediatamente. Depois de escrever uma política ACL, o lado de destino de uma regra tem de abranger o intervalo privado, especificando-o pelo nome ou usando o wildcard *, que inclui rotas de sub-rede aprovadas, porque 10.0.0.20 não é um endereço do tailnet e não é abrangido por regras escritas para endereços IP ou tags do tailnet.

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íticas ficam nesse serviço. Antes de lhe dar uma rota para a sua rede privada, deve avaliar o que alguém poderia efetivamente fazer com um plano de controlo comprometido ou com credenciais de identidade roubadas. O modelo de confiança do Tailscale define os limites dessa relação. O custo raramente é o motivo para abandonar o serviço, porque o plano gratuito suporta até seis utilizadores com dispositivos ilimitados de cada utilizador. No entanto, um router de sub-rede que inicia sob uma tag é contabilizado de forma diferente de um router com sessão iniciada pela sua própria conta. A partir desse limite, a faturação acompanha o número de pessoas, não o número de máquinas. Por isso, vale a pena calcular quanto uma família ou uma equipa de cinco pessoas paga efetivamente quando o plano gratuito termina antes de adicionar a conta que faz ultrapassar o limite. Executar o servidor de controlo Tailscale autoalojado Headscale mantém esse serviço no seu próprio VPS, mas exige que o mantenha. Outra resposta à mesma preocupação é deixar também de utilizar os clientes Tailscale. A autoalojamento do servidor VPN NetBird coloca a camada de coordenação e os próprios clientes mesh numa máquina que controla. Ambos utilizam WireGuard por baixo. Assim, os aspetos que mudam quando troca de solução são os que a comparação entre NetBird e Tailscale avalia: quem gere o plano de controlo, como escreve a regra de acesso que abrange o seu intervalo privado e como o tráfego é encaminhado quando os peers não conseguem estabelecer uma ligação direta. 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 seu custo.

FAQ

Qual é a diferença entre um router de sub-rede e um exit node?

Um router de sub-rede anuncia um intervalo de endereços privados, para que os dispositivos do tailnet possam alcançar máquinas que não executam o Tailscale. Um exit node anuncia-se como uma rota para toda a Internet, por isso um dispositivo envia 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 distintas, --advertise-routes e --advertise-exit-node, e cada uma exige a sua própria aprovação na consola de administração.

Porque é 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 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 sub-rede deixou de funcionar depois de um reboot. O que falhou?

Provavelmente, o encaminhamento IP. Um valor definido com sysctl -w não persiste depois de 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. Um router que iniciou sessão como utilizador tem uma chave que expira depois de 180 dias por predefinição, e um router de sub-rede com a chave expirada parece uma falha de rede e não um problema de conta. Um router configurado com uma tag tem a expiração da chave desativada por predefinição, por isso, nesse caso, procure a causa noutro local.

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

Sim. Intervalos idênticos são a forma de criar um par de alta disponibilidade: ambos os routers anunciam exatamente os mesmos prefixos. Também são permitidos intervalos sobrepostos com comprimentos de prefixo diferentes, e o mais específico tem precedência. O failover exige atenção: quando o router que detém o prefixo mais específico fica offline, o Tailscale não recorre à rota mais abrangente, por isso esse tráfego para. Para 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 nenhuma rota aprovada abrange, 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 num cliente Linux, verifique primeiro se --accept-routes está ativo. Se estiver, anuncie um intervalo que abranja esse endereço e aprove o novo prefixo na consola de administração.