Sophos ZTNA Agent: systematisk felsökning

Syfte och kort svar

Att en ZTNA-resurs inte går att nå betyder inte automatiskt att det är fel på agenten. Installationen, policyn, användargruppen, DNS, identitetsleverantören, gatewayen och den interna applikationen ingår alla i samma kedja. Börja därför felsökningen vid det synliga symtomet och ändra bara den del som det finns belägg för att undersöka.

Den kortaste tillförlitliga kontrollen är att:

Anteckna berörd användare, enhet och resurs samt tidpunkten för felet.
Kontrollera installationen och agentens lokala status.
Jämför resurs, åtkomstmetod och policy under My Products > ZTNA (fullständig sökväg: Sophos Central > My Products > ZTNA).
Leta efter en lyckad autentisering eller orsaken till att åtkomsten nekades under ZTNA > Reports (fullständig sökväg: Sophos Central > My Products > ZTNA > Reports).
Leta under My Environment > Alerts (fullständig sökväg: Sophos Central > Alerts) efter en händelse för enheten som gäller installation, uppdatering, licensiering eller anslutning och som inträffade vid samma tidpunkt.
Kontrollera DNS, identitet, enhetshälsa eller gateway endast om det aktuella symtomet pekar på den delen.

Att resursen går att öppna i en webbläsare bevisar inte att trafiken gick via agenten. Omvänt visar ZTNA-användarportalen endast agentlösa applikationer. En agentbaserad resurs behöver alltså inte visas där.

Krav, licensiering och roller

För felsökningen behövs en berörd användare och hanterad enhet, FQDN för den berörda resursen samt åtkomst till ZTNA-konfigurationen, rapporterna, enhetsvyn och aviseringarna i rätt Sophos Central-miljö. Vid test av en agentbaserad resurs måste ZTNA Agent vara tilldelad till enheten. Under Devices > Computers eller Servers visar en grön bock att ZTNA-komponenten är installerad. Ett plustecken visar att den kan installeras.

De angivna källorna specificerar varken ett separat licensnamn eller en viss administratörsroll för den här felsökningen. Utgå inte från att en administratör har mer omfattande behörigheter enbart för att en meny visas. Om en nödvändig vy eller åtgärd saknas ska du ta hjälp av administratören för Sophos Central-miljön i stället för att anta att problemet gäller licensen eller rollen.

Dokumentera följande för exakt en berörd användare och enhet innan du ändrar något:

operativsystem, nätverk och tidpunkt inklusive tidszon,
resursens FQDN och åtkomstmetod, Agent eller Agentless,
exakt lokal ZTNA-status och exakt meddelande i webbläsaren,
om andra ZTNA-resurser fungerar på samma enhet,
om samma resurs fungerar för samma användare i ett annat nätverk,
senaste ändringen av policy, grupp, DNS, identitetsleverantör eller gateway.

Konfiguration med anpassningsbara exempelvärden

Gör inga generella ändringar i produktionsmiljön för ett avgränsat test. Ersätt exempelvärden som <USER>, <DEVICE>, <RESOURCE-FQDN> och <TEST TIME WITH TIME ZONE> med uppgifter från exakt ett fall.

Öppna fliken Report Generator under ZTNA > Reports. Vid nekad åtkomst väljer du mallen Denied resource access, avgränsar perioden kring <TEST TIME WITH TIME ZONE> och filtrerar, om de tillgängliga kolumnerna medger det, på <USER>, <DEVICE> eller <RESOURCE-FQDN>. Filtervärden med = och != är skiftlägeskänsliga. Operatorn ~ använder * som jokertecken och är inte skiftlägeskänslig. Om du anger flera filter måste samtliga villkor vara uppfyllda. Kör sedan rapporten med Create.

Använd i stället Authenticated users när en inloggning förväntas lyckas. Rapporten visar användare som har autentiserats av ZTNA-gatewayer, oavsett hur gatewayen har distribuerats. Mallarna Gateway bandwidth och Resource bandwidth visar hur trafiken fördelas. De bevisar inte i sig att ett enskilt åtkomstförsök lyckades.

Avgränsa perioden och enheten under My Environment > Alerts så att de motsvarar testet. En avisering kan innehålla flera återkommande händelser. Öppna aviseringens rubrik för att se tillhörande händelser och fullständig information. Stäng inte aviseringen bara för att rensa listan medan analysen pågår.

Validering och förväntat resultat

Ett test kan räknas som lyckat först när samtliga punkter nedan stämmer överens:

Agenten visar förväntad status för den testade åtkomstvägen.
<RESOURCE-FQDN> går att öppna med avsedd användare, enhet och nätverksanslutning.
Rapporten Authenticated users innehåller den lyckade autentiseringen under den valda perioden.
Rapporten Denied resource access innehåller inget nytt avslag för samma test.
Under My Environment > Alerts finns ingen öppen avisering om installation, uppdatering, licensiering eller anslutning vid samma tidpunkt som ger anledning att ifrågasätta resultatet.

