Sophos Firewall SFOS 22: kontrola blokad aktualizacji

Przed aktualizacją do SFOS 22 trzeba ustalić, czy platforma, ścieżka aktualizacji i konfiguracja obsługują wersję docelową. Ta kontrola uwzględnia SFOS 22.0 MR2 Build 546 z 14 lipca 2026 r. i uzupełnia ogólną instrukcję Aktualizacja firmware Sophos Firewall.

Bezwzględne blokady aktualizacji i przywracania

• Sprzęt XG lub SG: SFOS 22 nie jest obsługiwany. Zamiast aktualizacji konieczna jest migracja na XGS albo platformę wirtualną, programową lub chmurową.
• Legacy Remote Access IPsec: Od SFOS 22.0 MR1 konfigurację trzeba zmigrować lub usunąć przed aktualizacją.
• Legacy CLI VLAN Tagging na interfejsie bridge: Od SFOS 22.0 MR2 polecenie system vlan-tag trzeba zastąpić obsługiwanymi interfejsami VLAN.
• Kopia zapasowa z Legacy VLAN Tagging: Przywrócenie w SFOS 22.0 GA lub nowszej wersji wymaga oczyszczenia konfiguracji źródłowej i utworzenia nowej kopii zapasowej.
• Miejsce lub ścieżka aktualizacji: Jeśli strona Firmware zgłasza za mało miejsca lub nieprawidłową ścieżkę aktualizacji, najpierw trzeba usunąć przyczynę.

Jeśli występuje blokada lub któryś punkt pozostaje niejasny, nie należy rozpoczynać aktualizacji.

Bezpośrednia ścieżka aktualizacji do SFOS 22.0 MR2

Dla omawianej tutaj wersji docelowej SFOS 22.0 MR2 Build 546 Sophos obsługuje bezpośrednią aktualizację z następujących wersji:

• SFOS 22.0: MR1 Build 490 oraz GA Build 411 lub 365
• SFOS 21.5: MR2 Build 323, MR1 Build 261 lub GA Build 171
• SFOS 21.0: MR2 Build 349, MR1 Build 277, 272 lub 237 oraz GA Build 169
• Starsze wersje: każda wersja SFOS 20.0, 19.5 lub 19.0

⚠️ Jeśli bieżąca wersja nie znajduje się na tej liście, nie wolno potwierdzać ostrzeżenia o nieobsługiwanej migracji. W przeciwnym razie firewall uruchomi się ponownie z ustawieniami fabrycznymi, a bieżąca konfiguracja zostanie utracona. Backup można również przywrócić tylko z wersji, dla której obsługiwana jest migracja konfiguracji.

W przypadku starszej lub niewymienionej wersji trzeba najpierw zaplanować obsługiwaną ścieżkę pośrednią. Lista wersji nie zastępuje też pozostałych kontroli: platforma, miejsce, starsze zależności oraz plan przywracania również muszą być odpowiednie.

Kontrole przed oknem serwisowym

Platforma i starsze zależności

• Udokumentować model i aktualny firmware, aby można było prześledzić podaną wyżej ścieżkę aktualizacji i ewentualne przywracanie.
• Sprzęt XG i SG traktować jako migrację, a nie zwykłą aktualizację.
• Przed aktualizacją zastąpić tunele UTM9 SSL VPN oraz urządzenia RED 15, RED 15w i RED 50.
• W Network > Interfaces poprawić nazwy kończące się dziesięcioma lub więcej cyframi. Po aktualizacji takie nazwy mogą ukrywać interfejsy w WebAdmin.

Miejsce na dysku, kopia zapasowa i dostęp

Zapełnienie partycji można zgrubnie sprawdzić w Advanced Shell:

df -kh

Jeśli na stronie Firmware pojawi się ostrzeżenie, nie należy jeszcze rozpoczynać aktualizacji. Kod referencyjny wskazuje przyczynę i kolejny krok:

