A tabela de rotas mostra uma rota predefinida pela interface ZeroTier, a rede aparece online e o navegador continua saindo pelo endereço local do provedor. Essa combinação é comum e não é um erro do cliente. Uma rota predefinida apenas indica para onde os pacotes devem ir; algo precisa encaminhá-los e traduzi-los no outro extremo. Três partes separadas precisam estar corretas antes de um nó de saída funcionar.

A rota existe, mas nada sai

Verifique primeiro a tabela de rotas do cliente. Uma linha como default via 10.147.20.5 dev zt0 prova que a rota foi instalada, não que o destino aceitará o tráfego. O próximo salto deve ser um membro disposto e capaz de encaminhá-la.

Se a mesma solicitação ainda sai pela interface física, o cliente não instalou a rota, ou instalou-a com uma métrica que perdeu para a predefinida local. Se a solicitação desaparece depois de instalar a rota, o membro de saída recebe os pacotes e falha ao encaminhá-los ou traduzi-los. Um cliente que mantém a predefinida física não envia nenhum pacote à saída.

Essa distinção decide onde trabalhar. Comparar um endereço público antes e depois da mudança separa uma rota nunca usada de uma que foi usada e descartada, e exige um único comando em vez de revisar toda a configuração. Faça a comparação antes de mudar qualquer outra coisa, para que os dois resultados venham do mesmo estado inicial.

Três partes que precisam estar todas corretas

Uma saída é uma corrente, e o elo mais fraco determina o sintoma. A tabela abaixo lista os elos na ordem em que costumam falhar.

PartWhere it livesWhat a failure looks like
Forwarding and NATExit node kernel and firewallTraffic arrives, no reply
Managed default routeZeroTier network controllerNo default via the tunnel on the member
Client acceptanceMember's per-network settingRoute offered but not installed
DNS behaviorClient resolver configurationPages fail by name, IP works

A primeira linha é a que o nome da opção esconde. Um membro só se torna saída quando o seu núcleo encaminha pacotes entre a interface ZeroTier e a interface voltada à internet, e quando o caminho de resposta é traduzido de volta ao túnel. Sem esse encaminhamento, o membro é um par, não um gateway.

A linha do controlador é autorização, não configuração. Anunciar 0.0.0.0/0 por um membro diz a cada cliente onde está a saída; isso não torna esse membro capaz de transportar o tráfego. Também não verifica se o membro tem um caminho funcional para a internet. A documentação de nó de saída do ZeroTier cobre a mesma separação entre nó, rota e cliente.

Configure o nó de saída para encaminhar e traduzir

Ative o encaminhamento IPv4 de forma persistente e depois adicione NAT de origem para o tráfego que sai da interface WAN. As regras de filtro precisam permitir o fluxo encaminhado nos dois sentidos, porque encaminhamento e tradução são independentes da permissão:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i zt0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o zt0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Substitua zt0 e eth0 pelos nomes no host; uma regra guardada para uma interface de exemplo não segue os pacotes numa real. Torne as mudanças persistentes pelo gestor de firewall que possui as regras, porque um comando numa shell interativa desaparece no próximo reinício.

Se o host executa um gestor de firewall como UFW ou firewalld, adicione as regras por esse gestor em vez de empilhar linhas de iptables ao lado. Dois proprietários a editar as mesmas cadeias produzem uma política que depende da ordem de arranque. A ordem importa quando o gestor gera as suas próprias cadeias. Teste a partir de um cliente depois de recarregar o gestor, não antes.

Anuncie a rota e aceite-a no cliente

No controlador de rede, adicione uma rota gerida para 0.0.0.0/0 cujo próximo salto seja o endereço ZeroTier do membro de saída. Depois, no membro que a deve usar, permita a substituição para essa rede. A permissão é local: não reconfigura outros membros nem altera o controlador.

zerotier-cli listnetworks
zerotier-cli set <network-id> allowDefault=1
ip route get 1.1.1.1

O último comando deve informar a interface ZeroTier e o endereço do membro de saída. Se ainda informar a interface física, falta a rota ou uma predefinida concorrente tem melhor métrica.

Mantenha a configuração limitada à rede que precisa dela. Ativar a aceitação da rota predefinida globalmente, ou numa rede que só deve fornecer uma sub-rede privada, envia o tráfego por uma saída que nunca foi dimensionada para isso.

Verifique a saída e confira as outras famílias de endereços

Peça um endereço público a um serviço que informe a origem e compare-o com o endereço WAN do nó de saída. Depois carregue um site pelo nome para confirmar que o DNS ainda resolve, e teste uma aplicação importante em vez de apenas um navegador.

Um cliente de pilha dupla pode continuar a usar o seu caminho IPv6 nativo enquanto o IPv4 sai pelo ZeroTier. Se o objetivo é ocultar ou controlar todo o tráfego, são necessárias uma rota ::/0 separada e encaminhamento IPv6 na saída, e um teste IPv4 não diz nada sobre isso.

A filtragem de caminho inverso do Linux também pode descartar tráfego de saída válido no cliente. O ZeroTier documenta uma consideração sobre rp_filter para os membros participantes; altere essa configuração de forma deliberada e só depois de confirmar a rota e o NAT, não como primeira experiência.

Se o requisito é acessar um NAS ou uma sub-rede de escritório, uma rota gerida para esse prefixo é uma mudança menor e mais segura do que uma saída completa. Enviar toda a navegação por outro dispositivo é uma decisão diferente de alcançar um recurso privado, e merece uma revisão separada.

Artigos relacionados