Om den förväntade rapportposten saknas kontrollerar du perioden och stavningen i filtren. Upprepa därefter testet en gång och ändra endast en variabel. Om ett avslag visas i stället avgör avslagsorsaken vilket avsnitt du ska gå vidare till. Om inte heller det andra testet ger en användbar post ska du inte försöka framtvinga ett ”lyckat” resultat genom fler konfigurationsändringar. Spara loggarna och SDU-arkivet för eskalering.

Felsökning efter symtom

Status ”Not configured”

Kontrollera under Devices > Computers eller Servers om ZTNA är installerat på enheten. En grön bock bekräftar att komponenten är installerad, medan ett plustecken gör det möjligt att installera den. En befintlig Sophos Endpoint-installation bevisar inte i sig att ZTNA har tilldelats.

Det finns ett viktigt undantag för Windows. Om Don’t intercept on-premises traffic har konfigurerats under Global Settings > Products and Services > ZTNA och Windows-agenten identifierar det interna nätverket slutar den avsiktligt att fånga upp trafiken där och visar Not Configured. När enheten flyttas till ett annat nätverk förväntas statusen återgå till Configured. Enligt Sophos gäller funktionen för närvarande endast Windows. Utgå därför inte från att macOS fungerar på samma sätt.

Det här beteendet i Windows kräver Sophos Core Agent 2025.2.1.709 eller senare. Öppna enheten i Sophos Fusion (tidigare Sophos Central) och kontrollera den installerade versionen av Core Agent på fliken Summary innan du felsöker identifieringen av det interna nätverket. Äldre versioner stöder inte undantaget på det sätt som beskrivs här.

Om undantaget inte är tillämpligt kontrollerar du komponenttilldelningen, onlinestatusen och uppdateringsstatusen i Sophos Fusion. Börja inte med att installera om programvaran så länge det är oklart om ZTNA över huvud taget har tilldelats.

Status ”Zero Trust Network Access: Error”

Statusen visar att det finns ett anslutningsproblem. Kontrollera följande i angiven ordning:

Finns det en ZTNA-policy, och är den tilldelad till resursen?
Kan enheten slå upp gatewayens FQDN via DNS till förväntad adress?
Visar Sophos Fusion något installations- eller hälsofel för enheten?
Finns Sophos TAP-konfigurationen kvar i Windows, eller har ett annat nätverksprogram ändrat den?

Sophos anger inaktivering av IPv6 som ett felsökningssteg. Det är inte en standardåtgärd. Gör det endast på en pilotenhet, dokumentera utgångsläget och genomför ett enda reproduktionstest. Aktivera IPv6 igen efter testet. Om symtomet ändras på ett entydigt sätt sparar du tidsstämplar och ett SDU-arkiv och utreder resultatet tillsammans med Sophos Support. Låt inte IPv6 förbli inaktiverat permanent eller på flera enheter.

En inaktiv tunnel kan stängas. Beroende på den centrala inställningen sker det efter 5, 15 eller 30 minuter eller efter en timme. Standardvärdet är 5 minuter. Tunneln upprättas igen när ny trafik skickas. En stängd, inaktiv tunnel är därför inte i sig ett tecken på fel.

Inloggningsfönstret visas inte

Kontrollera följande i angiven ordning för en agentbaserad resurs:

Kan enheten nå ZTNA-gatewayen?
Körs processen för ZTNA Agent?
Finns det felaktigt en offentlig eller intern CNAME-post från applikationens FQDN till gatewayen? En sådan CNAME-post får inte finnas för agentbaserade applikationer.
Stämmer resursen, åtkomstmetoden och FQDN överens i Sophos Fusion?
Visar ZTNA-loggarna något SNTP-, DNS- eller anslutningsfel vid tidpunkten för testet?

Om inloggningsfönstret visas men användaren inte skickas tillbaka till applikationen kontrollerar du identitetsleverantörens omdirigerings-URI. För Okta är även Groups claim expression skiftlägeskänsligt. Återställ inte webbläsarcookies eller autentiseringsuppgifter förrän du har bekräftat att det är själva autentiseringen som misslyckas.

En autentiserad agentresurs fungerar inte eller slutar fungera

Om autentiseringen lyckas men en agentbaserad applikation inte öppnas kontrollerar du klientens SNTP-loggar efter fel. Kontrollera också i heartbeat.xml att certifikatet som anges där fortfarande är giltigt. Felaktig tid på enheten, misslyckad tidssynkronisering eller ett certifikat som har upphört att gälla eller ännu inte är giltigt kan bryta den autentiserade trafikvägen via agenten, även om policy och DNS verkar vara korrekta. Spara loggarna, filen och tidsstämpeln. Redigera inte XML-filen och kringgå inte certifikatverifieringen.

