Agent Sophos ZTNA : méthode de dépannage

Objectif et réponse rapide

Une ressource ZTNA inaccessible ne signifie pas nécessairement que l’agent est défectueux. L’installation, la stratégie, le groupe d’utilisateurs, le DNS, le fournisseur d’identité, la passerelle et l’application interne forment une chaîne. Le dépannage doit donc partir du symptôme observé et ne porter que sur la couche pour laquelle vous disposez d’éléments probants.

Voici la vérification fiable la plus rapide :

Notez l’utilisateur, l’appareil, la ressource et l’heure concernés.
Vérifiez l’installation et l’état local de l’agent.
Sous My Products > ZTNA (chemin complet : Sophos Central > My Products > ZTNA), vérifiez la ressource, la méthode d’accès et la stratégie.
Sous ZTNA > Reports (chemin complet : Sophos Central > My Products > ZTNA > Reports), recherchez une authentification réussie ou le motif du refus d’accès.
Sous My Environment > Alerts (chemin complet : Sophos Central > Alerts), recherchez un événement lié à l’installation, à la mise à jour, à la licence ou à la connectivité de l’appareil à l’heure concernée.
Ne vérifiez ensuite le DNS, l’identité, l’intégrité de l’appareil ou la passerelle que si le symptôme constaté vous y conduit.

Le chargement d’une page dans le navigateur ne prouve pas que la connexion est passée par l’agent. À l’inverse, le portail utilisateur ZTNA n’affiche que les applications sans agent : il est donc normal qu’une ressource avec agent n’y figure pas.

Prérequis, licences et rôles

Pour établir ce diagnostic, vous devez disposer d’un utilisateur concerné et d’un appareil géré, du nom de domaine complet (FQDN) d’une ressource concernée, ainsi que d’un accès à la configuration ZTNA, aux rapports, à la vue des appareils et aux alertes du tenant approprié. Pour tester une ressource avec agent, l’agent ZTNA doit être affecté à l’appareil. Sous Devices > Computers ou Servers, une coche verte indique que le composant ZTNA est installé ; un signe plus indique qu’il peut être installé.

Les sources utilisées ne mentionnent ni licence distincte ni rôle d’administrateur particulier pour ce dépannage. La présence d’un menu ne permet pas de conclure que l’utilisateur dispose de droits plus étendus. Si une vue ou une action nécessaire n’est pas disponible, faites appel à l’administrateur du tenant au lieu d’en déduire un problème de licence ou de rôle.

Avant toute modification, relevez les informations suivantes pour un seul utilisateur et un seul appareil concernés :

le système d’exploitation, le réseau et l’heure, fuseau horaire compris ;
le FQDN de la ressource et la méthode d’accès, Agent ou Agentless ;
le libellé exact de l’état ZTNA local et du message affiché par le navigateur ;
le fonctionnement éventuel d’autres ressources ZTNA sur le même appareil ;
le fonctionnement éventuel de la même ressource, pour le même utilisateur, depuis un autre réseau ;
la dernière modification apportée à la stratégie, au groupe, au DNS, au fournisseur d’identité ou à la passerelle.

Configuration avec des exemples à adapter

Ne modifiez pas l’ensemble des paramètres de production pour les besoins d’un test circonscrit. Remplacez les exemples <USER>, <DEVICE>, <RESOURCE-FQDN> et <TEST TIME WITH TIME ZONE> par les valeurs correspondant à un seul cas précis.

Sous ZTNA > Reports, ouvrez l’onglet Report Generator. En cas de refus d’accès, sélectionnez le modèle Denied resource access, limitez la période autour de <TEST TIME WITH TIME ZONE> puis, si les colonnes disponibles le permettent, appliquez un filtre sur <USER>, <DEVICE> ou <RESOURCE-FQDN>. Avec les opérateurs = et !=, les valeurs de filtre sont sensibles à la casse. L’opérateur ~, quant à lui, utilise * comme caractère générique et n’est pas sensible à la casse. Lorsque vous définissez plusieurs filtres, ils doivent tous être satisfaits. Lancez ensuite le rapport avec Create.

