Ein Client kann sich mit einem Konto an einem Apache-Forward-Proxy authentifizieren, während sich Apache mit einem anderen Konto am übergeordneten Proxy authentifiziert:

client ── client account ── Apache ── parent account ── parent proxy

Für ein festes Konto am übergeordneten Proxy akzeptiert ProxyRemote ab httpd 2.4.59 ein drittes Argument:

ProxyRemote "*" "http://parent.example:3128" "parent-user:replace_with_private_password"

Dies ergänzt die bestehende zugriffskontrollierte Forward-Proxy-Konfiguration, etwa einen privaten Listener, der sowohl eine Client-IP als auch eine Proxy-Anmeldung verlangt. Das Konto gehört zum ausgewählten übergeordneten Proxy. Schützen Sie die Konfiguration, die es enthält, und wählen Sie den von der Bereitstellung geforderten Abgleichsumfang.

Apache sendet diese Basic-Zugangsdaten vorab, ohne zuerst eine Aufforderung abzuwarten. Dadurch werden Transport und Kontorichtlinie der Verbindung zum übergeordneten Proxy wichtig; die spätere HTTPS-Sitzung der Website schützt selbst keinen Klartext-HTTP-Sprung zum übergeordneten Proxy.

Wann dasselbe eingehende Konto weitergegeben werden sollte

Apache verbraucht normalerweise die an ihn selbst gerichtete Proxy-Authentifizierung. Die Umgebungseinstellung proxy-chain-auth erlaubt stattdessen, die Proxy-Zugangsdaten des Clients an den nächsten Proxy weiterzugeben:

SetEnv proxy-chain-auth On

Das ist nur für eine bewusst geteilte Authentifizierungskette geeignet. Sie reicht das eingehende Kontomaterial weiter; sie erfindet keinen anderen Benutzernamen und kein anderes Passwort für den übergeordneten Proxy.

Mit dem expliziten Zugangsdaten-Argument von ProxyRemote hat proxy-chain-auth keine Wirkung. Wählen Sie die Quelle der Zugangsdaten bewusst, statt beide Einstellungen zu überlagern in der Hoffnung, dass das passende Passwort ausgewählt wird.

Diese Mechanismen authentifizieren Proxy-Sprünge. Der Authorization-Header einer Zielwebsite bleibt ein getrennter Austausch.

Ähnliche Artikel