Размясціце SOCKS-перамовы Netty перад пратаколам вашай праграмы

Змяшчайце апрацоўшчык SOCKS-проксі Netty перад трафікам праграмы і захоўвайце нявырашаны пункт прызначэння, калі DNS патрэбны на баку проксі.

Для існуючага Netty bootstrap/pipeline, дзе SOCKS-сервер павінен вырашаць пункт прызначэння:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

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

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

Канечная кропка проксі — лакальны порт 1080; нявырашаная мэта злучэння — example.com:443. Не выкарыстоўвайце адрас проксі для абедзвюх роляў і не вырашайце імя да таго, як апрацоўшчык яго атрымае. Для публічных мэтаў на дазволеным маршруце публічнага проксі спіс SOCKS5-проксі дае кандыдатаў для канечнай кропкі проксі апрацоўшчыка.

Змяшчайце Socks5ProxyHandler перад апрацоўшчыкамі, што абменьваюць трафік пункта прызначэння. Чакайце future злучэння проксі, а не проста канал, што дасягнуў слухача. Адхілены метад або пункт прызначэння належыць гэтаму этапу наладкі.

Для HTTPS наступны ўзровень TLS выкарыстоўвае імя хаста пункта прызначэння, неабходную праверку і давер—а не ідэнтычнасць канечнай кропкі SOCKS. Толькі пасля гэтага пачынаецца абмен HTTP/праграмы.

Фрагмент не дае цыклаў падзей, тыпаў каналаў, апрацоўшчыкаў TLS/HTTP або звычайнай апрацоўкі памылак. Выбірайце канструктар SOCKS, што адпавядае патрэбам аўтэнтыфікацыі; апрацоўшчык HTTP Basic — іншы пратакол.

Выкарыстоўвайце no-op resolver толькі там, дзе гэты ніжні апрацоўшчык валодае вырашэннем імя хаста. Іншыя злучэнні могуць патрабаваць лакальнага пошуку. Трымайце вывад resolver, future проксі, TLS і вынік праграмы асобна пры дыягностыцы збою.

Падобныя артыкулы