З'єднання з брокером Artemis, яке успішне з неправильним паролем SOCKS, могло пропустити обробник проксі. Перевірте призначення брокера, а не лише socksHost.

Документація транспорту описує loopback-адреси брокера, як-от localhost і 127.0.0.1, як адреси, що обходять конфігурацію SOCKS. Для звичайного шляху локального розв'язання використовуйте передбачену не-loopback адресу брокера, коли з'єднання має проходити через посередника. Інший alias, який усе ще розв'язується в loopback, може дати той самий результат.

Перевірте точну умову версії конектора

Новіший вихідний код конектора upstream містить явний виняток remote-DNS. Умова обробника проксі така:

socksEnabled && (socksRemoteDNS || !isTargetLocalHost())

Коли socksRemoteDNS увімкнено в реалізації, що містить цю умову, конектор залишає призначення нерозв'язаним і встановлює обробник SOCKS навіть для призначення, схожого на loopback. За документованого значення за замовчуванням false перевірка локальної адреси все ще важлива.

Це змінює значення імені хоста на кшталт localhost: коли його передають серверу SOCKS для розв'язання, воно вказує на подання проксі про призначення. Підтвердьте, що це передбачене розташування брокера, перш ніж вибирати віддалене розв'язання.

Узгодьте поведінку зі встановленим клієнтом Artemis. Коли обробник справді в маршруті, розрізняйте автентифікацію SOCKS і автентифікацію брокера та перевіряйте отриманий шлях з'єднання, а не вважайте успішний сеанс брокера доказом використання даних проксі.

Схожі статті