Artemis kan kringgå SOCKS för en loopback-broker
Kontrollera broker-destinationen och socksRemoteDNS-beteendet när en Artemis-anslutning lyckas trots avsiktligt felaktiga SOCKS-uppgifter.
En Artemis-brokeranslutning som lyckas med fel SOCKS-lösenord kan ha hoppat över proxy-hanteraren. Kontrollera broker-destinationen, inte bara socksHost.
Transportdokumentationen beskriver loopback-brokeradresser som localhost och 127.0.0.1 som adresser som kringgår SOCKS-konfigurationen. Använd den avsedda icke-loopback-brokeradressen för den vanliga lokala upplösningsvägen när anslutningen måste gå via mellanhanden. Ett annat alias som fortfarande löses till loopback kan ge samma resultat.
Kontrollera connectorversionens exakta villkor
Nyare upstream-connectorkällkod innehåller ett uttryckligt remote-DNS-undantag. Proxy-hanterarens villkor är:
socksEnabled && (socksRemoteDNS || !isTargetLocalHost())När socksRemoteDNS är aktiverat i en implementering som innehåller det villkoret lämnar connectorn destinationen oupplöst och installerar SOCKS-hanteraren även för en destination som ser ut som loopback. Med det dokumenterade standardvärdet false är testet av den lokala adressen fortfarande viktigt.
Det ändrar betydelsen av ett värdnamn som localhost: när det skickas till en SOCKS-server för upplösning hänvisar det till proxyns vy av destinationen. Bekräfta att detta är den avsedda brokerplatsen innan du väljer fjärrupplösning.
Anpassa beteendet till den installerade Artemis-klienten. När hanteraren faktiskt är i rutten skiljer du SOCKS-autentisering från broker-autentisering och verifierar den resulterande anslutningsvägen i stället för att betrakta en lyckad brokersession som bevis på att proxyuppgifterna användes.