Sophos Central Kontrollera Firewall Management Task Queue

Om en ändring sparades i Sophos Central men inte kommer till Sophos Firewall, är den lokala brandväggen inte alltid den första felkällan. För centralt hanterade brandväggar bör du också kontrollera Tasks Queue i Sophos Central. Där kan du se om Central fortfarande har bearbetat en grupppolicy, en API-baserad brandväggsuppgift eller annan central ändring, delvis tillämpat den, hoppat över den eller avslutat den med ett fel.

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

Task Queue ersätter därför inte loggar, Packet Capture eller lokal kontroll på brandväggen. Den svarar först på transportfrågan: har Sophos Central accepterat, behandlat och tillämpat uppgiften på den berörda brandväggen eller gruppen? Först därefter är den egentliga brandväggsanalysen meningsfull.

När uppgiftskön är relevant

Uppgiftskön är relevant så snart ändringar inte görs direkt lokalt på brandväggen utan via Sophos Central. Detta påverkar särskilt miljöer där brandväggar är anslutna till Sophos Central och där central brandväggshantering används aktivt.

Typiska situationer:

• en grupppolicy ändrades till Sophos Central
• En förändring kom på vissa brandväggar, men inte på andra
• en firmware-uppdatering planerades eller startade via Sophos Central
• MDR eller API-baserade brandväggsuppgifter verkar inte vara helt implementerade
• en uppgift är på Pending eller In Progress under lång tid
• en uppgift är Failed, Skipped, Invalid license eller endast delvis lyckad
• efter ett fel bearbetas inte efterföljande ändringar som förväntat

Log Viewer-brandväggen är fortfarande viktig för lokal live-felsökning. Men uppgiftskön svarar på en annan fråga: Har Sophos Central lyckats få igenom ändringen till brandväggen?

Var hittar du uppgiftskön

Sophos Central-sökvägen är:

My Products > Firewall Management > Tasks Queue

Sophos skiljer mellan två flikar. Den uppdelningen är viktig för att inte blanda grupppolicyer med API-/MDR-uppgifter.

• Task Queue: status för brandväggsgrupppolicyer som tillämpas på brandväggar via Sophos Central.
• Firewall Task Queue: brandväggsuppgifter från MDR Settings, MDR IOCs och Firewall Configuration API. Vyn grupperar uppgifter bland annat efter Pending, In Progress, Failed, Partial Successful och Successful.

För klassiska problem med hantering av centrala brandväggar är uppgiftskön vanligtvis det första av intresse. Firewall Task Queue blir viktigare när ändringar utlöstes via Firewall Configuration API eller MDR-relaterade brandväggsfunktioner.

I uppgiftskövyn är historiken också viktig. Använd Show History för att visa slutförda eller överhoppade uppgifter för brandväggar eller grupper som sedan har tagits bort. För ändringsgranskningar eller supportärenden bör du fortfarande dokumentera relevant uppgiftsinformation omgående, eftersom Pending-uppgifter inte finns kvar permanent i gränssnittet efter en lång tidsperiod.

Vilken information är viktig

En enskild uppgift är bara användbar om den är organiserad på rätt sätt. Innan du gör en ändring eller en Retry bör du notera åtminstone dessa fält:

• Uppgiftsnummer
• Berörd grupp eller brandvägg
• Status
• timing
• Administratör eller ID
• Enhet och underenhet
• felmeddelande visas
• Antal framgångsrika och misslyckade brandväggar

Tidpunkten är inte alltid synonym med starten av bearbetningen på varje brandvägg. För grupppolicyer visar Sophos Central först skapandet eller ändringstiden och uppdaterar den senare när policyn tillämpas på brandväggar. Det är därför du inte bara ska titta på första gången efter längre utrullningar.

Källan till uppgiften är viktig för felsökning. Ett användarnamn är mer sannolikt att indikera en förändring i Sophos Central-portalen. Ett autentiserings-ID indikerar en API- eller MDR-relaterad beställning. I det här fallet bör du också kontrollera vilket system eller vilken process som utlöste ändringen.

Vid grupppolicyer spelar även gruppvyn roll: finns brandväggen verkligen i den förväntade gruppen eller undergruppen, har den ärvt en policy, eller lades den till med Skip full sync? En överhoppad full sync kan vara avsiktlig, men kan lätt skapa en skillnad mellan Central och den lokala brandväggen.

