Kontrollera Sophos Firewall före uppgradering till SFOS 22

SFOS 22 medför viktiga arkitekturförändringar i Sophos Firewall. För administratörer är det därför inte bara intressant vilka nya funktioner som blir tillgängliga efter uppdateringen. Viktigare är först frågan om den egna brandväggen kan uppdateras till SFOS 22 utan problem.

Denna guide fungerar som en kontroll före uppgradering. Artikeln ersätter inte den allmänna guiden för Sophos Firewall Firmware Update, utan kompletterar den med punkter som särskilt snabbt kan leda till problem med SFOS 22: stödd plattform, gränssnittnamn, lagringsutrymme, säkerhetskopiering, HA-status, Legacy Remote Access IPsec, policy-baserad IPsec, NAT och återställningsplan.

Videoguide

Kort sagt: Uppgraderingen bör först startas när plattform, uppgraderingsväg, backup, lagringsutrymme, HA-tillstånd, VPN-beroenden och en återgångsväg är skriftligt klargjorda. Om någon av dessa punkter är oklar är underhållsfönstret oftast planerat för tidigt.

Före underhållsfönstret måste framför allt dessa områden vara klara:

• Plattform: XGS, virtuell, software eller Cloud Deployment i stället för XG/SG-hårdvara.
• Firmwareväg: Kontrollera utgångsversion och direkt uppgraderingsväg mot Release Notes.
• Konfiguration: Säkra backup, Secure Storage Master Key och åtkomst utanför den normala VPN-vägen.
• Nätverk: Dokumentera Interface-namn, policy-based IPsec, NAT och kritiska testflöden.
• Drift: Förbered HA-status, STAS, Central Management, loggar och rollback-beslut.

När denna kontroll är användbar

Kontrollen bör utföras före varje planerad uppgradering till SFOS 22 eller högre. Den är särskilt viktig om någon av följande situationer gäller:

• brandväggen körs fortfarande på XG- eller SG-hårdvara
• enheten har redan uppdaterats över flera större versioner
• det finns många VLAN, alias, bryggor, LAGs, RED- eller XFRM-gränssnitt
• det handlar om en liten skrivbordsapplikation, virtuell brandvägg eller mjukvaruapplikation
• brandväggen körs i ett HA-kluster
• Remote Access IPsec VPN används eller har använts tidigare
• UTM9 SSL VPN-tunnlar eller gamla RED 15, RED 15w eller RED 50-enheter finns fortfarande
• policy-baserad Site-to-Site IPsec, speciella SNAT-regler eller VPN-NAT-regler används
• STAS eller annan användarbaserad autentisering styr produktiva brandväggsregler
• brandväggen hanteras via Sophos Central eller ska uppdateras därigenom
• bryggor med VLAN-taggar som satts manuellt via CLI eller VLAN-trafik till själva brandväggen används

Om brandväggen redan är instabil i vardagen, tjänster regelbundet måste startas om eller partitioner är kraftigt fyllda, bör uppgraderingen inte ses som ett reparationsförsök. I detta fall stabilisera först det aktuella tillståndet och klargör orsaken.

1. Kontrollera plattform och uppgraderingsväg

SFOS 22.0 och senare versioner stöder inte längre XG- och SG-hårdvaruenheter. De som fortfarande använder sådana enheter måste först planera migreringen till XGS, virtuell brandvägg, mjukvaruapplikation eller molndistribution. För beslutet mellan gamla och nya hårdvarugenerationer hjälper artikeln Vad är skillnaden mellan en XG och XGS Firewall?.

På stödda plattformar bör man dessutom kontrollera från vilken version uppdateringen sker. SFOS 22 Release Notes visar vilka versioner som kan migreras direkt till SFOS 22. Om en icke-stödd väg väljs kan brandväggen starta med fabriksinställningar efter bekräftelse. Just denna risk måste uteslutas före ett underhållsfönster.

