Sophos ZTNA Agent: Fehler systematisch eingrenzen

Zweck und direkte Antwort

Ein nicht erreichbares ZTNA-Ziel ist nicht automatisch ein defekter Agent. Installation, Policy, Benutzergruppe, DNS, Identity Provider, Gateway und interne Anwendung bilden eine Kette. Die Fehlersuche beginnt deshalb beim sichtbaren Symptom und ändert nur die Ebene, für die es Belege gibt.

Die kürzeste belastbare Prüfung lautet:

Betroffenen Benutzer, Gerät, Ressource und Zeitpunkt festhalten.
Installation und lokalen Agent-Status prüfen.
Unter Meine Produkte > ZTNA (englische Navigation: Sophos Central > My Products > ZTNA) Ressource, Zugriffsmethode und Policy abgleichen.
Unter ZTNA > Berichte (englische Navigation: Sophos Central > My Products > ZTNA > Reports) die erfolgreiche Authentifizierung oder den Grund für die Zugriffsverweigerung suchen.
Unter Meine Umgebung > Alerts (englische Navigation: Sophos Central > Alerts) nach einem zeitlich passenden Installations-, Update-, Lizenzierungs- oder Konnektivitätsereignis des Geräts suchen.
DNS, Identität, Gerätestatus oder Gateway nur entsprechend dem gefundenen Symptom prüfen.

Ein erfolgreicher Browseraufruf beweist nicht, dass der Agentenpfad verwendet wurde. Umgekehrt zeigt das ZTNA-Benutzerportal nur agentlose Anwendungen; eine agentenbasierte Ressource muss dort nicht erscheinen.

Voraussetzungen, Lizenz und Rollen

Für diese Diagnose werden ein betroffener Benutzer und ein verwaltetes Gerät, der FQDN einer betroffenen Ressource sowie Zugriff auf die ZTNA-Konfiguration, Berichte, Geräteansicht und Alerts des richtigen Tenants benötigt. Der ZTNA-Agent muss dem Gerät zugewiesen sein, wenn eine agentenbasierte Ressource getestet wird. Unter Geräte > Computer beziehungsweise Server zeigt ein grüner Haken die installierte ZTNA-Komponente; ein Pluszeichen bedeutet, dass sie noch installiert werden kann.

Die zugeteilten Quellen nennen für diese Fehlersuche weder eine eigene Lizenzbezeichnung noch eine bestimmte Administratorrolle. Aus der Sichtbarkeit eines Menüs darf deshalb keine weitergehende Berechtigung abgeleitet werden. Fehlt eine benötigte Ansicht oder Aktion, nicht auf ein Lizenz- oder Rollenproblem schliessen, sondern den Tenant-Administrator einbeziehen.

Vor jeder Änderung mit genau einem betroffenen Benutzer und Gerät notieren:

Betriebssystem, Netzwerk und Zeitpunkt mit Zeitzone,
FQDN der Ressource und Zugriffsmethode Agent oder Agentless,
Wortlaut des lokalen ZTNA-Status und der Browsermeldung,
ob andere ZTNA-Ressourcen auf demselben Gerät funktionieren,
ob dieselbe Ressource mit demselben Benutzer in einem anderen Netzwerk funktioniert,
letzte Änderung an Policy, Gruppe, DNS, Identity Provider oder Gateway.

Konfiguration mit anpassbaren Beispielwerten

Für einen begrenzten Test werden keine produktiven Einstellungen pauschal geändert. Beispielwerte wie <BENUTZER>, <GERÄT>, <RESSOURCEN-FQDN> und <TESTZEIT MIT ZEITZONE> müssen durch Werte aus genau einem Fall ersetzt werden.

Unter ZTNA > Berichte die Registerkarte Report Generator öffnen. Für einen verweigerten Zugriff die Vorlage Verweigerter Ressourcenzugriff wählen, den Zeitraum eng um <TESTZEIT MIT ZEITZONE> legen und, soweit die vorhandenen Spalten dies erlauben, nach <BENUTZER>, <GERÄT> oder <RESSOURCEN-FQDN> filtern. Filterwerte bei = und != sind gross-/kleinschreibungssensitiv; ~ verwendet * als Platzhalter und unterscheidet nicht zwischen Gross- und Kleinschreibung. Mehrere Filter werden gemeinsam erfüllt. Danach den Bericht mit Erstellen ausführen.

