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. Sprzęt Sophos XG jest End of Life od 31 marca 2025. 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 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: End of Life. aktywnie wspierana platforma sprzętowa.
- Firmware: brak wsparcia dla SFOS 21.0/21.5/22.0. aktualne wersje SFOS.
- Wydajność: starsza platforma, mniej rezerw dla nowoczesnej Inspection. architektura Xstream z większymi rezerwami.
- Eksploatacja: ryzyko migracji i granica wsparcia. standardowa platforma dla nowych projektów.
- Planowanie: wymagana wymiana. starannie zaplanować sizing, mapowanie portów i transfer licencji.
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.
- Aktualizacje bezpieczeństwa, Hotfixes i wsparcie producenta są ograniczone albo niedostępne.
- 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 z dedykowanymi funkcjami akceleracji. Daje to większe rezerwy dla aktualnych funkcji bezpieczeństwa, VPN, TLS Inspection, IPS, Web Protection i routingu.
- Migracja i eksploatacja: przejście na XGS jest projektem migracyjnym. Trzeba sprawdzić kompatybilność backupu, mapowanie portów, stan licencji, HA, SD-WAN, Central Reporting, RED, Access Points i ZTNA-Gateways.
Architektura: Xstream zamiast starej platformy XG
Seria XGS została zbudowana dla architektury Xstream. W codziennej pracy nie jest to tylko pojęcie marketingowe, lecz coś istotnego szczególnie przy aktywnych funkcjach ochronnych. Wiele starszych instalacji XG było pierwotnie wymiarowanych w czasie, gdy było mniej TLS Inspection, mniej ruchu cloud, mniej SD-WAN i mniej obciążenia Remote Access.
XGS, 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. 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 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 istnieją Central Firewall Reporting, Sophos Central Management 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?
Backup-Restore Assistant i mapowanie portów
Migration Center dla migracji XG do XGS jest najważniejszym zewnętrznym punktem odniesienia dla mapowania portów i Backup-Restore Assistant. Jest to ważne, ponieważ nazwy portów, liczba portów, moduły Flexi-Port, modele Wireless i modele docelowe nie zawsze pasują 1:1.
W praktyce przed restore należy przygotować tabelę portów:
- Port1: Port1. LAN. VLAN, DHCP, DNS.
- Port2: Port2. WAN. Gateway, alias IP, NAT.
- Port3: Port4. DMZ. Firewall Rules, WAF, DNAT.
- Flexi Port: nowy moduł. Uplink albo Trunk. kompatybilność modułu.
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 urządzeniach XGS. HA trzeba zaplanować świadomie: zgodność modeli, stan firmware, licencje, port HA, monitoring, passphrase, zmianę ról i okno testowe. Szczegóły należą do planowania HA, na przykład z Konfiguracją Sophos Firewall High Availability.
Dociągnij Central, Reporting, SD-WAN i ZTNA
Po restore nowy XGS nie jest automatycznie tak samo podłączony do każdej funkcji Sophos Central. W zależności od środowiska trzeba:
- zarejestrować nowy firewall w Sophos Central,
- sprawdzić Firewall Management i Central Reporting,
- skontrolować licencję Central Firewall Reporting i przypisanie danych,
- ponownie przypisać SD-WAN Connection Groups,
- przestawić ZTNA-Gateways na nowy firewall,
- przetestować przypisanie RED i Access Points,
- 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 Central. Te punkty należą do checklisty, a nie do diagnostyki po przełączeniu.
Checklista przed wymianą
- Udokumentowano aktualne firmware XG i docelowe firmware XGS.
- Utworzono aktualny backup i bezpiecznie zapisano hasło restore.
- Secure Storage Master Key jest znany i udokumentowany.
- Przygotowano mapowanie portów dla WAN, LAN, DMZ, VLAN-Trunks i HA.
- Sprawdzono transfer licencji, rejestrację Central i status supportu.
- Przygotowano VPN, NAT, WAF, SD-WAN, DHCP, DNS i routing jako listę testową.
- Uwzględniono RED, Access Points, ZTNA, Central 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.
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ę Central 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 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.