Artemis kan SOCKS omzeilen voor een loopback-broker
Controleer de broker-bestemming en het socksRemoteDNS-gedrag wanneer een Artemis-verbinding slaagt ondanks opzettelijk verkeerde SOCKS-inloggegevens.
Een Artemis-brokerverbinding die slaagt met het verkeerde SOCKS-wachtwoord heeft mogelijk de proxy-handler overgeslagen. Controleer de broker-bestemming, niet alleen socksHost.
De transportdocumentatie beschrijft loopback-brokeradressen zoals localhost en 127.0.0.1 als adressen die de SOCKS-configuratie omzeilen. Gebruik voor het normale lokale resolutiepad het bedoelde niet-loopback-brokeradres wanneer de verbinding via de tussenpersoon moet lopen. Een andere alias die nog steeds naar loopback resolveert, kan hetzelfde resultaat hebben.
Controleer de exacte voorwaarde van de connectorversie
Nieuwere upstream-connectorbron bevat een expliciete remote-DNS-uitzondering. De voorwaarde van de proxy-handler is:
socksEnabled && (socksRemoteDNS || !isTargetLocalHost())
Wanneer socksRemoteDNS is ingeschakeld in een implementatie die die voorwaarde bevat, laat de connector de bestemming onopgelost en installeert de SOCKS-handler zelfs voor een bestemming die op loopback lijkt. Met de gedocumenteerde standaardwaarde false blijft de test van het lokale adres belangrijk.
Dat verandert de betekenis van een hostnaam zoals localhost: wanneer die naar een SOCKS-server wordt gestuurd voor resolutie, verwijst die naar de bestemmingsweergave van de proxy. Bevestig dat dit de bedoelde brokerlocatie is voordat u voor externe resolutie kiest.
Stem het gedrag af op de geïnstalleerde Artemis-client. Zodra de handler daadwerkelijk in de route zit, onderscheidt u SOCKS-authenticatie van broker-authenticatie en verifieert u het resulterende verbindingspad in plaats van een geslaagde brokersessie te beschouwen als bewijs dat proxy-inloggegevens zijn gebruikt.