Praktiskt förfarande:

1. Notera aktuell firmwareversion under Backup & Firmware > Firmware.
2. Dokumentera modell, serienummer och plattformstyp.
3. Kontrollera i de officiella Sophos Release Notes om den direkta uppgraderingsvägen stöds.
4. Behandla inte längre SFOS-22-planering som en vanlig uppdatering för XG- eller SG-hårdvara, utan som ett migrationsprojekt.

Vid migreringar till XGS, virtuella eller cloud-appliances är backup/restore ofta en del av projektet. Backuper från stödda källversioner kan migreras till andra plattformar; med nyare backuper stöder Sophos restore med en assistent för interface-mappning. Det ersätter inte migreringsplanering, men är viktigt så att XG/SG-ersättning inte förväxlas med en in-place upgrade.

2. Kontrollera gränssnittnamn före uppgradering

En lätt förbisedd uppgraderingspunkt gäller namnen på gränssnitt. Fysiska eller logiska gränssnitt kan i WebAdmin-vyn under Network > Interfaces vara osynliga eller inte möjliga att expandera om ett gränssnittnamn, hårdvarunamn eller filialnamn slutar med tio eller fler siffror.

Detta är obehagligt eftersom trafiken kan fortsätta bearbetas, men administrationen i WebAdmin plötsligt ser ut som om gränssnitt saknas. Särskilt vid migrationer, automatiserade namnscheman, importerade konfigurationer eller VLAN-namn med plats-, kund- eller inventarienummer bör man kontrollera denna punkt före uppgraderingen.

Kritiska exempel:

• VLAN_1234567890: slutar med tio siffror.
• Branch_1000000001: filialnamn kan störa visningen.
• PortA_2026010101: avsett att vara beskrivande, men riskabelt sifferavslut.

Praktiskt förfarande:

1. Öppna Network > Interfaces.
2. Kontrollera fysiska gränssnitt, VLAN, alias, bryggor, LAGs, RED-gränssnitt och XFRM-gränssnitt.
3. Sök efter namn som slutar med tio eller fler siffror.
4. Ändra berörda namn till en kortare eller tydligt åtskild skrivning före uppgraderingen.
5. Efter ändringen, kontrollera om brandväggsregler, NAT-regler, SD-WAN-rutter, DHCP, VPN och dokumentation fortfarande är begripliga.

Bättre är namn där siffror inte står som ett långt block i slutet. Istället för VLAN_1234567890 är till exempel VLAN-1234567890-Client eller ett fackligt namn som Client-VLAN-100 mer läsbart och operativt robust.

Om gränssnitt saknas i WebAdmin-vyn efter en uppgradering, bör man inte omedelbart anta att nätverkskonfigurationen är förlorad. Först kontrollera om beteendet passar in på gränssnittnamnsproblematiken, om trafiken fortfarande fungerar och om de berörda namnen behöver justeras. För den generella gränssnittsplaneringen passar Konfigurera Sophos Firewall-zoner och gränssnitt.

3. Kontrollera legacy-beroenden

Vid uppgradering från äldre SFOS-versioner mot version 22 är det lätt att missa anmärkningarna från SFOS 21.5. Det är riskabelt, eftersom vissa begränsningar gäller redan från 21.5 GA och därför också påverkar uppgraderingsvägen till SFOS 22.

Före underhållsfönstret bör dessa legacy-beroenden antingen uteslutas eller migreras medvetet:

• UTM9 SSL VPN: Firewalls från 21.5 GA etablerar inte längre SSL VPN-tunnlar till UTM9 OS. Sådana anslutningar bör migreras till SFOS 20.0 MR1 eller senare, Site-to-Site IPsec eller RED.
• RED 15, RED 15w och RED 50: Dessa legacy RED-enheter stöds inte längre från 21.5 GA. Om platser fortfarande är beroende av dem bör ersättningen ske före firewall-uppgraderingen.
• Legacy Remote Access IPsec: Från SFOS 22.0 MR1 blockerar denna gamla Remote Access IPsec-konfiguration uppgraderingen. Denna punkt kontrolleras separat nedan.

