VPN în Tor, Tor în VPN: de ce se rupe lanțul
Când un VPN, Tor și un proxy sunt suprapuse, ordinea decide ce se rezolvă și ce se transportă. Găsiți prima graniță ruptă înainte de a le schimba pe toate trei.
Suprapunerea unui VPN, a Tor și a unui proxy de aplicație pare o multiplicare a confidențialității, iar în realitate multiplică numărul de locuri în care o conexiune poate muri. Rezultatul obișnuit este un browser care se învârte în timp ce toate cele trei instrumente se declară sănătoase. Dacă schimbați toate cele trei setări deodată, dispare și singurul indiciu despre care dintre ele minte.
Desenați mai întâi traseul dorit, în ordine, numind ce program deschide fiecare conexiune și ce nume se rezolvă la fiecare pas.
Straturile nu se adună, ele interacționează
Un VPN înaintea Tor înseamnă că conexiunea de intrare a clientului Tor călătorește în interiorul tunelului. Un VPN purtat prin Tor înseamnă că punctul final al clientului VPN însuși trebuie să fie accesibil prin Tor, ceea ce este o cerință complet diferită. Proxy-ul browserului adaugă încă un salt despre care sistemul de operare nu știe nimic. Trei aranjamente, trei liste de dependențe separate.
Fiecare aranjament schimbă ce poate fi rezolvat, ce poate fi transportat și cine vede primul pachet. Doar unul dintre ele poate fi configurația la care v-ați gândit.
Adăugați și calea directă pe diagramă. O rută de rezervă, o excepție de tunel divizat sau ocolirea proxy-ului pot face o pagină să se încarce în timp ce sar în liniște lanțul pe care voiați să îl testați, iar un astfel de succes înșeală mai mult decât eșecul.
Ordinea decide ce poate fi transportat
Tor transportă fluxuri TCP prin interfața sa SOCKS, iar un client care cere proxy-ului să rezolve numele gazdei păstrează interogarea în interiorul circuitului. UDP nu călătorește așa în configurațiile obișnuite, de aceea un tunel WireGuard nu poate fi imbricat în Tor fără un releu TCP suplimentar la mijloc.
OpenVPN poate fi forțat pe TCP, așa că acel aranjament este cel puțin descriptibil. Este și mai lent și mai fragil, iar modul de eșec când se rupe arată identic cu un port blocat. Așteptați-vă să petreceți mai mult timp distingând cele două decât reparând oricare dintre ele.
Rezolvarea este cealaltă jumătate. Cu --socks5-hostname proxy-ul rezolvă destinația, în timp ce --socks5 simplu întreabă mai întâi resolverul local și scurge numele în afara circuitului. Exact acel singur steag decide dacă interogarea numelui aparține lanțului sau furnizorului dumneavoastră de internet.
| Order | What must resolve the endpoint | What usually breaks |
|---|---|---|
| VPN, then Tor | The tunnel's resolver | Entry guards blocked by the VPN provider's filters |
| Tor, then VPN | The SOCKS proxy, remotely | UDP transports, which Tor does not carry |
| App proxy on top | The application itself | Proxy bypass rules and cached connections |
Localizarea primei granițe rupte
Testați etapele în ordinea în care călătoresc pachetele, cu cereri inofensive, și opriți-vă la prima care eșuează. Notați care comandă a rulat prima, pentru că ordinea face parte din dovadă. Două comenzi separă un circuit mort de o ieșire moartă:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
Prima raportează dacă o cerere se finalizează prin proxy-ul SOCKS, iar a doua arată adresa pe care rețeaua o prezintă în acest moment. Dacă prima eșuează și a doua reușește, problema este la clientul Tor sau înaintea lui. Dacă ambele reușesc și browserul tot eșuează, aplicația folosește o cale diferită de shell.
O pagină de IP public descrie și ea doar ultima ieșire vizibilă. Nu poate spune câte salturi au precedat-o, așa că asociați-o cu ieșirea de stare acceptată a fiecărui instrument în loc să tratați un singur număr ca pe o diagramă.
Când să nu mai adăugați straturi
Dacă nu puteți spune într-o propoziție ce aduce un strat, eliminați-l. Un lanț al cărui scop nu este clar este un lanț pe care nimeni nu îl poate depana la trei dimineața, iar câștigul de confidențialitate al unui salt neexplicat este de obicei mai mic decât disponibilitatea pe care o pierdeți.
Dacă un strat chiar își merită locul, testați-l singur mai întâi, apoi adăugați următorul și confirmați din nou calea cu aceleași două comenzi. Restabiliți lanțul complet înainte de utilizarea obișnuită și lăsați validarea TLS și autentificarea pornite; un avertisment de certificat acceptat pentru ca pagina să se încarce este o ocolire a rutării, nu o reparație. Notați ordinea la care v-ați oprit cât timp este proaspătă.
Scrieți acea ordine, inclusiv resolverul care răspunde la fiecare etapă. Un lanț funcțional pe care îl puteți descrie supraviețuiește următoarei actualizări, în timp ce un lanț funcțional asamblat prin încercări dispare odată cu ea. Adăugați data și versiunile, ca o defecțiune ulterioară să poată fi comparată cu o stare cunoscută bună în loc să fie dezbătută din memorie. Zece rânduri într-un fișier text economisesc o seară de presupuneri.