Artemis может обходить SOCKS для loopback-брокера
Проверьте назначение брокера и поведение socksRemoteDNS, когда соединение Artemis успешно, несмотря на намеренно неверные учётные данные SOCKS.
Соединение с брокером 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 от аутентификации брокера и проверяйте итоговый путь соединения, а не считайте успешный сеанс брокера доказательством использования учётных данных прокси.