Dessa beroenden är inte bara “gamla enheter i inventariet”. De avgör om filialer, fjärranvändare eller övergångsanslutningar fortfarande kan nås efter uppgraderingen. För RED- eller UTM9-beroenden bör en separat migrationsplan finnas före SFOS 22-fönstret.

4. Kontrollera lagringsutrymme och firmwaremeddelanden

SFOS 22 kräver ytterligare lagringsutrymme för nya funktioner och arkitekturförändringar. De flesta enheter uppfyller kraven, men vissa skrivbords-, virtuella och mjukvarudistributioner kan behöva en manuell kontroll eller korrigering. Om brandväggen på Control Center- eller Firmware-sidan visar ett meddelande om lagringsutrymmeskrav bör detta inte ignoreras.

För virtuella och softwarebaserade firewalls bör man kontrollera extra noggrant om den tilldelade virtuella disken och root- respektive primary-partitionen passar för den planerade SFOS-22-uppgraderingen. Sophos beskriver separata anvisningar om SFOS-22-lagringskravet och utökning av virtuella diskar i supportartiklarna KBA-000010091 och KBA-000043681. Dessa länkar är meningsfulla om en virtuell disk faktiskt måste anpassas; ändringen bör dock inte improviseras spontant i firmwarefönstret.

Via SSH kan man grovt kontrollera partitionernas fyllnadsgrad:

df -kh

Utdata ersätter inte en Sophos-kompatibilitetskontroll, men hjälper till att bedöma om /, /var, /content eller andra partitioner är anmärkningsvärt fulla. Om en partition är mycket knapp bör man inte bara blint uppdatera. Först klargöra vilka data som finns där, om loggar eller gamla filer kan rensas och om det finns en Sophos-anmärkning för den berörda enheten.

Viktigt är också tidsplaneringen: Om brandväggen under uppgraderingen måste anpassa partitioner kan uppdateringen ta längre tid än en vanlig underhållsuppdatering. Underhållsfönstret bör därför inte planeras för snävt.

Om en virtuell disk måste utökas ska backup, Secure Storage Master Key, Hypervisor-snapshot-strategi, Datastore-kapacitet och återgångsväg klargöras först. Efter anpassningen bör man kontrollera partitionerna igen och först därefter upprepa SFOS-22-uppgraderingsförsöket. För allmän lagringsanalys passar Kontrollera Sophos Firewall-lagringsutrymme och hantera rapporter.

5. Förbered säkerhetskopiering och återställning

Före uppgraderingen behövs en färsk säkerhetskopiering. Det låter banalt, men är avgörande vid större versioner. Säkerhetskopieringen bör inte bara skapas, utan också vara lätt att hitta, dekryptera och tilldela en specifik enhet. Artikeln Skapa eller återställa Sophos Firewall-säkerhetskopiering förklarar de viktigaste punkterna kring säkerhetskopiering, återställning och Secure Storage Master Key.

Före SFOS 22 bör minst dessa punkter vara klara:

• skapa aktuell konfigurationssäkerhetskopiering och spara externt
• dokumentera Secure Storage Master Key om krypterade säkerhetskopior används
• kontrollera administratörsåtkomst lokalt och via underhållsnätverket
• kontrollera licensstatus och Sophos Central-åtkomst
• ha aktuell firmwarebild och mål-firmware tillgänglig
• definiera återställningsbeslut: när ska man vänta, när ska man återställa

Vid kritiska platser bör det dessutom vara klart vem som har tillgång till enheten på plats och hur man vid behov skulle genomföra en ominstallation. Nyinstallation är ett annat förfarande än en vanlig firmwareuppdatering. För detta finns den separata guiden Installera om Sophos Firewall OS.