Für einen erwarteten erfolgreichen Anmeldevorgang stattdessen Authentifizierte Benutzer verwenden. Dieser Bericht erfasst Benutzer, die von ZTNA-Gateways erfolgreich authentifiziert wurden, unabhängig vom Bereitstellungsmodus des Gateways. Die Vorlagen Gateway-Bandbreite und Ressourcen-Bandbreite dienen der Verkehrszuordnung, nicht als alleiniger Nachweis eines erfolgreichen Einzelzugriffs.

Unter Meine Umgebung > Alerts den Zeitraum und das Gerät passend zum Test eingrenzen. Ein Alert kann mehrere wiederkehrende Ereignisse zusammenfassen. Den Titel öffnen, damit die zugehörigen Ereignisse und vollständigen Details sichtbar werden. Den Alert während der Analyse nicht nur zur Bereinigung der Liste schliessen.

Validierung und erwartetes Ergebnis

Ein positiver Test ist erst vollständig, wenn alle folgenden Punkte zusammenpassen:

Der Agent zeigt für den getesteten Pfad den erwarteten Zustand.
<RESSOURCEN-FQDN> öffnet sich mit dem vorgesehenen Benutzer, Gerät und Netzwerk.
Der Bericht Authentifizierte Benutzer enthält die erfolgreiche Authentifizierung im gewählten Zeitraum.
Der Bericht Verweigerter Ressourcenzugriff enthält für denselben Test keine neue Verweigerung.
In Meine Umgebung > Alerts gibt es keinen offenen, zeitlich passenden Installations-, Update-, Lizenzierungs- oder Konnektivitätsalert, der den Erfolg infrage stellt.

Fehlt der erwartete Berichtsdatensatz, Zeitraum und Schreibweise der Filter prüfen und den Test einmal mit nur einer geänderten Variable wiederholen. Erscheint stattdessen eine Verweigerung, bestimmt deren Grund den nächsten Abschnitt. Bleibt auch der zweite Test ohne verwertbaren Datensatz, nicht durch weitere Konfigurationsänderungen «Erfolg» erzwingen, sondern Logs und SDU für die Eskalation sichern.

Troubleshooting nach Symptom

Status «Not configured»

Unter Geräte > Computer beziehungsweise Server (englische Navigation: Devices > Computers beziehungsweise Servers) am Gerät prüfen, ob ZTNA installiert ist. Ein grüner Haken bestätigt die installierte Komponente; ein Pluszeichen bietet die Installation an. Eine vorhandene Sophos-Endpoint-Installation allein beweist nicht, dass ZTNA zugewiesen wurde.

Es gibt eine wichtige Windows-Ausnahme: Ist unter Globale Einstellungen > Produkte und Services > ZTNA (englische Navigation: Global Settings > Products and Services > ZTNA) die Funktion Don’t intercept on-premises traffic eingerichtet und erkennt der Windows-Agent das interne Netz, stoppt er dort absichtlich die Interception und zeigt Not Configured. Beim Wechsel in ein anderes Netz wird wieder Configured erwartet. Diese Funktion ist laut Sophos derzeit Windows-spezifisch; daraus darf keine macOS-Parität abgeleitet werden.

Dieses Windows-Verhalten setzt Sophos Core Agent 2025.2.1.709 oder neuer voraus. In Sophos Fusion (ehemals Sophos Central) das Gerät öffnen und auf dessen Registerkarte Summary die installierte Core-Agent-Version prüfen, bevor die On-Premises-Erkennung diagnostiziert wird. Eine ältere Version unterstützt diese Ausnahme nicht wie beschrieben.

Passt die Ausnahme nicht, Komponentenzuweisung, Online-Status und Update-Zustand in Sophos Fusion prüfen. Nicht mit einer Neuinstallation beginnen, solange unklar ist, ob ZTNA überhaupt zugewiesen wurde.

Status «Zero Trust Network Access: Error»

Dieser Status steht für ein Verbindungsproblem. In dieser Reihenfolge prüfen:

Existiert eine ZTNA Policy und ist sie der Ressource zugeordnet?
Löst das Gerät den Gateway-FQDN wie vorgesehen auf?
Zeigt Sophos Fusion einen Installations- oder Health-Fehler für das Gerät?
Ist unter Windows die Sophos-TAP-Konfiguration vorhanden, oder wurde sie durch eine andere Netzwerksoftware verändert?

