Proxy HTTP, túnel SSH ou VPN: escolha a camada certa

Pergunte a três engenheiros como chegar a um serviço interno e você terá três projetos: um proxy web, um túnel SSH ou uma VPN completa. Os três conseguem colocar um serviço remoto ao alcance e os três conseguem fazer o tráfego parecer vir de outro lugar. As diferenças aparecem depois, quando o protocolo em uso não é o que a ferramenta escolhida pressupõe. Um projeto que passa num teste rápido de navegador costuma falhar na aplicação que motivou o pedido.

Decida com base em dois fatos: quais protocolos precisam atravessar e quem consegue resolver os nomes envolvidos. O resto é preferência.

O proxy só move o que entende

Um proxy web analisa o protocolo para o qual foi criado. O cliente entrega uma requisição e ele a repassa adiante, então um aplicativo sem configuração de proxy nunca participa. Para HTTPS o cliente precisa de um canal opaco, que o proxy fornece via CONNECT em vez de ler a requisição.

Um encaminhamento dinâmico SSH abre uma porta local que fala SOCKS, e essa porta retransmite um fluxo TCP para qualquer destino que o cliente indicar. Protocolos construídos sobre TCP em geral funcionam por ela. UDP não, a menos que uma ferramenta acrescente suporte explicitamente. Um encaminhamento local é ainda mais estreito: uma porta local mapeada para um host e uma porta fixos, que atende a um único serviço conhecido e nada mais.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

Uma VPN move pacotes. Tudo o que o cliente encaminha para o túnel o atravessa, UDP e ICMP incluídos, e é por isso que ela serve a um requisito de rede em vez de a uma única conexão.

Alguém precisa resolver o nome

Quando o nome de destino existe apenas no DNS da rede remota, a máquina que faz a consulta precisa enxergar essa zona. Um proxy web faz a consulta ele mesmo, então um nome interno funciona por meio dele mesmo quando o laptop não consegue resolvê-lo de jeito nenhum. O SOCKS pode se comportar da mesma forma, mas só se o cliente encaminhar o nome em vez de conectar a um endereço que já resolveu. Essa escolha fica no cliente, não no servidor.

O curl mostra a divisão com clareza: uma flag passa o nome do host ao proxy, outra o resolve localmente primeiro. Com resolução local, um nome só interno falha antes de qualquer túnel ser tocado, e o erro culpa o proxy por algo que era na verdade uma decisão de DNS.

A VPN segue o terceiro caminho instalando o resolvedor privado e o domínio de busca ao lado das rotas. Isso é conveniente e cria uma ilusão familiar: uma rota que existe com um resolvedor que não responde parece exatamente um túnel morto, embora os pacotes estejam chegando ao outro lado.

Quando a rede permite apenas uma saída

Muitas redes corporativas permitem conexões de saída somente por meio de um proxy web autenticado. O OpenVPN e o SSH podem ambos funcionar ali, o primeiro tunelando seu próprio transporte pelo proxy e o segundo por um comando de proxy que executa um pequeno auxiliar CONNECT.

Túneis construídos sobre TCP sobrevivem a essa restrição, e uma VPN baseada em UDP não, o que explica muitíssimas configurações que funcionam em casa e falham no escritório. Um segundo custo passa fácil despercebido: um túnel TCP levado dentro de uma conexão TCP proxied agora tem duas camadas retransmitindo, e sob perda essa combinação trava de um modo que nenhuma das camadas produz sozinha.

Encadear intermediários é uma questão diferente de escolher uma camada. Acrescentar um segundo proxy ou o Tor muda quem observa o quê, e a posição na cadeia decide qual salto vê texto cifrado.

A ordem importa mais que o número de saltos. Um salto externo observa um fluxo cifrado enquanto um interno vê o texto claro que ele carrega, então uma cadeia é tão privada quanto seu elo menos cuidadoso. Misturar protocolos entre saltos não melhora isso automaticamente. Na maior parte, só torna os modos de falha mais difíceis de raciocinar.

Um endereço forjado não é uma das opções

Criar pacotes com o endereço de origem de outra pessoa não alcança nada útil: as respostas vão ao dono real, e a maioria das redes descarta o tráfego de imediato. Um intermediário é necessário justamente porque a origem não pode ser inventada, e essa é a justificativa honesta dos três projetos.

Isso também limita o que qualquer um deles pode alegar. Parecer originar-se de um endereço específico é uma questão sobre onde esse endereço é atribuído legitimamente e quem pode roteá-lo, não sobre qual ferramenta consegue falsificar um cabeçalho. Se um projeto assume o contrário, a suposição falha no primeiro provedor que a filtra. Anote a suposição para que a falha seja reconhecível quando chegar.

Decida por protocolos e nomes

Recorra a um proxy quando um único cliente web precisa de um único serviço web e tem configurações de proxy. Recorra a um túnel SSH quando alguns serviços TCP conhecidos bastam e o acesso SSH já existe. Recorra a uma VPN quando vários aplicativos, tráfego não TCP, DNS privado ou um caminho reutilizável fazem parte do requisito.

Depois verifique com o cliente real e o nome real. Carregar uma página por um proxy não ensina nada sobre UDP, e fazer uma ferramenta funcionar sobre SOCKS não ensina nada sobre o resolvedor do sistema. Leia qual endereço local o processo vinculou e qual resolvedor respondeu. É a diferença entre um caminho que funciona e um que funcionou por acaso uma vez.