Om en brandvägg medvetet lades till med Skip full sync ska man inte blint utgå från en ren gruppbas. I Sophos Central kan en Force sync startas via brandväggens synkroniseringsstatus. För HA-par måste denna fullständiga synkronisering startas på den aktiva brandväggen, eftersom Sophos inte visar länken för passiva brandväggar.

Tolka status korrekt

• Pending: Uppgiften väntar fortfarande på att behandlas. Om varaktigheten är längre, kontrollera anslutning, licens och central anslutning.
• In Progress: Centralen bearbetar fortfarande uppgiften. Starta inte flera korrigeringar parallellt om uppgiften körs för närvarande.
• Success: Central rapporterar uppgiften som lyckad. Validera sedan fortfarande på brandväggen om den förväntade effekten är synlig.
• Partial Success: Vissa tillämpades, andra inte. Detta är särskilt viktigt för grupper eller flera objekt.
• Failed: Ändringen slutfördes inte. Dokumentera felmeddelandet och den berörda brandväggen.
• Skipped: Uppgiften hoppades över medvetet. Då krävs en professionell efterbesiktning.
• Invalid license: Licens eller auktorisering matchar inte den planerade åtgärden. Försök inte lösa detta genom att upprepa Retry.

Sophos Central kan automatiskt ta bort uppgifter med status Pending efter tre veckor. Relevanta fel bör därför säkerhetskopieras omgående för driftdokumentation, supportärenden eller ändringsgranskningar.

Success betyder bara att Sophos Central behandlade beställningen framgångsrikt. Det bevisar inte automatiskt att den önskade trafiken fungerar, att en regel verkligen matchar eller att en användare kan arbeta igen. För produktiva förändringar krävs alltid tre nivåer: kontrollera den centrala uppgiften, kontrollera den lokala brandväggskonfigurationen och testa den tekniska effekten.

Central-policy är inte automatiskt lokal sanning

För brandväggs- och NAT-regler som hanteras via Sophos Central finns en viktig operativ skillnad: positionen Top eller Bottom beskriver först ordningen inne i Central-policyn. På brandväggen infogas regler som skickas från Central högst upp i den lokala regellistan. Om lokala regler också finns kan den effektiva ordningen kännas annorlunda än väntat i Central-editorn.

Avanet rekommenderar därför ett tydligt operativt beslut för centralt hanterade brandväggar: antingen hanteras regler konsekvent via Sophos Central, eller så dokumenteras lokala undantag medvetet och kontrolleras efter varje Central-ändring. Blandad drift fungerar tekniskt, men är mer felkänslig eftersom Task Queue, lokal Rule ID, lokal NAT Rule ID och Audit Trail måste läsas tillsammans.

Ren testprocess

Om en central ändring blockeras, hjälper en tyst process mer än att upprepade gånger klicka på Retry.

1. Öppna Sophos Central My Products > Firewall Management > Tasks Queue.
2. Begränsa tidsperioden och berörd brandvägg eller brandväggsgrupp.
3. Öppna uppgiften och kontrollera de berörda brandväggarna.
4. Dokumentera status, felmeddelande, entity, sub-entity och tid.
5. För borttagna brandväggar eller grupper, aktivera Show History vid behov.
6. Kontrollera från vilken grupp eller undergrupp policyn kom.
7. Vid misstänkt gruppavvikelse, kontrollera synkroniseringsstatusen och besluta medvetet om Force sync är rimligt.
8. Kontrollera på brandväggen om ändringen är synlig eller bara finns i Central.
9. Vid brandväggs- eller NAT-regler, kontrollera lokal regelposition, Rule ID och NAT Rule ID.
10. Vid konfigurationsändringar, kontrollera även Audit Trail Logs.
11. Utvärdera Log Viewer, Policy Test och relevanta serviceloggar för trafikproblem.
12. Bestäm först då om Retry, Skip eller ett supportärende är rimligt.

Om det är oklart vilken lokal logg som är relevant, hjälper Sophos Firewall Felsökning: Services och loggar. För regel- och trafikanalys är Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture också lämplig.

