HTTP su ZeroTier è cifrato? Verifica dove finisce l'overlay

Segui questi controlli in ordine e fermati al primo che fallisce, perché ogni risposta cambia cosa significa il passo successivo. La domanda vera è stretta: il semplice HTTP su una rete ZeroTier viaggia in chiaro su internet? Tra due peer ZeroTier di solito no, perché l'overlay cifra quel salto. Ma è un'affermazione su due estremi, non su ogni segmento che una richiesta attraversa. Un router, un bridge o un reverse proxy spostano l'estremo, e il testo in chiaro riprende dall'altra parte.

Controllo 1: trova l'indirizzo che il browser contatta

Confronta l'URL con ciò che la macchina ha davvero. ip -brief addr show elenca l'interfaccia zt e l'indirizzo overlay assegnato dal controller di rete; se l'URL usa quell'indirizzo, il socket del browser entra nell'overlay.

Quando invece il nome si risolve in un indirizzo LAN, l'overlay può non entrarci affatto, qualunque cosa suggerisca l'indicatore di stato del client. ip route get 10.147.20.5 stampa l'interfaccia e l'indirizzo sorgente che il kernel sceglierebbe, quindi un'interfaccia zt lì significa che il pacchetto entra nell'overlay e il nome della tua scheda di rete fisica significa che non ci entra. I nomi aggiungono un altro strato: un record che punta a un indirizzo overlay si comporta diversamente da uno che punta a un indirizzo LAN, e un suffisso di ricerca o una voce del file hosts possono decidere in silenzio quale ottieni.

Controllo 2: conferma che entrambi gli estremi siano peer, non un relè che decifra

ZeroTier cifra tra peer, e dove non esiste un percorso diretto i pacchetti vengono inoltrati attraverso una radice che li trasmette ancora cifrati. zerotier-cli peers contrassegna il percorso di ogni peer come DIRECT o RELAY con una cifra di latenza. Un percorso inoltrato costa andata e ritorno, non riservatezza.

Ciò che cambia davvero la risposta è un membro che non è davvero un estremo. Quando l'altro lato è un membro ZeroTier che fa routing o bridging verso una LAN fisica, l'overlay finisce in quel membro e il salto successivo è Ethernet ordinario.

Controllo 3: osserva dove la richiesta diventa leggibile

Sull'host che credi serva la pagina, cattura l'interfaccia overlay mentre ricarichi: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. Una riga di richiesta leggibile in quell'output dimostra che il traffico è arrivato decifrato su quell'host, ed è il confine che stai cercando.

Poi cattura sull'interfaccia rivolta al resto della LAN. Se la stessa richiesta compare lì in chiaro, ha lasciato l'overlay prima di raggiungere l'applicazione e ogni dispositivo di quel segmento può leggerla. Se non compare nulla sul lato LAN e la pagina si carica comunque, l'applicazione termina sull'host ZeroTier stesso.

Catturare il loopback conta anche quando davanti c'è un reverse proxy, perché un proxy che accetta HTTPS e inoltra HTTP sposta il confine sul proprio backend.

Controllo 4: conta ogni salto dietro un router o un bridge

Un membro configurato per fare routing tra l'overlay e una LAN è un progetto ordinario ed è il punto in cui la maggior parte di queste ipotesi si rompe. L'overlay protegge il tratto dal browser al router e nulla dopo. Un bridge racconta la stessa storia con un altro meccanismo: l'overlay e il segmento fisico diventano un unico dominio di broadcast, così una richiesta da un portatile collegato in bridge attraversa Ethernet ordinario anche se quel portatile sta sulla rete ZeroTier.

Traccialo invece di presumerlo. traceroute dal client all'indirizzo del servizio più la tabella di routing sul membro gateway mostrano se l'ultimo salto è zt o eth.

ZeroTier offre anche una modalità di percorso fidato che può rinunciare alla sicurezza del trasporto su percorsi locali designati per le prestazioni. Una rete che la usa non eredita la consueta ipotesi di percorso cifrato, quindi leggi la configurazione di rete prima di citarne una. La documentazione del protocollo descrive sia la cifratura tra peer sia quell'eccezione.

Controllo 5: decidi cosa deve ancora fare l'applicazione

L'appartenenza all'overlay autentica un dispositivo verso una rete e non dice nulla sul fatto che il servizio dall'altra parte sia quello che volevi raggiungere. HTTPS risponde a un'altra domanda legando un nome host a una chiave, quindi le due protezioni si sovrappongono senza sostituirsi. Un peer autorizzato può comunque essere il servizio sbagliato, e un estremo compromesso legge la richiesta sia prima della cifratura sia dopo la decifratura. Nessuno dei due meccanismi verifica ciò che l'applicazione registra.

Per qualunque cosa abbia una sessione riutilizzabile o una password, termina TLS nell'applicazione o in un proxy che controlli e lascia attiva la convalida dei certificati. Dove un servizio legacy deve restare su HTTP semplice, annota il percorso esatto da host a host che può usare, chi può raggiungerlo e quale segmento resta non protetto; quella nota è ciò che servirà a un revisore futuro.

"La VPN è connessa" non è una valutazione di nulla di tutto ciò. La versione onesta nomina entrambi gli estremi, il percorso tra loro e il primo salto che non è coperto.

Tieni l'output della cattura e l'elenco dei peer accanto alla documentazione del servizio, così chiunque cambi una rotta o aggiunga un bridge veda quale ipotesi sta per rompere.