Sophos XG vs. XGS: różnice, EOL i migracja
Seria XGS jest następcą serii XG od 2021 roku. Pierwotne porównanie starego i nowego sprzętu nie jest dziś jednak tylko kwestią wydajności. Ostatnie modele XG Series osiągnęły End of Life 31 marca 2025; niektóre starsze modele były EOL już wcześniej. Ponadto SFOS 21.0 i późniejsze linie firmware nie obsługują już sprzętu XG ani SG-Series.
Dlatego właściwe pytanie nie brzmi już Czy XGS się opłaca?, lecz Jak poprawnie zaplanować przejście z XG, nie pomijając routingu, VPN, Central Firewall Reporting ani lokalizacji zdalnych?
Krótka odpowiedź
XG i XGS działają z Sophos Firewall OS, ale nie są już równorzędnymi platformami.
- Lifecycle: XG: End of Life. XGS: aktywnie wspierana platforma sprzętowa.
- Firmware: XG: żadna wersja SFOS od 21.0. XGS: aktualne linie SFOS, w tym 22.0.
- Wydajność: XG: starsza platforma z mniejszym zapasem dla nowoczesnej Inspection. XGS: architektura Xstream; dostępna akceleracja zależy od modelu, firmware i ścieżki danych.
- Eksploatacja: XG: granica migracji i wsparcia. XGS: standardowa platforma dla nowych projektów sprzętowych.
- Planowanie: XG: wymagana wymiana. XGS: sizing, mapowanie portów i transfer licencji muszą być ustalone przed cutover.
XG nie powinien więc być już traktowany jako zwykły model firewalla, lecz jako starsza platforma do zastąpienia. W kwestiach licencji i lifecycle pasuje dodatkowo kalendarz Sophos Product Lifecycle.
Co End of Life oznacza w eksploatacji firewalla
End of Life w przypadku sprzętu firewall nie jest formalnym wpisem w tabeli. Firewall stoi na brzegu sieci, terminuje VPN, filtruje ruch webowy i aplikacyjny, chroni publikowane usługi i często zawiera wrażliwe konfiguracje. Jeżeli taka platforma nie jest już utrzymywana, powstaje realne ryzyko operacyjne.
Dla produkcyjnego XG krytyczne są przede wszystkim te punkty:
- Nie można już używać nowych linii firmware SFOS.
- Sophos ostrzega, że aktualizacje oprogramowania kończą się krótko po EOL; wsparcia producenta i wymiany sprzętu nie można więc już niezawodnie planować.
- Nowe funkcje, takie jak aktualne funkcje VPN, Logging, Health Check albo bezpieczeństwa, trafiają na wspierane platformy.
- Licencje, RMA, urządzenia zastępcze i zgłoszenia supportowe są trudniejsze do planowania.
- Audyty i ubezpieczenia cybernetyczne mogą krytycznie oceniać dalszą eksploatację firewalla EOL.
Jest to szczególnie krytyczne przy firewallach z aktywnym Remote Access VPN, Site-to-Site VPN, WAF, TLS Inspection, Web Protection, publikowanymi serwerami albo szeroko osiągalnym WebAdmin. W takich środowiskach dalsza eksploatacja XG powinna być traktowana wyłącznie jako ograniczone czasowo rozwiązanie przejściowe z udokumentowanym planem migracji.
Trzy najważniejsze różnice
XG i XGS wyglądają z zewnątrz, zależnie od modelu, podobnie, ale technicznie i operacyjnie wyraźnie się różnią.
- Lifecycle i Firmware: sprzęt XG jest End of Life. SFOS 21.0, 21.5 i 22.0 nie obsługują już sprzętu XG ani SG-Series. XGS jest wspieraną platformą sprzętową dla aktualnych wersji SFOS.
- Architektura i wydajność: XGS używa architektury Xstream i akceleracji zależnej od modelu. Daje to większy zapas dla aktualnych funkcji bezpieczeństwa, VPN, TLS Inspection, IPS, Web Protection i routingu. Miarodajna pozostaje specyfikacja konkretnego modelu.
- Migracja i eksploatacja: przejście na XGS jest projektem migracyjnym. Trzeba sprawdzić kompatybilność backupu, mapowanie portów, stan licencji, HA, SD-WAN, Central Firewall Reporting, RED, Access Points i ZTNA-Gateways.
Architektura: Xstream zamiast starej platformy XG
Seria XGS została zbudowana dla architektury Xstream, co jest szczególnie istotne przy aktywnych funkcjach ochronnych. Przyspieszone ścieżki danych i dostępne zasoby różnią się jednak między modelami desktop, 1U i 2U; sama nazwa serii nie określa throughput. Wiele starszych instalacji XG wymiarowano ponadto przy mniejszym obciążeniu TLS Inspection, ruchem cloud, SD-WAN i Remote Access.
XGS Appliance, zależnie od modelu, daje większe rezerwy dla:
- IPS, Web Protection i Application Control.
- TLS Inspection oraz większych wdrożeń certyfikatów/CA.
- IPsec VPN, SSL VPN, SD-WAN i kilku WAN-Uplinks.
- większej liczby jednoczesnych użytkowników, sesji i reguł.
- nowych funkcji SFOS, które na XG nie są już w ogóle dostępne.
Nie każda ścieżka danych automatycznie przyspieszy tylko dlatego, że zostanie zamontowany XGS Appliance. Błędny sizing, zbyt małe modele, źle zaplanowane TLS Inspection albo niejasna architektura VPN mogą spowolnić również nowy firewall. Przy wyborze właściwego modelu docelowego Sophos Firewall Sizing Guide jest ważniejszy niż proste porównanie modeli 1:1.
Kiedy XG powinien zostać zastąpiony
Wymiana XG nie powinna być planowana dopiero wtedy, gdy aktualizacja firmware zostaje zablokowana albo awaria sprzętu już tworzy presję. Najpóźniej przy tych sygnałach potrzebny jest projekt migracyjny:
- Firewall ma zostać zaktualizowany do SFOS 21.0, 21.5, 22.0 albo nowszego.
- Istnieje Remote Access VPN, WAF, publicznie dostępne usługi albo kilka Site-to-Site VPN.
- Support, audit, RMA albo przedłużenie licencji nie mogą być już poprawnie odwzorowane.
- Istniejący XG jest na granicy możliwości przy IPS, Web Protection, TLS Inspection albo obciążeniu VPN.
- RED, Access Points, SD-WAN, Central Firewall Reporting albo ZTNA są powiązane z istniejącym firewallem.
- I tak planowany jest HA-Cluster, redesign portów albo zmiana providera.
Jeżeli XG nadal działa produkcyjnie, należy najpierw udokumentować aktualny backup, Secure Storage Master Key i używaną wersję firmware. Procedura jest opisana dokładniej w artykule Tworzenie lub odtwarzanie backupu Sophos Firewall.
Planowanie migracji z XG do XGS
Przy migracji z XG do XGS nie należy po prostu wybierać pozornie najbliższego modelu. Sensowniejsza jest krótka inwentaryzacja przed oknem serwisowym:
- Które porty WAN, LAN i DMZ są faktycznie używane?
- Czy istnieją HA, stosy VLAN, RED, przypadki specjalne SD-WAN albo VPN?
- Które funkcje bezpieczeństwa są dziś aktywne i które mają zostać dodatkowo aktywowane w przyszłości?
- Które scenariusze IPsec, SSL VPN, Sophos Connect albo ZTNA są produkcyjne?
- Czy używane są Central Firewall Reporting, zarządzanie przez Sophos Fusion albo SD-WAN Connection Groups?
- Czy Access Points albo SD-RED są przypisane do tego firewalla?
- Czy istnieją trasy statyczne, aliasy adresów IP, reguły DNAT albo publikacje WAF, które po przełączeniu muszą być natychmiast osiągalne?
- Czy platforma docelowa ma być ponownie sprzętowa, czy wirtualna albo cloud-appliance?
Ustalenie ścieżki firmware przed backupem
XG nie można zaktualizować do SFOS 21.0 ani 22.0. Sophos rozróżnia dlatego restore według wersji źródłowego XG; na docelowym XGS Appliance Backup-Restore Assistant wymaga SFOS 20.0 MR2 lub nowszego:
- Przy 19.5 MR4 lub dowolnej wersji 20.0 wykonaj backup bezpośrednio i przypisz interfejsy podczas restore za pomocą Backup-Restore Assistant.
- Przy 19.5 MR3 lub starszej migracja jest możliwa, ale assistant się nie pojawia. Sophos zaleca najpierw aktualizację XG do 19.5 MR4 lub 20.0 MR2 i nowszej, o ile ten krok pośredni nadal jest wspierany i operacyjnie akceptowalny.
Setup Assistant nowego XGS Appliance aktualizuje cel do najnowszej oferowanej wersji. Jeśli przejście wprowadza również SFOS 22, przed oknem serwisowym przeczytaj przewodnik po aktualizacji firmware Sophos Firewall. Legacy Remote Access IPsec blokuje aktualizację do 22.0 MR1 i nowszych; legacy CLI VLAN tagging na bridge interfaces blokuje 22.0 MR2 i nowsze, a backupów z tą konfiguracją nie można również odtworzyć na 22.0 GA ani nowszej. SFOS 22 może ponadto wymagać dodatkowego miejsca na dysku i zmienia zachowanie policy-based IPsec VPN.
Zalecenie Avanet: łącz zmianę sprzętu z dużą zmianą firmware w jednym oknie dopiero po przejściu tych kontroli. W przeciwnym razie awaria pozostawia niepotrzebną wątpliwość, czy przyczyną był backup, mapowanie portów czy firmware.
Backup-Restore Assistant i mapowanie portów
Mapowanie portów i Backup-Restore Assistant trzeba zaplanować dla dokładnych urządzeń źródłowych i docelowych: nazwy i liczba portów, moduły Flexi Port, warianty wireless i modele docelowe nie zawsze pasują 1:1. Moduły Flexi Port XG nie są kompatybilne z XGS i trzeba je zastąpić odpowiednimi modułami XGS.
W praktyce przed restore należy przygotować tabelę portów:
- Port1 do Port1 dla LAN: sprawdź VLAN, DHCP i DNS.
- Port2 do Port2 dla WAN: sprawdź Gateway, alias IP i NAT.
- Port3 do Port4 dla DMZ: sprawdź Firewall Rules, WAF i DNAT.
- Flexi Port do nowego modułu: sprawdź Uplink, Trunk i kompatybilność modułu.
Assistant pokazuje tylko porty fizyczne. Interfejsy VLAN i alias podążają za Parent Interface; LAG i bridge są odtwarzane z przypisanych członków fizycznych. Nieprzypisane interfejsy powiązane mogą stać się pseudo ports. Oprócz numeru portu sprawdź więc Zone, IP Assignment, Link Mode, Parent Interface i członkostwo.
Modele wireless mają dodatkowe ograniczenia. Przy odtwarzaniu backupu XG Wireless lub XGS Wireless Gen.1 na modelu XGS Wireless Gen.2 Sophos wymaga między innymi WPA2 lub nowszego, braku TKIP, braku interfejsów wireless w fizycznych bridge i maksymalnie ośmiu unikalnych SSID na LocalWiFi0 i LocalWiFi1. Restore na model bez zintegrowanego WLAN wymaga usunięcia sieci wireless przed backupem. Potraktuj tę zmianę jako osobny, sprawdzony krok, a nie improwizację podczas cutover.
Jeżeli zmieni się adres MAC WAN, routery upstream albo Provider-CPE mogą nadal trzymać stare wpisy ARP. Przy takich objawach pomaga artykuł Rozwiązywanie problemu ARP po migracji Sophos Firewall.
HA potraktować osobno
Klastra XG HA nie zastępuje się po prostu restore na dwóch nowych XGS Appliances. Jeśli backup HA zostanie odtworzony na nowym XGS Appliance bez HA, restore nie odtworzy konfiguracji HA; trzeba skonfigurować ją ręcznie. Zgodność modeli, firmware, licencje, port HA, monitoring, passphrase, zmiana ról i okno testowe wymagają więc osobnej procedury, na przykład Konfiguracji Sophos Firewall High Availability.
Dociągnij Sophos Fusion, Reporting, SD-WAN i ZTNA
Po restore nowy XGS Appliance nie jest automatycznie tak samo podłączony do każdej funkcji Sophos Fusion. W zależności od środowiska trzeba:
- zarejestrować nowy firewall w Sophos Fusion,
- sprawdzić Firewall Management i Central Firewall Reporting,
- przypisać do urządzenia zastępczego oddzielną licencję Central Firewall Reporting i jej dane; lokalne raporty XG nie są przenoszone,
- dla SD-WAN Connection Groups najpierw usunąć na XGS Appliance reguły i tunele utworzone przez Sophos Fusion z prefiksem
Central_, a następnie dodać urządzenie do grupy, - przestawić ZTNA-Gateways na nowy firewall,
- przetestować przypisanie SD-RED i Access Points; jeśli XG pozostaje podłączony równolegle, usunąć tam konfigurację SD-RED i zaakceptować Access Points na XGS Appliance,
- ponownie sprawdzić powiadomienia, backupy i zaplanowane raporty.
Dla konfiguracji reportingowych pasuje dodatkowo Aktywacja Central Firewall Reporting. Dla operacyjnych dowodów po migracji Testowanie reguły Sophos Firewall z Log Viewer i Packet Capture oraz Analiza porzuconych pakietów Sophos Firewall są bardziej pomocne niż zwykły test ping.
Typowe błędy przy migracjach XG do XGS
Zbyt mały model docelowy
Pozornie pasujący model następcy może być za mały, jeżeli od czasu pierwotnego zakupu XG przybyło użytkowników, VPN, TLS Inspection, Web Protection albo przepustowości. Dlatego nie należy porównywać tylko modelu XG z modelem XGS, lecz uwzględnić rzeczywiste obciążenie, aktywne funkcje ochronne i wzrost.
Mapowanie portów sprawdzone tylko ogólnie
Jeżeli LAN, WAN, DMZ, VLAN-Trunks, porty HA albo połączenia providera zostaną przepięte inaczej, udany restore nie wystarczy. Po restore trzeba celowo sprawdzić Interface-Zones, Gateways, SD-WAN-Routes, NAT-Rules, WAF-Rules i Firewall Rules.
Stare firmware albo stary stan backupu
Bardzo stary stan backupu zwiększa ryzyko, że Interface-Mapping, certyfikaty, VPN albo konfiguracje specjalne zmigrują nieoczekiwanie. Przed wymianą należy, o ile nadal ma to sens i jest wspierane, doprowadzić stary firewall do odpowiedniego stanu i utworzyć świeży backup.
Zapomniane systemy zależne
Wiele migracji nie kończy się problemem przy restore, lecz na systemach zależnych: Monitoring, Syslog, SIEM, wiadomości backupowe, klienci VPN, Provider-ARP, DNS, DHCP, RED, Access Points albo Sophos Fusion. Te punkty należą do checklisty, a nie do diagnostyki po przełączeniu.
Checklista przed wymianą
- Udokumentowano aktualne firmware XG i docelowe firmware XGS Appliance.
- Sprawdzono w narzędziu Sophos kompatybilność restore dokładnych modeli źródłowego i docelowego.
- Utworzono aktualny backup i bezpiecznie zapisano hasło restore.
- Aktualny i ewentualnie poprzedni Secure Storage Master Key oraz hasło backupu są bezpiecznie dostępne osobno.
- Przygotowano mapowanie portów dla WAN, LAN, DMZ, VLAN-Trunks i HA.
- Flexi Ports XG zastąpiono zgodnymi modułami XGS; sprawdzono ograniczenia wireless.
- Sprawdzono transfer licencji, rejestrację w Sophos Fusion i status supportu.
- Dla SFOS 22 sprawdzono legacy IPsec, CLI VLAN tagging, miejsce na dysku i policy-based IPsec VPN.
- Przygotowano VPN, NAT, WAF, SD-WAN, DHCP, DNS i routing jako listę testową.
- Uwzględniono RED, Access Points, ZTNA, Central Firewall Reporting i Monitoring.
- Zdefiniowano plan rollbacku ze starym urządzeniem, planem kabli i oknem serwisowym.
- Dostępne są osoby kontaktowe dla providera, DNS, monitoringu i aplikacji.
Rollback z jednoznaczną granicą przerwania
Do odbioru zachowaj stary XG bez zmian, wyłączony lub fizycznie odizolowany, wraz z opisanym planem okablowania. Przed cutover określ czas i mierzalne kryteria przerwania, takie jak nieosiągalny WAN Gateway, niedziałająca krytyczna publikacja DNAT albo biznesowo krytyczny tunel VPN nadal down po zarezerwowanym czasie diagnostyki.
Przy rollbacku odizoluj XGS Appliance, przywróć okablowanie do XG zgodnie z planem i dopiero wtedy włącz XG. Ponownie sprawdź WAN, routing, VPN i publikowane usługi. Zmiany wykonane podczas testów XGS Appliance nie znajdują się automatycznie na starym XG; zapisz je i oceń po rollbacku. Nie resetuj ani nie wycofuj XG, zanim XGS Appliance nie zostanie odebrany jako stabilny, zarchiwizowany w backupie i udokumentowany.
Kontrola po migracji
Po przełączeniu nie należy sprawdzać tylko, czy działa Internet. Czysta migracja jest zakończona dopiero wtedy, gdy zwalidowane są najważniejsze funkcje operacyjne:
- Sprawdzić dashboard, status licencji, rejestrację w Sophos Fusion i wiadomość backupową.
- Przetestować WAN-Gateway, aliasy IP, NAT i publikowane usługi.
- Sprawdzić Site-to-Site VPN, Remote Access VPN i profile Sophos Connect.
- Skontrolować SD-WAN-Routes, trasy statyczne i Route Precedence.
- Przetestować Firewall Rules z logowaniem.
- Wyrywkowo sprawdzić IPS, Web Protection, TLS Inspection i Application Control.
- Skontrolować połączenia RED i Access Points.
- Przetestować Syslog, Central Firewall Reporting, powiadomienia i Monitoring.
- Wyłączyć stary XG dopiero po stabilnej fazie pracy.
Jeżeli bezpośrednio po migracji pojedyncze cele są nieosiągalne, należy pracować systematycznie z Log Viewer, Packet Capture i kontrolami routingu. Do podstawowej diagnostyki pomagają Użycie Sophos Firewall Packet Capture w WebAdmin oraz Bezpieczna zmiana Sophos Firewall Route Precedence.