Sophos Central Controleer de takenwachtrij voor firewallbeheer

Als een wijziging is opgeslagen in Sophos Central maar niet aankomt op de Sophos Firewall, is de lokale firewall niet altijd de eerste bron van fouten. Voor centraal beheerde firewalls moet u ook de Takenwachtrij in Sophos Central controleren. Daar kunt u zien of Central een groepsbeleid, een API-gebaseerde firewalltaak of een andere centrale wijziging nog heeft verwerkt, gedeeltelijk heeft toegepast, overgeslagen of met een fout heeft beëindigd.

Dit is vooral belangrijk wanneer meerdere firewalls in een groep worden beheerd. Eén enkele mislukte taak kan daaropvolgende wijzigingen vertragen of het oplossen van problemen verwarren, omdat de configuratie op Sophos Central er anders uitziet dan op de getroffen firewall.

De Task Queue vervangt dus geen logs, Packet Capture of lokale visuele controle. De wachtrij beantwoordt eerst de transportvraag: heeft Sophos Central de opdracht geaccepteerd, verwerkt en toegepast op de betreffende firewall of groep? Pas daarna heeft de eigenlijke firewallanalyse zin.

Wanneer de takenwachtrij relevant is

De takenwachtrij is relevant zodra wijzigingen niet direct lokaal op de firewall worden uitgevoerd, maar via Sophos Central. Dit heeft vooral gevolgen voor omgevingen waarin firewalls zijn aangesloten op Sophos Central en Centraal Firewallbeheer actief wordt gebruikt.

Typische situaties:

• er is een groepsbeleid gewijzigd in Sophos Central
• er is een verandering doorgevoerd op sommige firewalls, maar niet op andere
• er is een firmware-update gepland of gestart via Sophos Central
• MDR of API-gebaseerde firewalltaken lijken niet volledig geïmplementeerd
• een taak staat al langere tijd op Pending of In Progress
• een taak is Failed, Skipped, Invalid license of slechts gedeeltelijk succesvol
• na een fout worden daaropvolgende wijzigingen niet verwerkt zoals verwacht

De Log Viewer-firewall blijft belangrijk voor lokale live probleemoplossing. Maar de takenwachtrij beantwoordt nog een vraag: heeft Sophos Central de wijziging met succes doorgestuurd naar de firewall?

Waar u de takenwachtrij kunt vinden

Het Sophos Central-pad is:

My Products > Firewall Management > Tasks Queue

Sophos maakt onderscheid tussen twee tabbladen. Die scheiding is belangrijk, omdat groepsbeleid en API-/MDR-opdrachten anders door elkaar lopen.

• Task Queue: status van firewallgroepsbeleid dat via Sophos Central op firewalls wordt toegepast.
• Firewall Task Queue: firewalltaken uit MDR Settings, MDR IOCs en Firewall Configuration API. De weergave groepeert taken onder andere op Pending, In Progress, Failed, Partial Successful en Successful.

Voor klassieke Central Firewall Management-problemen is de Task Queue meestal de eerste plaats om te kijken. De Firewall Task Queue wordt belangrijker wanneer wijzigingen via de Firewall Configuration API of MDR-gerelateerde firewallfuncties zijn gestart.

In de taakwachtrijweergave is de geschiedenis ook belangrijk. Gebruik Show History om voltooide of overgeslagen taken weer te geven voor firewalls of groepen die sindsdien zijn verwijderd. Voor wijzigingsbeoordelingen of ondersteuningsgevallen moet u relevante taakdetails nog steeds onmiddellijk documenteren, omdat Pending-taken na een lange periode niet permanent in de interface blijven staan.

Welke informatie is belangrijk

Een enkele taak heeft alleen zin als deze goed is georganiseerd. Voordat u een wijziging aanbrengt in een Retry, moet u in ieder geval deze velden noteren:

• Taaknummer
• getroffen groep of firewall
• Status
• timing
• Beheerder of referentie-ID
• Entiteit en subentiteit
• foutmelding weergegeven
• Aantal succesvolle en mislukte firewalls

De timing is niet altijd synoniem met het begin van de verwerking op elke firewall. Voor groepsbeleid toont Sophos Central eerst de aanmaak- of wijzigingstijd en werkt deze later bij wanneer het beleid wordt toegepast op firewalls. Daarom moet je bij langere uitrol niet alleen naar de eerste keer kijken.

De bron van de taak is belangrijk voor het oplossen van problemen. Het is waarschijnlijker dat een gebruikersnaam een ​​wijziging in het Sophos Central-portaal aangeeft. Een inloggegevens-ID geeft een API- of MDR-gerelateerde bestelling aan. In dit geval moet u ook controleren welk systeem of proces de wijziging heeft veroorzaakt.