Si la connexion est censée réussir, utilisez plutôt Authenticated users. Ce rapport recense les utilisateurs que les passerelles ZTNA ont authentifiés, quel que soit le mode de déploiement de la passerelle. Les modèles Gateway bandwidth et Resource bandwidth servent à attribuer le trafic ; à eux seuls, ils ne prouvent pas la réussite d’une tentative d’accès donnée.

Sous My Environment > Alerts, limitez la période et la sélection d’appareils afin qu’elles correspondent au test. Une même alerte peut regrouper plusieurs événements récurrents. Cliquez sur son titre pour afficher les événements associés et tous les détails. Tant que l’analyse est en cours, ne fermez pas une alerte dans le seul but de l’effacer de la liste.

Validation et résultat attendu

Un test n’est concluant que si tous les éléments suivants concordent :

L’agent affiche l’état attendu pour le chemin testé.
<RESOURCE-FQDN> s’ouvre avec l’utilisateur, l’appareil et le réseau prévus.
Le rapport Authenticated users contient l’authentification réussie pendant la période sélectionnée.
Le rapport Denied resource access ne contient aucun nouveau refus correspondant au même test.
Sous My Environment > Alerts, aucune alerte ouverte liée à l’installation, à la mise à jour, à la licence ou à la connectivité ne correspond à l’heure du test et ne remet sa réussite en cause.

Si l’entrée attendue n’apparaît pas dans le rapport, vérifiez la période et l’orthographe du filtre, puis recommencez le test une fois en ne changeant qu’une seule variable. Si un refus apparaît, son motif indique la section à consulter ci-dessous. Si le deuxième test ne produit toujours aucune donnée exploitable, ne tentez pas d’obtenir artificiellement un « succès » en multipliant les modifications de configuration : conservez les journaux et le SDU en vue d’une escalade.

Dépannage par symptôme

État « Not Configured »

Sous Devices > Computers ou Servers, vérifiez si ZTNA est installé sur l’appareil. Une coche verte confirme que le composant est installé ; un signe plus permet de lancer son installation. La seule présence de Sophos Endpoint ne prouve pas que ZTNA a été affecté à l’appareil.

Il existe une exception importante sous Windows. Si l’option Don’t intercept on-premises traffic est configurée sous Global Settings > Products and Services > ZTNA et que l’agent Windows détecte le réseau interne, il cesse volontairement d’intercepter le trafic sur ce réseau et affiche Not Configured. Après le passage sur un autre réseau, l’état attendu redevient Configured. Selon Sophos, cette fonction est actuellement propre à Windows ; ne présumez pas qu’elle existe également sous macOS.

Ce comportement sous Windows nécessite Sophos Core Agent 2025.2.1.709 ou version ultérieure. Dans Sophos Fusion (anciennement Sophos Central), ouvrez la fiche de l’appareil et vérifiez, dans l’onglet Summary, la version de Core Agent installée avant d’analyser la détection du réseau interne. Les versions antérieures ne prennent pas en charge cette exception telle qu’elle est décrite ici.

Si cette exception ne s’applique pas, vérifiez dans Sophos Fusion l’affectation des composants, la connexion de l’appareil et l’état de ses mises à jour. Ne commencez pas par réinstaller l’agent tant que vous ne savez pas si ZTNA a bien été affecté.

État « Zero Trust Network Access: Error »

Cet état signale un problème de connexion. Procédez dans l’ordre suivant :

Une stratégie ZTNA existe-t-elle et est-elle affectée à la ressource ?
L’appareil résout-il le FQDN de la passerelle comme prévu ?
Sophos Fusion signale-t-il un problème d’installation ou d’intégrité sur l’appareil ?
Sous Windows, la configuration Sophos TAP est-elle présente ou un autre logiciel réseau l’a-t-il modifiée ?

Sophos cite la désactivation d’IPv6 parmi les étapes de dépannage. Il ne s’agit pas d’une solution à appliquer par défaut : ne la testez que sur un seul appareil pilote, après avoir consigné son état initial, et pendant un unique essai de reproduction. Réactivez ensuite IPv6. Si le symptôme évolue sans ambiguïté, conservez les horodatages et un SDU, puis poursuivez l’analyse avec le support Sophos. Ne laissez pas IPv6 désactivé de façon permanente ou sur plusieurs appareils.

