Proxies SOCKS5 e SOCKS4

Um proxy SOCKS permite que um aplicativo peça a um servidor intermediário que se conecte a um destino por ele. O proxy abre a conexão solicitada e transmite dados nas duas direções. O aplicativo continua usando seu próprio protocolo; por isso, isso funciona para solicitações web, clientes de API, transferências de arquivos e outros softwares com suporte a SOCKS.

Para uma nova configuração, SOCKS5 geralmente oferece as opções mais úteis: mais formatos de endereço, uma escolha de métodos de autenticação e suporte a UDP. SOCKS4 continua útil para softwares que exigem a versão mais antiga. A escolha mais ampla entre esses protocolos e proxies HTTP é abordada em Proxies SOCKS ou HTTP.

Como um aplicativo se conecta por SOCKS

Considere um aplicativo que abre https://example.com/ por um proxy SOCKS5. Primeiro, ele alcança o proxy, pede que abra uma conexão com o site e só então troca dados do site. O processo tem quatro etapas:

1. O aplicativo se conecta ao nome de host ou IP e à porta de escuta do proxy por TCP.
2. O aplicativo e o proxy selecionam um método de acesso. Se esse método exige credenciais, o aplicativo as fornece e o proxy as verifica.
3. O aplicativo envia uma solicitação SOCKS CONNECT com o endereço e a porta de destino. O proxy verifica suas regras de acesso, tenta a conexão seguinte e informa o resultado.
4. Após uma resposta bem-sucedida, o aplicativo se comunica com o destino pelo proxy. Para um site HTTPS, ele estabelece TLS com o site e verifica seu certificado antes de enviar a solicitação web.

Os dois números de porta pertencem a servidores diferentes. Um proxy de exemplo pode escutar em proxy.example:1080, enquanto o site é acessado em example.com:443. A porta 1080 é convencional para SOCKS, mas um serviço pode usar outra porta. Use a porta de escuta atribuída ao seu proxy; ela não substitui a porta do destino.

Durante o encaminhamento TCP comum, SOCKS transmite o fluxo de bytes do aplicativo sem precisar interpretar cada solicitação HTTP ou comando de arquivo. O aplicativo continua se comunicando com o destino em seu próprio protocolo. Por isso, o mesmo mecanismo de conexão SOCKS pode atender clientes web e outros tipos de software.

CONNECT é um comando de SOCKS, com seu próprio formato de mensagem; ele é diferente do método HTTP CONNECT. SOCKS também define BIND para aplicativos que precisam que um servidor faça uma conexão de retorno pelo proxy, como pode acontecer com FTP ativo. BIND exige suporte separado e não é usado para uma solicitação comum de site ou API.

O que muda entre SOCKS4, SOCKS4a e SOCKS5

SOCKS4 abre conexões TCP com endereços IPv4. SOCKS4a acrescenta a opção de enviar um nome de host para que o proxy encontre seu IP por DNS. SOCKS5 acrescenta uma escolha de métodos de autenticação, aceita endereços IPv4, endereços IPv6 e nomes de host e define o encaminhamento UDP.

Esses são recursos do protocolo. O cliente e o serviço de proxy devem implementar o recurso específico que você pretende usar. Por exemplo, um serviço SOCKS5 pode lidar com conexões TCP sem oferecer uma retransmissão UDP utilizável.

SOCKS5 pode transportar um destino IPv6 na solicitação, mas o proxy também deve conseguir alcançar esse servidor IPv6. As duas conexões podem usar versões de IP diferentes: o aplicativo pode chegar ao proxy por IPv4, enquanto o proxy se conecta ao destino por IPv6.

SOCKS4a é uma extensão de SOCKS4, não outro nome para toda conexão SOCKS4. Se um cliente antigo só envia endereços IPv4, selecionar SOCKS4 não lhe dá DNS remoto. SOCKS4a exige suporte nas duas extremidades. SOCKS5 normalmente é a escolha mais simples quando as duas extremidades oferecem suporte; selecionar SOCKS4 não melhora, por si só, a reputação nem a velocidade do IP de saída.

Quem resolve o nome do destino

Antes que uma conexão possa alcançar um servidor pelo nome, esse nome deve ser traduzido em um endereço IP. SOCKS5 pode aceitar o resultado dessa consulta ou o próprio nome. A configuração de DNS do cliente determina o que ele envia.

Com DNS local, o aplicativo consulta seu resolvedor configurado sobre reports.example. Suponha que a resposta seja 203.0.113.27: o aplicativo então solicita uma conexão SOCKS com 203.0.113.27:443. A consulta já aconteceu do lado do cliente, embora a conexão posterior com o site passe pelo proxy.