Sophos nennt das Abschalten von IPv6 als Troubleshooting-Schritt. Das ist keine Baseline-Lösung: nur auf einem Pilotgerät, mit dokumentiertem Ausgangszustand und für einen einzelnen Reproduktionstest durchführen. Danach IPv6 wieder aktivieren. Ändert sich das Fehlerbild eindeutig, Zeitstempel und SDU sichern und mit Sophos Support klären; IPv6 nicht dauerhaft oder flächig deaktivieren.

Ein Tunnel darf bei Inaktivität schliessen. Je nach zentraler Einstellung geschieht dies nach 5, 15 oder 30 Minuten beziehungsweise einer Stunde; Standard sind 5 Minuten. Neuer Traffic baut ihn wieder auf. Ein geschlossener Leerlauftunnel allein ist deshalb kein Fehlernachweis.

Das Anmeldefenster erscheint nicht

Bei einer agentenbasierten Ressource nacheinander prüfen:

Kann das Gerät das ZTNA Gateway erreichen?
Läuft der ZTNA-Agent-Prozess?
Existiert für den Anwendungs-FQDN fälschlich ein öffentlicher oder interner CNAME zum Gateway? Für agentenbasierte Anwendungen darf dieser CNAME nicht vorhanden sein.
Stimmen Ressource, Zugriffsmethode und FQDN in Sophos Fusion?
Zeigen die ZTNA-Logs zur Testzeit einen SNTP-, DNS- oder Verbindungsfehler?

Erscheint die Anmeldung, aber die Rückleitung zur Anwendung nicht, Redirect URI des Identity Providers prüfen. Bei Okta ist zusätzlich die Groups claim expression gross-/kleinschreibungssensitiv. Browser-Cookies oder Zugangsdaten erst zurücksetzen, wenn die Anmeldung selbst als Fehlerklasse bestätigt ist.

Authentifizierte Agent-Ressource schlägt fehl oder funktioniert nicht mehr

Ist die Anmeldung erfolgreich, aber eine agentenbasierte Anwendung öffnet sich nicht, die SNTP-Logs auf dem Endpoint auf Fehler prüfen und in heartbeat.xml sicherstellen, dass das dort erfasste Zertifikat aktuell gültig ist. Eine falsche Gerätezeit, fehlgeschlagene Zeitsynchronisierung oder ein abgelaufenes beziehungsweise noch nicht gültiges Zertifikat kann den authentifizierten Agentenpfad unterbrechen, obwohl Policy und DNS korrekt erscheinen. Logs, Datei und Zeitstempel sichern; die XML-Datei nicht bearbeiten und die Zertifikatsprüfung nicht umgehen.

Hat der Zugriff zuvor funktioniert und geht dann verloren, dieselben Prüfungen der SNTP-Logs und der Zertifikatsgültigkeit in heartbeat.xml durchführen und das Gerät in Sophos Fusion prüfen. Ein roter Status Endpoint health ist ein Diagnosehinweis: die gemeldete Health-Ursache beheben und danach erneut testen, statt die ZTNA Policy zu lockern.

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

Der Bericht Verweigerter Ressourcenzugriff grenzt die nächste Prüfung ein:

Kein Zugriff / 403 Access Denied / No Access: Der Benutzer ist keiner der Ressource zugewiesenen Gruppe wirksam zugeordnet, oder für die Gruppe ist in Microsoft Entra ID die Sicherheit nicht aktiviert. Gruppenimport, Security-enabled-Status und API-Berechtigungen des Identity Providers prüfen. Änderungen an erlaubten Gruppen können bis zu einer Stunde benötigen.
Geräte-Integrität / Device Health: Das Gerät erfüllt die Health-Bedingungen der zugeordneten Agent Policy nicht. Den konkreten Health-Fehler beheben, nicht die Policy pauschal lockern.
Richtlinie aus / Policy Off: Unter Meine Produkte > ZTNA > Richtlinien (englische Navigation: My Products > ZTNA > Policies) die betroffene Policy öffnen und Richtlinie durchgesetzt wird beziehungsweise Policy is enforced prüfen.
Upstream request error bei Agentless: Das Gateway erreicht die interne Anwendung nicht, die Anwendung läuft nicht, FQDN/IP löst falsch auf oder der konfigurierte Port stimmt nicht. Das ist kein Beleg für einen defekten Endpoint-Agent.
404 Not Found bei Agentless: CNAME der Anwendung zum Gateway-FQDN prüfen. Diese DNS-Regel nicht auf agentenbasierte Ressourcen übertragen.