Bij groepsbeleid telt ook de groepsweergave: staat de firewall echt in de verwachte groep of subgroep, is er beleid geërfd, of is de firewall met Skip full sync aan een groep toegevoegd? Een overgeslagen full sync kan bewust zijn, maar kan gemakkelijk een afwijking tussen Central en de lokale firewall veroorzaken.

Als een firewall bewust met Skip full sync is toegevoegd, mag men niet blind uitgaan van een schone groepsbasis. In Sophos Central kan via de synchronisatiestatus van de firewall een Force sync worden gestart. Bij HA-paren moet deze volledige synchronisatie op de actieve firewall worden gestart, omdat Sophos de link voor passieve firewalls niet toont.

Interpreteer de status correct

• Pending: De taak wacht nog op verwerking. Als de duur langer is, controleer dan de connectiviteit, licentie en centrale verbinding.
• In Progress: Central is nog steeds bezig met het verwerken van de taak. Start niet meerdere correcties tegelijk als de taak momenteel wordt uitgevoerd.
• Success: Centraal rapporteert de taak als succesvol. Valideer vervolgens nog op de firewall of het verwachte effect zichtbaar is.
• Partial Success: Sommige werden toegepast, andere niet. Dit is vooral belangrijk voor groepen of meerdere objecten.
• Failed: De wijziging is niet succesvol voltooid. Documenteer de foutmelding en de getroffen firewall.
• Skipped: De taak is bewust overgeslagen. Een professionele vervolginspectie is dan noodzakelijk.
• Invalid license: Licentie of autorisatie komt niet overeen met de geplande actie. Probeer dit niet op te lossen door Retry te herhalen.

Sophos Central kan na drie weken automatisch taken met status Pending verwijderen. Er moet daarom onmiddellijk een back-up worden gemaakt van relevante fouten voor operationele documentatie, ondersteuningsgevallen of wijzigingsbeoordelingen.

Success betekent alleen dat Sophos Central de bestelling succesvol heeft verwerkt. Het bewijst niet automatisch dat het gewenste verkeer werkt, dat een regel echt overeenkomt, of dat een gebruiker weer kan werken. Voor productieve veranderingen zijn altijd drie niveaus nodig: het controleren van de centrale taak, het controleren van de lokale firewallconfiguratie en het testen van het technische effect.

Central-policy is niet automatisch lokale waarheid

Bij firewall- en NAT-regels via Sophos Central is er een belangrijk operationeel verschil: de positie Top of Bottom beschrijft eerst de volgorde binnen de Central-policy. Op de firewall worden vanuit Central gepushte regels bovenaan de lokale regellijst ingevoegd. Als er tegelijk lokale regels bestaan, kan de effectieve volgorde anders aanvoelen dan verwacht in de Central-editor.

Avanet raadt daarom aan bij centraal beheerde firewalls een duidelijke operationele keuze te maken: regels consequent via Sophos Central beheren, of lokale uitzonderingen bewust documenteren en na elke Central-wijziging controleren. Gemengd beheer werkt technisch, maar is foutgevoeliger omdat Task Queue, lokale Rule ID, lokale NAT Rule ID en Audit Trail samen moeten worden gelezen.

Voor troubleshooting betekent dit: een succesvolle Central-taak verklaart alleen dat de policy is verspreid. Of de regel op de juiste plaats werkt, moet lokaal in de regels en daarna in Log Viewer worden gecontroleerd.

Schoon testproces

Bij een geblokkeerde Central-wijziging helpt een rustige procedure meer dan herhaald op Retry klikken.

1. In Sophos Central My Products > Firewall Management > Tasks Queue openen.
2. Periode en betrokken firewall of firewallgroep beperken.
3. Taak openklappen en betrokken firewalls controleren.
4. Status, foutmelding, entity, sub-entity en tijd documenteren.
5. Bij verwijderde firewalls of groepen indien nodig Show History activeren.
6. Bij groepsbeleid controleren of de firewall in de juiste groep of subgroep staat.
7. Bij vermoeden van groepsafwijking de synchronisatiestatus controleren en bewust beslissen of Force sync zinvol is.
8. Op de firewall controleren of de wijziging zichtbaar is of alleen in Central is opgeslagen.
9. Bij firewall- of NAT-regels de lokale regelpositie, Rule ID en NAT Rule ID controleren.
10. Bij configuratiewijzigingen ook Audit Trail Logs controleren.
11. Bij verkeersproblemen Log Viewer, Policy Test en relevante servicelogs evalueren.
12. Pas daarna beslissen of Retry, Skip of een supportcase zinvol is.

Als onduidelijk is welk lokaal log relevant is, helpt Sophos Firewall troubleshooting: services en logs bij de oriëntatie. Voor regel- en verkeersanalyse is ook firewallregels testen met Log Viewer, Policy Test en Packet Capture nuttig.