Com DNS do lado do proxy, o aplicativo envia reports.example:443 sem consultar esse destino localmente primeiro. O proxy obtém seu IP por DNS e abre a conexão solicitada. O nome de host chega ao proxy como parte da solicitação SOCKS.

Isso pode ajudar quando o cliente não consegue resolver um nome que o proxy consegue resolver. Alguns serviços retornam endereços diferentes conforme o resolvedor DNS; por isso, mover a consulta pode mudar qual servidor recebe a conexão. Isso não define o país de saída do proxy nem garante que o site aceitará a solicitação.

No curl, os dois comandos a seguir escolhem os dois modos de DNS:

curl --proxy socks5://proxy.example:1080 https://example.com/
curl --proxy socks5h://proxy.example:1080 https://example.com/

socks5:// faz o curl resolver o nome do site localmente; socks5h:// o passa ao proxy. Os dois usam SOCKS5. O h significa resolução de nome de host pelo proxy na sintaxe de URL desse cliente. Ele não transforma SOCKS5 em HTTPS nem acrescenta criptografia. Outros aplicativos podem usar uma caixa de seleção ou escolher DNS remoto automaticamente. Substitua o nome de host e a porta do proxy de exemplo pelos dados do seu serviço e forneça a autenticação exigida.

Passar um nome de domínio em uma solicitação TCP SOCKS5 não exige suporte à retransmissão UDP. O proxy realiza a consulta usando sua própria configuração de DNS. Isso é diferente de pedir ao SOCKS5 que transporte os pacotes UDP de um cliente.

Se um cliente foi configurado para deixar o DNS do destino a cargo do proxy, mas faz essa consulta localmente, ele expõe o nome solicitado fora da rota pretendida. Isso é um vazamento de DNS. O DNS criptografado protege a troca com o resolvedor, mas esse resolvedor ainda recebe o nome. Consultar o nome de host do próprio proxy é uma tarefa separada, e outros aplicativos mantêm seu próprio comportamento de DNS. O DNS remoto em um programa não move todas as consultas do dispositivo.

Autenticação e criptografia

SOCKS5 permite que o cliente ofereça métodos de autenticação compatíveis e que o proxy escolha um. Nome de usuário e senha são uma opção. Outra é uma conexão sem uma troca de login SOCKS, que um serviço pode permitir depois de verificar o IP de origem do cliente em uma lista de IPs permitidos. Portanto, um ponto de conexão sem campo de senha ainda pode restringir o acesso.

Uma falha na negociação de um método é diferente de uma senha rejeitada: no primeiro caso, a troca de senha não aconteceu. Um cliente sem suporte a nome de usuário/senha não consegue usar um ponto de conexão SOCKS5 somente com senha apenas por ter uma configuração SOCKS5. SOCKS4 tem um campo de ID de usuário, mas não uma troca padrão equivalente de senha; seu servidor ainda pode aplicar regras de acesso.

A troca habitual de nome de usuário/senha de SOCKS5 não criptografa as credenciais. Ela ocorre antes de o aplicativo estabelecer HTTPS com o destino; por isso, essa conexão HTTPS posterior não protege o login anterior do proxy. Criptografar o caminho entre cliente e proxy exige uma conexão protegida separada ou um mecanismo de segurança explicitamente compatível.

Durante o encaminhamento SOCKS comum, HTTPS protege a troca do aplicativo com o site, com a verificação de certificados ativada e sem interceptação TLS. Um protocolo de aplicativo sem criptografia continua sem criptografia pela retransmissão. O suporte a SOCKS5 ou a autenticação por senha, por si só, não promete tráfego criptografado.

O proxy ainda conhece o IP de conexão do cliente, o destino solicitado e os horários da conexão. O destino vê o IP de saída do proxy e recebe os dados do aplicativo destinados a ele. Cookies, logins de conta e outros identificadores do aplicativo ainda podem identificar o usuário; mudar a versão de SOCKS não os remove.

Como SOCKS5 transporta TCP e UDP

TCP fornece um fluxo ordenado de bytes. Uma solicitação de navegador, uma chamada de API ou uma sessão SSH pode usar uma conexão TCP SOCKS quando o cliente oferece suporte a essa rota e o proxy permite o destino. O sucesso na porta 443 de um site não comprova que a porta de outro aplicativo está disponível.

UDP envia datagramas separados. Um cliente SOCKS5 primeiro abre uma conexão TCP de controle e solicita uma retransmissão usando UDP ASSOCIATE. O proxy retorna o endereço de retransmissão e a porta UDP. O cliente envia seus datagramas para lá com cabeçalhos SOCKS que descrevem seus destinos. Fechar a conexão TCP de controle encerra essa associação UDP; os datagramas viajam separadamente da conexão de controle, não dentro de um fluxo SOCKS CONNECT comum.

