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 da 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 na consola de administração e selecionar o nó no portátil. O quarto passo é uma opção numa página Web, não um comando. É nesse ponto 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 não vê mais nada.

O Tailscale usa WireGuard no plano 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 é o motivo pelo qual não é necessário copiar chaves em nenhum dos passos abaixo. Para conhecer devidamente as diferenças, leia como o Tailscale e o WireGuard simples se comparam. Se preferir controlar todos os componentes do túnel, configure uma VPN WireGuard simples no seu VPS.

Os passos abaixo pressupõem que o Tailscale já está a ser executado no seu portátil e que as duas máquinas iniciaram sessão na mesma tailnet. Uma tailnet é a sua rede privada do Tailscale. A menos que um administrador tenha desativado o IPv4 nessa rede, todos os dispositivos recebem 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 nó de saída

Um nó de saída anuncia as duas 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 parados nesse ponto. Teste no VPS antes de confiar nele:

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

Uma ligação que falha significa que o VPS não tem um caminho IPv6 funcional para a Internet. Se o curl devolver "Could not resolve host", o problema está na resolução de nomes, não no IPv6. Corrija o DNS no VPS e execute o teste novamente. Os sites com suporte dual stack normalmente continuam a carregar, porque os clientes que implementam Happy Eyeballs, incluindo o curl, iniciam uma tentativa IPv4 em paralelo quando a tentativa IPv6 não estabelece ligação após uma breve espera e mantêm a que estabelecer ligação primeiro. Por predefinição, o curl espera 200 milissegundos. Essa espera acrescenta um atraso às novas ligações, mas não provoca um erro. Os destinos acessíveis apenas por IPv6 continuam indisponí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 manifesta-se como "alguns sites estão lentos", e não como um erro fácil de pesquisar. As duas linhas devem ficar no ficheiro sysctl.

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

Um nó de saída transporta todo o tráfego de 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 usar ambas. Nenhuma delas expõe um serviço executado no próprio VPS. Se o que pretende é um URL HTTPS para uma aplicação nesse servidor, serve e funnel são as funcionalidades adequadas.

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

Anuncie uma sub-rede quando o VPS partilhar uma rede privada com outros servidores que pretende alcançar pelos respetivos endereços privados. Aprove a rota no mesmo painel Edit route settings, usando o respetivo botão de ativação. Os clientes Linux ignoram a rota anunciada até passar --accept-routes. Esta é uma das diferenças que o guia de configuração do router de sub-rede explica em detalhe.

Escolha o intervalo com cuidado. Depois de uma rota ser aprovada, um portátil que a aceite (Windows, macOS, iOS e Android fazem isso por predefinição; no Linux, depois de --accept-routes) pode enviar para o túnel o tráfego destinado a esse intervalo. Se aprovar 192.168.1.0/24 no VPS e um portátil numa rede doméstica usar o mesmo intervalo, esses endereços podem passar para o túnel, e os dispositivos na sua secretária deixam de responder. Use um intervalo escolhido por si, não o intervalo que o router doméstico escolheu.

Torne o exit node rápido com encaminhamento UDP GRO

O Tailscale 1.54 e versões posteriores, com um kernel Linux 6.2 ou posterior, pode usar um mecanismo de receive offload que aumenta o throughput do tráfego encaminhado. O GRO (generic receive offload) agrega os pacotes recebidos antes de o kernel os processar individualmente. Em outubro de 2026, esta configuração ainda é manual 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 informa a interface que efetivamente alcança a internet, por isso não precisa de escolher entre eth0, ens3 e enp1s0. Confirme com ethtool -k $NETDEV | grep udp-gro-forwarding, que agora deve apresentar 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 fica mais lento do que a ligação subjacente.

A configuração é perdida após um reboot. Num sistema que executa o 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 o networkd-dispatcher. Nesse caso, uma pequena unidade systemd que execute a linha ethtool no boot faz o mesmo trabalho.

O que significa a política de utilização aceitável do seu provedor para o tráfego do exit node

Cada pacote que um cliente envia através do exit node sai com o endereço IP público do VPS, por isso é atribuído à sua conta. As denúncias de abuso chegam à sua caixa de entrada: avisos de direitos de autor e reclamações sobre port scans. Leia a AUP (acceptable use policy) do seu provedor antes de encaminhar o tráfego de uma residência ou de uma equipa através de um único servidor. Não disponibilize um exit node a pessoas por quem não possa assumir responsabilidade.

