Como usar seu VPS como nó de saída do Tailscale

O que um nó de saída do Tailscale faz

Um nó de saída do Tailscale é uma máquina na sua tailnet que transporta todo o tráfego de Internet dos seus outros dispositivos. Um VPS (servidor virtual privado) é uma boa opção porque tem um endereço público fixo e permanece online. A configuração tem cinco passos: instalar o Tailscale no servidor, anunciar o nó de saída, ativar o encaminhamento de IP, aprovar a rota no console de administração e selecionar o nó no portátil. O quarto passo é uma opção numa página Web, não um comando. É nessa etapa que a maioria das pessoas fica bloqueada.

Depois de ativado, o portátil encripta cada pacote e envia-o para o VPS. O VPS aplica NAT de origem (tradução de endereços de rede) e encaminha o pacote usando o seu próprio endereço IP público. Os sites veem o VPS. A rede Wi-Fi do café vê apenas um fluxo UDP encriptado para o VPS e nada mais.

O Tailscale usa WireGuard para o caminho de dados e um servidor de coordenação que distribui chaves e ajuda duas máquinas a encontrarem-se através de NAT. Esse servidor de coordenação é a razão pela qual não é necessário copiar chaves em nenhum dos passos abaixo. Para consultar uma comparação detalhada dos compromissos, leia como o Tailscale e o WireGuard simples se comparam. Se preferir controlar pessoalmente todas as partes do túnel, configure uma VPN WireGuard simples no seu VPS.

Os passos abaixo pressupõem que o Tailscale já está em execução no seu portátil e que ambas as máquinas iniciaram sessão na mesma tailnet. Uma tailnet é a sua rede privada do Tailscale, e cada dispositivo recebe nela um endereço estável dentro de 100.64.0.0/10.

Instalar o Tailscale no seu VPS

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

O script de instalação seleciona o repositório de pacotes da sua distribuição e instala o daemon tailscaled. Em seguida, tailscale up mostra um URL de autenticação. Abra-o num navegador e inicie sessão com a mesma conta que o seu portátil utiliza, porque um VPS autenticado numa tailnet diferente não consegue disponibilizar o seu portátil.

tailscale status
tailscale ip -4

tailscale status deve agora listar as duas máquinas. tailscale ip -4 mostra o endereço da tailnet do VPS. É esse endereço que será fornecido ao cliente mais tarde.

O Tailscale precisa de um dispositivo TUN para criar o túnel. Num VPS KVM, o dispositivo está disponível. Em planos baseados em virtualização por contentores que partilham o kernel do host, /dev/net/tun por vezes não está disponível e tailscaled não consegue criar a interface tailscale0. Execute ls -l /dev/net/tun antes de prosseguir.

Ative o encaminhamento de IP, ou o VPS descarta todos os pacotes

Uma máquina Linux descarta qualquer pacote que não seja destinado a si própria, porque net.ipv4.ip_forward é 0 por predefinição. O nó de saída aceitaria o seu tráfego, desencriptá-lo-ia e depois descartá-lo-ia. Escreva esta configuração num ficheiro para que sobreviva a um reboot.

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

tee -a acrescenta conteúdo, por isso executar estas linhas uma segunda vez escreve ambas as configurações duas vezes. O resultado continua a funcionar, mas cat /etc/sysctl.d/99-tailscale.conf ficará estranho. Confirme o valor ativo em vez de confiar no ficheiro:

sysctl net.ipv4.ip_forward

Deve apresentar net.ipv4.ip_forward = 1. Se ignorar este passo e utilizar tailscale up --advertise-exit-node, o cliente informa-o:

Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.

tailscale set --advertise-exit-node não faz essa verificação, por isso o silêncio de set não prova que o encaminhamento está ativo. Leia diretamente o valor de sysctl.

Não precisa de escrever manualmente uma regra de masquerade. tailscaled instala as suas próprias cadeias de firewall, chamadas ts-input, ts-forward e ts-postrouting, e a regra NAT para o tráfego do nó de saída está em ts-postrouting. Consulte-as com sudo iptables-save | grep ts- ou utilize sudo nft list ruleset num sistema com nftables.