• FWDS501: Primary Disk lub jedna z jego partycji systemowych jest zbyt mała dla SFOS 22. W przypadku VM wdrożonej przed SFOS 18 ten sam stary układ może podczas aktualizacji do SFOS 21.5 lub nowszej wersji początkowo objawić się jedynie ogólnym błędem firmware (NC-151465); sam komunikat nie potwierdza jednak błędu dysku. W przypadku wirtualnego firewalla artykuł Zwiększanie Primary Disk przed SFOS 22 pokazuje, jak sprawdzić i rozszerzyć Hard disk 1, a następnie zweryfikować wynik. Ten sam artykuł zawiera właściwe wartości graniczne i rozwiązania dla Software Appliance.
• FWDS502: na partycji /var brakuje wolnego miejsca. W 4. Device Console polecenie system firmware check-disk-space pokazuje wymaganą przestrzeń i odpowiedzialne obszary danych. Reports lub logs należy usuwać w sposób kontrolowany dopiero po zabezpieczeniu potrzebnych danych; procedurę opisuje artykuł Sprawdzanie miejsca i zarządzanie reports.
• FWDS503: partycja /content jest zbyt mała. Sophos wymaga przywrócenia ustawień fabrycznych, co wiąże się z przestojem i utratą bieżącej konfiguracji. Po utworzeniu świeżego backupu i zabezpieczeniu SSMK należy wprowadzić RESET wielkimi literami w konsoli szeregowej i wybrać opcję 2; spowoduje to usunięcie własnych konfiguracji i przywrócenie sygnatur wzorców do stanu aktywnego firmware. Następnie przywrócić backup, sprawdzić działanie funkcji i dopiero potem wykonać aktualizację. Lokalne reports nie są przywracane.
• FWDS504: firmware SSD jest nieaktualny i musi zostać zaktualizowany przed aktualizacją SFOS.
• FWDS505: Sophos Support musi sprawdzić stan SSD. Lokalny test SMART może udokumentować wartości dla supportu, ale nie usuwa blokady.

W klastrze HA każdy node należy sprawdzić oddzielnie, ponieważ obie appliances mogą wyświetlać różne kody referencyjne.

Przed rozpoczęciem muszą być również dostępne:

• aktualna kopia zapasowa przechowywana poza firewallem oraz odpowiedni Secure Storage Master Key
• lokalny dostęp administracyjny lub dostęp alternatywny poza normalną ścieżką VPN
• zdefiniowana ścieżka awaryjna z osobą odpowiedzialną i punktem decyzyjnym
• w przypadku HA zdrowy, zsynchronizowany klaster ze stabilnymi łączami HA i Monitored Ports

Szczegóły dotyczące kopii zapasowej i przywracania opisano w artykule Tworzenie lub przywracanie kopii zapasowej Sophos Firewall.

Konfiguracje o szczególnym ryzyku

Legacy Remote Access IPsec

Od SFOS 22.0 MR1 istniejąca konfiguracja Legacy Remote Access IPsec blokuje aktualizację. Użytkowników, pule i profile, których dotyczy zmiana, trzeba najpierw zmigrować do aktualnej konfiguracji Remote Access IPsec, SSL VPN, ZTNA lub innego odpowiedniego rozwiązania. Procedurę opisano w artykule Migracja Legacy Remote Access IPsec przed SFOS 22 MR1.

Microsoft Entra ID SSO przy Same as firewall

SFOS 22.0 lub nowszy automatycznie włącza Microsoft Entra ID SSO dla VPN Portal, Remote Access IPsec i SSL VPN, gdy przed aktualizacją ich metoda uwierzytelniania jest ustawiona na Same as firewall. Dlatego przed oknem serwisowym należy udokumentować ustawienia w Authentication > Services oraz rzeczywiście oczekiwanego dostawcę tożsamości.

Po aktualizacji trzeba osobno sprawdzić każdą faktycznie używaną metodę. Jeśli Entra SSO jest zamierzone, dokładny adres VPN portal and remote access URL z obiektu serwera Entra musi figurować jako Redirect URI w aplikacji Entra; adres reverse SSO z Sophos Central jest do tego niewłaściwy. Rzeczywiste logowanie pilotażowe weryfikuje portal, klienta i MFA. Jeśli SSO nie jest zamierzone, należy jawnie ustawić właściwą metodę. Pełną procedurę opisuje artykuł Konfiguracja Microsoft Entra ID SSO dla VPN Sophos Firewall.