6. Fastställ Go/No-Go före underhållsfönstret

En SFOS-22-uppgradering bör inte beslutas först under underhållsfönstret. Det måste vara klart i förväg under vilka förhållanden man startar, väntar, avbryter eller återställer. Detta minskar hektiska beslut när brandväggen tar längre tid, en HA-nod inte synkroniserar eller en kritisk tjänst inte fungerar efter omstart.

Meningsfulla Go/No-Go-punkter:

• Plattform stöder SFOS 22: Go om modell och uppgraderingsväg är kontrollerade. No-Go vid XG/SG-hårdvara eller oklar uppgraderingsväg.
• Backup och SSMK: Go om backup är sparad externt och restore-data är tillgängliga. No-Go om backup saknas, inte går att hitta eller Secure Storage Master Key saknas.
• Remote Access IPsec: Go om Legacy-konfiguration är utesluten eller migrerad. No-Go om Legacy-konfiguration finns eller är oklar.
• Legacy-platser: Go om UTM9 SSL VPN och gamla RED-enheter är uteslutna eller ersatta. No-Go om ett filialkontor fortfarande är produktivt beroende av dem.
• Site-to-Site IPsec: Go om policy-based IPsec, NAT och testtrafik är dokumenterade. No-Go om Traffic Selectors, SNAT eller motpart är oklara.
• Bridge VLANs: Go om bridge-VLAN-trafik till själva brandväggen har kontrollerats eller modellerats rent via VLAN-gränssnitt. No-Go om AD, DNS, Device Access eller STAS går via oklara bridge-CLI-VLAN-taggar.
• HA-status: Go om klustret är stabilt och synkroniserat. No-Go vid degraded, osynkroniserat eller oklart HA-tillstånd.
• Åtkomst: Go om lokal adminåtkomst och underhållsnät är kontrollerade. No-Go om åtkomst bara beror på en osäker Remote-väg.
• Rollback: Go om beslutspunkt och ansvariga är definierade. No-Go om ingen beslutar bindande om att vänta eller rulla tillbaka.

För distribuerade platser bör det dessutom vara klart vem som är tillgänglig under underhållsfönstret: teknisk kontaktperson, platskontakt, person med fysisk åtkomst och beslutsfattare för återställning. Om uppgraderingen utförs på distans bör man dessutom kontrollera om alternativ åtkomst finns, om VPN, WAN eller Central Management tillfälligt inte fungerar.

En återställningsplan är ingen svaghet i förändringen. Den förhindrar att firmware, routing, VPN, HA och switching ändras samtidigt vid en störning. Om en kritisk tjänst faller bort efter uppgraderingen bör man först arbeta igenom den definierade valideringsplanen. Först därefter beslutas om en återställning, en återställning, en ominstallation eller en riktad felsökning är mer lämplig.

7. Förbered HA-kluster noggrant

Vid HA-kluster får man inte bara betrakta den aktiva brandväggen. Båda noderna måste stödjas, ha samma meningsfulla utgångsläge och synkronisera rent. En uppgradering på ett redan svagt HA-kluster ökar risken för onödiga avbrott.

Före underhållsfönstret kontrollera:

• System services > High availability visar en hälsosam HA-status.
• Båda enheterna är samma modell eller en stödd HA-kombination.
• Firmwarestatus, licensstatus och prenumeration är rimliga.
• HA-länk, övervakade portar och anslutna switchportar är stabila.
• Det är dokumenterat vilken enhet som var aktiv före uppgraderingen.

För den generella HA-planeringen och särdragen hos Active-Passive, Active-Active, licensiering och underhåll passar artikeln Sophos Firewall HA-kluster varianter.

8. Sök efter Legacy Remote Access IPsec