Ist ein Benutzer gerade einer Gruppe hinzugefügt worden, erst nach der dokumentierten Replikationszeit erneut testen. Ein privates Browserfenster kann bei einer Web-App einen alten Browserzustand ausschliessen, beschleunigt aber keine Gruppenreplikation.

DNS-Fehler nach der Installation

Der ZTNA TAP Adapter kann für nslookup zum Standard werden. Eine Abfrage für ein Ziel ausserhalb des ZTNA Gateways kann dadurch scheitern, obwohl die normale Namensauflösung nicht grundsätzlich ausgefallen ist. Sophos dokumentiert für den Vergleich die explizite Angabe des vorgesehenen DNS-Servers:

nslookup <FQDN> <DNS-SERVER>

Die Antwort mit dem erwarteten Unternehmensresolver und anschliessend den echten Anwendungsaufruf vergleichen. Keine Adapterreihenfolge, Metrik oder DNS-Serveradresse auf Verdacht ändern. Bei agentenbasierten Ressourcen ausserdem sicherstellen, dass kein Gateway-CNAME für die Anwendung existiert.

Sophos DNS Protection ist ein separater Datenpfad. Wenn es ebenfalls eingesetzt wird, helfen die Policy- und Ausnahmeregeln unter DNS Protection für Endpoints konfigurieren; ZTNA-DNS und Endpoint DNS Protection dürfen nicht als dieselbe Funktion behandelt werden.

ZTNA neben VPN- oder Remote-Access-Software

Nicht pauschal TAP-Adapter löschen, Bindings ändern oder Netzwerkmetriken festschreiben. Zuerst mit derselben Ressource kontrolliert mit und ohne den anderen Client reproduzieren und Uhrzeit, DNS-Antwort und ZTNA-Status festhalten.

Für ZTNA 2026.1 mit Sophos DNS Protection beschreibt Sophos einen konkreten Koexistenzpfad: DNS Protection aktivieren und in dessen Endpoint Policy Retry with system- or application-configured DNS services when DNS Protection returns NXDOMAIN einschalten. Dieser Schritt setzt die entsprechende Version, Lizenz und DNS-Protection-Konfiguration voraus; er ist keine allgemeine Lösung für beliebige VPN-Produkte.

Eng begrenzte macOS-Fälle

Auf macOS Sequoia kann Chrome nach einer reinen ZTNA-Neuinstallation Anwendungen hinter einem On-premises Gateway blockieren, wenn der Browser keinen Zugriff auf das lokale Netzwerk hat. Unter System Settings > Privacy & Security > Local Network nur für dieses Fehlerbild prüfen, ob Google Chrome lokale Geräte finden darf. Sophos Cloud Gateway ist von diesem dokumentierten Fall nicht betroffen. Daraus folgt weder eine allgemeine Freigabeempfehlung noch ein macOS-«Private Access»-Versprechen.

Eine hohe CPU-Last nach einer MDM-Bereitstellung kann durch mehrere VPN-Profile entstehen, deren Name mit Sophos ZTNA beginnt. Unter System Settings > VPN prüfen, ob Duplikate vorhanden sind. Genau ein Profil behalten; ein durch MDM installiertes Profil lässt sich lokal nicht entfernen und muss deshalb das verbleibende Profil sein. Anschliessend den Mac neu starten und CPU-Last sowie ZTNA-Zugriff erneut prüfen. Diese Bereinigung gilt nur für diesen bestätigten macOS-Fall, nicht für Windows-TAP-Adapter.