Partial Success ren bearbetad

Partial Success är farligare än ett tydligt fel eftersom en del av miljön redan har ändrats. Med grupppolicyer bör du därför först öppna och koppla bort de berörda brandväggarna:

• Brandväggar med framgångsrik applikation
• Brandväggar med fel
• Brandväggar som är offline, ohanterliga eller blockerade av licens
• Brandväggar med olika SFOS versioner eller plattformar

Efteråt bör du inte omedelbart tillämpa samma ändring på hela gruppen igen. Det är bättre att göra en riktad korrigering av den berörda brandväggen eller gruppen, sedan en markerad Retry och sedan en jämförelse av den lokala brandväggskonfigurationen. För större ändringar hjälper Sophos Firewall Use Config Studio till att jämföra förväntade och faktiska konfigurationer på ett begripligt sätt.

Skip eller Retry?

Sophos Central erbjuder kampanjer Skip och Retry beroende på status. Båda är användbara, men ska inte ses som ren sanering.

• Retry: orsaken har lösts, till exempel anslutning, licens, objektkonflikt eller tillfälligt centralt fel Är det tydligt varför uppgiften misslyckades?
• Skip: en misslyckad eller inte längre relevant uppgift blockerar senare uppgifter och den tekniska effekten förstås Är detta medvetet inte att tillämpa en planerad policyändring?
• Vänta: uppgiften körs för närvarande eller Central bearbetar många brandväggar Finns det några tecken på verklig blockering eller bara normal fördröjning?
• Supportcase: felet uppstår upprepade gånger, påverkar flera produktiva brandväggar eller meddelandet är inte tydligt Är uppgiftsinformation, tid, brandväggsnamn och loggar säkra?

⚠️ Hoppa inte över en misslyckad uppgift bara för att få kön att se ren ut. Skip är ett operativt beslut: Den ändring som inte tillämpas måste sedan medvetet kontrolleras eller implementeras separat.

Inför en Retry bör du åtminstone kontrollera om brandväggen i Sophos Central är online, om Hantera från Sophos Central fortfarande är aktiv, om licens- och firmwareversionen matchar den planerade åtgärden och om den lokala brandväggen inte avvisar jobbet på grund av objekt, policy eller plattformsskillnader. Upprepad Retry utan rotorsakskontroll ger bara nya poster, men sällan klarhet.

Typiska felmönster

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

I det här fallet kontrollerar du först om den lämpliga uppgiften slutfördes framgångsrikt. Om uppgiften fortfarande är Pending, In Progress, Failed eller Partial Success, är problemet inte nödvändigtvis i den lokala brandväggsregeln. Först när Central rapporterar uppgiften som framgångsrik bör du gå djupare in på lokal policy, objekt eller logganalys.

Om uppgiften lyckas men den lokala brandväggen ser annorlunda ut bör du kontrollera om brandväggen verkligen är medlem i den förväntade gruppen, om en lokal förändring försvårar tolkningen och om du arbetar i rätt brandvägg eller i rätt klient. Denna banala check är förvånansvärt värdefull, speciellt när det finns flera Sophos Central-konton eller kontoöverföringar.

Den praktiska kontrollen är kort: skapa testtrafik, filtrera i Log Viewer efter source, destination och service och jämför faktisk Firewall Rule ID och NAT Rule ID med förväntad regel. Om dessa ID inte stämmer är Central-uppgiften inte det egentliga problemet; då ligger problemet i lokal regel- eller NAT-ordning.

Endast enskilda brandväggar i en grupp påverkas

Med grupprincip kan en ändring lyckas på flera brandväggar och misslyckas på en brandvägg. Då ska du inte ändra hela gruppen över hela linjen, utan hellre öppna 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 ordentligt

Om en Sophos Firewall Firmware Update planerades via Sophos Central, bör uppgiftskön vara en del av uppföljningen. Om brandväggen finns kvar på den gamla versionen, kontrollera först om Central utlöste och slutförde uppgiften. För större utgåvor är SFOS 22 Upgrade Check också en del av förberedelserna.

Synkronisering av webb- eller TLS-policy misslyckas