Un tunnel peut se fermer lorsqu’il est inactif. Selon le paramètre central, la fermeture intervient après 5, 15 ou 30 minutes, ou après une heure ; la valeur par défaut est de 5 minutes. Le tunnel est rétabli dès qu’un nouveau trafic est détecté. La fermeture d’un tunnel inactif ne suffit donc pas à établir l’existence d’une panne.

La fenêtre de connexion ne s’affiche pas

Pour une ressource avec agent, effectuez les vérifications suivantes dans l’ordre :

L’appareil peut-il joindre la passerelle ZTNA ?
Le processus de l’agent ZTNA est-il en cours d’exécution ?
Un CNAME public ou interne pointe-t-il à tort le FQDN de l’application vers la passerelle ? Ce CNAME ne doit pas exister pour une application avec agent.
La ressource, la méthode d’accès et le FQDN correspondent-ils dans Sophos Fusion ?
Les journaux ZTNA signalent-ils une erreur SNTP, DNS ou de connexion à l’heure du test ?

Si la fenêtre de connexion s’affiche, mais que l’utilisateur n’est pas redirigé vers l’application, vérifiez l’URI de redirection du fournisseur d’identité. Avec Okta, la valeur Groups claim expression est également sensible à la casse. Ne réinitialisez les cookies ou les identifiants du navigateur qu’après avoir confirmé que l’échec se situe bien au niveau de l’authentification.

Une ressource avec agent ne fonctionne plus malgré une authentification réussie

Si l’authentification réussit, mais que l’application avec agent ne s’ouvre pas, recherchez d’éventuelles erreurs dans les journaux SNTP du terminal et vérifiez dans heartbeat.xml que le certificat qui y est enregistré est actuellement valide. Une heure incorrecte sur l’appareil, un échec de synchronisation ou un certificat expiré ou pas encore valide peut interrompre la connexion authentifiée via l’agent, même si la stratégie et le DNS semblent corrects. Conservez les journaux, le fichier et l’horodatage ; ne modifiez pas le fichier XML et ne contournez pas la validation du certificat.

Si l’accès fonctionnait auparavant, effectuez les mêmes vérifications dans les journaux SNTP et dans heartbeat.xml, puis examinez l’appareil dans Sophos Fusion. Un état Endpoint health rouge constitue une piste de diagnostic : corrigez le problème d’intégrité signalé, puis recommencez le test au lieu d’assouplir la stratégie ZTNA.

« 403 Access Denied / No Access », « Device Health » ou « Policy Off »

Le rapport Denied resource access permet de cibler la vérification suivante :

403 Access Denied / No Access: L’utilisateur n’appartient pas effectivement à un groupe affecté à la ressource, ou le groupe n’est pas activé pour la sécurité dans Microsoft Entra ID. Vérifiez l’importation du groupe, son état d’activation pour la sécurité et les autorisations de l’API du fournisseur d’identité. La prise en compte des modifications apportées aux groupes autorisés peut nécessiter jusqu’à une heure.
Device Health: L’appareil ne satisfait pas aux critères d’intégrité de la stratégie d’agent qui lui est affectée. Corrigez le problème d’intégrité précis au lieu d’assouplir toute la stratégie.
Policy Off: Ouvrez la stratégie concernée sous My Products > ZTNA > Policies et vérifiez Policy is enforced.
Upstream request error pour Agentless: La passerelle ne peut pas joindre l’application interne, l’application est indisponible, son FQDN ou son adresse IP ne se résout pas correctement, ou le port configuré est incorrect. Cette erreur ne prouve pas que l’agent du terminal est défectueux.
404 Not Found for Agentless: Vérifiez le CNAME qui pointe l’application vers le FQDN de la passerelle. N’appliquez pas cette règle DNS aux ressources avec agent.

Si l’utilisateur vient d’être ajouté à un groupe, attendez la fin du délai de réplication documenté avant de refaire le test. Pour une application web, une fenêtre de navigation privée permet d’écarter l’hypothèse de données obsolètes dans le navigateur, mais elle n’accélère pas la réplication des groupes.