A largura de banda é contabilizada uma vez, no sentido de saída. Cada byte que passa pelo exit node atravessa o VPS duas vezes: chega por um lado e sai pelo outro. Na maioria dos planos VPS, apenas a metade de saída é contabilizada. Em outubro de 2026, a SSD Nodes lista a franquia de todos os planos KVM como outbound transfer, entre 4TB e 48TB por mês. A documentação da Vultr afirma que o tráfego de entrada não é contabilizado. Num download, o trecho contabilizado é a viagem do VPS pelo túnel até ao seu laptop. Num upload, é a viagem do VPS para a internet. Em ambos os casos, tudo o que encaminhar através do exit node conta uma vez para a franquia. Um stream de vídeo visto através de um exit node representa mais tráfego do que a maioria das pessoas espera. Consulte o seu próprio plano, porque um host que contabilize os dois sentidos conta esse stream duas vezes.

Os intervalos de endereços dos datacenters 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. Nada na sua configuração altera isso, porque é uma propriedade do bloco de endereços pertencente ao seu provedor.

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 o servidor de coordenação do Tailscale

Tudo o que foi descrito acima depende do servidor de coordenação alojado do Tailscale para a troca de chaves e para a aprovação que selecionou. O seu tráfego segue diretamente do portátil para o VPS ou passa por um dos relays DERP do Tailscale quando não é possível estabelecer um caminho direto. O servidor de coordenação nunca transporta esse tráfego, embora determine quem pode entrar na tailnet e a que cada dispositivo pode aceder. O preço raramente é motivo para mudar, porque o plano gratuito inclui seis utilizadores com dispositivos próprios ilimitados, por isso avalie a própria dependência, e não o custo. É a entrada da sétima pessoa que altera essa situação. Como o Tailscale cobra por utilizador, e não por dispositivo, calcule quanto paga efetivamente uma família ou uma equipa de cinco pessoas antes de decidir com base no custo. Avaliar isto de forma realista exige saber a que poderia efetivamente aceder um servidor de coordenação comprometido ou uma conta de identidade roubada. É isso que o modelo de confiança do Tailscale define. Se pretende remover essa dependência, execute o Headscale como o seu próprio servidor de controlo do Tailscale e aponte ambos os clientes para ele. Depois disso, os passos do exit node 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 utilizar os clientes do Tailscale. Se preferir executar toda a stack, o NetBird inclui 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 nó de saída?

Há duas causas comuns. O nó de saída 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 é uma opção da consola; nenhum comando no servidor a executa. A segunda causa é diferente: o encaminhamento IP está desativado. O túnel é estabelecido, tailscale ping para o VPS funciona, mas todos os endereços externos atingem o tempo limite. Verifique com sysctl net.ipv4.ip_forward, que deve apresentar 1.

Tenho de aprovar manualmente o nó de saída todas as vezes?

A opção é ativada uma única vez para cada máquina. Se recriar o VPS com frequência, adicione um bloco autoApprovers ao ficheiro de política da tailnet que contenha "exitNode": ["tag:exit"], defina tag:exit em tagOwners e coloque o nó online com --advertise-tags=tag:exit. Um dispositivo com uma tag pertence à tailnet, e não à sua conta de utilizador. Por isso, as regras de acesso aplicáveis também mudam.

Que servidor DNS o meu portátil utiliza enquanto um nó de saída está ativo?

O próprio nó de saída. Um dispositivo que utiliza um nó de saída envia para ele todas as consultas DNS. Isso substitui os servidores DNS globais e split DNS definidos para a tailnet. A rede local deixa de ver os nomes que consulta. Para manter um servidor DNS da 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 simultaneamente um nó de saída e um router de sub-rede?

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 a sua própria opção 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. Quando essa rota for aprovada e o portátil a aceitar, poderá assumir esses endereços da rede local e tornar os dispositivos locais inacessíveis.

Um nó de saída oculta o meu tráfego do fornecedor do VPS?

Não. O túnel termina no VPS. Por isso, o tráfego sai do servidor no formato esperado pelo destino, e o fornecedor transporta-o sem encriptação sempre que o próprio site não utiliza encriptação. Um nó de saída altera o ponto onde o tráfego entra na Internet, passando da rede onde está ligado para o servidor que aluga. Oculta a sua navegação do Wi-Fi do café e do ISP doméstico, mas mostra essa mesma navegação ao fornecedor do VPS, associada ao nome da sua conta.