För webbskydd, URL-grupper eller TLS-uteslutningar kan en central synkronisering vara särskilt förvirrande eftersom Central har accepterat en ändring men brandväggen inte bearbetar den helt. Sedan bör du jämföra den berörda enheten från uppgiftskön med den lokala konfigurationen. För den tekniska klassificeringen är Sophos Firewall Infoga TLS Inspection korrekt och Sophos Firewall Skapa webbskyddspolicy lämpliga.

XGS 88/w och lokal TLS-uteslutningslista

Ett specifikt problem med XGS 88/w-modeller finns dokumenterat i listan över kända problem: När du synkroniserar en Sophos Central-policy kan bearbetningen av Lokal TLS-uteslutningslista misslyckas. Felmeddelandet som visas är för en URL-grupp som inte kunde uppdateras. I det här fallet kan du hoppa över den misslyckade transaktionen från uppgiftskön så att senare uppgifter fortsätter att köras.

I praktiken ska man dock inte bara gå vidare efteråt. En uppföljningskontroll är viktig:

• Finns det önskade TLS-undantaget lokalt på brandväggen?
• Är webb- och TLS-policyerna på brandväggen fortfarande tekniskt korrekta?
• 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ållsversion eller ett Sophos-meddelande för den berörda versionen?

Uppföljningskontroll av brandväggen

En framgångsrik central uppgift är en bra signal, men inte ett fullständigt drifttest. Beroende på ändringen bör du kontrollera lokalt:

• Är den ändrade regeln, policyn, listan eller firmwareversionen synlig?
• Visar Log Viewer förväntade händelser?
• Loggades ändringen i revisionsspåret?
• Är den centrala kopplingen och rapporteringen fortfarande aktiv?
• Fungerar berörda användare, VPN, webbåtkomst eller applikationer?

För säkerhetsrelevanta ändringar bör du också definiera en kort återställningspunkt. Detta gäller särskilt för webbskydd, TLS Inspection, brandväggsregler, VPN, HA-kluster och firmwareuppdateringar.

Operationell checklista

• Innan du gör ändringar via Sophos Central, klargör vilka brandväggar eller grupper som berörs.
• Kontrollera uppgiftskön efter centrala ändringar.
• Dokumentera misslyckade uppgifter med felmeddelande, tid och brandväggsnamn.
• Behandla inte Partial Success som komplett.
• För borttagna brandväggar eller grupper, kontrollera Show History.
• Vid Skip full sync eller gruppavvikelser, kontrollera om Force sync är tekniskt korrekt och säkert.
• Använd endast Retry efter att ha kontrollerat orsaken.
• Använd endast Skip om den tekniska påverkan är förstådd.
• Success validerat med lokalt test och logg- eller auditbevis.
• För API- eller MDR-uppgifter, tilldela autentiserings-ID och utlösande system.
• Planera underhållsfönster, säkerhetskopiering och lokal åtkomst för firmware-uppgifter.
• Vid upprepade fel, säkerhetskopiera Audit Trail, Log Viewer och Sophos Supportinformation.

Validera Success med ett testfall

Ett Success i Task Queue bör alltid kopplas till ett passande testfall. Annars vet man bara att Central har behandlat uppgiften, inte om den berörda funktionen faktiskt fungerar.

Praktisk validering:

• Firewall-regel ändrad: Skapa testtrafik med source, destination, service och förväntat Rule ID.
• NAT eller DNAT ändrad: Testa extern eller intern åtkomst och kontrollera Firewall Rule ID och NAT Rule ID i Log Viewer.
• Webb- eller TLS-policy ändrad: Jämför testklient, måldomän, webblogg och SSL/TLS-inspection-logg.
• VPN- eller Remote Access-ändring: Kontrollera inloggning, pool-IP, intern åtkomst och användarmappning.
• Firmware- eller backupuppgift: Kontrollera version, bootstatus, HA-roll, Central-anslutning och senaste backup.
• MDR-, ATR- eller API-uppgift: Dokumentera Credential ID, utlösande system, lokal synlighet och förväntad logghändelse.

För change reviews räcker ett kort underlag: uppgiftsstatus, berörd firewall, lokalt test, logg- eller auditbevis och öppen punkt. Det hindrar att en lyckad Central-uppgift senare misstolkas som fullständig teknisk acceptans.

Vanliga frågor