Sophos ZTNA Agent: risoluzione sistematica dei problemi

Scopo e risposta diretta

Se una risorsa ZTNA non è raggiungibile, non significa necessariamente che l’agente sia guasto. Installazione, criterio, gruppo di utenti, DNS, provider di identità, gateway e applicazione interna formano una catena. La diagnosi deve quindi partire dal sintomo osservabile e spostarsi a un altro livello solo in presenza di elementi che lo giustifichino.

La verifica affidabile più rapida consiste nel:

Annotare l’utente, il dispositivo, la risorsa e l’ora interessati.
Verificare l’installazione e lo stato locale dell’agente.
In My Products > ZTNA (percorso completo: Sophos Central > My Products > ZTNA), confrontare la risorsa, il metodo di accesso e il criterio.
In ZTNA > Reports (percorso completo: Sophos Central > My Products > ZTNA > Reports), cercare l’autenticazione riuscita o il motivo per cui l’accesso è stato negato.
In My Environment > Alerts (percorso completo: Sophos Central > Alerts), cercare un evento del dispositivo relativo a installazione, aggiornamento, licenza o connettività che coincida con l’ora del problema.
Verificare DNS, identità, integrità del dispositivo o gateway soltanto in base al sintomo riscontrato.

Il corretto caricamento di una pagina nel browser non dimostra che sia stato utilizzato il percorso tramite agente. Viceversa, il portale utenti ZTNA mostra soltanto le applicazioni agentless; non è quindi necessario che vi compaia una risorsa basata su agente.

Requisiti, licenze e ruoli

Per questa diagnosi servono un utente interessato, un dispositivo gestito, l’FQDN di una risorsa interessata e l’accesso alla configurazione ZTNA, ai report, alla vista del dispositivo e agli avvisi del tenant corretto. Per provare una risorsa basata su agente, ZTNA Agent deve essere assegnato al dispositivo. In Devices > Computers o Servers, un segno di spunta verde indica che il componente ZTNA è installato; un segno più indica che è ancora possibile installarlo.

Le fonti assegnate non indicano né una licenza distinta né un ruolo amministrativo specifico per questa procedura di diagnosi. La visibilità di un menu non implica autorizzazioni più ampie. Se una vista o un’azione necessaria non è disponibile, coinvolgere l’amministratore del tenant anziché attribuire il problema alla licenza o al ruolo.

Prima di apportare qualsiasi modifica, annotare quanto segue per un solo utente e dispositivo interessati:

sistema operativo, rete e ora, compreso il fuso orario;
FQDN della risorsa e metodo di accesso, Agent o Agentless;
testo esatto dello stato ZTNA locale e del messaggio visualizzato nel browser;
eventuale funzionamento di altre risorse ZTNA sullo stesso dispositivo;
eventuale funzionamento della stessa risorsa, per lo stesso utente, da un’altra rete;
ultima modifica apportata a criterio, gruppo, DNS, provider di identità o gateway.

Configurazione con valori di esempio adattabili

Per una prova circoscritta, non modificare indiscriminatamente le impostazioni di produzione. Sostituire i valori di esempio, come <USER>, <DEVICE>, <RESOURCE-FQDN> e <TEST TIME WITH TIME ZONE>, con quelli relativi a un solo caso.

In ZTNA > Reports, aprire la scheda Report Generator. Per analizzare un accesso negato, selezionare il modello Denied resource access, limitare l’intervallo al periodo intorno a <TEST TIME WITH TIME ZONE> e, se le colonne disponibili lo consentono, filtrare per <USER>, <DEVICE> o <RESOURCE-FQDN>. I valori dei filtri con = e != distinguono tra maiuscole e minuscole; ~ utilizza * come carattere jolly e non distingue tra maiuscole e minuscole. Se sono presenti più filtri, devono essere soddisfatti tutti. Eseguire quindi il report con Create.

