Artemis poate ocoli SOCKS pentru un broker loopback
Verificați destinația brokerului și comportamentul socksRemoteDNS când o conexiune Artemis reușește în ciuda unor credențiale SOCKS intenționat greșite.
O conexiune la brokerul Artemis care reușește cu parola SOCKS greșită poate fi ocolit handlerul proxy. Verificați destinația brokerului, nu doar socksHost.
Documentația transportului descrie adresele de broker loopback, cum ar fi localhost și 127.0.0.1, ca adrese care ocolesc configurația SOCKS. Pentru calea normală de rezolvare locală, folosiți adresa de broker non-loopback dorită atunci când conexiunea trebuie să treacă prin intermediar. Un alt alias care se rezolvă în continuare la loopback poate avea același rezultat.
Verificați condiția exactă a versiunii connectorului
Codul sursă mai nou al connectorului upstream include o excepție remote-DNS explicită. Condiția handlerului proxy este:
socksEnabled && (socksRemoteDNS || !isTargetLocalHost())Când socksRemoteDNS este activat într-o implementare care conține această condiție, connectorul lasă destinația nerezolvată și instalează handlerul SOCKS chiar și pentru o destinație care pare loopback. Cu valoarea implicită documentată false, testul adresei locale contează în continuare.
Aceasta schimbă sensul unui nume de gazdă precum localhost: când este transmis unui server SOCKS pentru rezolvare, se referă la vederea proxy-ului asupra destinației. Confirmați că aceasta este locația dorită a brokerului înainte de a alege rezolvarea la distanță.
Aliniați comportamentul la clientul Artemis instalat. Odată ce handlerul este efectiv în rută, distingeți autentificarea SOCKS de autentificarea brokerului și verificați calea de conexiune rezultată în loc să tratați o sesiune de broker reușită drept dovadă că au fost folosite credențiale proxy.