Sophos XG vs. XGS: diferenças, EOL e migração
A série XGS é, desde 2021, a sucessora da série XG. A comparação original entre hardware antigo e novo já não é hoje apenas uma questão de desempenho. O hardware Sophos XG está End of Life desde 31 de março de 2025. Além disso, SFOS 21.0 e linhas de firmware posteriores já não suportam hardware XG e SG-Series.
Assim, a pergunta real já não é XGS vale a pena?, mas sim Como se planeia corretamente a transição de XG sem ignorar routing, VPN, Central Reporting ou localizações remotas?
Resposta curta
XG e XGS correm ambas Sophos Firewall OS, mas já não são plataformas equivalentes.
- Lifecycle: End of Life. plataforma de hardware com suporte ativo.
- Firmware: sem suporte para SFOS 21.0/21.5/22.0. versões SFOS atuais.
- Desempenho: plataforma mais antiga, menos reserva para Inspection moderna. arquitetura Xstream com mais reserva.
- Operação: risco de migração e limite de suporte. plataforma standard para novos projetos.
- Planeamento: substituição necessária. planear corretamente Sizing, Port-Mapping e transferência de licença.
Uma XG já não deve, por isso, ser vista como um modelo normal de firewall, mas como uma plataforma legada a substituir. Para questões de licença e lifecycle, ver adicionalmente o calendário Sophos Product Lifecycle.
O que End of Life significa na operação de firewall
End of Life em hardware de firewall não é uma entrada formal numa tabela. Uma firewall está no perímetro da rede, termina VPNs, filtra traffic Web e de aplicações, protege serviços publicados e contém muitas vezes configurações sensíveis. Quando essa plataforma deixa de ser mantida, surge um risco operacional real.
Para uma XG produtiva, estes pontos são especialmente críticos:
- Novas linhas de firmware SFOS já não podem ser usadas.
- Atualizações de segurança, Hotfixes e suporte do fabricante ficam limitados ou deixam de estar disponíveis.
- Novas funções, como funcionalidades atuais de VPN, logging, Health Check ou segurança, chegam a plataformas suportadas.
- Licenças, RMA, dispositivos de substituição e casos de suporte tornam-se mais difíceis de planear.
- Auditorias e seguradoras cyber podem avaliar criticamente a continuação da operação de uma firewall EOL.
Isto é particularmente crítico em firewalls com Remote Access VPN ativo, Site-to-Site VPN, WAF, TLS Inspection, Web Protection, servidores publicados ou WebAdmin amplamente acessível. Nestes ambientes, a continuação da operação de uma XG deve ser apenas uma solução transitória limitada no tempo, com plano de migração documentado.
As três diferenças mais importantes
XG e XGS podem parecer semelhantes por fora, consoante o modelo, mas diferem claramente em termos técnicos e operacionais.
- Lifecycle e firmware: o hardware XG está End of Life. SFOS 21.0, 21.5 e 22.0 já não suportam hardware XG e SG-Series. XGS é a plataforma de hardware suportada para versões SFOS atuais.
- Arquitetura e desempenho: XGS usa a arquitetura Xstream com funções de aceleração dedicadas. Isto dá mais reserva para funções de segurança atuais, VPN, TLS Inspection, IPS, Web Protection e routing.
- Migração e operação: a mudança para XGS é um projeto de migração. Compatibilidade de backup, Port-Mapping, estado de licenças, HA, SD-WAN, Central Reporting, RED, Access Points e ZTNA Gateways têm de ser verificados.
Arquitetura: Xstream em vez da antiga plataforma XG
A série XGS foi construída para a arquitetura Xstream. No dia a dia, isto não é apenas um termo de marketing, mas é relevante sobretudo quando funções de proteção estão ativas. Muitas instalações XG antigas foram originalmente dimensionadas numa altura em que havia menos TLS Inspection, menos cloud traffic, menos SD-WAN e menos carga de Remote Access.
Consoante o modelo, uma XGS traz mais reserva para:
- IPS, Web Protection e Application Control.
- TLS Inspection e rollouts maiores de certificados/CA.
- IPsec VPN, SSL VPN, SD-WAN e vários uplinks WAN.
- Mais utilizadores, sessões e regras simultâneos.
- Novas funções SFOS que já nem sequer estão disponíveis em XG.
Nem todos os caminhos de dados ficam automaticamente mais rápidos só porque se instala uma XGS. Sizing errado, modelos demasiado pequenos, TLS Inspection mal planeada ou arquitetura VPN pouco clara também podem travar uma firewall nova. Para escolher o modelo de destino adequado, o Sophos Firewall Sizing Guide é mais importante do que uma simples comparação 1:1 de modelos.
Quando uma XG deve ser substituída
A substituição de uma XG não deve ser planeada apenas quando um firmware upgrade bloqueia ou uma avaria de hardware já cria pressão. O mais tardar perante estes sinais, é necessário um projeto de migração:
- A firewall deve ser atualizada para SFOS 21.0, 21.5, 22.0 ou mais recente.
- Existem Remote Access VPN, WAF, serviços publicamente acessíveis ou vários Site-to-Site VPNs.
- Suporte, auditoria, RMA ou renovação de licença já não podem ser representados de forma limpa.
- A XG existente está no limite sob IPS, Web Protection, TLS Inspection ou carga VPN.
- RED, Access Points, SD-WAN, Central Reporting ou ZTNA dependem da firewall existente.
- Um cluster HA, redesenho de portas ou mudança de provider já está previsto.
Se uma XG ainda estiver produtiva, devem documentar-se primeiro um backup atual, o Secure Storage Master Key e a versão de firmware usada. O procedimento está descrito com mais detalhe no artigo Criar ou restaurar um backup da Sophos Firewall.
Planear a migração de XG para XGS
Numa migração de XG para XGS, não se deve escolher apenas o modelo aparentemente mais próximo. É mais útil fazer um breve levantamento antes da janela de manutenção:
- Que portas WAN, LAN e DMZ são efetivamente usadas?
- Existem casos especiais de HA, stacks VLAN, RED, SD-WAN ou VPN?
- Que funções de segurança estão ativas hoje e quais deverão ser ativadas adicionalmente no futuro?
- Que cenários IPsec, SSL-VPN, Sophos-Connect ou ZTNA estão produtivos?
- Existem Central Firewall Reporting, Sophos Central Management ou SD-WAN Connection Groups?
- Existem Access Points ou dispositivos SD-RED ligados a esta firewall?
- Existem rotas estáticas, endereços Alias-IP, regras DNAT ou publicações WAF que tenham de estar imediatamente acessíveis após a mudança?
- A plataforma de destino deve voltar a ser hardware ou uma appliance virtual ou cloud?
Backup-Restore Assistant e Port-Mapping
O Migration Center para migrações XG-para-XGS é a referência externa mais importante para Port-Mapping e Backup-Restore Assistant. Isto é importante porque nomes de portas, número de portas, módulos Flexi-Port, modelos Wireless e modelos de destino nem sempre correspondem 1:1.
Na prática, deve preparar-se uma tabela de portas antes do restore:
- Port1: Port1. LAN. VLANs, DHCP, DNS.
- Port2: Port2. WAN. Gateway, Alias-IP, NAT.
- Port3: Port4. DMZ. Firewall Rules, WAF, DNAT.
- Flexi Port: módulo novo. Uplink ou Trunk. compatibilidade do módulo.
Se o endereço MAC WAN mudar, routers a montante ou CPEs do provider ainda podem manter entradas ARP antigas. Perante esses sintomas, o artigo Resolver problema ARP na Sophos Firewall após migração ajuda.
Tratar HA separadamente
Um cluster HA XG não é simplesmente substituído por restore para dois novos dispositivos XGS. HA tem de ser planeado conscientemente de novo: igualdade de modelo, versão de firmware, licenças, porta HA, monitoring, passphrase, troca de papéis e janela de teste. Os detalhes pertencem ao planeamento HA, por exemplo com Configurar Sophos Firewall High Availability.
Atualizar Central, Reporting, SD-WAN e ZTNA
Após o restore, a nova XGS não fica automaticamente integrada de forma igual em todas as funções Sophos Central. Consoante o ambiente, é necessário:
- registar a nova firewall em Sophos Central,
- verificar Firewall Management e Central Reporting,
- controlar licença Central Firewall Reporting e associação de dados,
- reatribuir SD-WAN Connection Groups,
- mudar ZTNA Gateways para a nova firewall,
- testar atribuição de RED e Access Points,
- rever notificações, backups e relatórios agendados.
Para setups de reporting, ver adicionalmente Ativar Central Firewall Reporting. Para evidências operacionais após a migração, Testar regra da Sophos Firewall com Log Viewer e Packet Capture e Analisar pacotes descartados na Sophos Firewall são mais úteis do que um simples teste de ping.
Erros típicos em migrações XG-para-XGS
Modelo de destino demasiado pequeno
Um modelo sucessor aparentemente adequado pode ser pequeno demais se, desde a aquisição original da XG, tiverem sido adicionados mais utilizadores, mais VPNs, mais TLS Inspection, mais Web Protection ou mais largura de banda. Por isso, não se deve comparar apenas modelo XG contra modelo XGS, mas sim considerar carga real, funções de proteção ativas e crescimento.
Port-Mapping verificado apenas de forma superficial
Se LAN, WAN, DMZ, VLAN-Trunks, portas HA ou ligações de provider forem ligados de forma diferente, um restore bem-sucedido não basta. Após o restore, Interface-Zones, Gateways, SD-WAN Routes, regras NAT, regras WAF e Firewall Rules têm de ser verificados de forma direcionada.
Firmware antigo ou backup antigo
Um backup muito antigo aumenta o risco de Interface-Mapping, certificados, VPNs ou configurações especiais migrarem de forma inesperada. Antes da mudança, deve colocar-se a firewall antiga, na medida em que ainda faça sentido e seja suportado, numa versão adequada e criar um backup recente.
Sistemas dependentes esquecidos
Muitas migrações não falham no restore, mas sim em sistemas dependentes: Monitoring, Syslog, SIEM, e-mails de backup, VPN clients, ARP do provider, DNS, DHCP, RED, Access Points ou Sophos Central. Estes pontos pertencem à checklist, não à investigação de erros depois da comutação.
Checklist antes da mudança
- Firmware atual da XG e firmware de destino da XGS documentados.
- Backup atual criado e palavra-passe de restore guardada em segurança.
- Secure Storage Master Key conhecido e documentado.
- Port-Mapping preparado para WAN, LAN, DMZ, VLAN-Trunks e HA.
- Transferência de licença, registo Central e estado de suporte verificados.
- VPNs, NAT, WAF, SD-WAN, DHCP, DNS e routing preparados como lista de teste.
- RED, Access Points, ZTNA, Central Reporting e Monitoring considerados.
- Plano de rollback definido com dispositivo antigo, plano de cabos e janela de manutenção.
- Contactos para provider, DNS, monitoring e aplicações disponíveis.
Verificação após a migração
Depois da comutação, não se deve verificar apenas se a Internet funciona. Uma migração limpa só está concluída quando as funções operacionais mais importantes foram validadas:
- Verificar Dashboard, estado de licença, registo Central e e-mail de backup.
- Testar WAN-Gateway, endereços Alias-IP, NAT e serviços publicados.
- Verificar Site-to-Site VPN, Remote Access VPN e perfis Sophos Connect.
- Controlar SD-WAN Routes, rotas estáticas e Route Precedence.
- Testar Firewall Rules com logging.
- Verificar por amostragem IPS, Web Protection, TLS Inspection e Application Control.
- Controlar ligações RED e Access Point.
- Testar Syslog, Central Reporting, notificações e Monitoring.
- Retirar a XG antiga de operação apenas após uma fase estável.
Se alguns destinos não estiverem acessíveis imediatamente após a migração, deve trabalhar-se sistematicamente com Log Viewer, Packet Capture e verificações de routing. Para o diagnóstico de base, ajudam Usar Sophos Firewall Packet Capture no WebAdmin e Alterar Route Precedence na Sophos Firewall com segurança.