Was ist Surrogate IP?
Surrogate IP ist ein Zscaler-Dienst, der einen authentifizierten Nutzer seiner privaten IP-Adresse zuordnet, damit dessen Nutzer-Richtlinien auch für Verkehr gelten, den der Dienst nicht direkt authentifizieren kann. Das betrifft laut Zscaler-Dokumentation vor allem Anwendungen ohne Cookie-Unterstützung, nicht entschlüsselte HTTPS-Verbindungen und Transaktionen mit unbekannten User Agents. Ohne Surrogate IP würden für solchen Verkehr nur die pauschalen Standort-Richtlinien greifen. Die Zuordnung gilt für einen Nutzer je Adresse, wird in den Logs mitgeführt und endet mit Leerlaufzeit, Abmeldung oder der Anmeldung eines anderen Nutzers von derselben Adresse.
Surrogate IP im Detail
Der Mechanismus ist bewusst einfach: Meldet sich ein Nutzer an einem bekannten Standort erfolgreich an, merkt sich der Dienst die Verbindung „diese private IP gehört gerade diesem Nutzer“. Ab dann werden auch Transaktionen ohne Nutzerkennung dieser Person zugeordnet, in den Richtlinien wie in den Protokollen. Praktischer Nebeneffekt: Wer sich in einem Browser authentifiziert hat, muss sich in einem zweiten Browser oder in Desktop-Anwendungen nicht erneut anmelden.
Voraussetzungen sind ein Weiterleitungsweg, der die private Adresse sichtbar hält (GRE- oder IPsec-Tunnel ohne NAT, Proxy-Chaining mit XFF-Weitergabe oder ein dedizierter Proxy-Port), sowie erzwungene Authentifizierung am Standort. Die Grenzen liegen dort, wo sich viele Nutzer eine Adresse teilen: Für Multi-Session-VDI rät Zscaler ausdrücklich vom Einsatz ab, weil die Zuordnung dann falsche Nutzer treffen kann.
Warum ist Surrogate IP im Zscaler-Betrieb wichtig?
Im Alltag erklärt Surrogate IP eine ganze Familie von Rätsel-Tickets. Ein Nutzer bekommt scheinbar willkürlich die falschen Richtlinien: In Wahrheit greift die Standort-Richtlinie, weil die Zuordnung abgelaufen ist. Zwei Kollegen teilen sich einen Rechner, und der zweite erbt die Sperren des ersten: In Wahrheit hält die Zuordnung noch. Eine Desktop-Anwendung verhält sich anders als der Browser: In Wahrheit fehlt ohne Surrogate IP die Nutzerkennung für Nicht-Browser-Verkehr.
Auch für Auswertungen zählt der Mechanismus doppelt: Die Zuordnung macht Logs nutzerbezogen und damit aussagekräftig, sie überträgt aber auch Fehlzuordnungen ins Protokoll. Wer Berichte oder Nachweise auf Log-Daten stützt, sollte wissen, an welchen Standorten Surrogate IP aktiv ist, mit welcher Leerlaufzeit, und wo geteilte Geräte die Aussagekraft begrenzen.
Typische Fehlerquellen
- Surrogate IP mit Multi-Session-VDI kombiniert: Viele Nutzer teilen sich eine Adresse, Richtlinien und Logs treffen die Falschen.
- Leerlaufzeit unpassend gewählt: Zu kurz erzeugt ständige Rückfälle auf Standort-Richtlinien, zu lang hält Zuordnungen an geteilten Geräten künstlich am Leben.
- NAT im Weiterleitungspfad: Verschwindet die private Adresse unterwegs, kann der Dienst nicht zuordnen und die Funktion läuft ins Leere.
- Fehlende Dokumentation, wo Surrogate IP aktiv ist: Der Helpdesk deutet Richtlinien-Anomalien dann als Zscaler-Fehler statt als Zuordnungsfrage.
Surrogate IP in der Praxis: so hilft CentaurNexus
Ob hinter einem seltsamen Richtlinien-Verhalten eine abgelaufene oder fremde Zuordnung steckt, klärt CentaurNexus ohne Ansichten-Recherche. Die 360°-User-Suche zeigt zu Name, E-Mail oder IP-Adresse den Status eines Nutzers über ZIA, ZPA und ZDX auf einer Seite, ohne Zscaler-Admin-Rechte. Connectivity Triage Map ordnet dazu in Klartext ein, ob ein Problem am Gerät, am Netz, an einer Richtlinie oder an der Zuordnung hängt. So beantwortet der First-Level die Frage „Warum gilt für mich die falsche Regel?“ mit Befund statt Bauchgefühl. Den 360-Grad-Ansatz beschreibt der Beitrag Zscaler-Support ohne Admin-Rechte.
Verwandte Begriffe
Häufige Fragen zu Surrogate IP
Nicht jeder Verkehr lässt sich direkt authentifizieren: Anwendungen ohne Cookie-Unterstützung, nicht entschlüsselte HTTPS-Verbindungen und unbekannte User Agents tragen keine Nutzerkennung. Surrogate IP schließt die Lücke, indem der Dienst solche Transaktionen über die private IP-Adresse dem zuletzt dort authentifizierten Nutzer zuordnet. So gelten Nutzer-Richtlinien statt der pauschalen Standort-Richtlinien.
Die Zuordnung gilt für genau einen Nutzer je IP-Adresse und bleibt bestehen, bis die konfigurierte Leerlaufzeit abläuft, der Nutzer sich abmeldet oder sich ein anderer Nutzer von derselben Adresse authentifiziert. Die Leerlaufzeit konfiguriert der Admin am Standort; sie ist der wichtigste Stellhebel zwischen Komfort und sauberer Zuordnung.
Zscaler rät vom Einsatz mit Multi-Session-VDI ab, weil sich dort viele Nutzer eine virtuelle Maschine und damit dieselbe private IP-Adresse teilen. Die Zuordnung kann Verkehr dann dem falschen Nutzer zuschreiben, in den Richtlinien wie in den Logs. Für solche Umgebungen sind andere Authentifizierungswege die bessere Wahl.
Laut Zscaler-Dokumentation braucht es einen Weiterleitungsweg, der die private IP sichtbar hält: einen GRE- oder IPsec-Tunnel ohne NAT, Proxy-Chaining mit aktivierter XFF-Weitergabe oder einen dedizierten Proxy-Port. Zusätzlich muss am Standort die Authentifizierung erzwungen sein. Erst dann kann der Dienst Nutzer und Adresse verlässlich verknüpfen.
Der Dienst schreibt die zugeordneten Transaktionen dem Nutzer auch in den Logs zu. Das macht Auswertungen aussagekräftiger, bedeutet aber zugleich: Eine falsche Zuordnung, etwa an geteilten Rechnern, landet ebenfalls im Protokoll. Wer Logs für Nachweise oder Analysen nutzt, sollte die Grenzen der IP-basierten Zuordnung kennen und dokumentieren.
- Zscaler Help Portal: Understanding Surrogate IP - help.zscaler.com
- Zscaler Help Portal: Understanding User Provisioning and Authentication - help.zscaler.com
Hinweis: CentaurNexus ist ein unabhängiges Produkt der SourcingBlox GmbH und kein Angebot von Zscaler, Inc. Produkt- und Markennamen gehören ihren jeweiligen Inhabern.