Saltar para o conteudo
Avanet

Criar ou restaurar um backup de Sophos Firewall

Sophos Firewall

Um backup de Sophos Firewall é a base para atualizações de firmware, substituição de hardware, reimage, trabalhos de HA e migrações. No entanto, o ficheiro por si só não é suficiente: um restauro fiável também exige a palavra-passe do backup, o Secure Storage Master Key (SSMK) correto, uma versão de destino compatível e um acesso de gestão funcional.

⚠️ Importante: Antes de uma alteração com risco, o ficheiro de backup, a palavra-passe, o SSMK, a versão de destino, o IP de gestão e o caminho de restauro têm de estar disponíveis e verificados. Um backup guardado apenas na firewall ou sem a chave correspondente não é um retorno fiável.

O vídeo mostra a criação e o restauro de backups no Sophos Firewall e complementa as recomendações práticas de recuperação deste artigo.

Caminho de recuperação e requisitos

Escolher o caminho de recuperação adequado

Um restauro não é a primeira medida correta para todos os problemas:

Antes de um reimage, é quase sempre necessário um backup para restauro. Em contrapartida, um rollback de firmware não substitui um backup, porque o slot de firmware e o estado de configuração guardado são caminhos de recuperação diferentes.

Palavra-passe do backup e Secure Storage Master Key

Os backups atuais de Sophos Firewall são encriptados com uma palavra-passe. Se o backup tiver sido criado depois da configuração do SSMK, o restauro exige a palavra-passe do backup e o SSMK válido nesse momento.

O SSMK protege informações sensíveis, como palavras-passe, secrets e chaves. É configurado pela conta admin predefinida e deve ser guardado num gestor de palavras-passe ou noutro processo de recuperação protegido. Pelo menos duas pessoas autorizadas devem saber onde está guardado.

Se o SSMK for alterado mais tarde, os backups antigos continuam associados à chave anterior. Por isso, é necessário conservar as versões atual e anteriores do SSMK com o respetivo período de validade e associação à firewall.

Os legacy backups sem SSMK podem ser restaurados sem a master key. Se for restaurado um backup agendado sem SSMK, o agendamento guardado continua ativo, mas a frequência só pode ser alterada depois de configurar um SSMK. Em seguida, deve ser criado imediatamente um novo backup manual.

A ajuda pública do SFOS 22 contradiz-se quanto ao Factory Reset: a página específica do reset indica que o SSMK não é eliminado, enquanto a página geral de firmware afirma que é removido. Por isso, a chave deve ser guardada externamente antes de cada reset e o seu estado verificado depois, sem depender da sua disponibilidade. Um reimage remove claramente o SSMK atual; segundo a Sophos, Boot with factory default configuration na vista Firmware conserva-o. Um rollback de firmware ativa o estado de configuração da partição anterior. O histórico de chaves guardado continua a ser necessário em cada um destes caminhos.

Repor o SSMK apenas como alteração break-glass planeada

O Secure Storage Master Key só pode ser reposto através da CLI com o Super Administrator predefinido admin. A opção de menu só aparece depois de ter sido criado um SSMK. Outro administrador não pode executar esta alteração.

⚠️ O novo SSMK não consegue desencriptar backups antigos criados com a chave anterior. Uma reposição não substitui, por isso, nem o histórico de chaves guardado nem o SSMK antigo. Esta operação não é um teste sem riscos.

Antes da reposição, guardar externamente um backup atual, a respetiva palavra-passe e o SSMK anterior. Depois, aceder a 2. System Configuration > 5. Reset secure storage master key:

  1. Introduzir a palavra-passe do admin predefinido.
  2. Introduzir o novo SSMK.
  3. Voltar a introduzir a nova chave para confirmação.

A nova chave requer pelo menos 12 caracteres, incluindo pelo menos uma letra maiúscula, uma letra minúscula, um algarismo e um dos carateres especiais suportados pelo SFOS:

! # $ % & ( ) * + , - . / : ; < = > ? @ [ ] ^ _ ` { | } ~

Guardá-la imediatamente com a firewall, o número de série e a data de ativação no sistema de recuperação protegido, nunca num ticket, screenshot ou histórico da shell.