Policy-based IPsec i NAT

Produkcyjne tunele policy-based Site-to-Site należy przetestować przed aktualizacją i po niej przy użyciu konkretnego przepływu. Test powinien obejmować source, destination, service, Traffic Selectors, drugą stronę oraz oczekiwane reguły firewalla i NAT. W razie problemów pomocne są artykuły Rozwiązywanie problemów z IPsec VPN i Zrozumienie NAT w Sophos Firewall.

Przed aktualizacją należy również ustalić, czy OSPF lub BGP rozgłaszał dotąd zdalne sieci policy-based VPN przez redistribute kernel. Od SFOS 22 sieci te nie są już dostępne jako zwykłe trasy kernela; artykuł SFOS 22: trasy IPsec i redistribute kernel pokazuje, które prefiksy sprawdzić przed aktualizacją i po niej oraz dlaczego projekt route-based XFRM lepiej pasuje do routingu dynamicznego.

SMTP przez DNAT

Jeśli wewnętrzny serwer pocztowy jest publikowany przez DNAT, plan prac serwisowych powinien obejmować kilka rzeczywistych przychodzących wiadomości testowych, a nie tylko test portu. Pod numerem NC-184583 Sophos opisuje sporadycznie przerywane połączenia SMTP po aktualizacji do SFOS 22.x; jako wersję, której problem wprost dotyczy, podano GA Respin Build 411, a publiczny workaround nie jest dostępny. Szczegółowy zakres wersji, zebranie materiałów diagnostycznych i eskalację do pomocy technicznej opisano w artykule Publikowanie serwera przez DNAT w Sophos Firewall.

Let’s Encrypt i rollback migracji MR2

MR2 Build 546 obsługuje nowe CA Let’s Encrypt YE Root, YE1, YE2, YR Root, YR1 i YR2. Niezależnie od tego, podczas dwóch publicznie udokumentowanych aktualizacji z MR1 Build 490 do MR2 Build 546 migracja konfiguracji została przerwana w związku z używanym certyfikatem Let’s Encrypt. Firewall automatycznie wrócił do MR1. Po sprawdzeniu przez Support Access Sophos potwierdził znaną blokadę migracji dotyczącą certyfikatów z określonego, ale publicznie niezdefiniowanego okresu wystawiania. Według stanu na 9 sierpnia 2026 r. nadal brakuje publicznego ID błędu, niezawodnego testu wstępnego i potwierdzonej wersji z poprawką.

Przed aktualizacją firewalla z MR1 i niedawno wystawionym lub odnowionym certyfikatem Let’s Encrypt należy udokumentować Issuer oraz przypisanie do usługi w Certificates > Certificates. Issuer YE/YR lub sama obecność tych CA w Certificate authorities nie potwierdza błędu migracji i sama w sobie nie jest ogólną blokadą aktualizacji. W przypadku krytycznego firewalla warto mimo to wcześniej uzgodnić sprawę z Sophos Support lub odłożyć aktualizację do czasu potwierdzenia publicznego testu wstępnego albo poprawki. Certyfikatów ani CA nie należy usuwać ani zmieniać ich nazw na podstawie przypuszczeń: udokumentowana w Community próba usunięcia nie rozwiązała niezawodnie problemu, a certyfikat może zabezpieczać WAF, WebAdmin, portale, Hotspot lub SMTP TLS. Artykuł Zarządzanie certyfikatami w Sophos Firewall wyjaśnia, jak sprawdzić przypisania i przygotować bezpieczny certyfikat zastępczy z drogą powrotu.

Ten rollback migracji nie jest tym samym błędem co niekompletny łańcuch certyfikatów dostarczany po odnowieniu. Artykuł Certyfikaty Let’s Encrypt w Sophos Firewall opisuje sprawdzenie tego drugiego problemu i wdrożony dla niego hotfix.