Om åtkomsten fungerade tidigare men sedan upphörde gör du samma kontroller av SNTP-loggarna och certifikatets giltighet i heartbeat.xml. Granska även enheten i Sophos Fusion. Röd Endpoint health är en viktig ledtråd i felsökningen. Åtgärda den rapporterade orsaken och testa igen i stället för att sänka säkerhetskraven i ZTNA-policyn.

”403 Access Denied / No Access”, ”Device Health” eller ”Policy Off”

Rapporten Denied resource access visar vad du ska kontrollera härnäst:

403 Access Denied / No Access: Användaren är i praktiken inte medlem i en grupp som har tilldelats till resursen, eller så är gruppen inte säkerhetsaktiverad i Microsoft Entra ID. Kontrollera gruppimporten, att gruppen är säkerhetsaktiverad och identitetsleverantörens API-behörigheter. Ändringar av tillåtna grupper kan ta upp till en timme att slå igenom.
Device Health: Enheten uppfyller inte hälsovillkoren i den tilldelade agentpolicyn. Åtgärda det specifika hälsoproblemet i stället för att generellt sänka kraven i policyn.
Policy Off: Öppna den berörda policyn under My Products > ZTNA > Policies och markera Policy is enforced.
Upstream request error for Agentless: Gatewayen kan inte nå den interna applikationen, applikationen är inte tillgänglig, DNS-uppslagningen av den konfigurerade FQDN- eller IP-adressen ger fel resultat eller den konfigurerade porten är fel. Det bevisar inte att klientagenten är defekt.
404 Not Found for Agentless: Kontrollera applikationens CNAME-post till gatewayens FQDN. Den här DNS-regeln gäller inte agentbaserade resurser.

Om användaren nyligen lades till i en grupp väntar du tills den dokumenterade replikeringstiden har gått innan du testar igen. Ett privat webbläsarfönster kan utesluta att gammal webbläsarstatus påverkar en webbapplikation, men det påskyndar inte gruppreplikeringen.

DNS-fel efter installationen

ZTNA TAP-adaptern kan bli standardadapter för nslookup. Då kan en fråga efter ett mål utanför ZTNA-gatewayen misslyckas trots att DNS-upplösningen i övrigt fungerar. För att få ett jämförbart resultat rekommenderar Sophos att du uttryckligen anger den DNS-server som ska användas:

nslookup <FQDN> <DNS-SERVER>

Jämför svaret från den avsedda DNS-servern i företagsnätverket och prova sedan att faktiskt öppna applikationen. Ändra inte adapterordning, gränssnittsmått eller DNS-serveradresser på måfå. För agentbaserade resurser ska du också kontrollera att det inte finns någon CNAME-post från applikationen till gatewayen.

Sophos DNS Protection använder ett separat trafikflöde. Om även den produkten används följer du Konfigurera Sophos DNS Protection för klientenheter för policyer och undantag. Behandla inte ZTNA DNS och Endpoint DNS Protection som samma funktion.

ZTNA tillsammans med VPN- eller fjärråtkomstprogram

Ta inte bort TAP-adaptrar, ändra bindningar eller ange fasta nätverksmått som en generell åtgärd. Försök först att återskapa åtkomstproblemet för samma resurs i ett kontrollerat test med respektive utan den andra klienten. Anteckna tidpunkt, DNS-svar och ZTNA-status.

För ZTNA 2026.1 tillsammans med Sophos DNS Protection beskriver Sophos en särskild konfiguration för samexistens: aktivera DNS Protection och slå på Retry with system- or application-configured DNS services when DNS Protection returns NXDOMAIN i dess klientpolicy. Det kräver rätt version, licens och konfiguration av DNS Protection. Det är inte en generell lösning för valfria VPN-produkter.

Avgränsade fall i macOS

På macOS Sequoia kan Chrome blockera applikationer bakom en on-premises gateway efter en nyinstallation som endast omfattar ZTNA, om webbläsaren saknar åtkomst till det lokala nätverket. Kontrollera endast vid detta symtom under System Settings > Privacy & Security > Local Network om Google Chrome har tillåtelse att hitta lokala enheter. Det här dokumenterade fallet påverkar inte Sophos Cloud Gateway. Det innebär varken att behörigheten bör beviljas generellt eller att macOS har stöd för ”private access”.

Hög CPU-användning efter en MDM-distribution kan bero på att det finns flera VPN-profiler vars namn börjar med Sophos ZTNA. Kontrollera under System Settings > VPN om det finns dubbletter. Behåll exakt en profil. En MDM-installerad profil kan inte tas bort lokalt och måste därför vara den profil som behålls. Starta om Mac-datorn och kontrollera sedan CPU-användningen och ZTNA-åtkomsten igen. Rensningen gäller endast detta bekräftade macOS-fall, inte TAP-adaptrar i Windows.