Após a reposição, criar imediatamente um novo backup manual e guardá-lo externamente. Verificar também os backups agendados, credenciais guardadas, VPNs, certificados, ligação ao Central e acesso de gestão. Manter os backups anteriores com o respetivo SSMK; a nova chave não permite restaurá-los.

Pacote de recuperação por firewall

Cada localização ou tenant deve ter, além do backup, um pacote de recuperação protegido:

  • último backup verificado com data e finalidade
  • palavra-passe do backup e SSMK atual e anteriores
  • nome da firewall, número de série, modelo e versão do SFOS
  • credenciais WAN, informações do operador e default gateway
  • atribuição de interfaces, VLAN, LAG, bridges e portas HA
  • acesso local de administrador e break-glass
  • atribuição da licença e do Sophos Central
  • serviços críticos com testes de aceitação concretos

O backup e as credenciais não devem ser guardados em conjunto sem proteção. O pacote de recuperação deve ser atualizado após alterações de pessoal, operador, portas, HA ou localização.

Criar e gerir backups em segurança

Backup manual antes de alterações

Backup & Firmware > Backup & Restore
Criar um backup da configuração do SFOS
Sophos Firewall Backup & Restore: criar um backup manual e configurar backups agendados

Backup Now cria um backup imediato. Em seguida, o ficheiro deve ser guardado externamente e devem ser documentados, pelo menos, o nome da firewall, o número de série, a versão do SFOS, a data e a finalidade da alteração.

Em Download, é possível selecionar Download encrypted backup ou Encrypt backup with a different password before you download. A segunda palavra-passe aplica-se apenas à cópia transferida; não altera a Encryption password guardada para backups posteriores. Por isso, o ficheiro e a palavra-passe efetivamente utilizada devem ficar associados de forma inequívoca ao pacote de recuperação.

Um backup manual é particularmente importante antes de:

  • alterações de firmware, interfaces, VLAN, routing, SD-WAN ou VPN
  • configuração de HA, mudança de funções ou manutenção do cluster
  • alterações importantes de regras NAT, WAF ou firewall
  • reimage, factory reset, substituição de hardware ou migração de plataforma

Em alterações maiores, o Sophos Firewall Config Studio também pode mostrar diferenças de configuração. Uma comparação de Entities.xml não substitui um backup para restauro.

Se apenas uma parte claramente delimitada da configuração tiver de ser transferida ou alterada, exportar e importar seletivamente a configuração descreve o processo WebAdmin separado. Este import também não substitui o percurso completo de recuperação.

Backups automáticos

Em Frequency, é possível configurar backups diários, semanais ou mensais. Dependendo da configuração, os destinos disponíveis são armazenamento local, FTP e e-mail.

Pontos operacionais importantes:

  • Um backup local não ajuda se o appliance falhar ou for reinstalado.
  • Apenas o último backup local permanece na firewall; as versões anteriores necessárias têm de ser guardadas externamente.
  • Os backups por FTP e e-mail só são considerados funcionais após um teste real de entrega, obtenção e desencriptação.
  • O SFOS 22 limita Backup prefix a 32 carateres e não aceita, entre outros, /, \, :, *, ?, ", <, >, |, ~, `, .. nem letras UTF-8 que não sejam inglesas. O nome de utilizador FTP não pode conter \; os únicos carateres especiais suportados no nome de utilizador e na palavra-passe FTP são @, / e $. O nome do host no assunto de um backup por e-mail está limitado a 25 carateres.
  • Os backups automáticos não substituem um backup manual recente imediatamente antes de uma alteração com risco.
  • O período de conservação, o acesso e o processo de eliminação têm de corresponder aos requisitos de proteção da configuração.

Os backups da firewall contêm informações confidenciais sobre redes, regras, VPN, certificados e dados de contas. O acesso deve ser limitado a administradores e responsáveis pela recuperação; a palavra-passe e o SSMK permanecem separados, mas localizáveis numa emergência.

Backups do Sophos Central

Atualmente, a Sophos documenta dois caminhos de navegação no Central, consoante a vista e a página de ajuda:

Global Settings > Products and Services > Firewall
My Products > Firewall Management > Backup

A firewall tem de estar ligada ao Sophos Central e autorizada para backups de configuração. Ligar o Sophos Firewall ao Sophos Central descreve a configuração da ligação.

