Analyser les logs Zscaler Client Connector : de l'export au constat

Les logs ZCC sont une mine d'or, mais pénibles à lire

Quand un utilisateur signale qu'une application est inaccessible ou que la connexion reste bloquée, la réponse se trouve souvent déjà dans les logs du Zscaler Client Connector (ZCC). Plusieurs composants y journalisent en parallèle : établissement du tunnel, statut du service, mises à jour et autres processus se répartissent dans des fichiers comme ZSATunnel.log, ZSAService.log ou ZSAUpm.log.

C'est précisément ce qui rend l'analyse manuelle pénible. Un lot de logs exporté contient de nombreux fichiers, des archives tournantes et des dizaines de milliers de lignes. Les schémas pertinents sont cryptiques, répartis sur plusieurs fichiers et doivent être mis en relation dans le temps. Au quotidien du helpdesk, le temps manque souvent pour cela, et l'expérience permettant de savoir quelle ligne pointe vers quelle cause est inégalement répartie.

Voie 1 : charger le lot de logs et le faire analyser

Log Analyzer dans CentaurNexus prend en charge cette étape. Le déroulement pour la voie du chargement :

Un aperçu résume en plus les métadonnées du lot : version ZCC, système d'exploitation, version de Z-Tunnel, période couverte, ainsi que les compteurs d'erreurs et d'avertissements. Cela rend clair d'un coup d'œil quel état de client et quelle fenêtre temporelle l'analyse couvre.

Quels schémas de panne sont détectés

L'analyse recherche des schémas connus et les rattache à des catégories, entre autres : boucles d'authentification et échecs de connexion, connexions Z-Tunnel perturbées, résolution DNS échouée, erreurs de fichier PAC, posture d'appareil non conforme, erreurs SSL et de certificat, blocage local par antivirus ou pare-feu des paquets de loopback ZPA, portails captifs détectés et mises à jour ZCC bloquées.

Chaque catégorie est accompagnée d'une recommandation qui indique la prochaine étape de vérification pertinente : par exemple la configuration IdP et SAML ainsi que l'heure système pour les boucles d'authentification, le chemin réseau vers le Service Edge pour les perturbations de tunnel, ou la chaîne du trust store pour les erreurs de certificat. L'opérateur ne commence pas à la ligne un, mais par le levier le plus probable.

Trois cas, ligne par ligne

Les lignes ci-dessous proviennent du lot de démonstration anonymisé fourni avec Log Analyzer. Elles montrent le format réellement écrit par le Client Connector : date, heure avec microsecondes, décalage de fuseau horaire, identifiant de processus et de thread, puis l'un de quatre jetons — ERR, WAR, INF ou DBG — et le message. Il n'existe pas de « INFO », « ERROR » ou « WARN » dans ces logs ; qui cherche cela ne trouve rien.

Cas 1 : la Policy n'arrive jamais

Symptôme. Un appareil se comporte comme s'il gardait d'anciens réglages : mauvais profil de forwarding, exceptions manquantes, un interrupteur que plus personne ne règle ainsi.

Fichier. ZSAUpm, écrit par le téléchargeur de Policy (Policy Downloader, ZPD).

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

Constat. L'analyse l'enregistre comme un échec de téléchargement de Policy, gravité élevée. Les réglages du client proviennent exactement de ce téléchargement. S'il échoue, l'appareil continue avec le dernier état connu, et ne le signale à personne.

Autre explication. Un seul échec pendant un changement de réseau est normal. Ce qui compte, c'est de savoir si une tentative ultérieure réussit. Dans le même lot, l'état ZIA repasse à TUNNEL_FORWARDING à peine trois minutes plus tard : il s'agissait alors d'un épisode. Si l'erreur persiste sur plusieurs cycles, ce n'en était pas un.

Prochaine étape. Noter la fenêtre temporelle et vérifier si ADAPTER_DOWN_ERROR ou SERVER_DOWN_ERROR y figurent aussi. Si l'erreur se répète sans ces états associés, le cas relève du support Zscaler : avec la fenêtre temporelle, pas avec tout le lot.

Cas 2 : le proxy système pointe ailleurs

Symptôme. Certaines destinations contournent le tunnel ou aboutissent sur un proxy étranger. L'utilisateur signale « ça ne marche pas », mais le tunnel est actif.

Fichier. 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

Constat. L'URL PAC a été écrasée de l'extérieur, gravité élevée. Le client attend son propre fichier PAC diffusé localement ; le système en contient un autre. À noter : le jeton est INF, pas ERR. Le constat repose sur ce que dit la ligne, pas sur sa gravité apparente, c'est pourquoi il échappe à qui filtre uniquement sur les erreurs.

