Ce vede încă furnizorul tău când torrentezi printr-un VPN
Un tunel ascunde destinații, nu faptul că există tunelul. Verifică legarea clientului, resolverul și ce află oricum peerii și trackerii privați.
Parcurge întrebările în ordine: ce poate observa rețeaua de acces, ce iese din tunel fără ea, ce dezvăluie căutarea numelor și ce află oricum peerii și trackerii. Fiecare răspuns este independent de celelalte, iar un VPN rezolvă complet doar primul. Al patrulea este locul unde majoritatea așteptărilor eșuează în tăcere, pentru că niciun tunel nu elimină un nume de cont.
Începe prin a decide care observator te îngrijorează, pentru că răspunsul se schimbă cu observatorul.
O conexiune înlocuiește multe
Când clientul este cu adevărat în interiorul tunelului, rețeaua de acces vede o singură conexiune criptată susținută către o singură adresă VPN. Volumul, momentul și faptul că se folosește un VPN rămân vizibile; numele de gazdă ale trackerilor, adresele peerilor și numele fișierelor nu. Este o îmbunătățire reală, și mai îngustă decât sugerează marketingul. Operatorul tunelului stă la mijloc și vede mai mult decât rețeaua de acces.
O declarație fără jurnale descrie politica de păstrare, nu vizibilitatea tehnică. Sunt afirmații diferite, și doar prima este ceva ce un furnizor poate promite.
Scurgerea vine din legare, nu din tunel
BitTorrent creează un flux de conexiuni TCP și UDP de scurtă durată către peeri, trackeri, noduri DHT și descoperire locală. Leagă clientul de adaptorul fizic, sau repornește-l după ce tunelul a căzut, iar traficul rezultat este exact ceea ce tunelul exista ca să ascundă. Regulile de firewall sunt un control mai slab decât par: o regulă care se potrivește doar cu ruta implicită, doar cu IPv4 sau doar cu conexiuni noi lasă căi deschise. Legarea clientului de interfața tunelului și verificarea acestei legări este modelul mai puternic.
Verifică oprind intenționat tunelul și observând dacă transferurile se opresc. Dacă continuă, clientul nu a fost niciodată înăuntru. Repetă după o repornire a clientului și după trezirea unui laptop, pentru că atunci se pierd de obicei legările.
DNS numește site-ul fără să atingă transferul
Dacă căutările de nume merg încă la resolverul local, interogarea însăși anunță site-ul în timp ce transferul rămâne criptat. Mutarea rezolvării în tunel, sau criptarea ei, închide acel gol. Niciuna nu face nimic pentru un client ale cărui pachete ies în afara tunelului. Verifică ce resolver este folosit și prin ce interfață iese interogarea; cele două verificări răspund la întrebări diferite.
Un nume rezolvat prin tunel și un transfer care respectă legarea sunt proprietăți separate, iar fiecare poate eșua singură.
Roiul și trackerul văd lucruri diferite
Schimbul de adrese face parte din protocol, așa că peerii înregistrează ce văd. Conectarea din ieșire le dă ieșirea; conectarea directă le dă adresa de acasă. DHT și schimbul de peeri răspândesc mai departe această observație, iar o sesiune ulterioară fără tunel poate lega același port de client și aceeași versiune. Trackerul poate ști și mai mult: o cheie de acces din URL-ul de anunț identifică contul indiferent de ieșirea din care au venit pachetele.
Criptarea acoperă din nou o altă axă. HTTPS protejează o cerere de la ieșire înainte; HTTP simplu expune linia cererii fiecărei rețele de pe traseu, și de aceea un protocol poate fi modelat, iar celălalt nu.
Răspunde la cele patru întrebări cu dovezi, nu cu o pictogramă. Pictograma îți spune doar că există un tunel.