Az Artemis megkerülheti a SOCKS-t loopback broker esetén
Ellenőrizze a broker célját és a socksRemoteDNS viselkedését, amikor egy Artemis-kapcsolat szándékosan hibás SOCKS-hitelesítő adatokkal is sikeres.
Előfordulhat, hogy a helytelen SOCKS-jelszóval sikeres Artemis broker-kapcsolat kihagyta a proxy-kezelőt. Ellenőrizze a broker célját, ne csak a socksHostot.
A transport dokumentációja a localhost és 127.0.0.1 típusú loopback broker-címeket olyan címekként írja le, amelyek megkerülik a SOCKS konfigurációt. A szokásos helyi feloldási útvonalhoz a szándékolt, nem loopback broker-címet használja, amikor a kapcsolatnak a közvetítőn keresztül kell haladnia. Egy másik alias, amely továbbra is loopbackre oldódik, ugyanazt az eredményt adhatja.
Ellenőrizze a connector verziójának pontos feltételét
Az újabb upstream connector forráskódja kifejezett remote-DNS kivételt tartalmaz. A proxy-kezelő feltétele:
socksEnabled && (socksRemoteDNS || !isTargetLocalHost())Ha a socksRemoteDNS engedélyezett egy olyan implementációban, amely tartalmazza ezt a feltételt, a connector a célt feloldatlanul hagyja, és a SOCKS-kezelőt még egy loopbacknek tűnő cél esetén is telepíti. A dokumentált false alapértékkel a helyi cím vizsgálata továbbra is számít.
Ez megváltoztatja egy olyan gazdanév jelentését, mint a localhost: amikor feloldásra egy SOCKS-kiszolgálónak adják át, a proxy célról alkotott nézetére utal. A távoli feloldás kiválasztása előtt erősítse meg, hogy ez a szándékolt broker-hely.
Igazítsa a viselkedést a telepített Artemis-ügyfélhez. Miután a kezelő valóban az útvonalon van, különböztesse meg a SOCKS-hitelesítést a broker-hitelesítéstől, és ellenőrizze a létrejövő kapcsolati útvonalat ahelyett, hogy egy sikeres broker-munkamenetet a proxy-hitelesítő adatok használatának bizonyítékaként kezelne.