Är HTTP över ZeroTier krypterat? Kontrollera var overlayen slutar

Gå igenom dessa kontroller i ordning och stanna vid den första som misslyckas, eftersom varje svar ändrar vad nästa steg betyder. Den verkliga frågan är snäv: färdas vanlig HTTP på ett ZeroTier-nätverk i klartext över internet? Mellan två ZeroTier-peers gör det oftast inte det, eftersom overlayen krypterar det hoppet. Men det är ett påstående om två ändpunkter, inte om varje segment som en begäran passerar. En router, en brygga eller en omvänd proxy flyttar ändpunkten, och klartext återupptas på dess andra sida.

Kontroll 1: hitta adressen som webbläsaren ringer

Jämför URL:en med vad maskinen faktiskt har. ip -brief addr show listar zt-gränssnittet och overlay-adressen som nätverkskontrollern tilldelade; om URL:en använder den adressen går webbläsarens socket in i overlayen.

När namnet i stället löses till en LAN-adress är overlayen kanske inte inblandad alls, vad klientens statusindikator än antyder. ip route get 10.147.20.5 skriver ut gränssnittet och källadressen som kärnan skulle välja, så ett zt-gränssnitt där betyder att paketet går in i overlayen och namnet på ditt fysiska NIC betyder att det inte gör det. Namn lägger till ett extra lager: en post som pekar på en overlay-adress beter sig annorlunda än en som pekar på en LAN-adress, och ett söksuffix eller en post i hosts-filen kan tyst avgöra vilken du får.

Kontroll 2: bekräfta att båda ändarna är peers, inte en relay som dekrypterar

ZeroTier krypterar mellan peers, och där ingen direkt väg finns vidarebefordras paketen genom en rot som skickar dem vidare fortfarande krypterade. zerotier-cli peers markerar varje peers väg som DIRECT eller RELAY med en latenssiffra. En vidarebefordrad väg kostar rundturer, inte konfidentialitet.

Det som ändrar svaret är en medlem som inte riktigt är en ändpunkt. När andra sidan är en ZeroTier-medlem som routar eller bryggar in i ett fysiskt LAN slutar overlayen vid den medlemmen och nästa hopp är vanlig Ethernet.

Kontroll 3: se var begäran blir läsbar

På värden du tror serverar sidan, fånga overlay-gränssnittet medan du laddar om: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. En läsbar begäransrad i den utskriften bevisar att trafiken kom dekrypterad till den värden, och det är gränsen du letar efter.

Fånga sedan på gränssnittet som vetter mot resten av LAN:et. Om samma begäran dyker upp där i klartext lämnade den overlayen innan den nådde applikationen och varje enhet på det segmentet kan läsa den. Om inget dyker upp på LAN-sidan och sidan ändå laddas avslutar applikationen på själva ZeroTier-värden.

Att fånga loopback är också viktigt när en omvänd proxy står framför, eftersom en proxy som accepterar HTTPS och vidarebefordrar HTTP flyttar gränsen till sin egen backend.

Kontroll 4: räkna med varje hopp bakom en router eller brygga

En medlem konfigurerad att routa mellan overlayen och ett LAN är en vanlig design och platsen där de flesta av dessa antaganden brister. Overlayen skyddar benet från webbläsaren till routern och ingenting efter det. En brygga berättar samma historia genom en annan mekanism: overlayen och det fysiska segmentet blir en enda broadcast-domän, så en begäran från en bryggad laptop går över vanlig Ethernet även om den laptopen sitter på ZeroTier-nätverket.

Spåra det i stället för att anta det. traceroute från klienten till tjänstadressen plus routingtabellen på gateway-medlemmen visar om sista hoppet är zt eller eth.

ZeroTier erbjuder också ett trusted-path-läge som kan släppa transportskyddet på utpekade lokala vägar för prestandans skull. Ett nätverk som använder det ärver inte det vanliga antagandet om krypterad väg, så läs nätverkskonfigurationen innan du citerar en. Protokolldokumentationen beskriver både peer-krypteringen och det undantaget.

Kontroll 5: avgör vad applikationen fortfarande måste göra

Overlay-medlemskap autentiserar en enhet mot ett nätverk och säger ingenting om huruvida tjänsten på andra sidan är den du menade att nå. HTTPS svarar på en annan fråga genom att binda ett värdnamn till en nyckel, så de två skydden överlappar utan att ersätta varandra. En auktoriserad peer kan fortfarande vara fel tjänst, och en komprometterad ändpunkt läser begäran både före kryptering och efter dekryptering. Ingen av mekanismerna granskar vad applikationen registrerar.

För allt med en återanvändbar session eller ett lösenord, avsluta TLS i applikationen eller i en proxy du kontrollerar och låt certifikatvalideringen vara på. Där en äldre tjänst måste stanna på vanlig HTTP, skriv ner den exakta värd-till-värd-vägen den får använda, vem som kan nå den och vilket segment som förblir oskyddat; den anteckningen är vad en framtida granskare behöver.

"VPN:et är anslutet" är inte en bedömning av något av detta. Den ärliga versionen namnger båda ändpunkterna, vägen mellan dem och det första hoppet som inte täcks.

Förvara fångstutskriften och peer-listan bredvid tjänstedokumentationen, så att den som ändrar en rutt eller lägger till en brygga ser vilket antagande de är på väg att bryta.