Se l’accesso dovrebbe riuscire, utilizzare invece Authenticated users. Questo report registra gli utenti autenticati correttamente dai gateway ZTNA, indipendentemente dalla modalità di distribuzione del gateway. I modelli Gateway bandwidth e Resource bandwidth attribuiscono il traffico, ma da soli non dimostrano che un singolo tentativo di accesso sia riuscito.

In My Environment > Alerts, limitare l’intervallo e il dispositivo in modo che corrispondano alla prova. Un avviso può raggruppare più eventi ricorrenti. Aprirne il titolo per visualizzare gli eventi associati e tutti i dettagli. Durante l’analisi, non chiudere un avviso soltanto per rimuoverlo dall’elenco.

Convalida e risultato atteso

Una prova con esito positivo è completa soltanto se tutti gli elementi seguenti sono coerenti:

L’agente mostra lo stato previsto per il percorso sottoposto a prova.
<RESOURCE-FQDN> si apre con l’utente, il dispositivo e la rete previsti.
Il report Authenticated users contiene l’autenticazione riuscita nell’intervallo selezionato.
Il report Denied resource access non contiene un nuovo rifiuto relativo alla stessa prova.
In My Environment > Alerts non sono presenti avvisi aperti relativi a installazione, aggiornamento, licenza o connettività, coincidenti con l’ora della prova e tali da metterne in dubbio l’esito.

Se nel report non compare la voce prevista, verificare l’intervallo e la grafia dei filtri, quindi ripetere una volta la prova modificando una sola variabile. Se compare invece un rifiuto, il motivo indicato determina la sezione da consultare. Se anche la seconda prova non produce dati utilizzabili, non tentare di ottenere forzatamente un esito positivo con ulteriori modifiche alla configurazione: conservare i log e l’SDU per inoltrare il caso al livello di assistenza successivo.

Risoluzione dei problemi in base al sintomo

Stato “Not configured”

In Devices > Computers o Servers, verificare se ZTNA è installato sul dispositivo. Un segno di spunta verde conferma che il componente è installato; un segno più consente di installarlo. La sola presenza di Sophos Endpoint non dimostra che ZTNA sia stato assegnato.

In Windows esiste un’importante eccezione. Se in Global Settings > Products and Services > ZTNA è configurata l’opzione Don’t intercept on-premises traffic e l’agente Windows rileva la rete interna, interrompe intenzionalmente l’intercettazione su tale rete e mostra Not Configured. Dopo il passaggio a un’altra rete, lo stato previsto torna a essere Configured. Secondo Sophos, questa funzionalità è attualmente specifica di Windows; non presumerne la disponibilità anche in macOS.

Questo comportamento in Windows richiede Sophos Core Agent 2025.2.1.709 o versione successiva. Prima di diagnosticare il rilevamento della rete locale, aprire il dispositivo in Sophos Fusion (in precedenza Sophos Central) e verificare nella scheda Summary la versione di Core Agent installata. Le versioni precedenti non supportano l’eccezione descritta.

Se l’eccezione non è applicabile, verificare in Sophos Fusion l’assegnazione del componente, lo stato online e lo stato degli aggiornamenti. Non procedere subito alla reinstallazione finché non è stato accertato se ZTNA sia effettivamente assegnato.

Stato “Zero Trust Network Access: Error”

Questo stato segnala un problema di connessione. Eseguire le verifiche nell’ordine seguente:

Esiste un criterio ZTNA ed è assegnato alla risorsa?
Il dispositivo risolve l’FQDN del gateway come previsto?
Sophos Fusion segnala un errore di installazione o di integrità per il dispositivo?
In Windows, la configurazione di Sophos TAP è presente oppure è stata modificata da un altro software di rete?

Sophos indica la disattivazione di IPv6 come passaggio diagnostico. Non si tratta di una soluzione da adottare come configurazione standard: eseguire il passaggio soltanto su un dispositivo pilota, dopo averne documentato lo stato iniziale, e per una singola prova di riproduzione. Al termine, riattivare IPv6. Se il sintomo cambia in modo inequivocabile, conservare i timestamp e un archivio SDU e approfondire il problema con il supporto Sophos; non lasciare IPv6 disattivato in modo permanente o su larga scala.