Anuncie o VPS como exit node

sudo tailscale set --advertise-exit-node

tailscale set altera uma preferência e mantém as restantes inalteradas. tailscale up --advertise-exit-node também anuncia o node, mas tem um efeito secundário: up trata as flags da linha de comandos como o conjunto completo das definições não predefinidas. Por isso, um sudo tailscale up simples executado mais tarde recusa-se a funcionar e apresenta

changing settings via 'tailscale up' requires mentioning all
non-default flags. To proceed, either re-run your command with --reset or
use the command below to explicitly mention the current value of
all non-default settings:

Use set para alterações contínuas e nunca encontrará essa mensagem.

Anunciar é apenas uma oferta. O VPS passa a informar o coordination server de que está disponível para atuar como exit node. Nenhum cliente pode utilizá-lo ainda.

Aprovar o nó de saída do Tailscale no console de administração

Esta é a etapa que não tem um comando associado. Abra a página Machines no console de administração, localize o VPS, abra o menu de três pontos no fim da linha, selecione Edit route settings e ative Use as exit node.

Enquanto essa opção não estiver ativada, o plano de controlo mantém a oferta pendente e não a atribui a nenhum dispositivo. tailscale exit-node list no portátil não mostra nada, e o tráfego continua a usar a rota normal. Não é apresentada nenhuma mensagem de erro em nenhuma das máquinas. O nó de saída simplesmente nunca aparece.

Pode aprovar nós de saída automaticamente com uma entrada no ficheiro de política do tailnet:

"autoApprovers": {
  "exitNode": ["tag:exit"],
}

Um dispositivo iniciado com --advertise-tags=tag:exit é aprovado automaticamente, desde que tag:exit esteja definido em tagOwners no mesmo ficheiro de política. A atribuição de uma tag altera a propriedade: um dispositivo com tag pertence ao tailnet, e não à sua conta de utilizador, e as regras de acesso aplicáveis a esse dispositivo também mudam. Para um único VPS, a opção no console é mais simples.

Selecione o nó de saída no laptop

Num cliente Linux:

tailscale exit-node list
sudo tailscale set --exit-node=vps.your-tailnet.ts.net

exit-node list mostra os nós de saída aprovados na sua tailnet, juntamente com os respetivos endereços. Uma lista vazia significa que a etapa de aprovação não foi concluída. No macOS, Windows, iOS e Android, a mesma opção está disponível no menu Exit Node da aplicação Tailscale.

Verifique a partir do cliente, nunca a partir do servidor:

curl -4 https://ifconfig.me

Execute o comando uma vez antes de selecionar o nó de saída e outra vez depois. O endereço deve mudar do endereço local para o IP público do VPS. Para deixar de usar o nó de saída:

sudo tailscale set --exit-node=

Há mais uma flag importante no primeiro dia. Com um nó de saída selecionado, o cliente envia tudo pelo túnel, incluindo os pacotes destinados a 192.168.1.50. Por isso, a impressora e o armazenamento de rede deixam de responder. Mantenha a rede local na rota local:

sudo tailscale set --exit-node=<name> --exit-node-allow-lan-access=true

Por que o seu DNS muda assim que o exit node é ativado

Por padrão, um dispositivo que usa um exit node também usa esse exit node como resolvedor de DNS (domain name system) para todos os domínios. Isto substitui os servidores de DNS globais e split DNS configurados para a sua tailnet. Este comportamento é intencional. Se as consultas continuassem a ser enviadas para o resolvedor da rede local, o router do café continuaria a ver o nome de todos os sites que visita, enquanto o tráfego permaneceria privado. Os nomes e os pacotes devem sair do mesmo local.

Uma consequência afeta quem executa um resolvedor interno: um servidor de nomes da tailnet de que depende deixa de ser utilizado enquanto o exit node está ativo. Ative Use with exit node para esse servidor de nomes na página DNS da consola de administração para o voltar a utilizar.