Från och med SFOS 22.0 MR1 stöds inte längre Legacy Remote Access IPsec VPN. Brandväggar med denna Legacy-konfiguration kan inte uppdateras till SFOS 22.0 MR1 eller senare. Detta är en typisk uppgraderingsblockerare eftersom Remote Access IPsec i äldre miljöer ofta en gång har konfigurerats och sedan länge inte har rörts.

Före uppgraderingen bör man därför kontrollera om gamla Remote Access IPsec-konfigurationer finns. Om så är fallet måste man först migrera till den aktuella Remote Access IPsec-konfigurationen, SSL VPN, ZTNA eller en annan lämplig Remote Access-design. Den konkreta processen finns i Migrera Legacy Remote Access IPsec före SFOS 22 MR1. För allmän IPsec-felsökning hjälper dessutom Sophos Firewall IPsec VPN Troubleshooting.

Praktiskt förfarande:

1. Öppna området Remote access VPN i WebAdmin.
2. Kontrollera om en Legacy Remote Access IPsec-konfiguration finns.
3. Dokumentera berörda användare, profiler, pooler, autentisering och distribuerade Sophos Connect-konfigurationer.
4. Planera ersättningskonfiguration och testa med några få testanvändare.
5. Ta bort Legacy-konfigurationen först efter lyckad migrering och kontrollera firmwareuppgraderingen igen.

Om Sophos Connect används bör även de befintliga instruktionerna för Sophos Connect Firewall-konfiguration, Windows-installation och macOS-installation inkluderas.

9. Kontrollera policy-baserad IPsec och NAT

SFOS 22.0 GA och senare versioner ändrar beteendet för policy-baserad Site-to-Site IPsec VPN. Dessutom dokumenteras ett löst problem i SFOS-22-release-noterna där policy-baserad IPsec-trafik kunde misslyckas om standard-SNAT-regeln var konfigurerad med en statisk IP-adress istället för MASQ.

Detta är ingen anledning att bygga om varje IPsec-installation i förväg. Men det är en bra anledning att medvetet testa policy-baserad IPsec före och efter uppgraderingen. Detta är särskilt viktigt om brandväggen använder flera VPN:er, överlappande nätverk, specifika SNAT-regler, en anpassad standard-SNAT-regel eller partnernätverk med fasta käll-IP-förväntningar.

Före uppgraderingen kontrollera:

1. Identifiera policy-baserade Site-to-Site-tunnlar.
2. Dokumentera lokala och avlägsna nätverk respektive trafikväljare.
3. Kontrollera NAT-regler för VPN-trafik, särskilt standard-SNAT, MASQ, specifika SNAT-regler och regelordning.
4. Definiera ett testfall per viktig tunnel med källa, destination, tjänst och förväntad riktning.
5. Dokumentera motpart och returväg så att ett post-uppgraderingstest inte bara betyder “Ping fungerar inte”.

Efter uppgraderingen bör man inte blanda dessa tester med breda samlingskontroller. Bättre är ett smalt test per tunnel: Log Viewer, Packet Capture, Firewall Rule ID, NAT Rule ID och byte-räknare i ipsec statusall jämföra. Om tunneln är grön men ingen nyttotrafik flyter, passar Sophos Firewall IPsec VPN Troubleshooting. För NAT-klassificering hjälper Förstå NAT på Sophos Firewall.

10. Kontrollera Bridge VLANs och trafik till brandväggen

Ett annat SFOS 22-specialfall gäller bridge-interfaces med VLAN-taggar som tidigare satts via CLI. I SFOS 22.0 GA och SFOS 22.0 MR1 finns ett dokumenterat Known Issue: VLAN-taggad trafik som kommer från själva brandväggen eller går till själva brandväggen kan över sådana bridge-konfigurationer behandlas felaktigt. Normal transittrafik genom bridgen kan samtidigt fortsätta fungera.

Det är lurigt eftersom just fel saker kan sluta fungera: Active Directory, DNS, Device Access, STAS, LDAP, RADIUS eller managementåtkomst. Det ser då snabbt ut som ett autentiserings-, DNS- eller regelproblem, fast orsaken ligger i bridge/VLAN-modellen.