Un tunnel può chiudersi quando è inattivo. In base all’impostazione centrale, ciò avviene dopo 5, 15 o 30 minuti oppure dopo un’ora; il valore predefinito è 5 minuti. Il traffico successivo ristabilisce il tunnel. La sola presenza di un tunnel inattivo e chiuso non dimostra quindi l’esistenza di un guasto.

La finestra di accesso non viene visualizzata

Per una risorsa basata su agente, eseguire nell’ordine le verifiche seguenti:

Il dispositivo riesce a raggiungere il gateway ZTNA?
Il processo ZTNA Agent è in esecuzione?
Esiste erroneamente un CNAME pubblico o interno che associa l’FQDN dell’applicazione al gateway? Questo CNAME non deve esistere per le applicazioni basate su agente.
Risorsa, metodo di accesso e FQDN corrispondono in Sophos Fusion?
All’ora della prova, i log ZTNA mostrano un errore SNTP, DNS o di connessione?

Se viene visualizzata la finestra di accesso ma l’utente non viene reindirizzato all’applicazione, verificare l’URI di reindirizzamento del provider di identità. In Okta, anche Groups claim expression distingue tra maiuscole e minuscole. Reimpostare i cookie o le credenziali del browser soltanto dopo aver accertato che il problema riguarda l’autenticazione.

Una risorsa basata su agente non funziona dopo l’autenticazione o smette di funzionare

Se l’autenticazione riesce ma un’applicazione basata su agente non si apre, esaminare i log SNTP dell’endpoint per individuare eventuali errori e verificare in heartbeat.xml che il certificato registrato sia attualmente valido. L’ora errata del dispositivo, una sincronizzazione dell’ora non riuscita oppure un certificato scaduto o non ancora valido possono interrompere il percorso autenticato tramite agente anche quando criterio e DNS sembrano corretti. Conservare i log, il file e il timestamp; non modificare il file XML né aggirare la convalida del certificato.

Se l’accesso funzionava in precedenza e successivamente smette di funzionare, eseguire le stesse verifiche sui log SNTP e sulla validità del certificato in heartbeat.xml, quindi controllare il dispositivo in Sophos Fusion. Lo stato rosso di Endpoint health è un indizio diagnostico: correggere il problema di integrità segnalato e ripetere la prova, anziché rendere meno restrittivo il criterio ZTNA.

“403 Access Denied / No Access”, “Device Health” o “Policy Off”

Il report Denied resource access consente di circoscrivere la verifica successiva:

403 Access Denied / No Access: l’utente non appartiene effettivamente a un gruppo assegnato alla risorsa oppure, in Microsoft Entra ID, il gruppo non è abilitato per la sicurezza. Verificare l’importazione dei gruppi, lo stato di abilitazione per la sicurezza e le autorizzazioni API del provider di identità. La propagazione delle modifiche ai gruppi autorizzati può richiedere fino a un’ora.
Device Health: il dispositivo non soddisfa le condizioni di integrità del criterio dell’agente assegnato. Correggere il problema di integrità specifico anziché rendere meno restrittivo l’intero criterio.
Policy Off: aprire il criterio interessato in My Products > ZTNA > Policies e verificare Policy is enforced.
Upstream request error per Agentless: il gateway non riesce a raggiungere l’applicazione interna, l’applicazione non è disponibile, il relativo FQDN o indirizzo IP viene risolto in modo errato oppure la porta configurata non è corretta. Ciò non dimostra che l’agente dell’endpoint sia guasto.
404 Not Found per Agentless: verificare il CNAME che associa l’applicazione all’FQDN del gateway. Non applicare questa regola DNS alle risorse basate su agente.

Se l’utente è stato appena aggiunto a un gruppo, ripetere la prova soltanto dopo l’intervallo di replica documentato. Per un’applicazione web, una finestra di navigazione privata può escludere uno stato obsoleto del browser, ma non può accelerare la replica del gruppo.

