Kontrollera Sophos Central Firewall Management Task Queue

När en ändring har sparats i Sophos Central men inte når Sophos Firewall, är den lokala brandväggen inte alltid den första felkällan. För centralt hanterade brandväggar bör man också kontrollera Tasks Queue i Sophos Central. Där kan man se om Central fortfarande bearbetar, delvis har tillämpat, hoppat över eller avslutat en gruppolicy, en API-baserad brandväggsuppgift eller någon annan central ändring med fel.

Detta är särskilt viktigt när flera brandväggar hanteras i en grupp. En enskild misslyckad uppgift kan försena senare ändringar eller förvirra felsökningen eftersom konfigurationen i Sophos Central ser annorlunda ut än på den berörda brandväggen.

När Task Queue är relevant

Task Queue är relevant så snart ändringar inte utförs direkt lokalt på brandväggen utan via Sophos Central. Detta gäller särskilt miljöer där brandväggar är anslutna till Sophos Central och Central Firewall Management används aktivt.

Typiska situationer:

en gruppolicy har ändrats i Sophos Central
en ändring har nått vissa brandväggar men inte andra
en firmwareuppdatering har planerats eller startats via Sophos Central
MDR- eller API-baserade brandväggsuppgifter verkar inte ha genomförts fullt ut
en uppgift står länge på Pending eller In Progress
en uppgift är Failed, Skipped, Invalid license eller bara delvis framgångsrik
efter ett fel behandlas senare ändringar inte som förväntat

För lokal live-felsökning är Firewall Log Viewer fortfarande viktig. Task Queue svarar dock på en annan fråga: Har Sophos Central överhuvudtaget lyckats få igenom ändringen till brandväggen?

Var man hittar Task Queue

Sophos Central-vägen är:

My Products > Firewall Management > Tasks Queue

Sophos skiljer där mellan Task Queue och Firewall Task Queue.

Vy	Vad den är avsedd för
Task Queue	Status för brandväggsgruppolicyer som tillämpas på brandväggar via Sophos Central
Firewall Task Queue	Brandväggsuppgifter från MDR Settings, MDR IOCs och Firewall Configuration API

För klassiska Central Firewall Management-problem är oftast först Task Queue intressant. Firewall Task Queue blir viktigare när ändringar har initierats via Firewall Configuration API eller MDR-relaterade brandväggsfunktioner.

Vilken information som är viktig

En enskild uppgift är bara användbar om man kan placera den korrekt. Innan en ändring eller en Retry bör man åtminstone notera dessa fält:

Uppgiftsnummer
Berörd grupp eller brandvägg
Status
Tidpunkt
Administratör eller Credential ID
Entity och Sub-entity
Visat felmeddelande
Antal framgångsrika och misslyckade brandväggar

Tidpunkten är inte alltid densamma som starten av bearbetningen på varje brandvägg. Vid gruppolicyer visar Sophos Central först tidpunkten för skapandet eller ändringen och uppdaterar den senare när policyn tillämpas på brandväggar. Därför bör man vid längre utrullningar inte bara titta på den första tidpunkten.

Tolka status korrekt

Status	Betydelse i praktiken
`Pending`	Uppgiften väntar fortfarande på bearbetning. Vid längre varaktighet kontrollera anslutning, licens och Central-anslutning.
`In Progress`	Central bearbetar fortfarande uppgiften. Starta inte flera korrigeringar parallellt när uppgiften just körs.
`Success`	Central rapporterar uppgiften som framgångsrik. Kontrollera ändå på brandväggen om den förväntade effekten är synlig.
`Partial Success`	En del har tillämpats, en del inte. Detta är särskilt viktigt vid grupper eller flera objekt.
`Failed`	Ändringen avslutades inte framgångsrikt. Dokumentera felmeddelande och berörd brandvägg.
`Skipped`	Uppgiften hoppades medvetet över. Därefter krävs en facklig efterkontroll.
`Invalid license`	Licens eller behörighet passar inte för den planerade åtgärden. Försök inte lösa genom upprepad Retry.

Sophos Central kan automatiskt ta bort uppgifter med status Pending efter flera veckor. För driftdokumentation, supportärenden eller ändringsgranskningar bör man därför säkra relevanta fel i tid.

Ren kontrollprocess

Vid en blockerad Central-ändring hjälper en lugn process mer än upprepade klick på Retry.

Öppna My Products > Firewall Management > Tasks Queue i Sophos Central.
Begränsa tidsperiod och berörd brandvägg eller brandväggsgrupp.
Expandera uppgiften och kontrollera berörda brandväggar.
Dokumentera status, felmeddelande, Entity, Sub-entity och tidpunkt.
Kontrollera på brandväggen om ändringen är synlig eller bara sparad i Central.
Vid konfigurationsändringar kontrollera även Audit Trail Logs.
Vid trafikproblem utvärdera Log Viewer, Policy Test och relevanta serviceloggar.
Bestäm först därefter om Retry, Skip eller ett supportärende är lämpligt.

Om det är oklart vilken lokal logg som är relevant, hjälper Sophos Firewall Troubleshooting: Services och Logs. För regel- och trafikanalys passar dessutom Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture.

Skip eller Retry?

Sophos Central erbjuder beroende på status åtgärderna Skip och Retry. Båda är användbara, men bör inte ses som en ren städåtgärd.

Åtgärd	Lämplig när	Kontrollera innan
Retry	orsaken har åtgärdats, till exempel anslutning, licens, objektkonflikt eller tillfällig Central-störning	Är det klart varför uppgiften misslyckades?
Skip	en misslyckad eller inte längre relevant uppgift blockerar senare uppgifter och den fackliga effekten är förstådd	Kommer en planerad policyändring medvetet inte att tillämpas?
Vänta	uppgiften just körs eller Central bearbetar många brandväggar	Finns det tecken på verklig blockering eller bara normal fördröjning?
Supportärende	felet upprepas, påverkar flera produktiva brandväggar eller meddelandet är otydligt	Är uppgiftsdetaljer, tidpunkt, brandväggsnamn och loggar säkrade?

