Artemis kan SOCKS omseil vir 'n loopback-broker
Kontroleer die broker-bestemming en socksRemoteDNS-gedrag wanneer 'n Artemis-verbinding slaag ten spyte van opsetlik verkeerde SOCKS-referensies.
'n Artemis-brokerverbinding wat met die verkeerde SOCKS-wagwoord slaag, het moontlik die proxy-hanteerder oorgeslaan. Kontroleer die broker-bestemming, nie net socksHost nie.
Die vervoerdokumentasie beskryf loopback-brokeradresse soos localhost en 127.0.0.1 as adresse wat die SOCKS-konfigurasie omseil. Vir die normale plaaslike oplossingsroete gebruik die beoogde nie-loopback-brokeradres wanneer die verbinding deur die tussenganger moet gaan. 'n Ander alias wat steeds na loopback oplos, kan dieselfde resultaat hê.
Kontroleer die presiese voorwaarde van die connector-weergawe
Nuwer stroomop-connectorbron bevat 'n eksplisiete remote-DNS-uitsondering. Die voorwaarde vir die proxy-hanteerder is:
socksEnabled && (socksRemoteDNS || !isTargetLocalHost())
Met socksRemoteDNS geaktiveer in 'n implementering wat daardie voorwaarde bevat, hou die connector die bestemming onopgelos en installeer die SOCKS-hanteerder selfs vir 'n bestemming wat soos loopback lyk. Met die gedokumenteerde verstekwaarde false bly die plaaslike-adrestoets steeds belangrik.
Dit verander die betekenis van 'n gasheernaam soos localhost: wanneer dit na 'n SOCKS-bediener gestuur word vir oplossing, verwys dit na die proxy se bestemmingsbeeld. Bevestig dat dit die beoogde broker-ligging is voordat jy remote-oplossing kies.
Pas die gedrag by die geïnstalleerde Artemis-kliënt aan. Sodra die hanteerder werklik in die roete is, onderskei SOCKS-verifikasie van broker-verifikasie en verifieer die resulterende verbindingspad in plaas daarvan om 'n suksesvolle broker-sessie as bewys te beskou dat proxy-referensies gebruik is.