Titkosított-e a HTTP a ZeroTier fölött? Nézze meg, hol végződik az overlay

Vegye sorra ezeket az ellenőrzéseket, és álljon meg az elsőnél, amelyik megbukik, mert minden válasz megváltoztatja, mit jelent a következő lépés. A valódi kérdés szűk: a sima HTTP egy ZeroTier-hálózaton nyíltan halad-e át az interneten? Két ZeroTier-peer között általában nem, mert az overlay titkosítja azt az ugrást. De ez két végpontról szóló állítás, nem minden szegmensről, amelyet egy kérés átszel. Egy router, egy híd vagy egy fordított proxy elmozdítja a végpontot, és a nyílt szöveg a túloldalán folytatódik.

Ellenőrzés 1: keresse meg a címet, amelyet a böngésző hív

Hasonlítsa össze az URL-t azzal, ami a gépen valóban van. ip -brief addr show kilistázza a zt interfészt és az overlay-címet, amelyet a hálózatvezérlő kiosztott; ha az URL ezt a címet használja, a böngésző socketje az overlaybe kerül.

Ha a név inkább LAN-címre oldódik fel, lehet, hogy az overlay egyáltalán nem érintett, bármit sugall is a kliens állapotjelzője. ip route get 10.147.20.5 kiírja az interfészt és azt a forrás-címet, amelyet a kernel választana, tehát egy ottani zt interfész azt jelenti, hogy a csomag belép az overlaybe, a fizikai hálózati kártya neve pedig azt, hogy nem. A nevek még egy réteget adnak: az overlay-címre mutató rekord másképp viselkedik, mint a LAN-címre mutató, és egy keresési utótag vagy egy hosts-fájlbeli bejegyzés csendesen eldöntheti, melyiket kapja.

Ellenőrzés 2: erősítse meg, hogy mindkét vég peer, nem titkosítást bontó relé

A ZeroTier a peer-ek között titkosít, és ahol nincs közvetlen útvonal, a csomagok egy gyökéren keresztül továbbítódnak, amely még titkosítva adja tovább őket. zerotier-cli peers az egyes peer-ek útvonalát DIRECT vagy RELAY jelzéssel látja el, késleltetési számmal. A továbbított útvonal oda-vissza utakat költségesít, nem bizalmasságot.

Amit viszont megváltoztat a válaszon, az egy olyan tag, amely nem igazi végpont. Ha a túloldal egy ZeroTier-tag, amely fizikai LAN-ba route-ol vagy hidat képez, az overlay annál a tagnál végződik, és a következő ugrás közönséges Ethernet.

Ellenőrzés 3: figyelje, hol válik olvashatóvá a kérés

A gazdagépen, amelyről azt hiszi, hogy kiszolgálja az oldalt, rögzítse az overlay-interfészt az újratöltés alatt: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. Egy olvasható kérésor abban a kimenetben bizonyítja, hogy a forgalom visszafejtve érkezett arra a gazdagépre, és ez az a határ, amelyet keres.

Ezután rögzítsen a LAN többi része felé néző interfészen. Ha ugyanaz a kérés ott nyíltan megjelenik, elhagyta az overlayt, mielőtt elérte volna az alkalmazást, és abban a szegmensben minden eszköz olvashatja. Ha a LAN oldalán semmi sem jelenik meg, és az oldal mégis betöltődik, az alkalmazás magán a ZeroTier-gazdagépen végződik.

A loopback rögzítése akkor is számít, ha fordított proxy áll előtte, mert a HTTPS-t elfogadó és HTTP-t továbbító proxy a határt a saját backendjére mozgatja.

Ellenőrzés 4: számoljon el minden ugrással egy router vagy híd mögött

Az overlay és egy LAN közötti route-olásra beállított tag szokványos megoldás, és itt törik meg e feltételezések többsége. Az overlay a böngésző és a router közötti szakaszt védi, azon túl semmit. A híd ugyanezt a történetet más mechanizmussal mondja el: az overlay és a fizikai szegmens egyetlen broadcast-tartománnyá válik, így egy áthidalt laptop kérése közönséges Etherneten halad át, még ha az a laptop a ZeroTier-hálózaton ül is.

Kövesse nyomon, ahelyett hogy feltételezné. traceroute az ügyféltől a szolgáltatás címéig, valamint az átjáró-tag routing táblája megmutatja, hogy az utolsó ugrás zt vagy eth.

A ZeroTier kínál megbízható útvonal módot is, amely a teljesítmény érdekében feladhatja a szállítási biztonságot a kijelölt helyi útvonalakon. Az ezt használó hálózat nem örökli a szokásos titkosított útvonal feltételezését, ezért olvassa el a hálózati konfigurációt, mielőtt egyet idézne. A protokoll dokumentációja leírja a peer-ek közötti titkosítást és ezt a kivételt is.

Ellenőrzés 5: döntse el, mit kell még tennie az alkalmazásnak

Az overlay-tagság egy eszközt hitelesít egy hálózat felé, és semmit sem mond arról, hogy a túloldali szolgáltatás az-e, amelyet el akart érni. A HTTPS más kérdésre válaszol azzal, hogy egy hosztnevet kulcshoz köt, így a két védelem átfedi egymást, de nem helyettesíti. Egy jogosult peer még mindig lehet rossz szolgáltatás, és egy kompromittált végpont a kérést a titkosítás előtt és a visszafejtés után is olvassa. Egyik mechanizmus sem auditálja, mit rögzít az alkalmazás.

Minden újrahasználható munkamenettel vagy jelszóval rendelkező dolognál fejezze be a TLS-t az alkalmazásban vagy egy Ön által irányított proxyban, és hagyja bekapcsolva a tanúsítvány-ellenőrzést. Ahol egy örökölt szolgáltatásnak sima HTTP-n kell maradnia, írja le a pontos gép-gép közötti útvonalat, amelyet használhat, ki érheti el, és melyik szegmens marad védelem nélkül; erre a feljegyzésre lesz szüksége egy jövőbeli bírálónak.

"A VPN csatlakoztatva van" nem értékelése semminek ebből. Az őszinte változat megnevezi mindkét végpontot, a köztük lévő útvonalat és az első lefedetlen ugrást.

Tartsa a rögzítés kimenetét és a peer-listát a szolgáltatás dokumentációja mellett, hogy aki útvonalat módosít vagy hidat ad hozzá, lássa, melyik feltételezést készül megtörni.