Praktisk kontroll:

1. Dokumentera bridges och VLAN-användning under Network > Interfaces.
2. Klargör om VLAN-taggar tidigare satts via CLI på ett bridge-interface.
3. Identifiera om AD, DNS, RADIUS, LDAP, STAS, Device Access eller managementtrafik använder dessa VLAN-vägar.
4. Om specialfallet passar, planera före uppgraderingen VLAN-interfaces med bridge-interfacet som parent.
5. Efter uppgraderingen, testa specifikt trafik från och till brandväggen, inte bara klient-till-server-trafik genom bridgen.

Specialfallet beskrivs mer detaljerat i Kontrollera Sophos Firewall Bridge VLANs före SFOS 22. För normal planering av zones, interfaces, VLAN och bridges är Konfigurera Sophos Firewall-zoner och interfaces fortsatt den bättre startpunkten.

11. Kontrollera STAS och användarbaserade regler

Om STAS är aktiv bör det inte bara avfärdas som “fungerar i vardagen” före SFOS 22.0 MR1 eller senare. I listan över kända problem dokumenteras ett problem där alternativet Restrict client traffic during identity probe kan blockera en uppgradering till SFOS 22.0 MR1 eller efter uppgraderingen leda till upprepade identitetsprober med kortvariga trafikavbrott.

Detta påverkar främst miljöer där STAS inte bara används för rapportering utan för produktiva användarbaserade brandväggsregler. Om användar-IP-tilldelningen kort avbryts ser det snabbt ut som ett regel-, DNS- eller applikationsproblem i drift.

Före uppgraderingen kontrollera:

1. Öppna Authentication > STAS.
2. Kontrollera STAS-status och använda samlare.
3. Kontrollera om Restrict client traffic during identity probe är aktiv.
4. Identifiera användarbaserade regler som beror på STAS.
5. Logga in testanvändare och kontrollera Live Users samt Log Viewer.

Om detta alternativ är aktivt eller om korta avbrott redan märks bör punkten klargöras före underhållsfönstret. Den detaljerade processen finns i Ställ in STAS på Sophos Firewall.

12. Validera specifikt efter uppgraderingen

Efter omstarten är uppgraderingen inte automatiskt avslutad. Först när de viktigaste driftfunktionerna har kontrollerats är underhållsfönstret rent avslutat.

Minst kontrollera:

• rätt firmwareversion är aktiv
• Network > Interfaces visar fysiska och logiska gränssnitt rimligt
• internetåtkomst och centrala brandväggsregler fungerar
• Site-to-Site VPN och Remote Access VPN fungerar
• policy-baserade IPsec-tester visar förväntad käll-IP och lämplig NAT-regel
• HA-status är åter synkroniserad
• STAS, AD SSO eller annan användartilldelning fungerar om det används produktivt
• Sophos Central Management och rapportering skickar data
• Log Viewer visar inga nya kritiska fel
• viktiga tjänster som DNS, DHCP, Web Protection, IPS och autentisering fungerar som förväntat

Om VPN, routing eller regler inte fungerar som förväntat, ändra inte direkt på flera ställen samtidigt. Avgränsa först med Log Viewer, Packet Capture och berörda serviceloggar. Policy Test är användbart, men bör läsas försiktigt med SFOS 22.0 GA och SFOS 22.0 MR1: Sophos dokumenterar ett Known Issue där verktyget kan visa blockerad eller felmatchad trafik trots att produktionstrafik flyter korrekt. I detta fall är riktiga testpaket, Log Viewer, Packet Capture, Rule ID och NAT Rule ID viktigare än ett enskilt Policy Test-resultat.

För strukturerad felsökning är Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture och Sophos Firewall troubleshooting: services och logs användbara tillägg.

