Er HTTP over ZeroTier kryptert? Sjekk kvar overlayen sluttar
ZeroTier krypterer peer-til-peer-hopp, ikkje LAN-delen bak ein ruter eller bru. Sjekk kvar overlayen sluttar før du kallar vanleg HTTP trygt.
Gå gjennom desse sjekkane i rekkefølgje og stopp ved den første som feilar, fordi kvart svar endrar kva neste steg tyder. Det eigentlege spørsmålet er smalt: går vanleg HTTP på eit ZeroTier-nettverk i klartekst over internett? Mellom to ZeroTier-peerar gjer det vanlegvis ikkje det, sidan overlayen krypterer det hoppet. Men det er ei utsegn om to endepunkt, ikkje om kvart segment ein førespurnad kryssar. Ein ruter, ei bru eller ein omvend proxy flyttar endepunktet, og klartekst tek til att på den andre sida av det.
Sjekk 1: finn adressa nettlesaren ringer
Samanlikn URL-en med det maskinen faktisk har. ip -brief addr show viser zt-grensesnittet og overlay-adressa nettverkskontrolløren tildelte; viss URL-en brukar den adressa, går nettsokelen til nettlesaren inn i overlayen.
Når namnet i staden blir løyst til ei LAN-adresse, er overlayen kanskje ikkje involvert i det heile, kva klientens statusindikator enn antydar. ip route get 10.147.20.5 skriv ut grensesnittet og kjeldeadressa kjernen ville valt, så eit zt-grensesnitt der tyder at pakken går inn i overlayen, og namnet på det fysiske NIC-et ditt tyder at han ikkje gjer det. Namn legg til eit ekstra lag: ei oppføring som peikar på ei overlay-adresse oppfører seg annleis enn ei som peikar på ei LAN-adresse, og eit søkjesuffiks eller ei oppføring i hosts-fila kan stille avgjere kva du får.
Sjekk 2: stadfest at begge endar er peerar, ikkje eit relé som dekrypterer
ZeroTier krypterer mellom peerar, og der ingen direkte veg finst blir pakkane sende vidare gjennom ein rot som sender dei vidare framleis krypterte. zerotier-cli peers markerer vegen til kvar peer som DIRECT eller RELAY med eit latenstal. Ein reléa veg kostar rundturar, ikkje konfidensialitet.
Det som endrar svaret er eit medlem som eigentleg ikkje er eit endepunkt. Når den andre sida er eit ZeroTier-medlem som rutar eller bruar inn i eit fysisk LAN, sluttar overlayen ved det medlemmet og neste hopp er vanleg Ethernet.
Sjekk 3: sjå kvar førespurnaden blir lesbar
På verten du trur serverer sida, fang overlay-grensesnittet medan du lastar på nytt: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. Ei lesbar førespurnadslinje i den utskrifta provar at trafikken kom dekryptert til den verten, og det er grensa du leitar etter.
Fang deretter på grensesnittet som vender mot resten av LAN-et. Viss den same førespurnaden dukkar opp der i klartekst, forlét han overlayen før han nådde applikasjonen, og kvar eining på det segmentet kan lese han. Viss ingenting blir vist på LAN-sida og sida framleis lastar, terminerer applikasjonen på sjølve ZeroTier-verten.
Å fange loopback er òg viktig når ein omvend proxy står framom, sidan ein proxy som tek imot HTTPS og sender HTTP vidare flyttar grensa til sin eigen bakende.
Sjekk 4: rekn med kvart hopp bak ein ruter eller bru
Eit medlem sett opp til å rute mellom overlayen og eit LAN er eit vanleg design og staden der dei fleste av desse føresetnadene bryt saman. Overlayen verner beinet frå nettlesaren til ruteren og ingenting etter det. Ei bru fortel den same historia gjennom ein annan mekanisme: overlayen og det fysiske segmentet blir eitt kringkastingsdomene, så ein førespurnad frå ein brua berbar PC går over vanleg Ethernet sjølv om den PC-en sit på ZeroTier-nettverket.
Spor det i staden for å gå ut frå det. traceroute frå klienten til tenesteadressa pluss rutetabellen på gateway-medlemmet viser om siste hopp er zt eller eth.
ZeroTier tilbyr òg ein trusted-path-modus som kan droppe transporttryggleik på utpeika lokale vegar for ytinga si skuld. Eit nettverk som brukar han arvar ikkje den vanlege føresetnaden om kryptert veg, så les nettverkskonfigurasjonen før du siterer ein. Protokolldokumentasjonen skildrar både peer-krypteringa og det unntaket.
Sjekk 5: avgjer kva applikasjonen framleis må gjere
Overlay-medlemskap autentiserer ei eining mot eit nettverk og seier ingenting om tenesta i andre enden er den du meinte å nå. HTTPS svarar på eit anna spørsmål ved å binde eit vertsnamn til ein nøkkel, så dei to vernene overlappar utan å erstatte kvarandre. Ein autorisert peer kan framleis vere feil teneste, og eit kompromittert endepunkt les førespurnaden både før kryptering og etter dekryptering. Ingen av mekanismane reviderer det applikasjonen registrerer.
For alt med ei gjenbrukbar økt eller eit passord, terminer TLS i applikasjonen eller i ein proxy du kontrollerer, og la sertifikatvalideringa stå på. Der ei eldre teneste må bli på vanleg HTTP, skriv ned den nøyaktige vert-til-vert-vegen ho kan bruke, kven som kan nå ho og kva segment som blir verande uverna; den notata er det ein framtidig gjennomgåar treng.
"VPN-en er tilkopla" er ikkje ei vurdering av noko av dette. Den ærlege versjonen nemner begge endepunkta, vegen mellom dei og det første hoppet som ikkje er dekt.
Oppbevar fangstutskrifta og peer-lista ved sida av tenestedokumentasjonen, slik at den som endrar ein rute eller legg til ei bru, kan sjå kva føresetnad dei er i ferd med å bryte.