Wat is Surrogate IP?
Surrogate IP is een Zscaler-dienst die een geauthenticeerde gebruiker aan zijn private IP-adres koppelt, zodat diens gebruikerspolicies ook gelden voor verkeer dat de dienst niet rechtstreeks kan authenticeren. Volgens de Zscaler-documentatie betreft dit vooral applicaties zonder cookie-ondersteuning, niet-ontsleutelde HTTPS-verbindingen en transacties met onbekende user agents. Zonder Surrogate IP zouden voor zulk verkeer alleen de generieke locatiepolicies gelden. De koppeling geldt voor één gebruiker per adres, wordt meegenomen in de logs en eindigt bij inactiviteit, afmelden, of het aanmelden van een andere gebruiker vanaf hetzelfde adres.
Surrogate IP in detail
Het mechanisme is bewust eenvoudig: meldt een gebruiker zich succesvol aan op een bekende locatie, dan onthoudt de dienst de koppeling „dit private IP-adres hoort op dit moment bij deze gebruiker". Vanaf dat moment worden ook transacties zonder gebruikersidentificatie aan deze persoon toegeschreven, zowel in de policies als in de logs. Praktisch neveneffect: wie zich in de ene browser heeft geauthenticeerd, hoeft zich in een tweede browser of in desktoptoepassingen niet opnieuw aan te melden.
Vereist zijn een doorstuurpad dat het private adres zichtbaar houdt (GRE- of IPsec-tunnel zonder NAT, proxy chaining met XFF-doorgifte, of een dedicated proxypoort), plus verplichte authenticatie op de locatie. De grenzen liggen daar waar veel gebruikers een adres delen: voor multi-session VDI raadt Zscaler het gebruik uitdrukkelijk af, omdat de koppeling dan de verkeerde gebruiker kan treffen.
Waarom telt Surrogate IP in de Zscaler-praktijk?
In de praktijk verklaart Surrogate IP een hele familie van raadselachtige tickets. Een gebruiker krijgt schijnbaar willekeurig de verkeerde policies: in werkelijkheid geldt de locatiepolicy, omdat de koppeling is verlopen. Twee collega's delen een pc, en de tweede erft de blokkades van de eerste: in werkelijkheid staat de koppeling nog. Een desktoptoepassing gedraagt zich anders dan de browser: in werkelijkheid ontbreekt zonder Surrogate IP de gebruikersidentificatie voor niet-browserverkeer.
Ook voor analyses telt het mechanisme dubbel: de koppeling maakt logs gebruikersgebonden en dus veelzeggend, maar draagt ook foutieve koppelingen over naar het logboek. Wie rapporten of bewijsvoering op loggegevens baseert, moet weten op welke locaties Surrogate IP actief is, met welke inactiviteitstijd, en waar gedeelde apparaten de zeggingskracht beperken.
Veelvoorkomende foutbronnen
- Surrogate IP gecombineerd met multi-session VDI: veel gebruikers delen een adres, policies en logs treffen de verkeerde personen.
- Inactiviteitstijd verkeerd gekozen: te kort veroorzaakt voortdurende terugval op locatiepolicies, te lang houdt koppelingen op gedeelde apparaten kunstmatig in leven.
- NAT in het doorstuurpad: verdwijnt het private adres onderweg, dan kan de dienst niet koppelen en werkt de functie niet.
- Ontbrekende documentatie over waar Surrogate IP actief is: de helpdesk interpreteert policy-afwijkingen dan als Zscaler-fout in plaats van als koppelingskwestie.
Surrogate IP in de praktijk: wat CentaurNexus bijdraagt
Of achter vreemd policygedrag een verlopen of vreemde koppeling schuilt, achterhaalt CentaurNexus zonder onderzoek in losse weergaven. De 360°-gebruikerszoekopdracht toont op naam, e-mail of IP-adres de status van een gebruiker over ZIA, ZPA en ZDX op één pagina, zonder Zscaler-beheerdersrechten. Connectivity Triage Map geeft daarbij in gewone taal aan of een probleem aan het apparaat, het netwerk, een policy of de koppeling ligt. Zo beantwoordt de eerstelijns medewerker de vraag „waarom geldt voor mij de verkeerde regel?" met een bevinding in plaats van een onderbuikgevoel. De 360-gradenaanpak beschrijft dit artikel: Zscaler-support zonder beheerdersrechten.
Verwante begrippen
Veelgestelde vragen over Surrogate IP
Niet al het verkeer is rechtstreeks te authenticeren: applicaties zonder cookie-ondersteuning, niet-ontsleutelde HTTPS-verbindingen en onbekende user agents dragen geen gebruikersidentificatie. Surrogate IP dicht dat gat door zulke transacties via het private IP-adres toe te schrijven aan de laatst daar geauthenticeerde gebruiker. Zo gelden gebruikerspolicies in plaats van de generieke locatiepolicies.
De koppeling geldt voor precies één gebruiker per IP-adres en blijft bestaan totdat de ingestelde inactiviteitstijd verstrijkt, de gebruiker zich afmeldt, of een andere gebruiker zich vanaf hetzelfde adres authenticeert. De beheerder stelt de inactiviteitstijd in op locatieniveau; dat is de belangrijkste hendel tussen gebruiksgemak en een zuivere koppeling.
Zscaler raadt het gebruik met multi-session VDI af, omdat daar veel gebruikers een virtuele machine en dus hetzelfde private IP-adres delen. De koppeling kan verkeer dan aan de verkeerde gebruiker toeschrijven, zowel in de policies als in de logs. Voor zulke omgevingen zijn andere authenticatiemethoden de betere keuze.
Volgens de Zscaler-documentatie is een doorstuurpad nodig dat het private IP zichtbaar houdt: een GRE- of IPsec-tunnel zonder NAT, proxy chaining met geactiveerde XFF-doorgifte, of een dedicated proxypoort. Daarnaast moet op de locatie authenticatie verplicht zijn. Pas dan kan de dienst gebruiker en adres betrouwbaar aan elkaar koppelen.
De dienst schrijft de gekoppelde transacties ook in de logs aan de gebruiker toe. Dat maakt analyses veelzeggender, maar betekent ook: een foutieve koppeling, bijvoorbeeld op gedeelde pc's, komt eveneens in het logboek terecht. Wie logs gebruikt voor bewijsvoering of analyse, moet de grenzen van de IP-gebaseerde koppeling kennen en documenteren.
- Zscaler Help Portal: Understanding Surrogate IP - help.zscaler.com
- Zscaler Help Portal: Understanding User Provisioning and Authentication - help.zscaler.com
Let op: CentaurNexus is een onafhankelijk product van SourcingBlox GmbH en geen aanbod van Zscaler, Inc. Product- en merknamen behoren toe aan hun respectieve eigenaren.