Er HTTP over ZeroTier krypteret? Se hvor overlay-laget slutter

Gå gennem disse kontroller i rækkefølge, og stop ved den første, der fejler, fordi hvert svar ændrer, hvad næste trin betyder. Det egentlige spørgsmål er snævert: kører almindelig HTTP på et ZeroTier-netværk i klartekst over internettet? Mellem to ZeroTier-peers gør det normalt ikke, fordi overlayet krypterer det hop. Men det er en udtalelse om to endepunkter, ikke om hvert segment, en anmodning krydser. En router, en bro eller en reverse proxy flytter endepunktet, og klartekst fortsætter på den anden side af det.

Kontrol 1: find den adresse, browseren ringer til

Sammenlign URL'en med det, maskinen faktisk har. ip -brief addr show viser zt-interfacet og den overlay-adresse, netværkscontrolleren tildelte; hvis URL'en bruger den adresse, går browserens socket ind i overlayet.

Når navnet i stedet opløses til en LAN-adresse, er overlayet måske slet ikke involveret, uanset hvad klientens statusindikator antyder. ip route get 10.147.20.5 udskriver interfacet og den kildeadresse, kernen ville vælge, så et zt-interface der betyder, at pakken går ind i overlayet, og dit fysiske NIC-navn betyder, at den ikke gør. Navne tilføjer endnu et lag: en post, der peger på en overlay-adresse, opfører sig anderledes end en, der peger på en LAN-adresse, og et søgesuffiks eller en post i hosts-filen kan stille afgøre, hvilken du får.

Kontrol 2: bekræft, at begge ender er peers, ikke et dekrypterende relay

ZeroTier krypterer mellem peers, og hvor der ikke findes en direkte vej, videresendes pakkerne gennem en rod, der sender dem videre stadig krypteret. zerotier-cli peers markerer hver peers vej som DIRECT eller RELAY med et latencetal. En videresendt vej koster rundture, ikke fortrolighed.

Det, der virkelig ændrer svaret, er et medlem, der ikke rigtigt er et endepunkt. Når den anden side er et ZeroTier-medlem, der router eller broer ind i et fysisk LAN, slutter overlayet ved det medlem, og næste hop er almindeligt Ethernet.

Kontrol 3: se, hvor anmodningen bliver læsbar

På den vært, du mener serverer siden, skal du optage overlay-interfacet, mens du genindlæser: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. En læsbar anmodningslinje i det output beviser, at trafikken ankom dekrypteret til den vært, og det er den grænse, du leder efter.

Optag derefter på det interface, der vender mod resten af LAN'et. Hvis den samme anmodning dukker op der i klartekst, forlod den overlayet, før den nåede applikationen, og hver enhed på det segment kan læse den. Hvis der intet vises på LAN-siden, og siden stadig indlæses, terminerer applikationen på selve ZeroTier-værten.

Optagelse af loopback er også vigtig, når en reverse proxy står foran, fordi en proxy, der accepterer HTTPS og videresender HTTP, flytter grænsen til sin egen backend.

Kontrol 4: gør rede for hvert hop bag en router eller bro

Et medlem konfigureret til at route mellem overlayet og et LAN er et almindeligt design og det sted, hvor de fleste af disse antagelser bryder sammen. Overlayet beskytter benet fra browser til router og intet efter det. En bro fortæller den samme historie med en anden mekanisme: overlayet og det fysiske segment bliver ét broadcast-domæne, så en anmodning fra en broet laptop krydser almindeligt Ethernet, selvom den laptop sidder på ZeroTier-netværket.

Spor det i stedet for at antage det. traceroute fra klienten til tjenesteadressen plus routingtabellen på gateway-medlemmet viser, om det sidste hop er zt eller eth.

ZeroTier tilbyder også en trusted-path-tilstand, der kan droppe transportsikkerheden på udpegede lokale veje af hensyn til ydeevnen. Et netværk, der bruger den, arver ikke den normale antagelse om krypteret vej, så læs netværkskonfigurationen, før du citerer en. Protokoldokumentationen beskriver både peer-krypteringen og den undtagelse.

Kontrol 5: afgør, hvad applikationen stadig skal gøre

Overlay-medlemskab autentificerer en enhed over for et netværk og siger intet om, hvorvidt tjenesten i den anden ende er den, du mente at nå. HTTPS besvarer et andet spørgsmål ved at binde et værtsnavn til en nøgle, så de to beskyttelser overlapper uden at erstatte hinanden. En autoriseret peer kan stadig være den forkerte tjeneste, og et kompromitteret endepunkt læser anmodningen både før kryptering og efter dekryptering. Ingen af mekanismerne reviderer, hvad applikationen registrerer.

For alt med en genbrugelig session eller en adgangskode skal du afslutte TLS i applikationen eller i en proxy, du styrer, og lade certifikatvalidering være slået til. Hvor en ældre tjeneste skal blive på almindelig HTTP, skal du skrive den præcise vært-til-vært-vej ned, som den må bruge, hvem der kan nå den, og hvilket segment der forbliver ubeskyttet; den note er, hvad en fremtidig anmelder har brug for.

"VPN'et er forbundet" er ikke en vurdering af noget af dette. Den ærlige version nævner begge endepunkter, vejen mellem dem og det første hop, der ikke er dækket.

Opbevar optagelsesoutputtet og peer-listen ved siden af tjenestedokumentationen, så enhver, der ændrer en rute eller tilføjer en bro, kan se, hvilken antagelse de er ved at bryde.