Placez la négociation SOCKS de Netty avant le protocole de votre application

Ordonnez un gestionnaire de proxy SOCKS Netty avant le trafic applicatif et préservez une destination non résolue lorsque le DNS côté proxy est voulu.

Pour un bootstrap/pipeline Netty existant où le serveur SOCKS doit résoudre la destination :

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

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

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

Le point de terminaison du proxy est le port local 1080 ; la cible de connexion non résolue est example.com:443. N'utilisez pas l'adresse du proxy pour les deux rôles et ne résolvez pas le nom avant que le gestionnaire le reçoive. Pour des cibles publiques sur une route de proxy public autorisée, la liste de proxys SOCKS5 fournit des candidats pour le point de terminaison proxy du gestionnaire.

Placez Socks5ProxyHandler avant les gestionnaires qui échangent le trafic vers la destination. Attendez le future de connexion du proxy, pas simplement un canal qui atteint l'écouteur. Une méthode ou une destination rejetée relève de cette étape de configuration.

Pour HTTPS, la couche TLS suivante utilise le nom d'hôte de la destination, la vérification et la confiance requises—pas l'identité du point de terminaison SOCKS. C'est seulement ensuite que l'échange HTTP/applicatif commence.

L'extrait ne fournit pas de boucles d'événements, de types de canaux, de gestionnaires TLS/HTTP ni de gestion normale des erreurs. Choisissez le constructeur SOCKS adapté aux besoins d'authentification ; un gestionnaire HTTP Basic est un autre protocole.

N'utilisez le résolveur no-op que là où ce gestionnaire en aval possède la résolution du nom d'hôte. D'autres connexions peuvent nécessiter une recherche locale. Gardez distincts la sortie du résolveur, le future du proxy, TLS et le résultat applicatif lors du diagnostic d'une défaillance.

Articles similaires