O nodo de saída de ZeroTier non funciona? Revise a ruta, o NAT e o cliente
Unha ruta 0.0.0.0/0 no cliente non é unha saída. O nodo debe reenviar e traducir, a rede debe anunciar a ruta e o cliente debe aceptala.
A táboa de rutas mostra unha ruta predeterminada pola interface ZeroTier, a rede aparece conectada e o navegador segue saíndo polo enderezo local do provedor. Esa combinación é habitual e non é un erro do cliente. Unha ruta predeterminada só indica onde deben ir os paquetes; algo ten que reenvialos e traducilos no outro extremo. Tres partes separadas deben cumprirse antes de que funcione un nodo de saída.
A ruta existe, pero non sae nada
Revise primeiro a táboa de rutas do cliente. Unha liña como default via 10.147.20.5 dev zt0 demostra que a ruta se instalou, non que o destino acepte o tráfico. O seguinte salto debe ser un membro disposto e capaz de reenviala.
Se a mesma solicitude segue saíndo pola interface física, o cliente non instalou a ruta, ou instalouna cunha métrica que perdeu fronte á predeterminada local. Se a solicitude desaparece despois de instalar a ruta, o membro de saída recibe paquetes e non logra reenvialos nin traducilos. Un cliente que conserva a predeterminada física non envía ningún paquete á saída.
Esa distinción decide onde traballar. Comparar un enderezo público antes e despois do cambio separa unha ruta que nunca se usou dunha que se usou e se descartou, e require un só comando en lugar de revisar toda a configuración. Faga a comparación antes de cambiar calquera outra cousa, para que ambos os resultados partan do mesmo estado inicial.
Tres partes que deben cumprirse todas
Unha saída é unha cadea, e o elo máis feble marca o síntoma. A táboa de abaixo enumera os elos na orde en que adoitan fallar.
| Part | Where it lives | What a failure looks like |
|---|---|---|
| Forwarding and NAT | Exit node kernel and firewall | Traffic arrives, no reply |
| Managed default route | ZeroTier network controller | No default via the tunnel on the member |
| Client acceptance | Member's per-network setting | Route offered but not installed |
| DNS behavior | Client resolver configuration | Pages fail by name, IP works |
A primeira fila é a que oculta o nome da opción. Un membro convértese en saída só cando o seu núcleo reenvía paquetes entre a interface ZeroTier e a interface orientada a internet, e cando a ruta de resposta se traduce de volta ao túnel. Sen ese reenvío, o membro é un par, non unha pasarela.
A fila do controlador é autorización, non configuración. Anunciar 0.0.0.0/0 a través dun membro di a cada cliente onde está a saída; non fai que ese membro sexa capaz de transportar o tráfico. Tampouco verifica que o membro teña unha ruta funcional a internet. A documentación de nodo de saída de ZeroTier cobre a mesma separación entre nodo, ruta e cliente.
Configure o nodo de saída para reenviar e traducir
Active o reenvío IPv4 de forma persistente e despois engada NAT de orixe para o tráfico que sae da interface WAN. As regras de filtro deben permitir o fluxo reenviado nas dúas direccións, porque o reenvío e a tradución son independentes do permiso:
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 ACCEPTSubstitúa zt0 e eth0 polos nomes do host; unha regra gardada para unha interface de exemplo non segue os paquetes nunha real. Faga os cambios persistentes mediante o xestor de devasas que posúe as regras, porque un comando nunha shell interactiva desaparece no seguinte reinicio.
Se o host executa un xestor de devasas como UFW ou firewalld, engada as regras mediante ese xestor en lugar de apilar liñas de iptables ao lado. Dous propietarios editando as mesmas cadeas producen unha política que depende da orde de arranque. A orde importa cando o xestor xera as súas propias cadeas. Probe desde un cliente despois de recargar o xestor, non antes.
Anuncie a ruta e acéptea no cliente
No controlador de rede, engada unha ruta xestionada para 0.0.0.0/0 cuxo seguinte salto sexa o enderezo ZeroTier do membro de saída. Despois, no membro que debe usala, permita a anulación para esa rede. O permiso é local: non reconfigura outros membros nin cambia o controlador.
zerotier-cli listnetworks
zerotier-cli set <network-id> allowDefault=1
ip route get 1.1.1.1O último comando debería informar da interface ZeroTier e do enderezo do membro de saída. Se segue informando da interface física, falta a ruta ou unha predeterminada competidora ten mellor métrica.
Manteña o axuste limitado á rede que o necesita. Activar a aceptación da ruta predeterminada globalmente, ou nunha rede que só debe proporcionar unha subrede privada, envía o tráfico por unha saída que nunca se dimensionou para iso.
Verifique a saída e revise as outras familias de enderezos
Solicite un enderezo público a un servizo que informe da orixe e compárao co enderezo WAN do nodo de saída. Despois cargue un sitio polo seu nome para confirmar que o DNS segue resolvendo, e probe unha aplicación importante en lugar de só un navegador.
Un cliente de dobre pila pode seguir usando a súa ruta IPv6 nativa mentres IPv4 sae por ZeroTier. Se o obxectivo é ocultar ou controlar todo o tráfico, necesítase unha ruta ::/0 separada e reenvío IPv6 na saída, e unha proba IPv4 non di nada sobre iso.
O filtrado de ruta inversa de Linux tamén pode descartar tráfico de saída válido no cliente. ZeroTier documenta unha consideración sobre rp_filter para os membros participantes; cambie ese axuste de forma deliberada e só despois de confirmar a ruta e o NAT, non como primeiro experimento.
Se o requisito é acceder a un NAS ou a unha subrede de oficina, unha ruta xestionada para ese prefixo é un cambio máis pequeno e seguro que unha saída completa. Enviar toda a navegación por outro dispositivo é unha decisión distinta de chegar a un recurso privado, e merece unha revisión aparte.