13. Säkerställ dokumentation och driftjournal

En uppgradering är först rent avslutad när resultatet är spårbart dokumenterat. Detta hjälper vid senare störningar, revisioner, supportärenden och vid nästa underhållsfönster. Direkt efter uppgraderingen bör man därför inte bara notera “fungerar igen”, utan säkra konkreta bevis.

Meningsfulla bevis:

• Skärmdump av Backup & Firmware > Firmware: visar målversion, aktiv firmware och eventuella tillgängliga images.
• Skärmdump av System services > High availability: visar HA-roll, synkronisering och klusterstatus efter uppgraderingen.
• Export eller skärmdump av relevanta Audit Logs: visar vilka ändringar som gjordes under underhållsfönstret.
• Central- eller Syslog-kontroll: visar om loggar och rapporter fortfarande kommer efter uppgraderingen.
• Lista över öppna efterarbeten: förhindrar att tillfälliga Workarounds glöms bort permanent.

Om ändringar gjordes i regler, gränssnitt, värdar eller tjänster bör man dessutom kontrollera Audit Trail Logs. I miljöer med längre loggförvaring hör även en kontroll av Central Firewall Reporting eller Syslog till avslutningen.

Vid flera brandväggar är det dessutom viktigt att säkerhetskopior kan tilldelas entydigt. I nyare SFOS-versioner innehåller säkerhetskopierings-e-postmeddelanden fler identifieringsdata som värdnamn, firmwareversion, serienummer och modell. Trots detta bör man internt fortfarande föra en enkel uppgraderingsnotering: brandvägg, plats, gammal version, ny version, tidsfönster, ansvarig person, testresultat och öppna punkter.

Om lagrings-, hårdvaru- eller SSD-anmärkningar märks efter uppgraderingen bör detta inte försvinna i firmwareärendet. För denna kontroll passar Kontrollera SSD-hälsotillstånd på Sophos Firewall.

Checklista för underhållsfönstret

• Testa bridge-VLAN-trafik till AD, DNS, Device Access, STAS eller management, om relevant

Före uppgraderingen

• Plattform och uppgraderingsväg kontrollerade

• Release Notes och kända anmärkningar lästa

• Gränssnittnamn med tio eller fler avslutande siffror uteslutna

• Lagringsutrymme och firmwaremeddelanden kontrollerade

• Säkerhetskopiering skapad och sparad externt

• Secure Storage Master Key tillgänglig

• Go/No-Go-beslut, återställningsväg och ansvariga fastställda

• HA-status dokumenterad

• Policy-baserad IPsec, VPN-NAT och testtrafik dokumenterade, om de används

• STAS och användarbaserade regler kontrollerade, om de används

• Bridge VLANs och trafik till själva brandväggen kontrollerade om bryggor används

• Legacy Remote Access IPsec utesluten eller migrerad

• Återställningsplan definierad

• UTM9 SSL VPN-tunnlar och gamla RED-enheter uteslutna eller migrerade

Under uppgraderingen

• Dokumentera statusmeddelanden
• Gör inga parallella ändringar i routing, VPN eller switching
• Vid HA-kluster observera failover och synkronisering
• Håll beslutspunkt för väntan, felanalys eller återställning
• Vid oväntade meddelanden, bekräfta inte blint utan kontrollera orsaken

Efter uppgraderingen

• Kontrollera firmwareversion och licensstatus
• Testa VPN, routing, DNS, DHCP och centrala brandväggsregler
• Kontrollera policy-baserad IPsec med definierat källa-/destinationstest, om det används
• Kontrollera STAS, AD SSO och användarbaserade regler med testanvändare
• Kontrollera HA-synk och Sophos Central-anslutning
• Kontrollera Log Viewer och relevanta tjänsteloggar
• Säkerställ firmware-, HA- och revisionsbevis
• Dokumentera resultat och öppna punkter i driftjournalen

FAQ