O agendamento deve ser sempre verificado explicitamente, em vez de se assumir um valor predefinido. Quando a primeira firewall é adicionada automaticamente a um agendamento vazio definido como Never, o Central pode alterá-lo uma vez para Monthly e para o primeiro dia do mês. Os agendamentos existentes não são alterados.

Outras propriedades fixas:

  • Os backups são executados às 08:00 no fuso horário da região do Central; a hora não pode ser alterada.
  • O Central tenta criar o backup até cinco vezes e, em seguida, gera um alert e um e-mail para o administrador.
  • São mantidos os cinco backups mais recentes; pode ainda ser guardado permanentemente exatamente um backup.
  • Ao efetuar o download, o backup é novamente encriptado com uma nova palavra-passe.
  • A remoção da firewall do Central Management elimina os respetivos backups no Central. Os ficheiros necessários devem ser descarregados antes de uma mudança de conta, RMA ou limpeza do tenant.
  • Em HA, Primary e Auxiliary são adicionados ao agendamento, mas o backup é criado pelo Primary.

Se uma firewall registada não aparecer no agendamento, deve ser adicionada em Schedule Backup. Se Send configuration backup to Sophos Central já estiver ativo, desmarque a caixa, aplique, volte a marcá-la, aplique novamente e, depois, aceite a autorização de serviço pendente no Central.

O Central é uma boa localização de armazenamento adicional, mas não substitui o SSMK, o acesso local, os dados WAN e uma cópia de backup acessível de forma independente.

Preparar e executar um restauro

Preparação e teste de restauro seguro

Antes do restauro, confirme:

  • disponibilidade do ficheiro de backup correto, da palavra-passe e do SSMK válido nessa altura
  • compatibilidade entre versão de origem, versão de destino, modelo e plataforma
  • armazenamento externo de um backup do estado atual da configuração
  • conhecimento do IP de gestão do backup e do acesso local
  • documentação dos dados de WAN, NTP, DNS, licença e Central
  • definição do destino HA e da sequência de restauro
  • preparação do mapeamento de interfaces e das diferentes atribuições de portas

⚠️ Atenção: Um restauro substitui a configuração atual e reinicia a firewall. Um aviso sobre um caminho de migração não suportado não deve ser confirmado por rotina; a firewall pode iniciar posteriormente com a factory configuration.

Um teste de restauro real deve ser efetuado numa firewall de laboratório ou de substituição adequada. Antes do teste, desative ou isole as ligações WAN, VPN e Central de produção para evitar conflitos de endereços, túneis ou registos duplicados.

Sem um equipamento de teste, é possível efetuar pelo menos um teste organizacional: obter o backup no armazenamento previsto, verificar a sua atribuição, confirmar a palavra-passe e o SSMK, avaliar a plataforma de destino e percorrer no runbook o acesso de gestão e os testes de aceitação. Isto não substitui um restauro real, mas elimina muitos problemas clássicos de emergência.

Restaurar um backup

Backup & Firmware > Backup & Restore
  1. Aceder à firewall de destino através do WebAdmin.
  2. Guardar o estado atual, caso ainda seja possível.
  3. Em Restore configuration, selecionar o ficheiro de backup com Choose file.
  4. Introduzir a Encryption password e, para um backup protegido por SSMK, também o SSMK válido na altura.
  5. Iniciar Upload and Restore.
  6. Aguardar pelo reinício e pelo restauro.
  7. Abrir o WebAdmin através do IP de gestão do backup.
  8. Verificar o fuso horário, NTP e a hora atual.
  9. Validar a rede, os serviços, a VPN, o HA e a ligação ao Central.

O restauro elimina o backup guardado localmente na firewall de destino. Por isso, o ficheiro utilizado tem de continuar disponível externamente. Num appliance novo, conclua primeiro o setup wizard e, depois, restaure o backup.

O que um restauro não resolve automaticamente