⚠️ En misslyckad uppgift bör inte hoppas över bara för att kölistan ska se ren ut. Skip är ett driftbeslut: Den icke tillämpade ändringen måste därefter medvetet kontrolleras eller genomföras separat.

Typiska felbilder

Ändring är synlig i Central men inte på brandväggen

I detta fall kontrollera först om den relevanta uppgiften har avslutats framgångsrikt. Om uppgiften fortfarande är Pending, In Progress, Failed eller Partial Success, ligger problemet inte nödvändigtvis i den lokala brandväggsregeln. Först när Central rapporterar uppgiften som framgångsrik bör man gå djupare in i lokal policy-, objekt- eller logganalys.

Endast enskilda brandväggar i en grupp påverkas

Vid gruppolicyer kan en ändring vara framgångsrik på flera brandväggar och misslyckas på en brandvägg. Då bör man inte ändra hela gruppen generellt, utan expandera den berörda brandväggen och kontrollera skillnader: licens, firmwareversion, Central-anslutning, lokala objektkonflikter, plattform och kända problem.

Firmware-uppgift via Central startar inte korrekt

Om en Sophos Firewall Firmware Update har planerats via Sophos Central bör Task Queue vara en del av efterkontrollen. Om brandväggen förblir på den gamla versionen, kontrollera först om Central har initierat och avslutat uppgiften. För större versioner ingår dessutom SFOS 22 Upgrade Check i förberedelserna.

Web- eller TLS-policy-synkronisering misslyckas

Vid Web Protection, URL-grupper eller TLS-undantag kan en Central-synkronisering verka särskilt förvirrande eftersom Central har accepterat en ändring som brandväggen inte har bearbetat fullt ut. Då bör man jämföra den berörda entiteten från Task Queue med den lokala konfigurationen. För den fackliga bedömningen passar Införa Sophos Firewall TLS Inspection korrekt och Skapa Sophos Firewall Web Protection Policy.

XGS 88/w och Local TLS Exclusion List

I listan över kända problem är ett specifikt problem dokumenterat för XGS 88/w-modeller: Vid synkronisering av en Sophos Central-policy kan bearbetningen av Local TLS exclusion list misslyckas. Det visade felmeddelandet hänvisar till en URL-grupp som inte kunde uppdateras. I detta fall kan man hoppa över den misslyckade transaktionen från Task Queue så att senare uppgifter kan fortsätta.

I praktiken bör man dock inte bara fortsätta. Viktigt är en efterkontroll:

Är det önskade TLS-undantaget lokalt på brandväggen?
Är Web- och TLS-policyn på brandväggen fortfarande fackligt korrekt?
Påverkar problemet bara en XGS 88/w eller flera brandväggar?
Måste ändringen tillfälligt genomföras lokalt eller skjutas upp?
Finns det en underhållsutgåva eller ett Sophos-meddelande för den berörda versionen?

Efterkontroll på brandväggen

En framgångsrik Central-uppgift är ett bra tecken, men ännu inget fullständigt driftstest. Beroende på ändring bör man lokalt kontrollera:

Är den ändrade regeln, policyn, listan eller firmwareversionen synlig?
Visar Log Viewer förväntade händelser?
Har ändringen loggats i Audit Trail?
Är Central-anslutning och rapportering fortfarande aktiva?
Fungerar berörda användare, VPN:er, webbtillgångar eller applikationer?

Vid säkerhetsrelaterade ändringar bör man dessutom definiera en kort återställningspunkt. Detta gäller särskilt för Web Protection, TLS Inspection, brandväggsregler, VPN, HA-kluster och firmwareuppdateringar.

Driftschecklista

Klargör innan ändringar via Sophos Central vilka brandväggar eller grupper som påverkas.
Kontrollera Task Queue efter Central-ändringar.
Dokumentera misslyckade uppgifter med felmeddelande, tidpunkt och brandväggsnamn.
Behandla inte Partial Success som helt avslutat.
Använd Retry först efter orsakskontroll.
Använd Skip endast om den fackliga effekten är förstådd.
Vid firmwareuppgifter planera underhållsfönster, backup och lokal åtkomst.
Vid upprepade fel säkra Audit Trail, Log Viewer och Sophos Support-information.

FAQ

Vad visar Sophos Central Task Queue?

Task Queue visar status för brandväggsgruppolicyer som tillämpas på brandväggar via Sophos Central. Man ser bland annat berörda grupper, brandväggar, status, administratör, entitet, sub-entitet och tidpunkt.

Vad är Firewall Task Queue?

Firewall Task Queue visar brandväggsuppgifter som kommer från MDR Settings, MDR IOCs eller Firewall Configuration API. Där är till exempel status, Credential ID, entitet, åtgärd och tidpunkt relevanta.

Får man hoppa över en misslyckad uppgift?

Ja, tekniskt kan man hoppa över vissa uppgifter. Operativt bör man bara göra det om det är klart vilken ändring som därmed inte tillämpades och hur den berörda brandväggen därefter kontrolleras.

När är Retry lämpligt?

Retry är lämpligt när orsaken till felet har åtgärdats. Exempel är en återställd Central-anslutning, en korrigerad licens, en rensad objektkonflikt eller ett tillfälligt fel som inte längre finns.

Ersätter Task Queue Log Viewer?

Nej. Task Queue visar om Central har bearbetat en ändring. Log Viewer visar lokala brandväggshändelser och är fortfarande nödvändig för trafik-, policy- och tjänsteanalys.