VPN ou proxy: que cobre cada un e que non

Tanto unha VPN como un proxy directo cambian o enderezo que ve un sitio web, e aí detense a maioría das comparacións. A diferenza que decide a túa configuración é a cobertura: un proxy directo é un intermediario que a túa aplicación elixe usar, a diferenza do proxy inverso que se sitúa diante dun sitio web, mentres que unha VPN move todo o que o sistema operativo enruta cara a un túnel. O cifrado, o manexo do DNS e o comportamento ante fallos derivan desa división. Executa estas cinco comprobacións en orde, e a primeira que falle diráche que ferramenta necesitas realmente.

Que aplicacións cobre o intermediario?

Unha extensión de proxy do navegador aplícase só a ese perfil do navegador. Os clientes de correo, os xestores de paquetes e un segundo navegador seguen usando a súa propia configuración, e algunhas aplicacións ignoran por completo as variables de proxy do sistema. Unha VPN cobre o que a táboa de enrutamento envía ao túnel, que pode ser todas as aplicacións ou un subconxunto en túnel dividido segundo as rutas e a política do cliente.

Proba as aplicacións que importan en vez de extrapolar a partir dunha soa carga de páxina. curl https://ifconfig.me segue as variables de proxy da contorna; unha aplicación de escritorio pode que non. En Windows, netsh winhttp show proxy mostra o proxy WinHTTP que usan os servizos, e esa é unha configuración distinta da do navegador.

Está cifrado o salto e onde remata TLS?

Un protocolo de proxy é un punto de encontro, non unha garantía. SOCKS5 reenvía TCP sen cifralo, e un proxy HTTP simple transporta a liña de solicitude e as cabeceiras en texto claro. HTTPS a través dun proxy usa CONNECT, así que a túa sesión TLS segue rematando no destino, non no proxy. A guía de MDN sobre servidores proxy e tunelización describe esa distinción desde o lado do protocolo.

Unha VPN cifra o tramo entre o teu dispositivo e o seu punto final. Máis alá do punto final aplícanse as mesmas regras que en calquera outra rede, e por iso un túnel por si só non protexe unha aplicación que envía credenciais por HTTP simple. Ningún dos dous deseños oculta unha conta con sesión iniciada, unha cookie nin unha pegada do 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

A saída detallada mostra se curl emitiu CONNECT ao porto 443 ou un GET simple cun URL completo. Con socks5h:// o proxy recibe o nome de host dentro da solicitude SOCKS5 e despois retransmite un TLS que non pode ler, así que ve o nome e o reconto de bytes. A través dun proxy http://, un URL https:// é un CONNECT, así que ese proxy tamén ve o nome e o volume do destino, pero non a solicitude nin o corpo da resposta.

Que resolutor ve o nome?

A resolución de nomes pode ocorrer localmente antes de que saia a solicitude, ou de forma remota no proxy. Con curl, socks5h:// envía o nome de host ao proxy mentres que socks5:// o resolve primeiro localmente. A configuración de proxy do navegador ofrece unha opción de DNS comparable, e os ficheiros PAC poden enrutar distintos hosts de distintas maneiras.

Dous protocolos poden evitar un proxy sen ningún erro de configuración. WebRTC recolle candidatos por STUN, e QUIC executa HTTP/3 sobre UDP, que un proxy TCP non pode transportar. O navegador volverá a TCP se UDP 443 está bloqueado, así que bloquear UDP 443 no cortafuegos do host (ou no router para toda unha rede), e non un indicador do navegador, é a forma fiable de manter HTTP/3 dentro da ruta do proxy.

Comproba o resolutor desde a perspectiva do destino, non desde a do teu portátil. Unha solicitude que chega co enderezo de saída do proxy pero cun nome resolto localmente segue dicindo ao resolutor local que sitios visitas.

Que ocorre cando falla o intermediario?

Un proxy explícito falla pechado: detén o proceso do proxy e o navegador ou a aplicación devolve un erro de conexión en lugar de saír directamente. As configuracións PAC e WPAD son as que fallan abertas - se o script non se pode obter, o cliente recorre a DIRECT e o sitio volve ver o teu enderezo real. Unha VPN pode fallar aberta ou pechada segundo o cliente e segundo se hai un kill switch ou unha regra de cortafuegos activos.

Proba o caso de fallo a propósito: detén o servizo de proxy e recarga; se obtés unha páxina de erro en lugar dunha carga directa, apunta o URL do PAC a un host inalcanzable para ver o respaldo. Se a páxina segue cargando pola túa ruta habitual, o proxy non ofrece ningunha protección contra a súa propia caída, e esa é unha propiedade que deberías coñecer antes de confiar nel.

A orde decide o que ve o sitio. Un proxy cuxo tráfico saínte viaxa pola VPN deixa ao sitio vendo o enderezo do punto final da VPN; pon o proxy fóra do túnel (VPN cara a un proxy nun host remoto) e o sitio verá no seu lugar o enderezo de saída dese proxy. En calquera caso, os dous saltos poden rexistrar cousas distintas.

Cinco comprobacións, en orde

A lista de comprobación de abaixo é toda a decisión nun só lugar. A cobertura vai primeiro porque elimina a maioría dos desaxustes: se a aplicación que debe cubrirse non respecta a configuración, nada máis adiante na lista a salva.

Logo confirma o resultado coa aplicación que motivou o cambio. Carga unha páxina no navegador configurado, obtén a mesma páxina con curl e compara o enderezo que reporta cada un. Se non coinciden, segue habendo unha extensión, unha regra PAC ou unha anulación a nivel de aplicación, e ningún axuste do túnel o arranxará.

Anota o que configurasches: que aplicacións usan o proxy, se o DNS é local ou remoto, se UDP está bloqueado e cal é o comportamento ante fallos. Ese pequeno inventario é o que fai posible a seguinte comparación, porque «o IP cambiou» nunca che dixo cal destas cinco comprobacións se superou.