Artemis povas preterpasi SOCKS por loopback-brokero
Kontrolu la broker-celon kaj la konduton de socksRemoteDNS kiam Artemis-konekto sukcesas malgraŭ intence malĝustaj SOCKS-akreditiloj.
Artemis-broker-konekto, kiu sukcesas kun la malĝusta SOCKS-pasvorto, eble preterpasis la prokuran tenilon. Kontrolu la broker-celon, ne nur socksHost.
La transporta dokumentaro priskribas loopback-broker-adresojn kiel localhost kaj 127.0.0.1 kiel adresojn, kiuj preterpasas la SOCKS-agordon. Por la normala loka solvovojo, uzu la celitan ne-loopback-broker-adreson kiam la konekto devas iri tra la peranto. Alia alinomo, kiu ankoraŭ solviĝas al loopback, povas havi la saman rezulton.
Kontrolu la ĝustan kondiĉon de la konektila versio
Pli nova upstream-konektila fontkodo enhavas eksplicitan remote-DNS-escepton. La kondiĉo de la prokura tenilo estas:
socksEnabled && (socksRemoteDNS || !isTargetLocalHost())Kiam socksRemoteDNS estas ŝaltita en efektivigo enhavanta tiun kondiĉon, la konektilo lasas la celon nesolvita kaj instalas la SOCKS-tenilon eĉ por celo aspektanta kiel loopback. Kun la dokumentita defaŭlto false, la loka-adresa testo ankoraŭ gravas.
Tio ŝanĝas la signifon de hostnomo kiel localhost: kiam ĝi estas pasigita al SOCKS-servilo por solvado, ĝi rilatas al la cella vidpunkto de la prokurilo. Konfirmu, ke tio estas la celita broker-loko antaŭ ol elekti malproksiman solvadon.
Akkonformigu la konduton al la instalita Artemis-kliento. Post kiam la tenilo estas efektive en la vojo, distingigu SOCKS-aŭtentikigon disde broker-aŭtentikigo kaj kontrolu la rezultan konektopadon anstataŭ trakti sukcesan broker-sesion kiel pruvon, ke prokuraj akreditiloj estis uzitaj.