Autre explication. Un fichier PAC lu proprement n'est pas automatiquement le bon. Le même lot contient Pac parse success! — un message de succès, pas un acquittement. Un objet de stratégie de groupe ou un second produit de sécurité peut aussi définir légitimement le proxy système.

Prochaine étape. Vérifier le fichier PAC réellement configuré face à deux adresses : une censée passer en direct, une censée passer par le tunnel. Cela fonctionne sans tenant dans le PAC Tester gratuit. Si le résultat diffère de l'intention, le problème vient du fichier, pas du client.

Cas 3 : le tunnel se coupe, et la cause se trouve juste avant

Symptôme. Les connexions disparaissent pendant quelques minutes, puis tout revient. L'utilisateur signale « Zscaler avait disparu ».

Fichier. ZSAUpm.

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

Constat. Adaptateur réseau indisponible, gravité élevée. La ligne se situe une demi-seconde après le changement d'état ZIA: TUNNEL_FORWARDING → ADAPTER_DOWN_ERROR. Le tunnel ne s'est pas rompu parce que Zscaler serait tombé, mais parce que l'appareil n'avait, pour un instant, aucun adaptateur réseau utilisable.

Autre explication. Toute ligne qui ressemble à un problème réseau n'en est pas forcément un. checkTunTcpEchoServerUpImpl et isUdpEchoServerUpImpl sont le test d'accessibilité propre au produit, et Sending NXDOMAIN … name: wpad. est une suppression WPAD volontaire. Les deux relèvent du fonctionnement normal et ne sont pas une panne.

Prochaine étape. Lire l'enchaînement d'états dans la même fenêtre temporelle. S'il passe par ADAPTER_DOWN_ERROR et revient à TUNNEL_FORWARDING, c'était un changement de réseau local : Wi-Fi, VPN, station d'accueil. Si FIREWALL_BLOCK_ERROR ou SERVER_DOWN_ERROR y figurent, le cas quitte le poste.

Avec CentaurNexusAgent, export et chargement disparaissent, il fonctionne avec la même base de règles que l'analyse présentée ici. Pour reproduire cela sans tenant : le Log Analyzer gratuit fournit précisément le lot dont proviennent ces trois lignes.

Voie 2 : avec CentaurNexusAgent, export et chargement disparaissent

Sur les appareils équipés de CentaurNexusAgent, le même processus se déroule sans intervention de l'utilisateur. CentaurNexusAgent analyse les logs ZCC directement sur l'appareil et ne transmet que des constats structurés. Pas d'export, pas de ZIP, pas de chargement, pas d'attente dans le ticket. Notre vidéo d'environ deux minutes et demie sur ce chemin montre comment un tel constat s'ouvre directement dans le contexte de support.

Lorsqu'un opérateur autorisé ouvre l'utilisateur concerné dans l'Unified Support Center, les constats de logs client apparaissent en ligne, dans la même vue de constats que pour la voie du chargement. Chaque constat porte sa fenêtre temporelle ainsi que sa première et dernière occurrence ; même une perturbation survenue des heures plus tôt reste ainsi traçable, sans que l'utilisateur doive la reproduire. Un clic ouvre les mêmes constats dans la vue Log Analyzer complète.

Confidentialité dans les deux workflows

La voie du chargement est elle aussi conçue pour l'économie de données : les logs ne sont analysés qu'en mémoire vive et ne sont pas stockés. Les données personnelles dans les lignes d'exemple sont obfusquées selon le réglage du tenant, et chaque consultation est auditée.

L'accès aux constats est protégé par rôle. Il n'est accordé qu'à ceux autorisés à utiliser Log Analyzer ou un centre de support, et un administrateur cantonné à certains domaines ne voit que les utilisateurs de ses propres domaines. L'analyse de logs reste ainsi un workflow contrôlé, et ne devient pas une porte dérobée vers de larges droits de consultation.

Zscaler reste l'éditeur central

Le Zscaler Client Connector reste le logiciel client de référence et la source des données de log. CentaurNexus complète le workflow pris en charge par l'analyse, la classification et des recommandations de correction, dans un contexte de travail commun pour le helpdesk et l'administration. Les constats renvoient volontairement vers le côté Zscaler du problème, par exemple les profils de posture, les fichiers PAC ou la configuration du tunnel, afin que la correction ait lieu là où elle doit avoir lieu.