Com exceção da palavra-passe da conta admin predefinida, o SFOS restaura a configuração, incluindo tokens MFA de todos os utilizadores, utilizadores VPN, RED, configurações VPN site-to-site e de acesso remoto e Sophos Connect. ApplianceCertificate, Default CA, SecurityAppliance_SSL_CA e chaves pre-shared também são restaurados a partir do backup. Assim que o routing e as interfaces voltam a estar ativos, estas relações de confiança e túneis podem voltar a produzir efeito. Por isso, um restauro de laboratório permanece isolado até serem verificados VPN, RED, certificados, Central e as redes de destino.

  • A palavra-passe da conta admin predefinida não é restaurada a partir do backup; a firewall de destino mantém a palavra-passe existente. Se tiver sido perdida, num appliance físico é reposta separadamente através da consola série. Para firewalls virtuais e cloud, é necessário verificar a consola da plataforma e o caminho de recuperação suportado.
  • Depois do reinício, o IP de gestão, o Device Access, as rotas e os serviços voltam a ser obtidos do backup.
  • Os valores personalizados de data e hora em Administration > Time não são incluídos no backup. Só são restaurados o fuso horário e os servidores NTP; os valores horários manuais têm de ser novamente configurados e verificados após o restauro.
  • Os valores dependentes do modelo ou da instance podem regressar aos defaults se não forem adequados ao destino. A Sophos indica como exemplo o número de instâncias IPS: Se for alterado para o modelo de destino durante o restauro, o destino aplica o seu default em vez do valor do backup.
  • O Sophos Central só permanece registado ao restaurar para a mesma firewall. Uma firewall diferente ou um cluster HA tem de ser novamente registado; depois, é necessário verificar Security Heartbeat, ZTNA, Central Management, Backup, Reporting, Task Queue e a atribuição a grupos.
  • Logs, reports e dados de monitorização externa não fazem parte de um rollback completo da configuração.

Numa migração para o modo FIPS 140-3, o estado do backup também é decisivo: Um backup com FIPS desativado restaura o estado sem FIPS e é, por isso, um caminho de regresso, não uma transferência sem alterações para o modo FIPS.

Restaurar para outro hardware e outras plataformas

Compatibilidade e versões do SFOS

Antes de uma migração, registe a versão de origem, a versão de destino, o modelo de destino e a plataforma. O backup-restore compatibility check faz agora parte do Sophos Firewall Config Studio. Abra Backup-restore compatibility e verifique a compatibilidade dos modelos XG e XGS Appliance, bem como dos módulos Flexi Port e transceivers utilizados. A ferramenta aplica-se ao SFOS 20.0 MR2 e posterior; considere também as informações de atualização nas release notes atuais e o SFOS 22 Upgrade Check.

O SFOS 22 tem limites rígidos:

  • O SFOS 22.0 GA e versões posteriores não suportam hardware XG ou SG.
  • Os backups com legacy CLI VLAN tagging em bridge interfaces não podem ser restaurados para o SFOS 22.0 GA ou posterior. Verificar Bridge VLAN antes do SFOS 22 descreve a limpeza.
  • O Legacy Remote Access IPsec bloqueia atualizações para o SFOS 22.0 MR1 e versões posteriores. O restauro ou a importação para estas versões não migra a configuração antiga; primeiro, é necessário mudar para o método suportado. Consulte Migrar Legacy Remote Access IPsec.

Backup-Restore Assistant e mapeamento de interfaces

O Assistant só aparece quando todas as condições são cumpridas:

  • O backup provém de XG, SG com SFOS, uma XGS Appliance, virtual ou cloud com SFOS 19.5 MR4 ou posterior.
  • O destino utiliza SFOS 20.0 MR2 ou posterior.
  • O destino é uma XGS Appliance, virtual ou cloud.

O Assistant não aparece em destinos XG ou SG nem para backups do SFOS 19.5 MR3 ou anterior. Nesse caso, a firewall efetua o mapeamento automaticamente; depois, é necessário verificar com especial cuidado interfaces, zones, gateways, VLAN, HA link, SD-WAN, NAT e VPN.

O Assistant também pode ser utilizado no mesmo appliance compatível para mover VLAN ou configurações de interfaces para outra porta física.

O Assistant apresenta em conjunto os modelos de origem e destino, os detalhes das interfaces e os mapeamentos disponíveis. Ao passar o ponteiro sobre uma interface de origem, o SFOS mostra o endereço IP, a máscara de sub-rede, o tipo de atribuição de IP e o link mode. Antes do mapeamento, estes valores são comparados com o plano de portas e a cablagem; um nome de porta semelhante, por si só, não é um critério suficiente.

