Is HTTP over ZeroTier versleuteld? Controleer waar de overlay ophoudt

Werk deze controles op volgorde af en stop bij de eerste die faalt, want elk antwoord verandert wat de volgende stap betekent. De echte vraag is smal: gaat gewoon HTTP op een ZeroTier-netwerk in het helder over het internet? Tussen twee ZeroTier-peers meestal niet, omdat de overlay die hop versleutelt. Dat is echter een uitspraak over twee eindpunten, niet over elk segment dat een verzoek doorkruist. Een router, een bridge of een reverse proxy verplaatst het eindpunt, en aan de andere kant ervan begint plaintext opnieuw.

Controle 1: zoek het adres dat de browser belt

Vergelijk de URL met wat de machine werkelijk heeft. ip -brief addr show toont de zt-interface en het overlay-adres dat de netwerkcontroller heeft toegewezen; als de URL dat adres gebruikt, gaat de socket van de browser de overlay in.

Wanneer de naam in plaats daarvan naar een LAN-adres resolvet, is de overlay misschien helemaal niet betrokken, wat de statusindicator van de client ook suggereert. ip route get 10.147.20.5 drukt de interface en het bronadres af dat de kernel zou kiezen, dus een zt-interface daar betekent dat het pakket de overlay in gaat en de naam van je fysieke NIC betekent dat het dat niet doet. Namen voegen een extra laag toe: een record dat naar een overlay-adres wijst gedraagt zich anders dan een dat naar een LAN-adres wijst, en een zoeksuffix of een hosts-bestandregel kan stilletjes beslissen welke je krijgt.

Controle 2: bevestig dat beide uiteinden peers zijn, geen ontsleutelende relay

ZeroTier versleutelt tussen peers, en waar geen direct pad bestaat worden de pakketten doorgegeven via een root die ze nog versleuteld doorstuurt. zerotier-cli peers markeert het pad van elke peer als DIRECT of RELAY met een latency-cijfer. Een doorgestuurd pad kost roundtrips, geen vertrouwelijkheid.

Wat het antwoord wel verandert, is een lid dat niet echt een eindpunt is. Wanneer de andere kant een ZeroTier-lid is dat routeert of bridget naar een fysiek LAN, eindigt de overlay bij dat lid en is de volgende hop gewoon Ethernet.

Controle 3: kijk waar het verzoek leesbaar wordt

Op de host waarvan je denkt dat die de pagina serveert, leg je de overlay-interface vast terwijl je herlaadt: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. Een leesbare verzoekregel in die uitvoer bewijst dat het verkeer ontsleuteld op die host aankwam, en dat is de grens die je zoekt.

Leg daarna vast op de interface die naar de rest van het LAN kijkt. Als hetzelfde verzoek daar in het helder opduikt, heeft het de overlay verlaten voordat het de applicatie bereikte en kan elk apparaat op dat segment het lezen. Als er niets aan de LAN-kant verschijnt en de pagina toch laadt, termineert de applicatie op de ZeroTier-host zelf.

Loopback vastleggen is ook belangrijk wanneer er een reverse proxy voor staat, omdat een proxy die HTTPS accepteert en HTTP doorstuurt de grens naar zijn eigen backend verplaatst.

Controle 4: reken elke hop achter een router of bridge mee

Een lid dat is geconfigureerd om tussen de overlay en een LAN te routeren is een gewoon ontwerp en de plek waar de meeste van deze aannames breken. De overlay beschermt het traject van browser naar router en niets daarna. Een bridge vertelt hetzelfde verhaal via een ander mechanisme: de overlay en het fysieke segment worden één broadcast-domein, dus een verzoek van een gebridgde laptop gaat over gewoon Ethernet, ook al staat die laptop op het ZeroTier-netwerk.

Traceer het in plaats van het aan te nemen. traceroute van de client naar het serviceadres plus de routetabel op het gateway-lid laat zien of de laatste hop zt of eth is.

ZeroTier biedt ook een trusted-path-modus die transportbeveiliging op aangewezen lokale paden kan laten vallen voor prestaties. Een netwerk dat die gebruikt erft niet de normale aanname van een versleuteld pad, dus lees de netwerkconfiguratie voordat je er een citeert. De protocoldocumentatie beschrijft zowel de peer-versleuteling als die uitzondering.

Controle 5: bepaal wat de applicatie nog moet doen

Overlay-lidmaatschap authenticeert een apparaat bij een netwerk en zegt niets over of de service aan de andere kant degene is die je wilde bereiken. HTTPS beantwoordt een andere vraag door een hostnaam aan een sleutel te binden, dus de twee beschermingen overlappen zonder elkaar te vervangen. Een geautoriseerde peer kan nog steeds de verkeerde service zijn, en een gecompromitteerd eindpunt leest het verzoek zowel voor versleuteling als na ontsleuteling. Geen van beide mechanismen controleert wat de applicatie vastlegt.

Voor alles met een herbruikbare sessie of een wachtwoord termineer je TLS bij de applicatie of bij een proxy die je beheert en laat je certificaatvalidatie aan staan. Waar een legacy-service op gewoon HTTP moet blijven, schrijf je het exacte host-naar-host-pad op dat die mag gebruiken, wie het kan bereiken en welk segment onbeschermd blijft; die notitie is wat een toekomstige beoordelaar nodig heeft.

"De VPN is verbonden" is geen beoordeling van dit alles. De eerlijke versie noemt beide eindpunten, het pad ertussen en de eerste hop die niet gedekt is.

Bewaar de capture-uitvoer en de peer-lijst naast de servicedocumentatie, zodat wie een route wijzigt of een bridge toevoegt, kan zien welke aanname die op het punt staat te breken.