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
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
- 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
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:
- Notera aktuell firmwareversion under
Backup & Firmware > Firmware. - Dokumentera modell, serienummer och plattformstyp.
- Kontrollera i de officiella Sophos Release Notes om den direkta uppgraderingsvägen stöds.
- Behandla inte längre SFOS-22-planering som en vanlig uppdatering för XG- eller SG-hårdvara, utan som ett migrationsprojekt.
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:
| Exempel | Risk |
|---|---|
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:
- Öppna Network > Interfaces.
- Kontrollera fysiska gränssnitt, VLAN, alias, bryggor, LAGs, RED-gränssnitt och XFRM-gränssnitt.
- Sök efter namn som slutar med tio eller fler siffror.
- Ändra berörda namn till en kortare eller tydligt åtskild skrivning före uppgraderingen.
- 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 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.
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.
4. 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.
5. 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:
| Fråga | Go | No-Go |
|---|---|---|
| Plattform stöder SFOS 22 | Modell och uppgraderingsväg är kontrollerade | XG/SG-hårdvara eller oklar uppgraderingsväg |
| Säkerhetskopiering och SSMK | Säkerhetskopiering är sparad externt och återställningsdata är tillgängliga | Säkerhetskopiering saknas, är inte hittbar eller SSMK saknas |
| Remote Access IPsec | Legacy-konfiguration är utesluten eller migrerad | Legacy-konfiguration finns eller är oklar |
| Site-to-Site IPsec | policy-baserad IPsec, NAT och testtrafik är dokumenterade | Trafikväljare, SNAT eller motpart är oklara |
| HA-status | Kluster är stabilt och synkroniserat | HA är degraderat, osynkroniserat eller oklart |
| Åtkomst | Lokal administratörsåtkomst och underhållsnätverk är kontrollerade | Åtkomst beror bara på en osäker fjärrväg |
| Återställning | Beslutspunkt och ansvariga är definierade | Ingen beslutar bindande om att vänta eller återställa |
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.
6. 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 availabilityvisar 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.
7. 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:
- Öppna området
Remote access VPNi WebAdmin. - Kontrollera om en Legacy Remote Access IPsec-konfiguration finns.
- Dokumentera berörda användare, profiler, pooler, autentisering och distribuerade Sophos Connect-konfigurationer.
- Planera ersättningskonfiguration och testa med några få testanvändare.
- 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.
8. 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:
- Identifiera policy-baserade Site-to-Site-tunnlar.
- Dokumentera lokala och avlägsna nätverk respektive trafikväljare.
- Kontrollera NAT-regler för VPN-trafik, särskilt standard-SNAT,
MASQ, specifika SNAT-regler och regelordning. - Definiera ett testfall per viktig tunnel med källa, destination, tjänst och förväntad riktning.
- 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.
9. 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:
- Öppna
Authentication > STAS. - Kontrollera STAS-status och använda samlare.
- Kontrollera om Restrict client traffic during identity probe är aktiv.
- Identifiera användarbaserade regler som beror på STAS.
- 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.
10. 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 omedelbart på flera ställen samtidigt. Först begränsa med Log Viewer, Policy Test, Packet Capture och de berörda tjänsteloggarna. 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.
11. 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:
| Bevis | Varför viktigt |
|---|---|
Skärmdump av Backup & Firmware > Firmware | visar målversion, aktiv firmware och eventuella tillgängliga bilder |
Skärmdump av System services > High availability | visar HA-roll, synkronisering och klusterstatus efter uppgraderingen |
| Export eller skärmdump av relevanta revisionsloggar | 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 lösningar 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
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
- Legacy Remote Access IPsec utesluten eller migrerad
- Återställningsplan definierad
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