Échecs DNS après l’installation

L’adaptateur ZTNA TAP peut devenir l’adaptateur utilisé par défaut par nslookup. La recherche d’une cible située en dehors de la passerelle ZTNA peut alors échouer sans que la résolution de noms soit globalement en panne. Pour établir une comparaison, Sophos recommande d’indiquer explicitement le serveur DNS à interroger :

nslookup <FQDN> <DNS-SERVER>

Comparez la réponse fournie par le résolveur d’entreprise attendu, puis tentez réellement d’accéder à l’application. Ne modifiez pas sans motif confirmé l’ordre des adaptateurs, les métriques réseau ou les adresses des serveurs DNS. Pour les ressources avec agent, vérifiez également qu’aucun CNAME ne pointe l’application vers la passerelle.

Sophos DNS Protection emprunte un chemin de données distinct. Si vous l’utilisez également, consultez Configurer Sophos DNS Protection pour les terminaux pour configurer la stratégie et les exclusions. Ne confondez pas le fonctionnement DNS de ZTNA avec Endpoint DNS Protection.

Coexistence de ZTNA avec un VPN ou un logiciel d’accès à distance

Ne supprimez pas les adaptateurs TAP, ne modifiez pas les liaisons et ne fixez pas arbitrairement les métriques réseau en guise de solution générale. Commencez par reproduire l’accès à la même ressource lors d’un test contrôlé, avec, puis sans l’autre client. Notez à chaque fois l’heure, la réponse DNS et l’état ZTNA.

Pour ZTNA 2026.1 associé à Sophos DNS Protection, Sophos décrit une configuration de coexistence précise : activez DNS Protection, puis activez Retry with system- or application-configured DNS services when DNS Protection returns NXDOMAIN dans sa stratégie de terminal. Cette configuration nécessite la version, la licence et les paramètres DNS Protection correspondants ; elle ne constitue pas une solution universelle applicable à n’importe quel produit VPN.

Cas macOS particuliers

Sous macOS Sequoia, après une nouvelle installation de ZTNA seul, Chrome peut bloquer les applications situées derrière une on-premises gateway si le navigateur n’est pas autorisé à accéder au réseau local. Pour ce symptôme précis uniquement, ouvrez System Settings > Privacy & Security > Local Network et vérifiez si Google Chrome est autorisé à rechercher des appareils locaux. Ce problème documenté ne concerne pas Sophos Cloud Gateway. Il ne justifie pas d’accorder systématiquement cette autorisation et ne signifie pas non plus que macOS garantit un « accès privé ».

Après un déploiement MDM, la présence de plusieurs profils VPN dont le nom commence par Sophos ZTNA peut entraîner une forte utilisation du processeur. Recherchez les doublons sous System Settings > VPN. Ne conservez qu’un seul profil. Un profil installé par MDM ne pouvant pas être supprimé localement, c’est celui-ci qui doit rester. Redémarrez ensuite le Mac, puis vérifiez de nouveau l’utilisation du processeur et l’accès ZTNA. Ce nettoyage ne s’applique qu’à ce cas macOS confirmé, et non aux adaptateurs TAP sous Windows.

Si vous avez clairement reproduit un problème d’identifiants obsolètes, n’utilisez les procédures de réinitialisation Sophos qu’à des fins de débogage ou de démonstration, jamais comme méthode habituelle de déconnexion en production. Sous macOS, l’outil de diagnostic Endpoint propose ZTNA > Reset ; les scripts de suppression des cookies du navigateur ou la suppression manuelle des données de sites web Safari doivent cibler exactement la passerelle et le fournisseur d’identité concernés. Sous Windows, la procédure Sophos exige la désactivation de la protection antialtération et l’exécution avec élévation de privilèges du fichier clearcreds.bat joint à l’article de la base de connaissances. N’utilisez ni script de nettoyage tiers ni procédure de suppression manuelle non documentée. Les fichiers d’origine et les restrictions d’utilisation figurent dans Sophos ZTNA : déconnexion de l’agent.

Rétablissement de la configuration ou retrait en toute sécurité

