En Artemis-broker-tilkobling som lykkes med feil SOCKS-passord, kan ha hoppet over proxy-behandleren. Kontroller broker-destinasjonen, ikke bare socksHost.

Transportdokumentasjonen beskriver loopback-brokeradresser som localhost og 127.0.0.1 som adresser som omgår SOCKS-konfigurasjonen. For den vanlige lokale oppløsningsbanen bruker du den tiltenkte ikke-loopback-brokeradressen når tilkoblingen må gå gjennom mellomleddet. Et annet alias som fortsatt løses til loopback, kan gi samme resultat.

Kontroller den nøyaktige betingelsen i connector-versjonen

Nyere upstream-connectorkilde inneholder et eksplisitt remote-DNS-unntak. Betingelsen for proxy-behandleren er:

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

Når socksRemoteDNS er aktivert i en implementering som inneholder den betingelsen, holder connectoren destinasjonen uløst og installerer SOCKS-behandleren selv for en destinasjon som ser ut som loopback. Med den dokumenterte standardverdien false er testen av den lokale adressen fortsatt viktig.

Det endrer betydningen av et vertsnavn som localhost: når det sendes til en SOCKS-server for oppløsning, viser det til proxyens syn på destinasjonen. Bekreft at dette er den tiltenkte broker-plasseringen før du velger ekstern oppløsning.

Tilpass atferden til den installerte Artemis-klienten. Når behandleren faktisk er i ruten, skill SOCKS-autentisering fra broker-autentisering og verifiser den resulterende tilkoblingsbanen i stedet for å behandle en vellykket broker-økt som bevis på at proxy-påloggingsinformasjon ble brukt.

Relaterte artikler