Os nomes MagicDNS continuam a funcionar, porque o cliente Tailscale responde localmente a esses nomes em 100.100.100.100 antes de qualquer tráfego chegar ao exit node. Verifique com dig @100.100.100.100 your-vps.your-tailnet.ts.net ou, num cliente systemd-resolved, com resolvectl status, onde a interface Tailscale lista 100.100.100.100 como servidor DNS.

Se desativar o tratamento de DNS do Tailscale com --accept-dns=false, o cliente mantém o resolvedor que aprendeu da rede local. O tráfego é encaminhado pelo túnel, mas as consultas DNS não. Isto corresponde a a mesma fuga de DNS que afeta túneis WireGuard configurados manualmente. Deixe --accept-dns inalterado, exceto se tiver uma razão específica para o modificar.

IPv6 através do exit node

Um exit node anuncia ambas as rotas predefinidas, 0.0.0.0/0 e ::/0. Se o VPS não tiver um caminho IPv6 funcional para a Internet, os pacotes IPv6 chegam pelo túnel e ficam bloqueados nesse ponto. Teste no VPS antes de confiar nele:

ip -6 addr show
curl -6 https://ifconfig.me

Uma solicitação falhada significa que o VPS não tem conectividade IPv6 a montante. Os sites com dual stack normalmente continuam a carregar, porque o cliente desiste do IPv6 e tenta novamente através do IPv4, embora essa nova tentativa acrescente um atraso na primeira ligação a cada site. Os destinos acessíveis apenas por IPv6 continuam inacessíveis.

A outra parte é o encaminhamento. net.ipv4.ip_forward = 1 com net.ipv6.conf.all.forwarding definido como 0 fornece um caminho IPv4 funcional e um black hole para IPv6. Para o utilizador, isto parece que "alguns sites estão lentos", e não um erro que seja fácil pesquisar. Ambas as linhas devem estar no ficheiro sysctl.

O VPS também deve anunciar rotas de sub-rede?

Um nó de saída transporta todo o tráfego da Internet. Uma rota de sub-rede transporta um intervalo privado que está atrás da máquina que o anuncia. São funcionalidades separadas, com aprovações separadas, e uma máquina pode fazer ambas. Nenhuma delas expõe um serviço em execução no próprio VPS. Portanto, se o que pretende é um URL HTTPS para uma aplicação nesse servidor, as funcionalidades serve e funnel são as opções corretas.

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

Anuncie uma sub-rede quando o VPS partilhar uma rede privada com outros servidores aos quais pretende aceder através dos respetivos endereços privados. Aprove a rota no mesmo painel Edit route settings, através do seu próprio seletor. Os clientes Linux ignoram a rota anunciada até executar --accept-routes. Esta é uma das diferenças que o guia do router de sub-rede explica em detalhe.

Escolha o intervalo com cuidado. Uma rota anunciada é mais específica do que a rota predefinida do portátil. Por isso, anunciar 192.168.1.0/24 a partir do VPS assume o controlo dos endereços de uma rede doméstica que utilize o mesmo intervalo, e os dispositivos na sua secretária deixam de responder. Use um intervalo que tenha escolhido, não o intervalo escolhido pelo router doméstico.

Torne o exit node mais rápido com encaminhamento UDP GRO

O Tailscale 1.54 e versões posteriores, num kernel Linux 6.2 ou posterior, podem usar um mecanismo de receive offload que aumenta o throughput do tráfego encaminhado. O GRO (generic receive offload) combina os pacotes recebidos antes de o kernel os processar individualmente. Em agosto de 2026, esta configuração ainda precisa de ser aplicada manualmente no exit node.

sudo apt install -y ethtool
NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

ip -o route get 8.8.8.8 mostra a interface que efetivamente chega à Internet, para não ter de escolher entre eth0, ens3 e enp1s0. Confirme com ethtool -k $NETDEV | grep udp-gro-forwarding, que agora deve mostrar on. O GRO só ajuda quando o caminho está saudável. Se o exit node continuar lento, meça o próprio caminho da mesma forma que faria com um túnel WireGuard simples que é mais lento do que a ligação subjacente.