Partial Success netjes verwerkt

Partial Success is gevaarlijker dan een duidelijke fout omdat een deel van de omgeving al is gewijzigd. Bij groepsbeleid moet u daarom eerst de getroffen firewalls openen en ontkoppelen:

• Firewalls met succesvolle toepassing
• Firewalls met fouten
• Firewalls die offline, onbeheersbaar of geblokkeerd zijn door een licentie
• Firewalls met verschillende SFOS-versie of platform

Daarna mag u dezelfde wijziging niet meteen opnieuw toepassen op de hele groep. Het is beter om een ​​gerichte correctie uit te voeren op de getroffen firewall of groep, vervolgens een gecontroleerde Retry en vervolgens een vergelijking van de lokale firewallconfiguratie. Voor grotere wijzigingen helpt Sophos Firewall Use Config Studio om verwachte en werkelijke configuraties op een begrijpelijke manier te vergelijken.

Skip of Retry?

Sophos Central biedt promoties Skip en Retry afhankelijk van de status. Beide zijn nuttig, maar mogen niet als pure opruiming worden gezien.

• Retry: de oorzaak is verholpen, bijvoorbeeld verbinding, licentie, objectconflict of tijdelijke centrale storing Is het duidelijk waarom de taak is mislukt?
• Skip: een mislukte of niet langer relevante taak blokkeert latere taken en de technische impact wordt begrepen Is hier sprake van het bewust niet toepassen van een geplande beleidswijziging?
• Wacht: de taak wordt momenteel uitgevoerd of Central verwerkt veel firewalls Is er enig bewijs van echte blokkering of gewoon normale vertraging?
• Ondersteuningsgeval: de fout treedt herhaaldelijk op, treft meerdere productieve firewalls of de boodschap is niet duidelijk Zijn taakdetails, tijd, firewallnaam en logbestanden beveiligd?

⚠️ Sla een mislukte taak niet over, alleen maar om de wachtrij er schoon uit te laten zien. Skip is een operationele beslissing: de wijziging die niet wordt doorgevoerd, moet dan bewust worden gecontroleerd of afzonderlijk worden geïmplementeerd.

Voordat u een Retry uitvoert, moet u in ieder geval controleren of de firewall in Sophos Central online is, of Beheren vanuit Sophos Central nog actief is, of de licentie en firmwareversie overeenkomen met de geplande actie en of de lokale firewall de taak niet afwijst vanwege object-, beleids- of platformverschillen. Herhaalde Retry zonder controle op de hoofdoorzaak levert alleen nieuwe gegevens op, maar zelden duidelijkheid.

Typische foutpatronen

Wijziging is zichtbaar in Central, maar niet in de firewall

Controleer in dit geval eerst of de betreffende taak met succes is voltooid. Als de taak nog steeds Pending, In Progress, Failed of Partial Success is, ligt het probleem niet noodzakelijkerwijs in de lokale firewallregel. Alleen wanneer Central de taak als succesvol rapporteert, moet u dieper ingaan op de lokale beleids-, object- of loganalyse.

Als de taak succesvol is maar de lokale firewall er anders uitziet, moet u controleren of de firewall echt lid is van de verwachte groep, of een lokale wijziging de interpretatie bemoeilijkt en of u in de juiste firewall of in de juiste client werkt. Deze banale controle is verrassend waardevol, vooral als er meerdere Sophos Central-accounts of accountoverdrachten zijn.

Regel werkt na Success anders dan verwacht

Bij firewall- en NAT-regels moet na een succesvolle taak niet alleen worden gecontroleerd of de regel bestaat. Beslissend is of deze in de lokale volgorde vóór of na relevante bestaande regels staat. Central kan de policy correct hebben gepusht, terwijl een lokale uitzonderingsregel, een eerdere Central-regel of een NAT-regel toch de verwachte match verandert.

De praktische controle is kort: testverkeer genereren, in Log Viewer filteren op source, destination en service, en de werkelijke Firewall Rule ID en NAT Rule ID vergelijken met de verwachte regel. Als deze IDs niet kloppen, is de Central-taak niet het eigenlijke probleem, maar de lokale regel- of NAT-volgorde.

Alleen individuele firewalls in een groep worden getroffen

Met Groepsbeleid kan een wijziging slagen op meerdere firewalls en mislukken op één firewall. Dan moet je niet de hele groep over de hele linie veranderen, maar eerder de getroffen firewall openen en de verschillen controleren: licentie, firmwareversie, centrale verbinding, lokale objectconflicten, platform en bekende problemen.

Firmware-taak via Central start niet correct

Als er een Sophos Firewall Firmware Update was gepland via Sophos Central, zou de takenwachtrij deel moeten uitmaken van de follow-up. Als de firewall op de oude versie blijft staan, controleer dan eerst of Central de taak heeft geactiveerd en voltooid. Voor grote releases maakt de SFOS 22 Upgrade Check ook deel uit van de voorbereiding.

