Поставте SOCKS-узгодження Netty перед протоколом вашого застосунку

Розмістіть обробник проксі SOCKS Netty перед трафіком застосунку та зберігайте невирішену адресу призначення, коли DNS на боці проксі є навмисним.

Для наявного bootstrap/pipeline Netty, де сервер 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 і результат застосунку.

Схожі статті