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 ад аўтэнтыфікацыі брокера і правярайце атрыманы шлях злучэння, а не лічыце паспяховую сесію брокера доказам выкарыстання ўліковых даных проксі.