Eng Artemis-Broker-Verbindung, déi mat dem falsche SOCKS-Passwuert erfollegräich ass, huet vläicht de Proxy-Handler iwwersprongen. Préift d'Broker-Zil, net nëmmen socksHost.

D'Transportdokumentatioun beschreift Loopback-Brokeradressen wéi localhost an 127.0.0.1 als Adressen, déi d'SOCKS-Konfiguratioun ëmgoen. Fir den normale lokalen Oplösungswee benotzt déi virgesinn Net-Loopback-Brokeradress, wann d'Verbindung iwwer den Intermédiaire muss goen. En aneren Alias, deen nach ëmmer op Loopback opléist, kann dat selwecht Resultat hunn.

Préift déi genau Bedingung vun der Connector-Versioun

Méi nei Upstream-Connector-Quellcode enthält eng explizit Remote-DNS-Ausnam. D'Bedingung vum Proxy-Handler ass:

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

Wann socksRemoteDNS an enger Implementatioun aktivéiert ass, déi déi Bedingung enthält, léisst den Connector d'Zil onopgeléist an installéiert den SOCKS-Handler och fir en Zil, dat wéi Loopback ausgesäit. Mat dem dokumentéierte Standardwäert false bleift den Test vun der lokaler Adress nach wichteg.

Dat ännert d'Bedeitung vun engem Hostnumm wéi localhost: wann en un en SOCKS-Server fir d'Opléisung iwwergoe gëtt, bezitt et sech op d'Siicht vum Proxy op d'Zil. Bestätegt, datt dëst déi virgesinn Broker-Plaz ass, ier Dir d'Remote-Opléisung auswielt.

Passt d'Verhalen un den installéierten Artemis-Client un. Soubal den Handler tatsächlech an der Route ass, ënnerscheet SOCKS-Authentifizéierung vun der Broker-Authentifizéierung a verifizéiert de resultéierende Verbindungswee, amplaz eng erfollegräich Broker-Sessioun als Beweis ze huelen, datt Proxy-Identitéitsdaten benotzt goufen.

Ähnlech Artikelen