O aplicativo e o serviço devem oferecer suporte a esse mecanismo, e a rede deve permitir o caminho UDP. Um programa pode concluir um login TCP enquanto sua função de voz, jogo ou outra função UDP ainda falha. Uma solicitação HTTPS bem-sucedida por SOCKS CONNECT demonstra encaminhamento TCP, não UDP em funcionamento. QUIC usa UDP, mas QUIC utilizável também depende do cliente e do caminho completo; o rótulo SOCKS5, por si só, não comprova isso.

Onde SOCKS é útil

SOCKS é útil quando um software precisa de uma conexão intermediária e mantém seu próprio protocolo de aplicativo. Um script pode solicitar dados de API por um IP de saída atribuído, um cliente de transferência de arquivos pode alcançar um servidor remoto por uma rota aprovada e um aplicativo de desktop compatível pode usar um proxy sem ser um navegador web. Cada caso depende do suporte a SOCKS do cliente e das portas de destino permitidas pelo serviço.

Para trabalho repetido com a mesma conta ou servidor, uma saída fixa pode ser adequada. Para tarefas separadas, um serviço rotativo pode ser útil. SOCKS4 e SOCKS5 não decidem esse comportamento: o serviço determina o IP de saída, seu tipo de rede, se outros clientes o usam e quando ele muda. A versão do protocolo também não fornece uma classificação de velocidade; o comprimento da rota, a carga do servidor e a largura de banda disponível afetam o resultado.

O suporte do cliente pode ser mais restrito que o protocolo. A implementação integrada de SOCKS5 no Chrome resolve nomes de destino pelo proxy, mas não realiza autenticação SOCKS5 com nome de usuário/senha nem retransmite UDP. Portanto, um ponto de conexão somente com senha pode funcionar no curl e falhar nessa configuração integrada do navegador. Um adaptador externo é uma parte separada da conexão, com seus próprios recursos.

Um proxy configurado dentro de um programa se aplica às conexões compatíveis desse programa. Ele não configura um baixador ou script separado. Da mesma forma, as configurações de proxy do sistema afetam os softwares que as usam. Quando um adaptador redireciona conexões de um aplicativo sem suporte nativo a SOCKS, seu alcance para TCP, UDP e DNS importa. SOCKS não oferece encaminhamento ICMP comum; por isso, ping não é um teste desse caminho de proxy.

Configurações de conexão e um teste útil

Comece com o endereço do proxy, a porta de escuta, a versão de SOCKS e o método de acesso fornecidos para o ponto de conexão. Um número como 1080 não identifica o protocolo por si só. Selecione SOCKS no cliente em vez de inserir o mesmo endereço em um campo de proxy somente HTTP.

As credenciais do proxy autorizam o uso do intermediário; um login de site autoriza o uso do site. Eles pertencem a configurações diferentes. No curl, --proxy-user fornece credenciais de proxy, enquanto --user fornece credenciais de destino. Para acesso por IP, a lista de IPs permitidos deve corresponder ao IP de origem do cliente visto pelo proxy, que pode mudar quando o cliente troca de rede.

Escolha o modo de DNS pretendido e depois verifique as regras de exceção. Um proxy configurado pode ser ignorado para destinos em uma lista de exclusão. No curl, NO_PROXY pode causar isso; --noproxy "" limpa essas exclusões em uma execução quando você deseja deliberadamente testar a rota pelo proxy.

Teste no programa que realmente fará o trabalho. Um ponto de conexão de verificação de IP ou o log de um servidor de destino que você controla pode mostrar o IP de origem da solicitação. Compare esse resultado com uma solicitação direta. O endereço usado para alcançar o proxy e o endereço de saída visto pelo destino não precisam ser idênticos.

Depois, tente a tarefa real. Um IP alterado demonstra a rota da solicitação testada, mas não mede todos os transportes nem comprova como outro site responderá. Teste UDP ou IPv6 separadamente quando a tarefa precisar deles e avalie o tempo de resposta e a estabilidade da conexão com uma carga de trabalho representativa.

Localize um erro pela etapa da conexão

Diferencie alcançar o proxy, obter acesso, abrir a conexão com o destino e receber a resposta do aplicativo. Essas etapas têm causas diferentes de falha.

Se uma conexão HTTPS verificada tem sucesso e o site retorna uma página de login, CAPTCHA ou recusa de acesso, a conexão SOCKS já transportou essa troca. Investigue a resposta do site e o comportamento do aplicativo. Se a solicitação mostrar seu IP público habitual, verifique o proxy selecionado e as regras de exceção nesse programa.