Wenn ausdrücklich alte Anmeldedaten reproduziert werden, dürfen die von Sophos dokumentierten Reset-Wege nur für Debugging oder Demos verwendet werden, nicht als normaler Sign-out in Produktion. Unter macOS bietet das Endpoint-Diagnosetool ZTNA > Reset; browserbezogene Cookie-Skripte beziehungsweise manuelles Löschen von Safari-Websitedaten müssen exakt zum Gateway und Identity Provider passen. Unter Windows setzt der Sophos-Weg deaktivierten Tamper Protection und das als KB-Anhang bereitgestellte clearcreds.bat mit erhöhten Rechten voraus. Keine fremden Cleanup-Skripte oder manuell erfundenen Löschpfade verwenden. Die Originaldateien und Grenzen stehen in Sophos ZTNA: Sign out from the agent.

Sicherer Rückweg oder Offboarding

Die zugeteilten Diagnose- und Berichtsquellen dokumentieren keine allgemeine Agent-Reparatur, Deinstallation oder Rückabwicklung. Deshalb gilt als sicherer Stopp:

Testfilter und Report Generator verändern den Datenpfad nicht; eine nur für die Diagnose gespeicherte Vorlage oder ein Zeitplan kann unter Gespeicherte Vorlagen beziehungsweise Geplante Exporte wieder gelöscht werden.
Nach einem IPv6-Vergleichstest den dokumentierten Ausgangszustand sofort wiederherstellen.
Eine testweise gelockerte Policy, geänderte Gruppe, DNS-Konfiguration oder Zertifikatsprüfung nicht als Fehlerbehebung stehen lassen. Wurde eine solche Änderung ausserhalb dieses Ablaufs vorgenommen, auf den vorab dokumentierten Zustand zurücksetzen und erneut mit demselben Testfall prüfen.
Den Agenten nicht entfernen, TAP-Adapter nicht löschen und Zertifikatsprüfung nicht umgehen, solange der Fehlerort nicht belegt ist. Fehlt ein dokumentierter Rückweg, stoppen und mit der gesicherten Evidenz eskalieren.

Nach jedem Rückweg müssen Agent-Status, DNS-Antwort, echter Ressourcenaufruf und der passende ZTNA-Bericht wieder dem Ausgangszustand entsprechen. Ist das nicht der Fall, keine zweite Änderung anschliessen.

Betrieb, Review und Lifecycle

ZTNA-Berichte und Alerts sind Betriebsnachweise, keine Reparaturaktionen. Für wiederkehrende Reviews kann eine gefilterte Berichtsvorlage gespeichert oder ein Export geplant werden. Geplante Berichte lassen sich täglich, wöchentlich oder monatlich als PDF, CSV oder HTML erzeugen; Sophos Central unterstützt höchstens 200 Zeitpläne. Manuell oder geplant erzeugte Exporte werden nach 90 Tagen gelöscht. Enthält ein Bericht personenbezogene Daten, ist ein E-Mail-Link einem Dateianhang vorzuziehen, weil der Link eine Anmeldung an Sophos Central verlangt.

Alerts zeigen Schweregrad, Status, Ereignisse und Gerät. Wiederkehrende Ereignisse können in einem Alert zusammengefasst werden; ein späteres Ereignis kann einen Alert automatisch als Behoben schliessen. Deshalb bei einer Störung immer die enthaltenen Ereignisse und Zeitstempel lesen. Als bestätigt markieren entfernt einen Alert aus der Liste, löst aber die Ursache nicht. Auch Als behoben markieren ist kein Ersatz für die technische Behebung.

Vor Neuinstallation, Profilbereinigung oder weiteren Netzwerkänderungen sammeln:

Gerät, Benutzer, Betriebssystem und tatsächlich installierte Komponenten,
Ressource, Zugriffsmethode, Policy und zugewiesene Gruppe,
exakte Meldung, lokaler ZTNA-Status und Zeitstempel mit Zeitzone,
Ergebnis mit zweitem Benutzer, Gerät oder Netzwerk – jeweils nur eine Variable verändert,
DNS-Antworten für Ressourcen- und Gateway-FQDN,
relevante Central Events sowie ZTNA-, SNTP- und Installationslogs,
gefilterten ZTNA-Bericht oder Export für den Testzeitraum,
ein aktuelles SDU-Archiv.

Aktuelle Hilfe- und Komponentenstände sind massgeblich. Aus diesem Ablauf lassen sich keine Aussagen zu historischen ZTNA-Umstellungen, zum Entzug früherer Berechtigungen, zu Migrationsfristen, Retirement oder exakten End-of-Life-Terminen ableiten.