A configuração perde-se depois de um reboot. Num sistema que utiliza networkd-dispatcher, torne-a automática:

printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

Verifique primeiro se /etc/networkd-dispatcher/routable.d/ existe. Se não existir, a máquina não está a executar networkd-dispatcher. Nesse caso, uma pequena unidade systemd que execute a linha ethtool no boot faz o mesmo trabalho.

O que a política de utilização aceitável do seu fornecedor significa para o tráfego de saída

Cada pacote que um cliente envia através do nó de saída sai com o endereço IP público do VPS, pelo que é associado à sua conta. As denúncias de abuso chegam à sua caixa de entrada: avisos de direitos de autor e reclamações sobre análises de portas. Leia a AUP (política de utilização aceitável) do seu fornecedor antes de encaminhar o tráfego de uma residência ou de uma equipa através de um único servidor. Não disponibilize um nó de saída a pessoas pelas quais não possa assumir responsabilidade.

A largura de banda é contabilizada duas vezes. O tráfego chega ao VPS através do túnel e depois sai novamente para a internet. Normalmente, ambas as direções contam para o limite de transferência do plano. Um fluxo de vídeo visto através de um nó de saída representa um consumo maior do que a maioria das pessoas espera.

Os intervalos de endereços de datacenter também têm uma reputação associada. Alguns sites apresentam mais CAPTCHAs a esses endereços, e alguns serviços de streaming recusam-nos diretamente. Nenhuma alteração na sua configuração muda esse comportamento, porque ele resulta do bloco de endereços que o seu fornecedor possui.

Por que o tráfego continua a sair pela sua ligação local

O nó de saída foi anunciado, mas não foi aprovado. tailscale exit-node list no cliente não apresenta nada, e nenhuma das máquinas regista um erro. Aceda à página Machines e ative Use as exit node.

O cliente nunca o selecionou. A aprovação disponibiliza o nó na tailnet. A seleção é uma ação separada em cada dispositivo. Execute novamente sudo tailscale set --exit-node=<name> e verifique curl -4 https://ifconfig.me.

O encaminhamento está desativado. O sintoma é específico: tailscale ping <vps> funciona, o túnel está claramente ativo e todos os endereços externos atingem o tempo limite. sysctl net.ipv4.ip_forward apresenta o valor 0. Corrija o ficheiro sysctl e execute sudo sysctl -p /etc/sysctl.d/99-tailscale.conf.

Uma firewall descarta os pacotes encaminhados. tailscaled insere a sua própria cadeia ts-forward, o que é suficiente num VPS limpo. Um servidor que já execute ufw ou Docker pode ficar com uma política FORWARD definida como DROP e regras posicionadas antes das regras do Tailscale. Não tente adivinhar qual é a causa: execute sudo iptables -L FORWARD -n -v enquanto o cliente tenta carregar uma página e monitorize quais os contadores que aumentam. Num servidor com ufw, a correção habitual é DEFAULT_FORWARD_POLICY="ACCEPT" em /etc/default/ufw, seguida de sudo ufw reload. Verifique também a firewall de rede do seu provedor no painel de controlo, pois esse é um controlo separado de tudo o que esteja a executar no servidor.

Funciona, mas está lento. Execute tailscale netcheck nas duas máquinas. Se indicar que o UDP está bloqueado, os dois dispositivos não conseguem estabelecer um caminho direto e recorrem a um relay DERP, o que acrescenta latência a todas as ligações. Permitir tráfego UDP de entrada na porta 41641 para o VPS na firewall de rede do provedor normalmente restaura o caminho direto.

Quando deixar de usar o servidor de coordenação do Tailscale

