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

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

Um nó de saída do Tailscale é uma máquina na sua tailnet que transporta todo o tráfego da Internet dos restantes dispositivos. Um VPS (servidor privado virtual) é uma boa opção porque tem um endereço público fixo e permanece online. A configuração exige 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 consiste numa caixa de seleção numa página web, não num comando. É nessa etapa que a maioria das pessoas fica bloqueada.

Depois de ativado, o portátil cifra todos os pacotes e envia-os para o VPS. O VPS aplica NAT de origem (tradução de endereços de rede) e envia 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 cifrado para o VPS. Não vê mais nada. Sem um nó de saída, o Tailscale transporta apenas o tráfego entre os seus próprios dispositivos. Cada site continua a ver o seu endereço real. Esta é a distinção que determina se o Tailscale pode ser considerado uma VPN.

O Tailscale usa WireGuard no plano de dados e um servidor de coordenação que distribui chaves e ajuda duas máquinas a encontrar-se através de NAT. Esse servidor de coordenação é o motivo pelo qual não é necessário copiar chaves nos passos abaixo. Para conhecer corretamente as vantagens e limitações, leia como o Tailscale e o WireGuard simples se comparam. Se preferir controlar 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 iniciam sessão na mesma tailnet. Uma tailnet é a sua rede privada do Tailscale. A menos que um administrador tenha desativado o IPv4 nessa rede, cada dispositivo recebe 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 exit node do Tailscale na consola de administração

Este é o passo que não tem nenhum comando associado. Abra a página Machines na consola de administração e localize o VPS, que deverá apresentar agora o selo Exit Node. Abra o menu desse dispositivo, escolha Edit exit node, marque a caixa Use as exit node e selecione Save.

Enquanto essa caixa não for marcada e guardada, o plano de controlo mantém a oferta pendente e não a atribui a nenhum dispositivo. tailscale exit-node list no seu portátil não mostra nada e o tráfego continua a seguir a rota normal. Não é apresentada nenhuma mensagem de erro em nenhuma das máquinas. O exit node simplesmente nunca aparece.

Pode aprovar exit nodes 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: o dispositivo com tag pertence ao tailnet, e não à sua conta de utilizador, e as regras de acesso aplicadas a esse dispositivo também mudam. Para um único VPS, a caixa de seleção é 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 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 existe 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 em execução 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 aos quais pretende aceder através dos respetivos endereços privados. Aprove a rota na sua própria caixa de diálogo, separada da do nó de saída: na página Machines, selecione o VPS, abra a secção Subnets, selecione Edit para abrir Edit subnet routes, selecione a rota e, em seguida, selecione Save. Os clientes Linux ignoram a rota anunciada até executar --accept-routes. Esta é uma das diferenças que o guia passo a passo do router de sub-rede explica em detalhe.

Escolha o intervalo com cuidado. Depois de aprovada uma rota, um portátil que a aceite (Windows, macOS, iOS e Android fazem-no 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 ser encaminhados para o túnel e os dispositivos na sua secretária deixam de responder. Use um intervalo escolhido por si, não o intervalo escolhido pelo router doméstico.

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 mostra nada, e nenhuma das máquinas regista um erro. Abra a página Machines, escolha Edit exit node no menu do VPS, marque Use as exit node e selecione Save.

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

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

Uma firewall descarta os pacotes encaminhados. tailscaled cria a sua própria cadeia ts-forward, o que é suficiente num VPS limpo. Um sistema que já execute ufw ou Docker pode ficar com uma política FORWARD definida como DROP e com regras posicionadas antes das regras do Tailscale. Não tente adivinhar qual é o caso: execute sudo iptables -L FORWARD -n -v enquanto o cliente tenta carregar uma página e observe quais os contadores que aumentam. Num sistema 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 fornecedor no painel de controlo, porque esse é um controlo separado de tudo o que está a executar no servidor.

Funciona, mas está lento. Execute tailscale netcheck nas duas máquinas. Se indicar que UDP está bloqueado, os dois dispositivos não conseguem estabelecer um caminho direto e usam um relay DERP, o que acrescenta latência a cada ligação. Permitir tráfego UDP de entrada na porta 41641 para o VPS na firewall de rede do fornecedor 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

Porque é 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, escolha Edit exit node no respetivo menu, selecione Use as exit node e clique em Save. A aprovação é feita na 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 e 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 aprovação é uma ação única para cada máquina. Se recriar o VPS com frequência, adicione um bloco autoApprovers ao ficheiro de políticas da 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 à tailnet, e não à sua conta de utilizador. Por isso, as regras de acesso aplicadas ao dispositivo também mudam.

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

O próprio nó de saída. Um dispositivo que usa um nó de saída envia todas as consultas DNS para esse nó. Isto substitui os servidores DNS globais e de DNS dividido definidos para a tailnet. A rede local deixa de ver os nomes que consulta. Para manter um servidor DNS da tailnet em utilização, 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 é aprovado na sua própria caixa de diálogo: o nó de saída através de Edit exit node no menu do dispositivo, na página Machines; a sub-rede através de Edit na secção Subnets do dispositivo, que abre Edit subnet routes. O encaminhamento IP tem de estar ativado no VPS para ambos. Evite anunciar um intervalo que coincida com a rede doméstica do seu portátil. Depois de essa rota ser aprovada e aceite pelo portátil, pode assumir esses endereços em vez da rede local, deixando 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 muda o ponto onde o tráfego entra na Internet: passa da rede onde está ligado para o servidor que aluga. Oculta a sua navegação do Wi-Fi de um café e do ISP doméstico, mas mostra essa mesma navegação ao fornecedor do VPS, associada ao nome da sua conta.