Om du uttryckligen har kunnat återskapa ett problem med inaktuella autentiseringsuppgifter får Sophos återställningsrutiner endast användas för felsökning eller demonstrationer, inte för normal utloggning i en produktionsmiljö. I macOS finns ZTNA > Reset i Endpoint-diagnostikverktyget. Skript för webbläsarcookies och manuell borttagning av Safari-webbplatsdata måste vara exakt anpassade till gatewayen och identitetsleverantören. I Windows kräver Sophos-rutinen att sabotageskyddet är inaktiverat och att KB-bilagan clearcreds.bat körs med förhöjd behörighet. Använd inte rensningsskript från tredje part eller egna, odokumenterade sökvägar för manuell borttagning. Originalfilerna och begränsningarna finns i Sophos ZTNA: Logga ut från agenten.

Säker återställning eller avveckling

De angivna källorna om diagnostik och rapportering beskriver ingen generell reparation, avinstallation eller återställning av agenten. Följ därför dessa säkra stoppunkter:

Testfilter och Report Generator ändrar inte trafikflödet. En mall eller ett schema som endast sparats för felsökning kan tas bort under Saved templates respektive Scheduled exports.
Återställ det dokumenterade utgångsläget omedelbart efter ett jämförelsetest med IPv6 inaktiverat.
Låt inte en tillfälligt uppluckrad policy, en ändrad grupp eller DNS-konfiguration eller en ändrad certifikatkontroll ligga kvar som lösning. Om en sådan ändring gjordes utanför den här proceduren återställer du det tidigare dokumenterade läget och testar samma fall igen.
Ta inte bort agenten eller TAP-adaptrar och kringgå inte certifikatverifieringen så länge det inte är fastställt var felet finns. Om det saknas en dokumenterad återställningsmetod ska du avbryta och eskalera ärendet med det underlag du har sparat.

Efter varje återställning ska agentstatusen, DNS-svaret, det faktiska försöket att öppna resursen och den relevanta ZTNA-rapporten åter stämma överens med utgångsläget. Gör ingen ytterligare ändring om de inte gör det.

Drift, granskning och livscykel

ZTNA-rapporter och aviseringar är underlag för driften, inte reparationsåtgärder. Vid återkommande granskningar kan du spara en filtrerad rapportmall eller schemalägga en export. Schemalagda rapporter kan skapas dagligen, veckovis eller månadsvis i PDF-, CSV- eller HTML-format. Sophos Central stöder högst 200 scheman. Både manuellt och automatiskt skapade exporter raderas efter 90 dagar. Om en rapport innehåller personuppgifter bör du skicka en länk via e-post i stället för att bifoga en fil, eftersom länken kräver inloggning i Sophos Central.

Aviseringar visar allvarlighetsgrad, status, händelser och enhet. Återkommande händelser kan slås samman i en avisering, och en senare händelse kan automatiskt stänga den med statusen Resolved. Läs därför alltid alla ingående händelser och tidsstämplar under en incident. Mark as acknowledged tar bort aviseringen från listan men åtgärdar inte orsaken. Mark as resolved ersätter inte heller en teknisk åtgärd.

Samla in följande innan du installerar om, rensar profiler eller gör fler nätverksändringar:

enhet, användare, operativsystem och de komponenter som faktiskt är installerade,
resurs, åtkomstmetod, policy och tilldelad grupp,
exakt meddelande, lokal ZTNA-status och tidsstämpel inklusive tidszon,
resultat med en annan användare, en annan enhet eller ett annat nätverk, med endast en ändrad variabel per test,
DNS-svar för resursens och gatewayens FQDN,
relevanta händelser i Sophos Central samt ZTNA-, SNTP- och installationsloggar,
den filtrerade ZTNA-rapporten eller exporten för testperioden,
ett aktuellt SDU-arkiv.

Aktuell dokumentation och aktuella komponentversioner har företräde. Den här proceduren ger inget stöd för slutsatser om historiska övergångar för ZTNA, indragning av tidigare rättigheter, migreringsfrister, utfasning eller exakta slutdatum för support.

Relaterade guider

Mer information om arkitektur och beroenden finns i Konfigurera Sophos ZTNA: översikt och ordningsföljd. Den här artikeln är avgränsad till agentstatus och underlag om anslutningen. Gatewaydistribution och antagandet att det finns en generell reparationsmetod för agenten ingår inte.

I Sophos Endpoint: diagnostik med SDU beskrivs hur du samlar in data på ett säkert sätt. Öppna därefter ett supportärende hos Sophos och bifoga det sparade underlaget. Kopiera inte inloggningsuppgifter, token eller webbläsarcookies till supportärenden eller oskyddade bilagor.