Einen Benutzer zu definieren ist nicht die gesamte Anmeldekonfiguration von 3proxy. Der Dienst benötigt außerdem eine Authentifizierungsmethode und eine Zugriffsregel, die sie verwendet. Die Reihenfolge ist wichtig, weil die Diensteinstellungen während der Verarbeitung der Konfiguration angewendet werden.

Ein nur lokales Beispiel für zwei Dienste ist:

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

Die Konfigurationsreferenz erklärt users, auth strong und die Dienstbefehle. CL speichert dieses Beispielkennwort im Klartext. Schützen Sie die Datei und wählen Sie eine unterstützte Form der Speicherung von Zugangsdaten, die für die Bereitstellung geeignet ist.

Der Client benötigt den richtigen Anmeldeaustausch

Der HTTP-Dienst erwartet eine HTTP-Proxy-Authentifizierung. Der SOCKS-Dienst benötigt einen Client, der die SOCKS5-Authentifizierung mit Benutzername und Kennwort unterstützt. Ein SOCKS4-Client kann diesen Austausch nicht bereitstellen, nur weil er denselben Listener-Port erreicht.

Das Wort strong ist der Name eines Authentifizierungsmodus, keine Garantie für einen verschlüsselten Transport. Schützen Sie die Strecke vom Client zum Proxy, wenn das nötig ist. HTTPS zum Ziel und Verschlüsselung zum Proxy bleiben getrennte Entscheidungen.

Loopback-Bindungen beschränken dieses Beispiel auf lokalen Zugriff. Wählen Sie für entfernte Clients ausdrücklich einen vorgesehenen Listener und eine Netzwerkrichtlinie. Ein öffentlicher Wildcard-Listener ersetzt nicht die Prüfung des Anmeldeverhaltens.

Wenn ein Dienst nach Zugangsdaten fragt und ein anderer nicht, prüfen Sie die Einstellungen vor jedem Dienstbefehl, die Regeln nach jedem flush und die Zwischenspeicherung der Authentifizierung. Ein geändertes Kennwort kann einen Dienst nicht reparieren, der unter der falschen Richtlinie gestartet wurde. Ebenso erzeugt ein Wechsel des Betriebssystemkontos des Daemons keinen Proxy-Benutzer.

Ähnliche Artikel