Er HTTP over ZeroTier kryptert? Sjekk hvor overlayen slutter
ZeroTier krypterer peer-til-peer-hopp, ikke LAN-delen bak en ruter eller bro. Sjekk hvor overlayen slutter før du kaller vanlig HTTP trygt.
Gå gjennom disse sjekkene i rekkefølge og stopp ved den første som feiler, fordi hvert svar endrer hva neste steg betyr. Det egentlige spørsmålet er smalt: går vanlig HTTP på et ZeroTier-nettverk i klartekst over internett? Mellom to ZeroTier-peere gjør det vanligvis ikke det, siden overlayen krypterer det hoppet. Men det er en uttalelse om to endepunkter, ikke om hvert segment en forespørsel krysser. En ruter, en bro eller en omvendt proxy flytter endepunktet, og klartekst gjenopptas på den andre siden av den.
Sjekk 1: finn adressen nettleseren ringer
Sammenlign URL-en med det maskinen faktisk har. ip -brief addr show viser zt-grensesnittet og overlay-adressen nettverkskontrolleren tildelte; hvis URL-en bruker den adressen, går nettleserens socket inn i overlayen.
Når navnet i stedet løses til en LAN-adresse, er overlayen kanskje ikke involvert i det hele tatt, uansett hva klientens statusindikator antyder. ip route get 10.147.20.5 skriver ut grensesnittet og kildeadressen kjernen ville valgt, så et zt-grensesnitt der betyr at pakken går inn i overlayen, og navnet på ditt fysiske NIC betyr at den ikke gjør det. Navn legger til et ekstra lag: en post som peker på en overlay-adresse oppfører seg annerledes enn en som peker på en LAN-adresse, og et søkesuffiks eller en oppføring i hosts-filen kan stille avgjøre hvilken du får.
Sjekk 2: bekreft at begge ender er peere, ikke en relé som dekrypterer
ZeroTier krypterer mellom peere, og der ingen direkte vei finnes sendes pakkene videre gjennom en rot som videresender dem fortsatt kryptert. zerotier-cli peers markerer hver peers vei som DIRECT eller RELAY med et latenstall. En reléet vei koster rundturer, ikke konfidensialitet.
Det som endrer svaret er et medlem som egentlig ikke er et endepunkt. Når den andre siden er et ZeroTier-medlem som ruter eller broer inn i et fysisk LAN, slutter overlayen ved det medlemmet og neste hopp er vanlig Ethernet.
Sjekk 3: se hvor forespørselen blir lesbar
På verten du tror serverer siden, fang overlay-grensesnittet mens du laster på nytt: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. En lesbar forespørselslinje i den utskriften beviser at trafikken kom dekryptert til den verten, og det er grensen du leter etter.
Fang deretter på grensesnittet som vender mot resten av LAN-et. Hvis den samme forespørselen dukker opp der i klartekst, forlot den overlayen før den nådde applikasjonen, og hver enhet på det segmentet kan lese den. Hvis ingenting vises på LAN-siden og siden fortsatt lastes, terminerer applikasjonen på selve ZeroTier-verten.
Å fange loopback er også viktig når en omvendt proxy står foran, siden en proxy som godtar HTTPS og videresender HTTP flytter grensen til sin egen bakende.
Sjekk 4: regn med hvert hopp bak en ruter eller bro
Et medlem konfigurert til å rute mellom overlayen og et LAN er et vanlig design og stedet der de fleste av disse antakelsene bryter sammen. Overlayen beskytter beinet fra nettleseren til ruteren og ingenting etter det. En bro forteller den samme historien gjennom en annen mekanisme: overlayen og det fysiske segmentet blir ett kringkastingsdomene, så en forespørsel fra en broet bærbar PC går over vanlig Ethernet selv om den PC-en sitter på ZeroTier-nettverket.
Spor det i stedet for å anta det. traceroute fra klienten til tjenesteadressen pluss rutetabellen på gateway-medlemmet viser om siste hopp er zt eller eth.
ZeroTier tilbyr også en trusted-path-modus som kan droppe transportssikkerhet på utpekte lokale veier for ytelsens skyld. Et nettverk som bruker den arver ikke den vanlige antakelsen om kryptert vei, så les nettverkskonfigurasjonen før du siterer en. Protokolldokumentasjonen beskriver både peer-krypteringen og det unntaket.
Sjekk 5: avgjør hva applikasjonen fortsatt må gjøre
Overlay-medlemskap autentiserer en enhet til et nettverk og sier ingenting om hvorvidt tjenesten i andre enden er den du mente å nå. HTTPS svarer på et annet spørsmål ved å binde et vertsnavn til en nøkkel, så de to beskyttelsene overlapper uten å erstatte hverandre. En autorisert peer kan fortsatt være feil tjeneste, og et kompromittert endepunkt leser forespørselen både før kryptering og etter dekryptering. Ingen av mekanismene reviderer det applikasjonen registrerer.
For alt med en gjenbrukbar økt eller et passord, terminer TLS i applikasjonen eller i en proxy du kontrollerer, og la sertifikatvalideringen stå på. Der en eldre tjeneste må bli på vanlig HTTP, skriv ned den nøyaktige vert-til-vert-veien den kan bruke, hvem som kan nå den og hvilket segment som forblir ubeskyttet; den notaten er det en fremtidig gjennomgåer trenger.
"VPN-en er tilkoblet" er ikke en vurdering av noe av dette. Den ærlige versjonen navngir begge endepunktene, veien mellom dem og det første hoppet som ikke er dekket.
Oppbevar fangstutskriften og peer-listen ved siden av tjenestedokumentasjonen, slik at den som endrer en rute eller legger til en bro, kan se hvilken antakelse de er i ferd med å bryte.