Coloque a negociação SOCKS do Netty antes do protocolo da sua aplicação

Ordene um manipulador de proxy SOCKS do Netty antes do tráfego da aplicação e preserve um destino não resolvido quando o DNS do lado do proxy é pretendido.

Para um bootstrap/pipeline Netty existente em que o servidor SOCKS deve resolver o destino:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

pipeline.addFirst(
    new Socks5ProxyHandler(new InetSocketAddress("127.0.0.1", 1080))
);

bootstrap.connect(
    InetSocketAddress.createUnresolved("example.com", 443)
);

O endpoint do proxy é a porta local 1080; o alvo de conexão não resolvido é example.com:443. Não use o endereço do proxy para as duas funções nem resolva o nome antes de o manipulador recebê-lo. Para alvos públicos numa rota de proxy público permitida, a lista de proxies SOCKS5 fornece candidatos para o endpoint de proxy do manipulador.

Coloque Socks5ProxyHandler antes dos manipuladores que trocam tráfego de destino. Aguarde o future da conexão do proxy, não apenas um canal que chegue ao listener. Um método ou destino rejeitado pertence a esta etapa de configuração.

Para HTTPS, a camada TLS seguinte usa o nome do host do destino, a verificação e a confiança necessárias—não a identidade do endpoint SOCKS. Só então começa a troca HTTP/aplicação.

O fragmento não fornece event loops, tipos de canal, manipuladores TLS/HTTP nem tratamento normal de erros. Escolha o construtor SOCKS adequado às necessidades de autenticação; um manipulador HTTP Basic é outro protocolo.

Use o resolver no-op apenas onde este manipulador a jusante detém a resolução de nomes de host. Outras conexões podem precisar de busca local. Mantenha separados a saída do resolver, o future do proxy, o TLS e o resultado da aplicação ao diagnosticar uma falha.

Artigos relacionados