Synchronisatie van web- of TLS-beleid mislukt

Voor webbeveiliging, URL-groepen of TLS-uitsluitingen kan een centrale synchronisatie bijzonder verwarrend zijn, omdat Central een wijziging heeft geaccepteerd, maar de firewall deze niet volledig verwerkt. Vervolgens moet u de getroffen entiteit uit de takenwachtrij vergelijken met de lokale configuratie. Voor de technische classificatie zijn Sophos Firewall TLS Inspection correct invoegen en Sophos Firewall Webbeschermingsbeleid maken geschikt.

XGS 88/w en lokale TLS-uitsluitingslijst

Een specifiek probleem met XGS 88/w-modellen is gedocumenteerd in de lijst met bekende problemen: bij het synchroniseren van een Sophos Central-beleid kan het verwerken van de Lokale TLS-uitsluitingslijst mislukken. Het weergegeven foutbericht heeft betrekking op een URL-groep die niet kon worden bijgewerkt. In dit geval kunt u de mislukte transactie uit de takenwachtrij overslaan, zodat latere taken kunnen worden uitgevoerd.

In de praktijk moet je daarna echter niet zomaar verder. Een vervolgcontrole is belangrijk:

• Is de gewenste TLS-uitzondering lokaal aanwezig op de firewall?
• Zijn het web- en TLS-beleid op de firewall technisch nog correct?
• Betreft het probleem slechts één XGS 88/w of meerdere firewalls?
• Moet de wijziging tijdelijk lokaal worden doorgevoerd of uitgesteld?
• Is er een onderhoudsrelease of een Sophos-kennisgeving voor de getroffen versie?

Vervolgcontrole op de firewall

Een succesvolle centrale taak is een goed signaal, maar geen volledige operationele test. Afhankelijk van de wijziging dient u lokaal het volgende te controleren:

• Is de gewijzigde regel, beleid, lijst of firmwareversie zichtbaar?
• Toont de Log Viewer verwachte gebeurtenissen?
• Is de wijziging vastgelegd in de audit trail?
• Zijn de centrale verbinding en rapportage nog actief?
• Werken de getroffen gebruikers, VPN’s, webtoegang of applicaties?

Voor beveiligingsrelevante wijzigingen moet u ook een kort terugdraaipunt definiëren. Dit geldt met name voor webbeveiliging, TLS Inspection, firewallregels, VPN, HA-clusters en firmware-updates.

Success met een testscenario valideren

Een Success in de Task Queue moet altijd aan een passend testscenario worden gekoppeld. Anders weet men alleen dat Central de taak heeft verwerkt, maar niet of de betreffende functie echt werkt.

Praktische validatie:

• Firewallregel gewijzigd: Genereer testverkeer met source, destination, service en de verwachte Rule ID.
• NAT of DNAT gewijzigd: Test externe of interne toegang en controleer Firewall Rule ID en NAT Rule ID in Log Viewer.
• Web- of TLS-policy gewijzigd: Vergelijk testclient, doeldomein, web-log en SSL/TLS-inspection-log.
• VPN- of Remote Access-wijziging: Controleer aanmelding, pool-IP, interne bereikbaarheid en gebruikerskoppeling.
• Firmware- of backuptaak: Controleer versie, bootstatus, HA-rol, Central-verbinding en laatste backuptijdstip.
• MDR-, ATR- of API-taak: Documenteer Credential ID, activerend systeem, lokale zichtbaarheid en verwacht logevent.

Voor change reviews volstaat een kort bewijs: taakstatus, betrokken firewall, lokale test, log- of auditbewijs en open punt. Zo wordt een succesvolle Central-taak later niet ten onrechte gezien als volledige technische acceptatie.

Operationele checklist

• Voordat u wijzigingen aanbrengt via Sophos Central, moet u duidelijk maken om welke firewalls of groepen het gaat.
• Controleer de takenwachtrij na centrale wijzigingen.
• Documenteer mislukte taken met foutmelding, tijd en firewallnaam.
• Beschouw Partial Success niet als compleet.
• Voor verwijderde firewalls of groepen, vink Show History aan.
• Gebruik Retry alleen nadat u de oorzaak hebt gecontroleerd.
• Gebruik Skip alleen als de technische impact duidelijk is.
• Success gevalideerd met een lokale test en log- of auditbewijs.
• Wijs voor API- of MDR-taken de identificatie-ID en het triggersysteem toe.
• Plan onderhoudsvensters, back-up en lokale toegang voor firmwaretaken.
• Maak in geval van herhaalde fouten een back-up van Audit Trail-, Log Viewer- en Sophos Support-informatie.

Veelgestelde vragen