Este HTTP prin ZeroTier criptat? Verifică unde se termină overlay-ul

Parcurge aceste verificări în ordine și oprește-te la prima care eșuează, pentru că fiecare răspuns schimbă ce înseamnă pasul următor. Întrebarea reală este îngustă: HTTP simplu într-o rețea ZeroTier călătorește în clar prin internet? Între doi peers ZeroTier de obicei nu, fiindcă overlay-ul criptează acel salt. Dar aceasta este o afirmație despre două puncte terminale, nu despre fiecare segment pe care trece o cerere. Un router, un pod sau un proxy invers mută punctul terminal, iar textul clar reîncepe de cealaltă parte a lui.

Verificarea 1: găsește adresa pe care o apelează browserul

Compară URL-ul cu ceea ce mașina are de fapt. ip -brief addr show afișează interfața zt și adresa de overlay atribuită de controlerul rețelei; dacă URL-ul folosește acea adresă, socketul browserului intră în overlay.

Când numele se rezolvă în schimb la o adresă LAN, overlay-ul poate să nu fie implicat deloc, orice ar sugera indicatorul de stare al clientului. ip route get 10.147.20.5 afișează interfața și adresa sursă pe care le-ar alege kernelul, deci o interfață zt acolo înseamnă că pachetul intră în overlay, iar numele NIC-ului tău fizic înseamnă că nu intră. Numele adaugă un alt strat: o înregistrare care indică o adresă de overlay se comportă altfel decât una care indică o adresă LAN, iar un sufix de căutare sau o intrare în fișierul hosts poate decide în liniște pe care o primești.

Verificarea 2: confirmă că ambele capete sunt peers, nu un relay care decriptează

ZeroTier criptează între peers, iar unde nu există o cale directă pachetele sunt retransmise printr-un root care le trimite mai departe tot criptate. zerotier-cli peers marchează calea fiecărui peer ca DIRECT sau RELAY, împreună cu o cifră de latență. O cale retransmisă costă dus-întors, nu confidențialitate.

Ce schimbă răspunsul este un membru care nu este cu adevărat un punct terminal. Când partea cealaltă este un membru ZeroTier care rutează sau face pod către o LAN fizică, overlay-ul se termină la acel membru și următorul salt este Ethernet obișnuit.

Verificarea 3: urmărește unde cererea devine lizibilă

Pe gazda despre care crezi că servește pagina, capturează interfața de overlay în timp ce reîncarci: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. O linie de cerere lizibilă în acea ieșire dovedește că traficul a ajuns decriptat pe acea gazdă, și aceasta este granița pe care o cauți.

Apoi capturează pe interfața orientată spre restul LAN-ului. Dacă aceeași cerere apare acolo în clar, a părăsit overlay-ul înainte de a ajunge la aplicație și fiecare dispozitiv din acel segment o poate citi. Dacă nu apare nimic pe partea LAN și pagina tot se încarcă, aplicația se termină chiar pe gazda ZeroTier.

Capturarea loopback-ului contează și ea când în față stă un proxy invers, fiindcă un proxy care acceptă HTTPS și trimite mai departe HTTP mută granița la propriul său backend.

Verificarea 4: ia în calcul fiecare salt din spatele unui router sau pod

Un membru configurat să ruteze între overlay și o LAN este un design obișnuit și locul unde majoritatea acestor presupuneri se rup. Overlay-ul protejează porțiunea de la browser la router și nimic după ea. Un pod spune aceeași poveste printr-un alt mecanism: overlay-ul și segmentul fizic devin un singur domeniu de broadcast, așa că o cerere de la un laptop conectat prin pod trece prin Ethernet obișnuit chiar dacă laptopul stă în rețeaua ZeroTier.

Urmărește-o în loc să presupui. traceroute de la client la adresa serviciului plus tabela de rutare de pe membrul gateway arată dacă ultimul salt este zt sau eth.

ZeroTier oferă și un mod trusted-path care poate renunța la securitatea transportului pe căi locale desemnate, pentru performanță. O rețea care îl folosește nu moștenește presupunerea obișnuită a căii criptate, așa că citește configurația rețelei înainte de a cita una. Documentația protocolului descrie atât criptarea între peers, cât și acea excepție.

Verificarea 5: decide ce mai trebuie să facă aplicația

Apartenența la overlay autentifică un dispozitiv într-o rețea și nu spune nimic despre dacă serviciul de la celălalt capăt este cel pe care voiai să-l atingi. HTTPS răspunde la o altă întrebare legând un nume de gazdă de o cheie, așa că cele două protecții se suprapun fără a se înlocui una pe cealaltă. Un peer autorizat poate fi totuși serviciul greșit, iar un punct terminal compromis citește cererea atât înainte de criptare, cât și după decriptare. Niciunul dintre mecanisme nu auditează ce înregistrează aplicația.

Pentru orice cu o sesiune reutilizabilă sau o parolă, termină TLS la aplicație sau la un proxy pe care îl controlezi și lasă validarea certificatului pornită. Unde un serviciu vechi trebuie să rămână pe HTTP simplu, notează calea exactă de la gazdă la gazdă pe care o poate folosi, cine o poate atinge și ce segment rămâne neprotejat; acea notă este ce are nevoie un recenzent viitor.

"VPN-ul este conectat" nu este o evaluare a nimic din toate acestea. Versiunea onestă numește ambele capete, calea dintre ele și primul salt care nu este acoperit.

Păstrează rezultatul capturii și lista de peers lângă documentația serviciului, ca oricine schimbă o rută sau adaugă un pod să vadă ce presupunere este pe cale să o încalce.