Les sources de diagnostic et de création de rapports utilisées ici ne décrivent aucune procédure générale de réparation, de désinstallation ou de restauration de l’agent. Respectez donc les limites suivantes :

Les filtres de test et le générateur de rapports ne modifient pas le chemin de données. Si vous avez enregistré un modèle ou une planification uniquement pour le diagnostic, vous pouvez les supprimer sous Saved templates ou Scheduled exports.
Après un test comparatif avec IPv6, rétablissez immédiatement l’état initial que vous aviez consigné.
Ne conservez pas comme solution une stratégie temporairement assouplie, un groupe modifié, une configuration DNS différente ou une vérification de certificat désactivée. Si une telle modification a été effectuée en dehors de cette procédure, rétablissez l’état précédemment consigné, puis recommencez le même test.
Ne supprimez ni l’agent ni les adaptateurs TAP et ne contournez pas la validation du certificat tant que l’origine de la panne n’a pas été démontrée. Si aucune procédure de retour à l’état initial n’est documentée, arrêtez-vous et transmettez au support les éléments recueillis.

Après chaque rétablissement, l’état de l’agent, la réponse DNS, la requête réelle vers la ressource et le rapport ZTNA correspondant doivent de nouveau concorder avec l’état initial. Dans le cas contraire, n’effectuez pas une deuxième modification.

Exploitation, suivi et cycle de vie

Les rapports et alertes ZTNA constituent des éléments de diagnostic opérationnel, et non des actions correctives. Pour les contrôles récurrents, enregistrez un modèle de rapport filtré ou planifiez un export. Les rapports planifiés peuvent être générés chaque jour, chaque semaine ou chaque mois, au format PDF, CSV ou HTML. Sophos Central accepte jusqu’à 200 planifications. Les exports, qu’ils soient générés manuellement ou automatiquement, sont supprimés après 90 jours. Si un rapport contient des données personnelles, préférez un lien envoyé par e-mail à une pièce jointe, car l’ouverture du lien nécessite une connexion à Sophos Central.

Les alertes indiquent la gravité, l’état, les événements et l’appareil concernés. Plusieurs événements récurrents peuvent être regroupés dans une même alerte ; un événement ultérieur peut automatiquement faire passer l’alerte à l’état Resolved. Lors d’un incident, examinez donc toujours les événements et leurs horodatages. La commande Mark as acknowledged retire une alerte de la liste sans en résoudre la cause. De même, Mark as resolved ne remplace pas une correction technique.

Avant de réinstaller l’agent, de nettoyer les profils ou d’apporter d’autres modifications au réseau, recueillez les éléments suivants :

l’appareil, l’utilisateur, le système d’exploitation et les composants effectivement installés ;
la ressource, la méthode d’accès, la stratégie et le groupe affecté ;
le message exact, l’état ZTNA local et l’horodatage, fuseau horaire compris ;
le résultat obtenu avec un deuxième utilisateur, appareil ou réseau, en ne changeant qu’une variable à la fois ;
les réponses DNS pour les FQDN de la ressource et de la passerelle ;
les événements Sophos Central pertinents et les journaux ZTNA, SNTP et d’installation ;
le rapport ZTNA filtré ou l’export correspondant à la période du test ;
une archive SDU récente.

Les versions actuelles de l’aide et des composants font foi. Cette procédure ne permet de tirer aucune conclusion sur les anciennes transitions de ZTNA, le retrait d’anciens droits d’utilisation, les échéances de migration, le retrait du produit ou ses dates précises de fin de vie.

Guides connexes

Pour comprendre l’architecture et les dépendances, consultez Configurer Sophos ZTNA : présentation et ordre des étapes. Le présent article reste centré sur l’état de l’agent et les éléments permettant d’analyser la connexion ; le déploiement de la passerelle et une prétendue procédure générale de réparation de l’agent n’entrent pas dans son périmètre.

L’article Sophos Endpoint : diagnostics avec SDU explique comment recueillir les données en toute sécurité. Ouvrez ensuite un dossier auprès du support Sophos en y joignant les éléments conservés. Ne copiez pas d’identifiants, de jetons ou de cookies de navigateur dans un ticket ou une pièce jointe non protégée.