Zscaler Client Connector-logs analyseren: van export naar bevinding

ZCC-logs zijn een goudmijn, maar lastig te lezen

Wanneer een gebruiker meldt dat een applicatie onbereikbaar is of dat de aanmelding blijft hangen, staat het antwoord vaak al in de logs van de Zscaler Client Connector (ZCC). Daar loggen meerdere componenten parallel: tunnelopbouw, dienststatus, updates en andere processen zijn verspreid over bestanden zoals ZSATunnel.log, ZSAService.log of ZSAUpm.log.

Precies dat maakt handmatige analyse lastig. Een geëxporteerde logbundel bevat veel bestanden, geroteerde archieven en tienduizenden regels. De relevante patronen zijn cryptisch, verspreid over meerdere bestanden en moeten in de tijd met elkaar in verband worden gebracht. In de dagelijkse helpdeskpraktijk ontbreekt daar vaak de tijd voor, en de ervaring om te weten welke regel naar welke oorzaak wijst, is ongelijk verdeeld.

Route 1: logbundel uploaden en laten analyseren

Log Analyzer in CentaurNexus neemt deze stap uit handen. Het verloop voor de uploadroute:

Daarnaast vat een overzicht de metadata van de bundel samen: ZCC-versie, besturingssysteem, Z-Tunnel-versie, gedekte periode, en de tellers voor fouten en waarschuwingen. Dat maakt in één oogopslag duidelijk welke clientstand en welk tijdvenster de analyse eigenlijk bekijkt.

Welke storingspatronen worden herkend

De analyse zoekt naar bekende patronen en wijst ze toe aan categorieën, onder meer: authenticatielussen en aanmeldfouten, verstoorde Z-Tunnel-verbindingen, mislukte DNS-resolutie, PAC-bestandsfouten, niet-voldane device posture, SSL- en certificaatfouten, lokale AV- of firewallblokkades van de ZPA-loopback-pakketten, herkende captive portals en vastgelopen ZCC-upgrades.

Bij elke categorie hoort een aanbeveling die de volgende zinvolle controlestap benoemt: bijvoorbeeld IdP- en SAML-configuratie inclusief systeemtijd bij authenticatielussen, het netwerkpad naar de Service Edge bij tunnelstoringen, of de trust-store-keten bij certificaatfouten. De behandelaar begint niet bij regel één, maar bij de meest waarschijnlijke hefboom.

Drie gevallen, regel voor regel

De onderstaande regels komen uit de geanonimiseerde demobundel die Log Analyzer meebrengt. Ze tonen het formaat waarin de Client Connector daadwerkelijk schrijft: datum, tijd met microseconden, tijdzoneverschil, proces- en threadkenmerk, dan een van vier tokens — ERR, WAR, INF of DBG — en het bericht. Een "INFO", "ERROR" of "WARN" bestaat daar niet; wie daarnaar zoekt, vindt niets.

Geval 1: de Policy komt nooit aan

Symptoom. Een apparaat gedraagt zich alsof het oude instellingen vasthoudt: verkeerd forwarding-profiel, ontbrekende uitzonderingen, een schakelaar die niemand meer zo instelt.

Bestand. ZSAUpm, geschreven door de Policy-downloader (Policy Downloader, ZPD).

2025-10-29 08:56:25.771190(+0100)[20002:30012] ERR ZPD: Failed to download UPM policy.

Bevinding. De analyse registreert dit als een mislukte Policy-download, hoge ernst. De instellingen van de client komen precies uit deze download. Mislukt die, dan werkt het apparaat door met de laatst bekende stand, en meldt dat aan niemand.

Andere verklaring. Eén mislukte poging tijdens een netwerkwissel is normaal. Doorslaggevend is of een latere poging slaagt. In dezelfde bundel staat de ZIA-status krap drie minuten later weer op TUNNEL_FORWARDING: dan was het een episode. Blijft de fout over meerdere cycli bestaan, dan was het dat niet.

Volgende stap. Het tijdvenster vastleggen en controleren of daar ook ADAPTER_DOWN_ERROR of SERVER_DOWN_ERROR voorkomen. Herhaalt de fout zich zonder zulke begeleidende toestanden, dan hoort het geval bij Zscaler-support: met het tijdvenster, niet met de hele bundel.

Geval 2: de systeemproxy wijst ergens anders naartoe

Symptoom. Afzonderlijke bestemmingen lopen langs de tunnel of komen op een vreemde proxy terecht. De gebruiker meldt "het werkt niet", maar de tunnel staat.

Bestand. ZSAService.

2025-09-04 16:32:21.784349(+0200)[20005:30041] INF PAC URL should be: http://127.0.0.1:9000/systemproxy-1a2b3c4d.pac but its changed to: http://proxy.contoso.example:8080/corp.pac