Errori DNS dopo l’installazione

L’adattatore ZTNA TAP può diventare l’adattatore predefinito per nslookup. Di conseguenza, la ricerca di una destinazione esterna al gateway ZTNA può non riuscire anche se la risoluzione dei nomi continua a funzionare in generale. Per il confronto, la documentazione Sophos indica di specificare esplicitamente il server DNS previsto:

nslookup <FQDN> <DNS-SERVER>

Confrontare la risposta ottenuta tramite il resolver aziendale previsto, quindi eseguire una richiesta effettiva all’applicazione. Non modificare in via sperimentale l’ordine degli adattatori, le metriche o gli indirizzi dei server DNS. Per le risorse basate su agente, accertarsi inoltre che non esista un CNAME che associ l’applicazione al gateway.

Sophos DNS Protection utilizza un percorso dati distinto. Se è in uso anche questo prodotto, consultare Configurare Sophos DNS Protection per gli endpoint per i criteri e le esclusioni; non considerare il DNS ZTNA ed Endpoint DNS Protection come un’unica funzionalità.

ZTNA insieme a software VPN o di accesso remoto

Come rimedio generico, non eliminare gli adattatori TAP, non modificarne i binding e non impostare metriche di rete fisse. Per prima cosa, riprodurre in modo controllato l’accesso alla stessa risorsa con e senza l’altro client, annotando l’ora, la risposta DNS e lo stato ZTNA.

Per ZTNA 2026.1 con Sophos DNS Protection, Sophos documenta una specifica configurazione di coesistenza: abilitare DNS Protection e attivare Retry with system- or application-configured DNS services when DNS Protection returns NXDOMAIN nel relativo criterio dell’endpoint. Questa configurazione richiede la versione, la licenza e la configurazione di DNS Protection applicabili; non è una soluzione universale per qualsiasi prodotto VPN.

Casi circoscritti in macOS

In macOS Sequoia, dopo una nuova installazione del solo ZTNA, Chrome può bloccare le applicazioni dietro un on-premises gateway se il browser non dispone dell’accesso alla rete locale. Soltanto in presenza di questo sintomo, verificare in System Settings > Privacy & Security > Local Network se Google Chrome è autorizzato a rilevare i dispositivi locali. Sophos Cloud Gateway non è interessato da questo caso documentato. Ciò non costituisce né una raccomandazione generale a concedere l’autorizzazione né una garanzia di “accesso privato” in macOS.

Un utilizzo elevato della CPU dopo una distribuzione tramite MDM può essere causato da più profili VPN il cui nome inizia con Sophos ZTNA. In System Settings > VPN, verificare la presenza di duplicati. Conservare un solo profilo; poiché un profilo installato tramite MDM non può essere rimosso localmente, deve essere quello mantenuto. Riavviare quindi il Mac e verificare nuovamente l’utilizzo della CPU e l’accesso ZTNA. Questa operazione di pulizia si applica esclusivamente al caso macOS confermato, non agli adattatori TAP di Windows.

Se è stata riprodotta in modo esplicito la persistenza di credenziali obsolete, utilizzare le procedure di reimpostazione Sophos soltanto per attività di debug o dimostrazioni, non come normale procedura di disconnessione in produzione. In macOS, lo strumento di diagnostica Endpoint offre ZTNA > Reset; gli script per i cookie del browser o la rimozione manuale dei dati dei siti web di Safari devono corrispondere esattamente al gateway e al provider di identità. In Windows, la procedura Sophos richiede la disattivazione della protezione antimanomissione e l’esecuzione con privilegi elevati dell’allegato della KB clearcreds.bat. Non utilizzare script di pulizia di terze parti né procedure di eliminazione manuale non documentate. I file originali e le limitazioni sono disponibili in Sophos ZTNA: disconnessione dall’agente.

Ripristino o dismissione in sicurezza