Tudo isto depende do servidor de coordenação alojado da Tailscale para a troca de chaves e para a aprovação que efetuou. O tráfego continua a seguir diretamente do portátil para o VPS. O servidor de coordenação nunca o transporta, embora determine quem pode aderir à tailnet e a que cada dispositivo pode aceder. O preço raramente é o motivo para mudar, porque o plano gratuito inclui seis utilizadores com dispositivos próprios ilimitados. Por isso, avalie a dependência em si, e não o custo. A sétima pessoa é o ponto em que isso muda. Como a Tailscale cobra por utilizador, e não por dispositivo, calcule quanto paga realmente uma família ou uma equipa de cinco pessoas antes de decidir com base no custo. Avaliar isto de forma correta exige saber a que recursos um servidor de coordenação comprometido ou uma conta de identidade roubada poderia efetivamente aceder. É isso que o modelo de confiança da Tailscale descreve. Se quiser eliminar essa dependência, execute o Headscale como o seu próprio servidor de controlo da Tailscale e aponte ambos os clientes para ele. Depois disso, os passos do nó de saída são os mesmos. A aprovação da rota é feita através da linha de comandos do Headscale, e não da consola alojada. O Headscale substitui o plano de controlo, mas permite continuar a usar os clientes Tailscale. Se preferir gerir toda a infraestrutura, o NetBird disponibiliza o seu próprio servidor de coordenação e clientes que pode alojar num VPS.

FAQ

Por que o meu tráfego continua a usar a ligação local depois de selecionar o exit node?

Há duas causas comuns. O exit node foi anunciado, mas nunca foi aprovado: abra a página Machines na consola de administração, localize o VPS, selecione Edit route settings e ative Use as exit node. A aprovação é feita por um controlo na consola. Nenhum comando no servidor a executa. A segunda causa é diferente: o encaminhamento IP está desativado. Nesse caso, o túnel é estabelecido, tailscale ping para o VPS funciona e todos os endereços externos atingem o tempo limite. Verifique com sysctl net.ipv4.ip_forward, que tem de apresentar 1.

Tenho de aprovar manualmente o exit node sempre que o utilizo?

O controlo é uma ação única para cada máquina. Se recriar o VPS com frequência, adicione um bloco autoApprovers ao ficheiro de políticas do tailnet que contenha "exitNode": ["tag:exit"], defina tag:exit em tagOwners e ative o nó com --advertise-tags=tag:exit. Um dispositivo com uma tag pertence ao tailnet, e não à sua conta de utilizador. Por isso, as regras de acesso aplicadas ao dispositivo também mudam.

Que servidor DNS o meu portátil usa quando um exit node está ativo?

O próprio exit node. Um dispositivo que usa um exit node envia para ele todas as consultas DNS. Isto substitui os servidores DNS globais e split DNS definidos para o tailnet. A rede local deixa de ver os nomes que consulta. Para manter um servidor DNS do tailnet ativo, ative Use with exit node para esse servidor na página DNS da consola de administração. Os nomes MagicDNS continuam a ser resolvidos, porque o cliente Tailscale responde localmente em 100.100.100.100.

Um VPS pode ser exit node e subnet router ao mesmo tempo?

Sim. sudo tailscale set --advertise-exit-node e sudo tailscale set --advertise-routes=10.0.0.0/24 são independentes, e cada um tem o seu próprio controlo de aprovação em Edit route settings. O encaminhamento IP tem de estar ativo no VPS para ambos. Evite anunciar um intervalo que corresponda à rede doméstica do seu portátil. A rota anunciada é mais específica do que a rota predefinida, e os dispositivos locais deixam de estar acessíveis.

Um exit node oculta o meu tráfego do meu fornecedor de VPS?

Não. O túnel termina no VPS. O tráfego sai do servidor no formato esperado pelo destino, e o fornecedor transporta-o sem cifragem nos casos em que o próprio site não está cifrado. Um exit node muda o ponto onde o seu tráfego entra na Internet: passa da rede onde se encontra para o servidor que arrenda. Oculta a sua navegação do Wi-Fi do café e do ISP doméstico. No entanto, essa mesma navegação fica visível para o fornecedor do VPS, associada ao nome da sua conta.