VPN ou proxy: o que cada um cobre e o que não cobre

Tanto uma VPN quanto um proxy direto mudam o endereço que um site vê, e é aí que a maioria das comparações para. A diferença que decide sua configuração é a cobertura: um proxy direto é um intermediário que seu aplicativo escolhe usar, ao contrário do proxy reverso que fica na frente de um site, enquanto uma VPN move tudo o que o sistema operacional roteia para um túnel. Criptografia, tratamento de DNS e comportamento em falhas decorrem dessa divisão. Execute estas cinco verificações em ordem, e a primeira que falhar dirá qual ferramenta você realmente precisa.

Quais aplicativos o intermediário cobre?

Uma extensão de proxy no navegador vale apenas para aquele perfil de navegador. Clientes de e-mail, gerenciadores de pacotes e um segundo navegador continuam usando as próprias configurações, e alguns aplicativos ignoram totalmente as variáveis de proxy do sistema. Uma VPN cobre o que a tabela de roteamento envia ao túnel, e isso pode ser todos os aplicativos ou um subconjunto em túnel dividido, dependendo das rotas e da política do cliente.

Teste os aplicativos que importam em vez de generalizar a partir de um único carregamento de página. curl https://ifconfig.me segue as variáveis de proxy do ambiente; um aplicativo de desktop pode não seguir. No Windows, netsh winhttp show proxy imprime o proxy WinHTTP usado pelos serviços, e essa é uma configuração diferente da do navegador.

O salto é criptografado, e onde o TLS termina?

Um protocolo de proxy é um ponto de encontro, não uma garantia. O SOCKS5 encaminha TCP sem criptografá-lo, e um proxy HTTP simples transporta a linha de requisição e os cabeçalhos em texto claro. HTTPS através de um proxy usa CONNECT, então sua sessão TLS ainda termina no destino, não no proxy. O guia do MDN sobre servidores proxy e tunelamento descreve essa distinção pelo lado do protocolo.

Uma VPN criptografa o trecho entre seu dispositivo e o ponto final dela. Além do ponto final valem as mesmas regras de qualquer outra rede, e por isso um túnel sozinho não protege um aplicativo que envia credenciais por HTTP simples. Nenhum dos dois projetos esconde uma conta conectada, um cookie ou uma impressão digital 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 detalhada mostra se o curl enviou CONNECT para a porta 443 ou um GET simples com uma URL completa. Com socks5h:// o nome do host é entregue ao proxy dentro da requisição SOCKS5 e ele então retransmite TLS que não consegue ler, portanto vê o nome e a contagem de bytes. Por um proxy http://, uma URL https:// é um CONNECT, então esse proxy também vê o nome e o volume do destino, mas não a requisição nem o corpo da resposta.

Qual resolvedor vê o nome?

A resolução de nomes pode acontecer localmente antes de a requisição sair, ou remotamente no proxy. Com o curl, socks5h:// envia o nome do host ao proxy enquanto socks5:// o resolve primeiro localmente. As configurações de proxy do navegador oferecem uma opção de DNS comparável, e arquivos PAC podem encaminhar hosts diferentes de maneiras diferentes.

Dois protocolos podem contornar um proxy sem nenhum erro de configuração. O WebRTC coleta candidatos via STUN, e o QUIC executa HTTP/3 sobre UDP, que um proxy TCP não consegue transportar. O navegador voltará ao TCP se a UDP 443 estiver bloqueada, então bloquear a UDP 443 no firewall do host (ou no roteador para toda uma rede), e não uma flag do navegador, é a forma confiável de manter o HTTP/3 dentro do caminho do proxy.

Verifique o resolvedor da perspectiva do destino, não do seu notebook. Uma requisição que chega com o endereço de saída do proxy mas com um nome resolvido localmente ainda conta ao resolvedor local quais sites você visita.

O que acontece quando o intermediário falha?

Um proxy explícito falha fechado: pare o processo do proxy e o navegador ou aplicativo retorna um erro de conexão em vez de sair direto. As configurações PAC e WPAD são as que falham abertas - se o script não puder ser obtido, o cliente recorre ao DIRECT e o site volta a ver seu endereço real. Uma VPN pode falhar aberta ou fechada dependendo do cliente e de haver um kill switch ou regra de firewall ativa.

Teste o caso de falha de propósito: pare o serviço de proxy e recarregue; se obtiver uma página de erro em vez de um carregamento direto, aponte a URL do PAC para um host inalcançável para ver a alternativa. Se a página ainda carregar pela sua rota habitual, o proxy não oferece nenhuma proteção contra a própria indisponibilidade, e essa é uma propriedade que você deveria conhecer antes de confiar nele.

A ordem decide o que o site vê. Um proxy cujo tráfego de saída passa pela VPN deixa o site vendo o endereço do ponto final da VPN; coloque o proxy fora do túnel (VPN para um proxy em um host remoto) e o site verá, em vez disso, o endereço de saída desse proxy. De qualquer forma, os dois saltos podem registrar coisas diferentes.

Cinco verificações, em ordem

A lista de verificação abaixo é toda a decisão em um só lugar. A cobertura vem primeiro porque elimina a maioria das incompatibilidades: se o aplicativo que precisa ser coberto não respeita a configuração, nada mais adiante na lista o salva.

Depois confirme o resultado com o aplicativo que motivou a mudança. Carregue uma página no navegador configurado, obtenha a mesma página com o curl e compare o endereço que cada um relata. Se divergirem, ainda há uma extensão, uma regra PAC ou uma substituição no nível do aplicativo em jogo, e nenhum ajuste do túnel vai corrigir isso.

Anote o que você configurou: quais aplicativos usam o proxy, se o DNS é local ou remoto, se a UDP está bloqueada e qual é o comportamento em falhas. Esse pequeno inventário é o que torna possível a próxima comparação, porque «o IP mudou» nunca lhe disse qual destas cinco verificações passou.