Le fonti assegnate relative a diagnostica e report non documentano una procedura generale per riparare, disinstallare o ripristinare l’agente. Il limite operativo sicuro è pertanto il seguente:

I filtri di prova e Report Generator non modificano il percorso dati; un modello o una pianificazione salvati soltanto a fini diagnostici possono essere eliminati in Saved templates o Scheduled exports.
Dopo una prova comparativa con IPv6, ripristinare immediatamente lo stato iniziale documentato.
Non lasciare come soluzione definitiva un criterio temporaneamente meno restrittivo, un gruppo modificato, una configurazione DNS modificata o un controllo dei certificati alterato. Se una modifica simile è stata apportata al di fuori di questa procedura, ripristinare lo stato precedentemente documentato e ripetere la prova sullo stesso caso.
Non rimuovere l’agente, non eliminare gli adattatori TAP e non aggirare la convalida dei certificati finché non è stata dimostrata l’origine del problema. Se non esiste una procedura di ripristino documentata, interrompere le modifiche e inoltrare il caso al livello di assistenza successivo insieme agli elementi raccolti.

Dopo ogni ripristino, lo stato dell’agente, la risposta DNS, la richiesta effettiva alla risorsa e il report ZTNA pertinente devono tornare a coincidere con lo stato iniziale. In caso contrario, non apportare una seconda modifica.

Operatività, verifica e ciclo di vita

I report e gli avvisi ZTNA costituiscono riscontri operativi, non azioni correttive. Per le verifiche ricorrenti, salvare un modello di report filtrato o pianificare un’esportazione. I report pianificati possono essere generati con cadenza giornaliera, settimanale o mensile nei formati PDF, CSV o HTML; Sophos Central supporta al massimo 200 pianificazioni. Le esportazioni generate manualmente o automaticamente vengono eliminate dopo 90 giorni. Se un report contiene dati personali, è preferibile inviare via e-mail un collegamento anziché allegare il file, poiché l’apertura del collegamento richiede l’accesso a Sophos Central.

Gli avvisi mostrano gravità, stato, eventi e dispositivo. Gli eventi ricorrenti possono essere raggruppati in un unico avviso; un evento successivo può chiuderlo automaticamente con lo stato Resolved. Durante un incidente, leggere quindi sempre gli eventi inclusi e i relativi timestamp. Mark as acknowledged rimuove un avviso dall’elenco, ma non ne elimina la causa. Analogamente, Mark as resolved non sostituisce la risoluzione tecnica del problema.

Prima di reinstallare, rimuovere profili o apportare ulteriori modifiche alla rete, raccogliere:

dispositivo, utente, sistema operativo e componenti effettivamente installati;
risorsa, metodo di accesso, criterio e gruppo assegnato;
messaggio esatto, stato ZTNA locale e timestamp, incluso il fuso orario;
risultato ottenuto con un secondo utente, dispositivo o rete, modificando una sola variabile alla volta;
risposte DNS per gli FQDN della risorsa e del gateway;
eventi pertinenti di Central e log ZTNA, SNTP e di installazione;
report ZTNA filtrato o esportazione relativi all’intervallo della prova;
un archivio SDU aggiornato.

Fanno fede le versioni correnti della guida e dei componenti. Questa procedura non consente di trarre conclusioni sulle transizioni storiche di ZTNA, sulla revoca di diritti concessi in precedenza, sulle scadenze di migrazione, sul ritiro del prodotto o sulle date esatte di fine vita.

Guide correlate

Per l’architettura e le dipendenze, consultare Configurare Sophos ZTNA: panoramica e sequenza. Il presente articolo rimane incentrato sullo stato dell’agente e sugli elementi relativi alla connessione; la distribuzione del gateway e una presunta procedura generale di riparazione dell’agente non rientrano nel suo ambito.

Sophos Endpoint: diagnostica con SDU descrive come raccogliere i dati in sicurezza. Aprire quindi un caso presso il supporto Sophos allegando gli elementi raccolti. Non inserire credenziali, token o cookie del browser nei ticket o in allegati non protetti.