Il nodo di uscita ZeroTier non funziona? Controllate rotta, NAT e client

La tabella delle rotte mostra una rotta predefinita attraverso l’interfaccia ZeroTier, la rete risulta online e il browser esce comunque dall’indirizzo locale del provider. Questa combinazione è comune e non è un difetto del client. Una rotta predefinita dice solo dove devono andare i pacchetti; qualcosa deve inoltrarli e tradurli dall’altra parte. Tre parti separate devono essere vere prima che un nodo di uscita funzioni.

La rotta esiste ma non esce nulla

Controllate prima la tabella delle rotte del client. Una riga come default via 10.147.20.5 dev zt0 dimostra che la rotta è stata installata, non che la destinazione accetterà il traffico. Il salto successivo deve essere un membro disposto e in grado di inoltrarla.

Se la stessa richiesta esce ancora dall’interfaccia fisica, il client non ha installato la rotta, oppure l’ha installata con una metrica che ha perso contro la predefinita locale. Se la richiesta scompare dopo l’installazione della rotta, il membro di uscita riceve i pacchetti e non riesce a inoltrarli o a tradurli. Un client che conserva la predefinita fisica non invia alcun pacchetto all’uscita.

Questa distinzione decide dove lavorare. Confrontare un indirizzo pubblico prima e dopo la modifica separa una rotta mai usata da una usata e scartata, e richiede un solo comando invece di una revisione dell’intera configurazione. Fate il confronto prima di cambiare qualsiasi altra cosa, così che entrambi i risultati partano dallo stesso stato iniziale.

Tre parti che devono essere tutte vere

Un’uscita è una catena, e l’anello più debole determina il sintomo. La tabella sotto elenca gli anelli nell’ordine in cui di solito falliscono.

La prima riga è quella che il nome dell’opzione nasconde. Un membro diventa un’uscita solo quando il suo kernel inoltra pacchetti tra l’interfaccia ZeroTier e l’interfaccia rivolta a internet, e quando il percorso di risposta viene tradotto di nuovo verso il tunnel. Senza questo inoltro, il membro è un pari, non un gateway.

La riga del controller è autorizzazione, non configurazione. Annunciare 0.0.0.0/0 attraverso un membro dice a ogni client dov’è l’uscita; non rende quel membro capace di trasportare il traffico. Non verifica nemmeno che il membro abbia un percorso funzionante verso internet. La documentazione di ZeroTier sul nodo di uscita copre la stessa separazione tra nodo, rotta e client.

Configurate il nodo di uscita per inoltrare e tradurre

Abilitate in modo persistente l’inoltro IPv4, poi aggiungete il NAT di origine per il traffico che lascia l’interfaccia WAN. Le regole del filtro devono consentire il flusso inoltrato in entrambe le direzioni, perché inoltro e traduzione sono separati dal permesso:

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

Sostituite zt0 e eth0 con i nomi sull’host; una regola salvata per un’interfaccia di esempio non segue i pacchetti su una reale. Rendete persistenti le modifiche tramite il gestore del firewall che possiede le regole, perché un comando in una shell interattiva scompare al riavvio successivo.

Se l’host esegue un gestore del firewall come UFW o firewalld, aggiungete le regole tramite quel gestore invece di impilare righe di iptables accanto. Due proprietari che modificano le stesse catene producono una politica che dipende dall’ordine di avvio. L’ordine conta quando il gestore genera le proprie catene. Provate da un client dopo aver ricaricato il gestore, non prima.

Annunciate la rotta e accettatela sul client

Sul controller di rete aggiungete una rotta gestita per 0.0.0.0/0 il cui salto successivo sia l’indirizzo ZeroTier del membro di uscita. Poi, sul membro che deve usarla, consentite l’override per quella rete. Il permesso è locale: non riconfigura altri membri e non cambia il controller.

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

L’ultimo comando dovrebbe riportare l’interfaccia ZeroTier e l’indirizzo del membro di uscita. Se riporta ancora l’interfaccia fisica, manca la rotta oppure una predefinita concorrente ha una metrica migliore.

Mantenete l’impostazione limitata alla rete che ne ha bisogno. Abilitare l’accettazione della rotta predefinita a livello globale, o su una rete che deve fornire solo una sottorete privata, invia il traffico attraverso un’uscita che non è mai stata dimensionata per questo.

Verificate l’uscita e controllate le altre famiglie di indirizzi

Chiedete un indirizzo pubblico a un servizio che riporta l’origine e confrontatelo con l’indirizzo WAN del nodo di uscita. Poi caricate un sito per nome per confermare che il DNS risolve ancora, e provate un’applicazione importante invece di solo un browser.

Un client dual-stack può continuare a usare il proprio percorso IPv6 nativo mentre IPv4 esce tramite ZeroTier. Se l’obiettivo è nascondere o controllare tutto il traffico, servono una rotta ::/0 separata e l’inoltro IPv6 sull’uscita, e un test IPv4 non dice nulla al riguardo.

Il filtro del percorso inverso di Linux può anche scartare traffico di uscita valido sul client. ZeroTier documenta una considerazione su rp_filter per i membri partecipanti; modificate quell’impostazione deliberatamente e solo dopo aver confermato rotta e NAT, non come primo esperimento.

Se il requisito è l’accesso a un NAS o a una sottorete d’ufficio, una rotta gestita per quel prefisso è una modifica più piccola e sicura di un’uscita completa. Inviare tutta la navigazione attraverso un altro dispositivo è una decisione diversa dal raggiungere una risorsa privata, e merita una revisione separata.