Por predefinição, o SFOS mapeia portas equivalentes. Se a porta correspondente não existir no dispositivo de destino, seleciona a porta disponível seguinte. Esta automatização é apenas uma proposta e deve ser verificada; com Don’t map. Creates Pseudo port, a configuração é deliberadamente mantida numa pseudo port não funcional.

Interfaces físicas e lógicas

  • Porta física: mapear deliberadamente para uma porta de destino ou deixar sem mapeamento; verificar cablagem, zone e função WAN/LAN.
  • VLAN ou alias: acompanha a parent interface mapeada; a parent port tem de estar operacionalmente correta.
  • LAG ou bridge: é recriada a partir das portas físicas mapeadas; verificar o número de members e a configuração do switch.
  • RED ou Cellular: a configuração associada é migrada; testar especificamente a ligação após o restauro.

Pseudo ports, breakout, management e HA

  • Pseudo port: mantém a configuração, mas não processa tráfego. Mover routing, NAT, VLAN e regras para uma porta ativa.
  • Breakout root port: só é possível mapear root ports, não members individuais. O destino requer um número e uma combinação de portas suportados. Configurar interfaces breakout explica a criação, o reinício e a verificação.
  • Management port: é mapeada para uma management port existente ou mantida como pseudo port. Planear antecipadamente a rede de gestão e o acesso local.
  • Dedicated HA link: o tipo de porta tem de permanecer igual; o Assistant não pode alterar a porta HA link. Para LAG, o número de members tem de corresponder; para VLAN, o VLAN ID; e para monitored ports, o estado de destino.

Uma pseudo port tem o estado Not available e normalmente o nome de hardware Pseudo<port number>. Em backups do SFOS 19.5 MR3 ou anterior pode aparecer o nome de porta original, mas a interface continua não funcional. Para breakout, o destino tem de ter configuradas pelo menos tantas breakout ports como o backup. Só são mapeadas root ports; uma porta física de origem pode ser mapeada para uma breakout root port suportada.

Antes de eliminar uma pseudo port, mova todas as rotas dependentes e as configurações NAT, de firewall e de VLAN. Em seguida, defina a zone como None em Network > Interfaces e reinicie a firewall numa janela de manutenção. Depois, confirme que a porta foi removida; pseudo ports não associadas com configuração VLAN não são eliminadas automaticamente.

O Backup-Restore Assistant remapeia interfaces, mas não torna compatível uma configuração Wireless ou bridge que não seja suportada no destino. Essas dependências têm de ser corrigidas ou ajustadas na origem antes do backup de migração, ou planeadas novamente para o destino.

Destinos HA, Wireless, virtual e cloud

Um backup que contenha uma configuração HA também pode ser restaurado num dispositivo standalone, mas o SFOS só restaura a restante configuração, não o HA. Para manter o HA, configure primeiro o novo cluster e restaure o backup no Primary atual, ou restaure primeiro e configure o HA depois. Não é possível restaurar um backup no Auxiliary.

Num cluster active-passive ou active-active existente, o Primary atual reinicia após o restauro sem failover. Por isso, o restauro causa uma interrupção em ambos os modos HA. Se o backup contiver uma configuração HA, o Primary sincroniza o Auxiliary após reiniciar. O restauro para um cluster HA também remove o registo de ambas as firewalls do Sophos Central. Volte a registar ambas as firewalls no Sophos Central e, se o Primary era utilizado como gateway Sophos ZTNA, adicione-o novamente como gateway. Se um backup sem configuração HA for restaurado no Primary atual, o HA é desativado e tem de ser configurado novamente. Depois, verifique especificamente as funções, a versão do firmware, o Dedicated HA link e as monitored ports.

A Sophos distingue três grupos Wireless para este restore: Gen.2 inclui XGS 88w, 108w, 118w e 128w; Gen.1 inclui XGS 87w, 107w, 116w, 126w e 136w; e a série XG inclui XG 86w, 106w, 115w, 125w e 135w. A pertença a um destes grupos determina a direção de restore suportada; um nome de modelo semelhante não é suficiente.

