Naka-encrypt ba ang HTTP sa ZeroTier? Tingnan kung saan nagtatapos ang overlay

Sundin ang mga pagsusuring ito nang sunod-sunod at huminto sa unang mabibigo, dahil binabago ng bawat sagot ang kahulugan ng susunod na hakbang. Ang tunay na tanong ay makitid: naglalakbay ba nang lantad sa internet ang ordinaryong HTTP sa isang ZeroTier network? Sa pagitan ng dalawang ZeroTier peer, karaniwang hindi, dahil ini-encrypt ng overlay ang hop na iyon. Ngunit pahayag iyon tungkol sa dalawang endpoint, hindi tungkol sa bawat segment na dinadaanan ng isang kahilingan. Inililipat ng router, bridge o reverse proxy ang endpoint, at nagpapatuloy muli ang plaintext sa kabilang panig nito.

Pagsusuri 1: hanapin ang address na tinatawagan ng browser

Ihambing ang URL sa aktwal na hawak ng makina. ip -brief addr show ay naglilista ng zt interface at ng overlay address na itinalaga ng network controller; kung ginagamit ng URL ang address na iyon, pumapasok sa overlay ang socket ng browser.

Kapag ang pangalan ay naresolba sa isang LAN address sa halip, maaaring hindi kasangkot ang overlay, anuman ang iminumungkahi ng status indicator ng client. ip route get 10.147.20.5 ay nagpi-print ng interface at source address na pipiliin ng kernel, kaya ang zt interface doon ay nangangahulugang pumapasok ang packet sa overlay at ang pangalan ng iyong pisikal na NIC ay nangangahulugang hindi ito pumapasok. Nagdaragdag ng isa pang patong ang mga pangalan: ang rekord na tumuturo sa isang overlay address ay kumikilos nang iba kaysa sa tumuturo sa isang LAN address, at ang search suffix o entry sa hosts file ay maaaring tahimik na magpasiya kung alin ang makukuha mo.

Pagsusuri 2: tiyakin na ang dalawang dulo ay peer, hindi relay na nagde-decrypt

Ini-encrypt ng ZeroTier sa pagitan ng mga peer, at kung walang direktang landas ang mga packet ay nire-relay sa isang root na nagpapasa sa kanila habang naka-encrypt pa rin. zerotier-cli peers ay minamarkahan ang landas ng bawat peer bilang DIRECT o RELAY kasama ang bilang ng latency. Ang nire-relay na landas ay gumugol ng round trip, hindi pagiging lihim.

Ang nagbabago sa sagot ay isang miyembro na hindi tunay na endpoint. Kapag ang kabilang panig ay miyembro ng ZeroTier na nagro-route o nagbi-bridge papasok sa pisikal na LAN, nagtatapos ang overlay sa miyembrong iyon at ang susunod na hop ay ordinaryong Ethernet.

Pagsusuri 3: obserbahan kung saan nagiging nababasa ang kahilingan

Sa host na inaakala mong nagseserbisyo ng pahina, hulihin ang overlay interface habang nagre-reload: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. Ang nababasang linya ng kahilingan sa output na iyon ay nagpapatunay na dumating ang trapiko na naka-decrypt sa host na iyon, at iyon ang hangganang hinahanap mo.

Pagkatapos, hulihin sa interface na nakaharap sa natitirang LAN. Kung ang parehong kahilingan ay lumitaw doon nang lantad, umalis ito sa overlay bago pa man umabot sa application at mababasa ito ng bawat device sa segment na iyon. Kung walang lumitaw sa panig ng LAN at naglo-load pa rin ang pahina, nagtatapos ang application sa mismong ZeroTier host.

Mahalaga rin ang paghuli sa loopback kapag may reverse proxy sa harap, dahil inililipat ng proxy na tumatanggap ng HTTPS at nagpapasa ng HTTP ang hangganan sa sarili nitong backend.

Pagsusuri 4: isaalang-alang ang bawat hop sa likod ng router o bridge

Ang miyembrong naka-configure na mag-route sa pagitan ng overlay at LAN ay ordinaryong disenyo at ang lugar kung saan nababali ang karamihan sa mga palagay na ito. Pinoprotektahan ng overlay ang bahagi mula browser hanggang router at wala nang iba pa. Nagsasalita ang bridge ng parehong kuwento sa ibang mekanismo: nagiging isang broadcast domain ang overlay at ang pisikal na segment, kaya ang kahilingan mula sa laptop na naka-bridge ay dumadaan sa ordinaryong Ethernet kahit pa ang laptop na iyon ay nasa ZeroTier network.

Sundan ito sa halip na ipagpalagay. traceroute mula sa client patungo sa service address kasama ang routing table sa gateway member ay nagpapakita kung ang huling hop ay zt o eth.

Naghahain din ang ZeroTier ng trusted-path mode na maaaring mag-alis ng transport security sa mga itinalagang lokal na landas para sa performance. Ang network na gumagamit nito ay hindi nagmamana ng karaniwang palagay na naka-encrypt na landas, kaya basahin ang configuration ng network bago sumipi ng isa. Ang dokumentasyon ng protocol ay naglalarawan ng encryption sa pagitan ng mga peer at ng eksepsiyong iyon.

Pagsusuri 5: magpasya kung ano pa ang dapat gawin ng application

Ang pagiging miyembro sa overlay ay nagpapatunay ng device sa isang network at walang sinasabi tungkol sa kung ang serbisyo sa kabilang dulo ay ang nilalayon mong maabot. Sinasagot ng HTTPS ang ibang tanong sa pamamagitan ng pagbibigkis ng hostname sa isang key, kaya nag-o-overlap ang dalawang proteksiyon nang hindi pinapalitan ang isa't isa. Ang awtorisadong peer ay maaari pa ring maling serbisyo, at ang komprometidong endpoint ay nagbabasa ng kahilingan bago ang encryption at pagkatapos ng decryption. Wala sa mga mekanismong ito ang nag-a-audit ng itinatala ng application.

Para sa anumang may magagamit muli na session o password, tapusin ang TLS sa application o sa proxy na kontrolado mo at iwanang nakabukas ang validation ng certificate. Kung kailangang manatili ng lumang serbisyo sa ordinaryong HTTP, isulat ang eksaktong host-to-host na landas na maaari nitong gamitin, kung sino ang makakaabot dito at kung aling segment ang nananatiling walang proteksiyon; ang tala na iyon ang kailangan ng susunod na tagasuri.

"Konektado ang VPN" ay hindi pagsusuri ng alinman sa mga ito. Pinapangalanan ng tapat na bersiyon ang dalawang dulo, ang landas sa pagitan nila at ang unang hop na hindi sakop.

Itabi ang output ng paghuli at ang listahan ng peer sa tabi ng dokumentasyon ng serbisyo, upang makita ng sinumang magbabago ng ruta o magdadagdag ng bridge kung aling palagay ang malapit nang sirain.