Puneți negocierea SOCKS a Netty înaintea protocolului aplicației dvs.

Ordonați un handler proxy SOCKS Netty înaintea traficului aplicației și păstrați o destinație nerezolvată când DNS-ul din partea proxy este intenționat.

Pentru un bootstrap/pipeline Netty existent în care serverul SOCKS trebuie să rezolve destinația:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

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

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

Punctul final al proxy-ului este portul local 1080; ținta de conexiune nerezolvată este example.com:443. Nu folosiți adresa proxy pentru ambele roluri și nu rezolvați numele înainte ca handler-ul să îl primească. Pentru ținte publice pe o rută de proxy public permisă, lista de proxy SOCKS5 oferă candidați pentru punctul final al proxy-ului handler-ului.

Puneți Socks5ProxyHandler înaintea handler-elor care schimbă trafic către destinație. Așteptați future-ul conexiunii proxy, nu doar un canal care ajunge la listener. O metodă sau o destinație respinsă aparține acestei etape de configurare.

Pentru HTTPS, următorul strat TLS folosește numele de gazdă al destinației, verificarea și încrederea necesare—nu identitatea punctului final SOCKS. Abia apoi începe schimbul HTTP/aplicație.

Fragmentul nu oferă bucle de evenimente, tipuri de canal, handler-e TLS/HTTP sau gestionare normală a erorilor. Alegeți constructorul SOCKS potrivit nevoilor de autentificare; un handler HTTP Basic este un alt protocol.

Folosiți resolver-ul no-op doar acolo unde acest handler din aval deține rezolvarea numelui de gazdă. Alte conexiuni pot avea nevoie de căutare locală. Țineți separate ieșirea resolver-ului, future-ul proxy, TLS și rezultatul aplicației la diagnosticarea unei defecțiuni.

Articole similare