Bevinding. De PAC-URL is van buitenaf overschreven, hoge ernst. De client verwacht zijn eigen, lokaal aangeleverde PAC-bestand; in het systeem staat een ander. Opmerkelijk: het token is INF, niet ERR. De bevinding hangt af van wat de regel zegt, niet van de ernstaanduiding, daarom mist wie alleen op fouten filtert deze regel.

Andere verklaring. Een PAC-bestand dat probleemloos wordt gelezen, is niet automatisch het juiste. In dezelfde bundel staat Pac parse success! — een succesmelding, geen vrijspraak. Ook een group policy object of een tweede beveiligingsproduct kan de systeemproxy-instelling legitiem zetten.

Volgende stap. Het daadwerkelijk ingestelde PAC-bestand controleren tegen twee adressen: één die direct moet gaan, één die via de tunnel moet lopen. Dat kan zonder tenant in de gratis PAC Tester. Wijkt het resultaat af van de bedoeling, dan ligt het aan het bestand, niet aan de client.

Geval 3: de tunnel valt weg, en de oorzaak staat er net vóór

Symptoom. Verbindingen vallen enkele minuten weg, daarna is alles er weer. De gebruiker meldt "Zscaler was weg".

Bestand. ZSAUpm.

2025-10-29 08:56:02.110477(+0100)[20002:30012] ERR ZUIfaceChangeMonitor::getAdapterDetails: Failed to get interface info

Bevinding. Netwerkadapter niet beschikbaar, hoge ernst. De regel staat een halve seconde na de statuswissel ZIA: TUNNEL_FORWARDING → ADAPTER_DOWN_ERROR. De tunnel viel niet weg omdat Zscaler uit de lucht was, maar omdat het apparaat voor een moment geen bruikbare netwerkadapter had.

Andere verklaring. Niet elke regel die op een netwerkprobleem lijkt, is er een. checkTunTcpEchoServerUpImpl en isUdpEchoServerUpImpl zijn de eigen bereikbaarheidstest van het product, en Sending NXDOMAIN … name: wpad. is bewuste WPAD-onderdrukking. Beide horen bij normaal bedrijf en zijn geen storing.

Volgende stap. Het statusverloop binnen hetzelfde tijdvenster lezen. Loopt het via ADAPTER_DOWN_ERROR en eindigt het weer bij TUNNEL_FORWARDING, dan was het een lokale netwerkwissel: wifi, VPN, dockingstation. Staat daar FIREWALL_BLOCK_ERROR of SERVER_DOWN_ERROR, dan verlaat het geval het eindpunt.

Met CentaurNexusAgent vervallen export en upload, het werkt met dezelfde regelbasis als de hier getoonde analyse. Wie dit zonder tenant wil nabootsen: de gratis Log Analyzer brengt precies de bundel mee waar deze drie regels uit komen.

Route 2: met CentaurNexusAgent vervallen export en upload

Op apparaten met CentaurNexusAgent verloopt hetzelfde proces zonder toedoen van de gebruiker. CentaurNexusAgent analyseert de ZCC-logs rechtstreeks op het apparaat en verstuurt uitsluitend gestructureerde bevindingen. Geen export, geen ZIP, geen upload, geen wachttijd in het ticket. Onze video van ongeveer tweeënhalve minuut over dit pad laat zien hoe zo'n bevinding rechtstreeks in de supportcontext opent.

Opent een bevoegde behandelaar de betrokken gebruiker in het Unified Support Center, dan verschijnen de client-logbevindingen inline, in dezelfde bevindingenweergave als bij de uploadroute. Elke bevinding draagt zijn tijdvenster plus eerste en laatste optreden; ook een storing die uren geleden optrad, blijft zo herleidbaar zonder dat de gebruiker deze hoeft te reproduceren. Eén klik opent dezelfde bevindingen in de volledige Log Analyzer-weergave.

Privacy in beide workflows

Ook de uploadroute is ontworpen voor dataminimalisatie: de logs worden alleen in het werkgeheugen geanalyseerd en niet opgeslagen. Persoonsgegevens in voorbeeldregels worden geobfusceerd volgens de tenantinstelling, en elke raadpleging wordt geauditeerd.

Toegang tot bevindingen is rolgebonden beveiligd. Die krijgt alleen wie Log Analyzer of een support center mag gebruiken, en een beheerder die tot bepaalde domeinen is beperkt, ziet uitsluitend gebruikers van zijn eigen domeinen. Loganalyse blijft zo een gecontroleerde workflow en wordt geen zijingang voor brede inzagerechten.

Zscaler blijft de kernleverancier

De Zscaler Client Connector blijft de gezaghebbende clientsoftware en bron van de loggegevens. CentaurNexus vult de ondersteunde workflow aan met analyse, classificatie en oplossingsaanbevelingen, in een gezamenlijke werkcontext voor helpdesk en administratie. De bevindingen verwijzen bewust terug naar de Zscaler-kant van het probleem, bijvoorbeeld posture-profielen, PAC-bestanden of de tunnelconfiguratie, zodat de correctie plaatsvindt waar ze hoort.