VPN sau proxy: ce acoperă fiecare și ce nu acoperă

Atât un VPN, cât și un proxy direct schimbă adresa pe care o vede un site web, și acolo se opresc majoritatea comparațiilor. Diferența care decide configurația dumneavoastră este acoperirea: un proxy direct este un intermediar pe care aplicația dumneavoastră alege să îl folosească, spre deosebire de proxy-ul invers care stă în fața unui site web, în timp ce un VPN mută tot ce sistemul de operare rutează într-un tunel. Criptarea, tratarea DNS și comportamentul la eșec decurg toate din această împărțire. Faceți aceste cinci verificări în ordine, iar prima care eșuează vă va spune de ce instrument aveți nevoie de fapt.

Ce aplicații acoperă intermediarul?

O extensie de proxy din browser se aplică doar acelui profil de browser. Clienții de e-mail, managerii de pachete și un al doilea browser continuă să folosească propriile setări, iar unele aplicații ignoră complet variabilele de proxy ale sistemului. Un VPN acoperă ce trimite tabela de rutare în tunel, iar aceasta poate fi toate aplicațiile sau un subset într-un tunel divizat, în funcție de rute și de politica clientului.

Testați aplicațiile care contează în loc să generalizați dintr-o singură încărcare de pagină. curl https://ifconfig.me urmează variabilele de proxy ale mediului; o aplicație desktop poate să nu o facă. În Windows, netsh winhttp show proxy afișează proxy-ul WinHTTP folosit de servicii, iar aceasta este o setare diferită de cea a browserului.

Saltul este criptat și unde se termină TLS?

Un protocol de proxy este un punct de întâlnire, nu o garanție. SOCKS5 transmite TCP fără a-l cripta, iar un proxy HTTP simplu transportă linia cererii și antetele în text clar. HTTPS printr-un proxy folosește CONNECT, așa că sesiunea TLS se termină tot la destinație, nu la proxy. Ghidul MDN despre serverele proxy și tunelare descrie această distincție din partea protocolului.

Un VPN criptează segmentul dintre dispozitivul dumneavoastră și punctul său final. Dincolo de punctul final se aplică aceleași reguli ca în orice altă rețea, motiv pentru care un tunel singur nu protejează o aplicație care trimite credențiale prin HTTP simplu. Niciuna dintre cele două concepții nu ascunde un cont conectat, un cookie sau o amprentă a browserului.

curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null

Ieșirea detaliată arată dacă curl a trimis CONNECT la portul 443 sau un GET simplu cu un URL complet. Cu socks5h:// numele gazdei este predat proxy-ului în interiorul cererii SOCKS5, iar acesta retransmite apoi TLS pe care nu îl poate citi, așa că vede numele și numărul de octeți. Printr-un proxy http://, un URL https:// este un CONNECT, așa că acel proxy vede și numele și volumul destinației, dar nu cererea sau corpul răspunsului.

Care resolver vede numele?

Rezolvarea numelor poate avea loc local înainte ca cererea să plece, sau de la distanță la proxy. Cu curl, socks5h:// trimite numele gazdei la proxy, în timp ce socks5:// îl rezolvă mai întâi local. Setările de proxy ale browserului oferă o opțiune DNS comparabilă, iar fișierele PAC pot ruta gazde diferite în moduri diferite.

Două protocoale pot ocoli un proxy fără nicio configurare greșită. WebRTC colectează candidați prin STUN, iar QUIC rulează HTTP/3 peste UDP, ceea ce un proxy TCP nu poate transporta. Browserul va reveni la TCP dacă UDP 443 este blocat, așa că blocarea UDP 443 în firewall-ul gazdei (sau pe router pentru o rețea întreagă), și nu un indicator din browser, este modalitatea fiabilă de a menține HTTP/3 pe calea proxy-ului.

Verificați resolverul din perspectiva destinației, nu a laptopului dumneavoastră. O cerere care sosește cu adresa de ieșire a proxy-ului, dar cu un nume rezolvat local, îi spune în continuare resolverului local ce site-uri vizitați.

Ce se întâmplă când intermediarul eșuează?

Un proxy explicit eșuează închis: opriți procesul proxy și browserul sau aplicația returnează o eroare de conexiune în loc să meargă direct. Configurațiile PAC și WPAD sunt cele care eșuează deschis - dacă scriptul nu poate fi obținut, clientul revine la DIRECT și site-ul vede din nou adresa dumneavoastră reală. Un VPN poate eșua deschis sau închis în funcție de client și de faptul dacă un kill switch sau o regulă de firewall este activă.

Testați cazul de eșec intenționat: opriți serviciul de proxy și reîncărcați; dacă obțineți o pagină de eroare în loc de o încărcare directă, indicați URL-ul PAC către o gazdă inaccesibilă pentru a vedea replierea. Dacă pagina se încarcă în continuare pe ruta dumneavoastră obișnuită, proxy-ul nu oferă nicio protecție împotriva propriei indisponibilități, iar aceasta este o proprietate pe care ar trebui să o cunoașteți înainte de a vă baza pe el.

Ordinea decide ce vede site-ul. Un proxy al cărui trafic de ieșire trece prin VPN lasă site-ul să vadă adresa punctului final al VPN-ului; puneți proxy-ul în afara tunelului (VPN către un proxy pe o gazdă la distanță) și site-ul va vedea în schimb adresa de ieșire a acelui proxy. În ambele cazuri, cele două salturi pot înregistra lucruri diferite.

Cinci verificări, în ordine

Lista de verificare de mai jos este întreaga decizie într-un singur loc. Acoperirea vine prima pentru că elimină majoritatea nepotrivirilor: dacă aplicația care trebuie acoperită nu respectă setarea, nimic mai departe în listă nu o salvează.

Apoi confirmați rezultatul cu aplicația care a provocat schimbarea. Încărcați o pagină în browserul configurat, obțineți aceeași pagină cu curl și comparați adresa pe care o raportează fiecare. Dacă nu coincid, o extensie, o regulă PAC sau o suprascriere la nivel de aplicație este încă în joc, iar nicio reglare a tunelului nu o va rezolva.

Notați ce ați configurat: ce aplicații folosesc proxy-ul, dacă DNS-ul este local sau la distanță, dacă UDP este blocat și care este comportamentul la eșec. Exact acest mic inventar face posibilă comparația următoare, pentru că „IP-ul s-a schimbat” nu v-a spus niciodată care dintre aceste cinci verificări a trecut.