Ĉu HTTP super ZeroTier estas ĉifrita? Kontrolu, kie la tavola reto finiĝas

Trairu ĉi tiujn kontrolojn laŭvice kaj haltu ĉe la unua, kiu malsukcesas, ĉar ĉiu respondo ŝanĝas, kion signifas la sekva paŝo. La vera demando estas mallarĝa: ĉu ordinara HTTP en ZeroTier-reto vojaĝas malkaŝe tra la interreto? Inter du ZeroTier-samranguloj ĝi kutime ne faras tion, ĉar la tavola reto ĉifras tiun salton. Sed tio estas aserto pri du finpunktoj, ne pri ĉiu segmento, kiun peto trapasas. Enkursigilo, ponto aŭ inversa prokurilo movas la finpunkton, kaj klarteksto rekomenciĝas ĉe ĝia alia flanko.

Kontrolo 1: trovu la adreson, kiun la retumilo alvokas

Komparu la URL-on kun tio, kion la maŝino efektive havas. ip -brief addr show listigas la interfacon zt kaj la tavolan adreson, kiun atribuis la reta regilo; se la URL uzas tiun adreson, la poŝo de la retumilo eniras la tavolan reton.

Kiam la nomo anstataŭe solviĝas al LAN-adreso, la tavola reto eble tute ne partoprenas, kion ajn sugestas la statindikilo de la kliento. ip route get 10.147.20.5 presas la interfacon kaj la fontan adreson, kiun la kerno elektus, do interfaco zt tie signifas, ke la pakaĵo eniras la tavolan reton, kaj la nomo de via fizika retkarto signifas, ke ĝi ne eniras. Nomoj aldonas plian tavolon: rikordo montranta al tavola adreso kondutas alie ol unu montranta al LAN-adreso, kaj serĉa sufikso aŭ enskribo en la dosiero hosts povas silente decidi, kiun vi ricevos.

Kontrolo 2: konfirmu, ke ambaŭ finoj estas samranguloj, ne malĉifranta relajso

ZeroTier ĉifras inter samranguloj, kaj kie ne ekzistas rekta vojo, la pakaĵoj estas plusenditaj tra radiko, kiu transdonas ilin ankoraŭ ĉifritaj. zerotier-cli peers markas la vojon de ĉiu samrangulo kiel DIRECT aŭ RELAY kun latenca nombro. Plusendita vojo kostas rondon da vojaĝoj, ne konfidecon.

Kio ja ŝanĝas la respondon estas membro, kiu ne vere estas finpunkto. Kiam la alia flanko estas ZeroTier-membro, kiu enkursigas aŭ pontas en fizikan LAN-on, la tavola reto finiĝas ĉe tiu membro kaj la sekva salto estas ordinara Eterreto.

Kontrolo 3: observu, kie la peto fariĝas legebla

Sur la gastiganto, kiun vi kredas servi la paĝon, kaptu la interfacon de la tavola reto dum vi reŝargas: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. Legebla peta linio en tiu eligo pruvas, ke la trafiko alvenis malĉifrita al tiu gastiganto, kaj tio estas la limo, kiun vi serĉas.

Poste kaptu sur la interfaco turnita al la resto de la LAN. Se la sama peto aperas tie malkaŝe, ĝi forlasis la tavolan reton antaŭ ol atingi la aplikaĵon kaj ĉiu aparato en tiu segmento povas legi ĝin. Se nenio aperas sur la LAN-flanko kaj la paĝo tamen ŝarĝiĝas, la aplikaĵo finiĝas sur la ZeroTier-gastiganto mem.

Kapti la buklan interfacon ankaŭ gravas, kiam inversa prokurilo staras antaŭe, ĉar prokurilo, kiu akceptas HTTPS kaj plusendas HTTP, movas la limon al sia propra malantaŭaĵo.

Kontrolo 4: kalkulu ĉiun salton malantaŭ enkursigilo aŭ ponto

Membro agordita por enkursigi inter la tavola reto kaj LAN estas ordinara dezajno kaj la loko, kie plej multaj el ĉi tiuj supozoj rompiĝas. La tavola reto protektas la parton de la retumilo ĝis la enkursigilo kaj nenion poste. Ponto rakontas la saman historion per alia mekanismo: la tavola reto kaj la fizika segmento fariĝas unu dissenda domajno, do peto de pontita tekkomputilo trapasas ordinaran Eterreton eĉ se tiu tekkomputilo sidas en la ZeroTier-reto.

Spuru ĝin anstataŭ supozi ĝin. traceroute de la kliento al la servo-adreso plus la enkursiga tabelo sur la enireja membro montras, ĉu la lasta salto estas zt aŭ eth.

ZeroTier ankaŭ proponas fidindan vojan reĝimon, kiu povas forigi transportan sekurecon sur difinitaj lokaj vojoj por rendimento. Reto, kiu uzas ĝin, ne heredas la normalan supozon de ĉifrita vojo, do legu la retan agordon antaŭ ol citi unu. La protokola dokumentaro priskribas kaj la samrangulan ĉifradon kaj tiun escepton.

Kontrolo 5: decidi, kion la aplikaĵo ankoraŭ devas fari

Tavola membreco aŭtentikigas aparaton al reto kaj diras nenion pri tio, ĉu la servo ĉe la alia fino estas tiu, kiun vi intencis atingi. HTTPS respondas alian demandon ligante gastigantan nomon al ŝlosilo, do la du protektoj interkovriĝas sen anstataŭigi unu la alian. Rajtigita samrangulo ankoraŭ povas esti la malĝusta servo, kaj kompromitita finpunkto legas la peton kaj antaŭ ĉifrado kaj post malĉifrado. Neniu el la mekanismoj revizias, kion la aplikaĵo registras.

Por io ajn kun reuzebla seanco aŭ pasvorto, finu TLS ĉe la aplikaĵo aŭ ĉe prokurilo, kiun vi kontrolas, kaj lasu atestilan validigon ŝaltita. Kie malnova servo devas resti sur ordinara HTTP, skribu la ĝustan vojon de gastiganto al gastiganto, kiun ĝi rajtas uzi, kiu povas atingi ĝin kaj kiu segmento restas neprotektita; tiu noto estas tio, kion bezonas estonta revizianto.

"La VPN estas konektita" ne estas takso de io ajn el ĉi tio. La honesta versio nomas ambaŭ finpunktojn, la vojon inter ili kaj la unuan salton, kiu ne estas kovrita.

Konservu la kaptan eligon kaj la samrangulan liston apud la serva dokumentaro, por ke ĉiu, kiu ŝanĝos vojon aŭ aldonos ponton, vidu, kiun supozon ĝi baldaŭ rompos.