Artemis peut contourner SOCKS pour un broker en loopback

Une connexion au broker Artemis qui réussit avec le mauvais mot de passe SOCKS a peut-être ignoré le gestionnaire de proxy. Vérifiez la destination du broker, pas seulement socksHost.

La documentation du transport décrit les adresses de broker en loopback, comme localhost et 127.0.0.1, comme contournant la configuration SOCKS. Pour le chemin normal de résolution locale, utilisez l'adresse de broker non loopback prévue lorsque la connexion doit passer par l'intermédiaire. Un autre alias qui se résout encore en loopback peut donner le même résultat.

Vérifiez la condition exacte de la version du connecteur

Le code source plus récent du connecteur upstream inclut une exception remote-DNS explicite. La condition du gestionnaire de proxy est :

socksEnabled && (socksRemoteDNS || !isTargetLocalHost())

Lorsque socksRemoteDNS est activé dans une implémentation contenant cette condition, le connecteur laisse la destination non résolue et installe le gestionnaire SOCKS même pour une destination qui ressemble à du loopback. Avec sa valeur par défaut documentée false, le test d'adresse locale compte toujours.

Cela change le sens d'un nom d'hôte comme localhost : lorsqu'il est transmis à un serveur SOCKS pour résolution, il désigne la vue de la destination du proxy. Confirmez qu'il s'agit bien de l'emplacement du broker prévu avant de choisir la résolution distante.

Alignez le comportement sur le client Artemis installé. Une fois le gestionnaire réellement dans la route, distinguez l'authentification SOCKS de l'authentification du broker et vérifiez le chemin de connexion obtenu au lieu de considérer une session broker réussie comme la preuve que les identifiants du proxy ont été utilisés.