Is HTTP oer ZeroTier fersifere? Sjoch wêr't de oerlach einiget
ZeroTier fersiferelet peer-oan-peer-sprongen, net it LAN-part efter in router of brêge. Sjoch wêr't de oerlach einiget foardat jo gewoane HTTP feilich neame.
Wurkgje dizze kontrôles yn folchoarder troch en stopje by de earste dy't mislearret, want elk antwurd feroaret wat de folgjende stap betsjut. De echte fraach is smel: reizget gewoane HTTP op in ZeroTier-netwurk iepen oer it ynternet? Tusken twa ZeroTier-peers ornaris net, want de oerlach fersiferelet dy sprong. Mar dat is in útspraak oer twa einpunt, net oer elk segmint dat in fersyk krúst. In router, in brêge of in omkearde proxy ferpleatst it einpunt, en platte tekst begjint wer oan 'e oare kant.
Kontrôle 1: fyn it adres dat de browser oanropt
Fergelykje de URL mei wat de masine eins hat. ip -brief addr show listet de zt-ynterface en it oerlachadres dat de netwurkcontroller tawiisde; as de URL dat adres brûkt, giet de socket fan de browser de oerlach yn.
As de namme ynstee nei in LAN-adres oplost, is de oerlach miskien hielendal net belutsen, wat de statusoantsjutting fan 'e klant ek suggerearret. ip route get 10.147.20.5 printsje de ynterface en it boarne-adres dat de kernel kieze soe, dus in zt-ynterface dêr betsjut dat it pakket de oerlach yngiet en de namme fan jo fysike NIC betsjut dat it net docht. Nammen foegje noch in laach ta: in record dy't nei in oerlachadres wiist, gedraacht him oars as ien dy't nei in LAN-adres wiist, en in sykstúfoeging of in ynfier yn it hosts-bestân kin stil beslisje hokker jo krije.
Kontrôle 2: befêstigje dat beide einen peers binne, gjin ûntsiferjend relais
ZeroTier fersiferelet tusken peers, en wêr't gjin direkte rûte is, wurde de pakketten troch in woartel trochstjoerd dy't se noch altyd fersifere trochjout. zerotier-cli peers markearret it paad fan elk peer as DIRECT of RELAY mei in latency-sifer. In trochstjoerd paad kostet hinne-en-wer, net fertroulikens.
Wat it antwurd wol feroaret, is in lid dat net echt in einpunt is. As de oare kant in ZeroTier-lid is dat nei in fysike LAN rûtelet of brêget, einiget de oerlach by dat lid en is de folgjende sprong gewoane Ethernet.
Kontrôle 3: sjoch wêr't it fersyk lêsber wurdt
Op 'e host dêr't jo tinke dat dy de side tsjinnet, fange it oerlach-ynterface op wylst jo werlaadzje: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. In lêsbere fersyksline yn dy útfier bewiist dat it ferkear ûntsifere op dy host oankaam, en dat is de grins dy't jo sykje.
Fange dan op it ynterface dat nei de rest fan it LAN rjochte is. As itselde fersyk dêr iepen ferskynt, hat it de oerlach ferlitten foardat it de applikaasje berikte en elk apparaat yn dat segmint kin it lêze. As der neat oan 'e LAN-kant ferskynt en de side noch altyd laden wurdt, einiget de applikaasje op 'e ZeroTier-host sels.
It opfangen fan loopback is ek wichtich as der in omkearde proxy foaroan stiet, want in proxy dy't HTTPS akseptearret en HTTP trochstjoert, ferpleatst de grins nei syn eigen backend.
Kontrôle 4: rekkene elke sprong efter in router of brêge
In lid dat konfigurearre is om tusken de oerlach en in LAN te rûtelet is in gewoan ûntwerp en it plak dêr't de measte fan dizze oannames brekke. De oerlach beskermet it part fan 'e browser oant de router en neat dêrnei. In brêge fertelt itselde ferhaal mei in oar meganisme: de oerlach en it fysike segmint wurde ien broadcast-domein, sadat in fersyk fan in oerbrêge laptop gewoane Ethernet krúst, ek al sit dy laptop op it ZeroTier-netwurk.
Folch it ynstee fan it oan te nimmen. traceroute fan 'e klant nei it tsjinstadres plus de rûtetabel op it gateway-lid litte sjen oft de lêste sprong zt of eth is.
ZeroTier biedt ek in trusted-path-modus dy't transportfeiligens op oanwiisde lokale paden foar prestaasjes weilitte kin. In netwurk dat dy brûkt, erft net de gewoane oanname fan in fersifere paad, dus lês de netwurkkonfiguraasje foardat jo ien sitearje. De protokol-dokumintaasje beskriuwt sawol de peer-fersifering as dy útsûndering.
Kontrôle 5: beslute wat de applikaasje noch dwaan moat
Oerlach-lidmaatskip autentisearret in apparaat by in netwurk en seit neat oer oft de tsjinst oan 'e oare kant dy is dy't jo berikke woene. HTTPS beantwurdet in oare fraach troch in hostnamme oan in kaai te binen, dus de twa beskermingen oerlaapje sûnder inoar te ferfangen. In autorisearre peer kin noch altyd de ferkearde tsjinst wêze, en in kompromittearre einpunt lêst it fersyk sawol foar fersifering as nei ûntsifering. Gjin fan beide meganismen auditearret wat de applikaasje registrearret.
Foar alles mei in werbrûkbere sesje of in wachtwurd, beëinigje TLS yn 'e applikaasje of yn in proxy dy't jo beheare en lit sertifikaatfalidaasje oan. Wêr't in legacy-tsjinst op gewoane HTTP bliuwe moat, skriuw it krekte host-to-host-paad op dat it brûke mei, wa't it berikke kin en hokker segmint ûnbeskermd bliuwt; dy notysje is wat in takomstige beoardieler nedich hat.
"De VPN is ferbûn" is gjin beoardieling fan ien fan dit. De earlike ferzje neamt beide einpunten, it paad dertusken en de earste sprong dy't net dekt is.
Hâld de opfangstútfier en de peer-list njonken de tsjinstedokumintaasje, sadat elkenien dy't in rûte feroaret of in brêge tafoeget, sjocht hokker oanname hy op it punt stiet te brekken.