As migrações Wireless têm limites adicionais:

  • Para Wireless-to-Non-Wireless, remova Wireless Networks antes de criar o backup.
  • Os backups de modelos Gen.2 XGS Wireless não podem ser restaurados para modelos XG ou Gen.1 XGS Wireless.
  • Ao migrar modelos Wireless mais antigos para Gen.2 XGS, aplicam-se limites adicionais a SSID, WPA, bridge mode e radio bands.

Configurações LocalWiFi e bridge durante a migração

Para restaurar um backup de XG Wireless ou Gen.1 XGS Wireless num modelo Gen.2 XGS W, aplicam-se os seguintes requisitos e limitações:

  • LocalWiFi0 e LocalWiFi1 têm apenas SSID com, pelo menos, WPA2 atribuídos.
  • A encriptação não utiliza TKIP nem TKIP/AES.
  • Nenhuma interface Wireless pertence a uma bridge física.
  • LocalWiFi0 e LocalWiFi1 utilizam, em conjunto, no máximo oito SSID únicos.
  • Se ambos os rádios utilizarem a mesma banda de frequência, apenas são restauradas as definições de LocalWiFi0.

A diferença entre as bridges é determinante. Para uma Wireless Network do tipo Bridge to AP LAN, os modelos Gen.1 XGS 87w, 107w, 116w, 126w e 136w ligam a rede Wi-Fi local à LAN através de uma bridge física. Os modelos Gen.2 XGS 88w, 108w, 118w e 128w não suportam esta arquitetura; nestes modelos, utiliza-se Bridge to Ethernet em Wireless > Access points > LocalWiFi > Advanced settings, com exatamente uma porta Ethernet e a zone LAN. A configuração em Gen.2 é explicada em Configurar Wi-Fi diretamente na Sophos Firewall.

Se o backup Gen.1 ainda contiver uma bridge física com a interface de uma Wireless Network do tipo Bridge to AP LAN, o restauro para Gen.2 falha. A Sophos identifica este comportamento como Known Issue NC-135094. Se alguma das configurações OSPF, OSPFv3, RIP, SPX Portal Setting ou Quarantine referenciar esta interface, o restauro é concluído, mas a configuração dependente não funciona em Gen.2.

Antes do backup de migração, verifique em Network > Interfaces se uma interface Wireless pertence a uma bridge e documente todas as definições dependentes. Não remova uma bridge em produção sem preparação: numa janela de manutenção, migre primeiro o endereço IP, a zone, o DHCP, as portas ligadas e as dependências de routing para uma arquitetura compatível com Gen.2. Em seguida, crie um novo backup. No destino, configure novamente Bridge to Ethernet e teste especificamente os SSID, o modo de segurança, as bandas de frequência, o DHCP e os serviços anteriormente dependentes.

Antes de uma migração de XG para uma XGS Appliance, também é útil a comparação entre XG e XGS Appliance.

Para firewalls virtual e cloud, o processo integrado de backup e restauro da Sophos é o único caminho de recuperação SFOS suportado. A Sophos não suporta hypervisor snapshots, cloud images ou backups de terceiros para este fim; estes podem causar problemas de integridade de dados ou configurações não suportadas.

Validar após o restauro

Verificação técnica

Imediatamente após o restauro, verifique:

  • IP do WebAdmin, redes de gestão permitidas e Device Access
  • interfaces, zones, VLAN, bridges, LAG e alias interfaces
  • WAN, PPPoE, default gateway, rotas estáticas e SD-WAN
  • regras de firewall, NAT e WAF, incluindo a ordem
  • IPsec, SSL VPN, Sophos Connect, RED e Remote Access
  • certificados, TLS Inspection, DNS, DHCP, NTP e Authentication Server
  • estado de HA, funções e sincronização
  • estado da licença, Pattern Updates, Hotfixes e sincronização do Central
  • Log Viewer, Syslog, Central Reporting e reporting local

Consoante o problema, podem ajudar Log Viewer, Policy Test e Packet Capture, Packet Capture no WebAdmin e a visão geral de Services e Logs. A Sophos não indica um caminho de logs SSH universal e fiável para erros gerais de restauro; por isso, não é sugerido aqui qualquer comando shell.

