VPN o proxy: què cobreix cadascun i què no

Tant una VPN com un proxy directe canvien l'adreça que veu un lloc web, i aquí s'aturen la majoria de comparacions. La diferència que decideix la vostra configuració és la cobertura: un proxy directe és un intermediari que la vostra aplicació tria fer servir, a diferència del proxy invers que se situa davant d'un lloc web, mentre que una VPN mou tot el que el sistema operatiu encamina cap a un túnel. El xifratge, la gestió del DNS i el comportament davant d'errors se'n deriven. Feu aquestes cinc comprovacions en ordre, i la primera que falli us dirà quina eina necessiteu realment.

Quines aplicacions cobreix l'intermediari?

Una extensió de proxy del navegador s'aplica només a aquest perfil del navegador. Els clients de correu, els gestors de paquets i un segon navegador continuen amb la seva pròpia configuració, i algunes aplicacions ignoren del tot les variables de proxy del sistema. Una VPN cobreix el que la taula d'encaminament envia al túnel, que pot ser totes les aplicacions o un subconjunt en túnel dividit segons les rutes i la política del client.

Proveu les aplicacions que importen en lloc d'extrapolar a partir d'una sola càrrega de pàgina. curl https://ifconfig.me segueix les variables de proxy de l'entorn; una aplicació d'escriptori potser no. A Windows, netsh winhttp show proxy mostra el proxy WinHTTP que fan servir els serveis, que és una configuració diferent de la del navegador.

El salt està xifrat, i on acaba el TLS?

Un protocol de proxy és un punt de trobada, no una garantia. SOCKS5 reenvia TCP sense xifrar-lo, i un proxy HTTP simple transporta la línia de sol·licitud i les capçaleres en text clar. HTTPS a través d'un proxy fa servir CONNECT, així que la vostra sessió TLS acaba igualment a la destinació, no al proxy. La guia de MDN sobre servidors proxy i tunelització descriu aquesta distinció des del costat del protocol.

Una VPN xifra el tram entre el vostre dispositiu i el seu punt final. Més enllà del punt final s'apliquen les mateixes regles que a qualsevol altra xarxa, i per això un túnel sol no protegeix una aplicació que envia credencials per HTTP pla. Cap dels dos dissenys amaga un compte iniciat, una galeta o una empremta del navegador.

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

La sortida detallada mostra si curl ha emès CONNECT al port 443 o un GET simple amb una URL completa. Amb socks5h:// el proxy rep el nom d'amfitrió dins de la sol·licitud SOCKS5 i després retransmet un TLS que no pot llegir, de manera que veu el nom i el recompte de bytes. A través d'un proxy http://, una URL https:// és un CONNECT, així que aquest proxy també veu el nom i el volum de la destinació, però no la sol·licitud ni el cos de la resposta.

Quin resolutor veu el nom?

La resolució de noms pot passar localment abans que la sol·licitud surti, o remotament al proxy. Amb curl, socks5h:// envia el nom d'amfitrió al proxy mentre que socks5:// el resol primer localment. La configuració de proxy del navegador ofereix una opció de DNS comparable, i els fitxers PAC poden encaminar amfitrions diferents de maneres diferents.

Dos protocols poden evitar un proxy sense cap error de configuració. WebRTC recull candidats per STUN, i QUIC executa HTTP/3 sobre UDP, que un proxy TCP no pot transportar. El navegador tornarà a TCP si el UDP 443 està bloquejat, així que bloquejar l'UDP 443 al tallafoc de l'amfitrió (o al router per a tota una xarxa), i no un indicador del navegador, és la manera fiable de mantenir HTTP/3 dins del camí del proxy.

Comproveu el resolutor des de la perspectiva de la destinació, no des del vostre portàtil. Una sol·licitud que arriba amb l'adreça de sortida del proxy però amb un nom resolt localment encara diu al resolutor local quins llocs visiteu.

Què passa quan l'intermediari falla?

Un proxy explícit falla tancat: atureu el procés del proxy i el navegador o l'aplicació retorna un error de connexió en lloc d'anar directe. Les configuracions PAC i WPAD són les que fallen obertes - si l'script no es pot obtenir, el client torna a DIRECT i el lloc torna a veure la vostra adreça real. Una VPN pot fallar oberta o tancada segons el client i si hi ha actiu un kill switch o una regla de tallafoc.

Proveu el cas de fallada expressament: atureu el servei de proxy i recarregueu; si obteniu una pàgina d'error en lloc d'una càrrega directa, apunteu l'URL del PAC a un amfitrió inabastable per veure el retrocés. Si la pàgina encara es carrega per la vostra ruta habitual, el proxy no ofereix cap protecció contra la seva pròpia caiguda, i aquesta és una propietat que hauríeu de conèixer abans de confiar-hi.

L'ordre decideix què veu el lloc. Un proxy la sortida del qual viatja per la VPN deixa el lloc veient l'adreça del punt final de la VPN; poseu el proxy fora del túnel (VPN cap a un proxy en un amfitrió remot) i el lloc veurà en canvi l'adreça de sortida d'aquell proxy. En qualsevol cas, els dos salts poden registrar coses diferents.

Cinc comprovacions, en ordre

La llista de comprovació següent és tota la decisió en un sol lloc. La cobertura va primer perquè elimina la majoria de desajustos: si l'aplicació que s'ha de cobrir no respecta la configuració, res més endavant a la llista no la salva.

Després confirmeu el resultat amb l'aplicació que va motivar el canvi. Carregueu una pàgina al navegador configurat, obteniu la mateixa pàgina amb curl i compareu l'adreça que reporta cadascun. Si no coincideixen, encara hi ha una extensió, una regla PAC o una anul·lació a nivell d'aplicació en joc, i cap ajust del túnel no ho arreglarà.

Anoteu què heu configurat: quines aplicacions fan servir el proxy, si el DNS és local o remot, si l'UDP està bloquejat i quin és el comportament davant d'errors. Aquest petit inventari és el que fa possible la propera comparació, perquè «la IP ha canviat» mai no us va dir quina d'aquestes cinc comprovacions s'havia superat.