Po automatycznym rollbacku znany błąd jest prawdopodobny, jeśli w migration.log występują dbv22.004 i tblvpncertificate_caid_fkey, a otaczająca je instrukcja usuwania wymienia obiekty YE/YR. Poniższe wyszukiwane ciągi ułatwiają znalezienie odpowiednich wierszy:

dbv22.004
tblvpncertificate_caid_fkey
Lets_Encrypt_YE
Lets_Encrypt_YR

Jeśli występują, należy zabezpieczyć migration.log, migrationhash.log, komunikat firmware, czas oraz build źródłowy i docelowy, a następnie nie powtarzać aktualizacji bez zmiany warunków. Trzeba też sprawdzić firmware źródłowy, HA, WAN, routing, VPN, połączenie z Central i wszystkie usługi zależne od certyfikatów. Artykuł Zabezpieczanie logów Sophos Firewall dla supportu pokazuje właściwy sposób zebrania dowodów; na ich podstawie Sophos Support może odróżnić ten błąd migracji.

Legacy VLAN Tagging na interfejsach bridge

Legacy CLI VLAN Tagging na interfejsach bridge ma trzy konsekwencje:

• W GA i MR1 ruch z lub do firewalla może przestać działać, podczas gdy ruch tranzytowy nadal działa.
• Od MR2 aktualizacja jest blokowana.
• Kopii zawierającej tę konfigurację nie można przywrócić w SFOS 22.0 GA ani nowszej wersji.

Przed oczyszczeniem konfiguracji trzeba udokumentować bridge, identyfikatory VLAN, adresy IP, strefy, trunki switchy i zależne usługi. Następnie tworzy się obsługiwane interfejsy VLAN z bridge jako parent i generuje nową kopię zapasową. Ten szczególny przypadek opisano w artykule Sprawdzenie bridge VLAN w Sophos Firewall przed SFOS 22.

STAS

Przy aktualizacji do MR1 opcja Restrict client traffic during identity probe w Authentication > STAS musi mieć wartość No. MR2 usuwa błąd z MR1 i używa No jako wartości domyślnej dla nowych konfiguracji; istniejące wartości oraz reguły oparte na użytkownikach nadal należy sprawdzić. Więcej informacji znajduje się w artykule Konfigurowanie STAS w Sophos Firewall.

Skanowanie malware podczas aktualizacji do GA Build 411

Tylko przy celowej aktualizacji do SFOS 22.0 GA Respin Build 411 błąd NC-177529 może podczas migracji tymczasowo zgłaszać Malware Unscannable, często dla www.msftconnecttest.com, ponieważ nowy silnik skanowania Sophos nie jest jeszcze dostępny. Przed tą aktualizacją GA należy w Web > General settings przełączyć Single engine na Dual engine, a po zakończeniu aktualizacji przywrócić wcześniej używany Single Engine. Ten środek nie obowiązuje ogólnie dla MR1, MR2 ani późniejszych wydań; tło problemu i wybór silnika skanowania opisano w artykule Konfigurowanie i testowanie skanowania malware w Sophos Firewall.

Okno serwisowe i kontrola

• Przed: Wykluczyć blokady, przygotować kopię zapasową i SSMK, sprawdzić synchronizację HA oraz udokumentować VPN, przepływy testowe i ścieżkę awaryjną.
• W trakcie: Nie wprowadzać równoległych zmian w routingu, VPN ani switchingu; obserwować stan i failover HA.
• Po: Sprawdzić firmware, interfejsy, Internet, reguły firewalla, VPN, NAT, HA, STAS, DNS, DHCP, Central i Log Viewer.

Zielony tunel lub pomyślny Policy Test nie dowodzi jeszcze, że ruch użytkowy działa. Dlatego krytyczne połączenia należy sprawdzić za pomocą rzeczywistych pakietów, Log Viewer, Packet Capture oraz Firewall i NAT Rule ID. W razie problemów nie należy zmieniać kilku obszarów jednocześnie.

Aktualizację można uznać za zakończoną, gdy zdefiniowane testy zakończą się powodzeniem, a wersja docelowa, stan HA, wyniki testów i otwarte zadania zostaną udokumentowane.

FAQ