Segundo a Sophos, uma mensagem de erro detalhada no WebAdmin só é garantida para um caminho de restauro mais restrito: O backup provém de uma appliance compatível com SFOS 19.5 MR4 ou posterior, o destino executa SFOS 20.0 MR2 ou posterior e é um XGS 88/88w, 108/108w, 118/118w, 128/128w ou 138. Noutros destinos, a ausência de uma mensagem na interface não significa que não tenha ocorrido um erro. Por isso, registam-se a hora, as versões de origem e destino, os modelos e a ação de restauro exata, correlacionando-os com os logs ou um caso de suporte. As revisões de hardware Rev.1, Rev.2 e Rev.3 seguem as mesmas regras de compatibilidade, mas o par de modelos concreto continua a ter de ser verificado em Compatibility Check.

Testes de aceitação

Um WebAdmin acessível não comprova que o tráfego de produção funciona. Para cada localização, devem ser documentados a origem concreta, o destino, a regra esperada e a entrada de log esperada para estes testes:

  • Gestão: acesso a partir da rede de gestão e início de sessão de um segundo administrador.
  • Internet: um cliente de teste alcança um destino externo definido através da regra, NAT e rota WAN corretos.
  • DNS e DHCP: um cliente recebe um endereço e resolve nomes internos e externos.
  • Site-to-Site VPN: hosts definidos estão acessíveis em ambas as direções.
  • Remote Access: um utilizador de teste verifica login, MFA, perfil, DNS e um destino interno.
  • WAF ou DNAT: um teste externo confirma certificado, regra, backend e logging.
  • Autenticação: AD, LDAP, RADIUS, STAS ou Entra SSO identifica corretamente um utilizador de teste.
  • Logging: o tráfego de teste é visível no Log Viewer, Syslog, Central Reporting ou SIEM.
  • HA: as funções, o estado do cluster e a sincronização correspondem ao plano.

Se WAN, DNS, Remote Access ou HA não funcionar, não altere várias áreas em simultâneo. Restrinja o problema com a hora, a origem do teste, o destino, a regra e o excerto de log e volte a testar após cada correção.

Troubleshooting e operação

Erros típicos

  • O backup existe apenas na firewall: fica indisponível após uma falha ou reimage; deve ser guardado externamente e em segurança.
  • Falta o SSMK: os dados protegidos não podem ser restaurados; devem ser documentadas as chaves atual e anteriores.
  • Ficheiro sem referência ao equipamento ou à versão: é selecionado o backup errado; devem ser registados o nome da firewall, o número de série, a versão e a data.
  • Sem backup do estado atual antes do restauro: não existe um caminho de retorno ao estado anterior.
  • IP de gestão restaurado desconhecido: a firewall parece offline; o endereço e o acesso local devem ser documentados antecipadamente.
  • Hora ou NTP incorretos: VPN, certificados, autenticação e Central podem falhar.
  • Caminho de restauro não suportado confirmado: o restauro falha ou o destino inicia com a factory configuration.
  • Mapeamento de interfaces não verificado: WAN, VLAN, VPN ou HA link ficam nas portas erradas.
  • Limites de Wireless ignorados: o backup é incompatível ou a configuração sem fios não funciona como esperado.
  • Contexto de HA ignorado: a configuração ou as funções do cluster perdem-se ou iniciam incorretamente.
  • Central como única cópia: a remoção da firewall do Central elimina esses backups.
  • Apenas o WebAdmin foi verificado: falhas de routing, NAT, VPN, WAF, DNS ou logging passam despercebidas.

Rotina operacional

Regularmente:

  • verificar backups automáticos, entrega, obtenção e conservação
  • verificar o armazenamento, as permissões e o SSMK atual e anteriores
  • manter atualizados o pacote de recuperação e os testes de aceitação
  • verificar periodicamente o ficheiro, a palavra-passe, o SSMK e a compatibilidade do destino

Antes de alterações importantes:

  • criar um backup manual, guardá-lo externamente e identificá-lo de forma inequívoca
  • definir o acesso de gestão, o caminho de restauro e os critérios de interrupção
  • nas migrações, verificar a compatibilidade, a versão do SFOS e o mapeamento de interfaces

Após um restauro:

  • documentar integralmente as verificações técnicas e os testes de aceitação
  • corrigir desvios e comparar com o Config Studio, se necessário
  • criar um novo backup do estado de destino verificado e atualizar o pacote de recuperação