Atualização do firewall sem interrupção: disciplina de backup, atualização e reversão
Uma atualização de firewall raramente falha por causa do comando de atualização em si — ela falha porque algo não foi copiado, o pacote não foi verificado antes de ser carregado, ou um par em espera ativa foi atualizado na ordem errada. Esta é a lista de backup, os passos de verificação do pacote, a sequência isolar-atualizar-verificar-comutar para um par em espera ativa, o caminho de reversão, e a lista de verificação a executar antes de fechar a mudança.
Por Atlas Yuwen Zhang, fundador da AtlasCommTech — 18 anos em ICT, 13 deles em redes de operadoras · Atualizado em julho de 2026
Por que incidentes de atualização são, na verdade, incidentes de backup
Quase toda atualização que dá errado remonta a uma destas três lacunas — algo não foi copiado, o pacote não foi verificado antes de ser carregado, ou um par em espera ativa foi atualizado na ordem errada.
A maioria das atualizações de firewall é rotineira, até aquela que não é — e nessa hora já é tarde demais para voltar e fazer backup da configuração que acabou de ser sobrescrita. As diretrizes de manutenção da Huawei para a plataforma HiSecEngine USG6000F, USG6000G e USG12000 tratam o backup como pré-condição de qualquer operação de manutenção séria, não como um pensamento posterior: os dados críticos da rede são citados explicitamente — topologia e inventário de dispositivos, arquivo de configuração, arquivo de License, e arquivos do software do sistema e dos patches — para serem copiados antes de qualquer outra coisa acontecer.
A seguir está essa lista de backup, como verificar um pacote de atualização antes de carregá-lo, a sequência que mantém um par em espera ativa passando tráfego durante toda a atualização, o caminho de reversão caso a nova versão não funcione, e a lista de verificação a executar antes de considerar a mudança concluída.
O que fazer backup antes de tocar no comando de atualização
A documentação do fabricante nomeia explicitamente esta lista como os dados críticos da rede — faça backup dela antes que qualquer outra coisa aconteça.
| Categoria | O que abrange | Por que importa |
|---|---|---|
| Topologia e inventário de dispositivos | Modelos de dispositivos, versões de software e patches, diagrama de topologia | Sem um instantâneo de o que estava conectado a o quê, uma atualização ruim passa de “reverter um dispositivo” para “reconstruir a rede de memória”. |
| Arquivo de configuração | vrpcfg.cfg / current-configuration | Todo caminho de reversão pressupõe que você ainda tem isso, em uma forma que pode comparar. |
| Arquivo de License | Carregado de forma independente em cada dispositivo | Um par em espera ativa não compartilha uma License — cada dispositivo precisa da sua própria, com o mesmo conjunto de recursos e vencimento. |
| Arquivos do software do sistema e dos patches | Os pacotes .cc atualmente em execução, mais qualquer patch carregado | Tanto a versão para a qual você está migrando quanto a versão da qual está saindo — excluir a antiga antes que a nova seja verificada remove seu caminho de reversão. |
| (Opcional) Logs e versões da base de assinaturas | Versões da base de recursos IPS / AV / URL | Confirma que nada regrediu silenciosamente; não é obrigatório para uma reversão básica. |
A documentação do fabricante compara Console, FTP, TFTP, SFTP e SCP como métodos de transferência de arquivos: TFTP e FTP simples enviam dados e credenciais de login em texto claro, enquanto SFTP e SCP criptografam e protegem a integridade da transferência. Para retirar um backup de configuração ou License de um dispositivo em produção, prefira SFTP ou SCP em vez de FTP ou TFTP.
A sequência de atualização de ponta a ponta
Dez passos, nesta ordem — pule a etapa de isolamento e um par em espera ativa pode acabar dividido; pule a etapa de verificação e você estará levando adiante uma suposição não verificada.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Os passos 1 a 5 rodam em um dispositivo de um par em espera ativa, isolado de seu par; os passos 6 a 10 repetem o mesmo padrão isolar-atualizar-verificar no outro dispositivo, depois que o tráfego foi comutado de propósito. Em um firewall único, sem redundância, os passos 3, 6 e 7 simplesmente não se aplicam — mas 1, 2, 4, 5, 9 e 10 continuam se aplicando.
Verifique o pacote antes de carregá-lo
Uma atualização falha geralmente não é um arquivo ruim — é um arquivo não verificado; algumas verificações detectam a maior parte do que apareceria no meio da atualização.
- Se for extrair o arquivo via FTP/SFTP, confirme primeiro se o dispositivo consegue sequer alcançar o servidor de arquivos: faça Ping entre o PC e o dispositivo, e faça login manualmente uma vez no serviço FTP ou SFTP para confirmar que o usuário e a senha estão realmente corretos nesse servidor.
- Verifique o espaço de armazenamento livre do dispositivo com dir antes de supor que uma transferência falha foi um problema de rede — um dispositivo flash cheio faz um upload falhar tão certeiramente quanto um link ruim.
- Verifique display version para confirmar que o pacote de software realmente corresponde ao tipo de hardware deste dispositivo; um pacote criado para o tipo de dispositivo errado não carregará não importa quantas vezes você tente novamente a transferência.
- Compare o tamanho do arquivo enviado com o tamanho do mesmo arquivo no servidor de origem — uma discrepância significa que a própria transferência ficou incompleta.
- Execute check system-software no arquivo enviado. Uma falha na verificação de assinatura não significa automaticamente que o arquivo está corrompido — verifique com um checksum antes de concluir isso e voltar à origem.
- Obtenha o valor SHA256 ou MD5 do arquivo no PC de origem com certutil -hashfile, depois compare com o valor do próprio dispositivo com check file-digest digest-algorithm sha256 (ou md5) — se coincidirem, a corrupção aconteceu antes mesmo de o arquivo chegar ao dispositivo.
<HUAWEI> dir
Directory of flash:/
Idx Attr Size(Byte) Date Time(LMT) FileName
10 -rw- 25,841,428 Nov 17 2015 09:48:10 basicsoft.cc
12 -rw- 26,101,692 Dec 21 2015 11:44:52 devicesoft.cc
1,927,220 KB total ( 1,130,464 KB free )
<HUAWEI> display version
Huawei YunShan OS
Version 1.23.0.X (XXX)
// software version must match this device's type — not interchangeable across device types
<HUAWEI> check system-software upgrade.cc
Caution! Confirm to check startup file! Continue? [Y/N]:y
Info: Prepare to check system software cfcard:/upgrade.cc, please wait, XX% completed.
// look for: System software signature check passed! / ...check failed!
C:\Users\xxxx> certutil -hashfile "C:\upgrade\upgrade.cc" SHA256
<HUAWEI> check file-digest digest-algorithm sha256 <hash-from-certutil> upgrade.cc
Info: Verification completed. The digest value of cfcard:/upgrade.cc is the same as the input digest value.Como atualizar um par em espera ativa sem perder tráfego
A ordem importa mais que os comandos — isole completamente um dispositivo, atualize-o sozinho, verifique-o, depois comute o tráfego de propósito.
- Antes de começar, confirme que os dois dispositivos do par ainda se qualificam para formar um par: modelo de produto, versão de software, versão de patch, pacote de recursos e versão da base de assinaturas idênticos; placas de interface idênticas em slots idênticos; interfaces de negócio e de batimento idênticas; e — como um par em espera ativa não compartilha uma License — cada dispositivo já com sua própria License válida, com conjunto de recursos e vencimento correspondentes.
- Escolha qual dispositivo atualizar primeiro (geralmente o de espera) e isole-o completamente: desligue suas interfaces de negócio e sua interface de batimento para que ele não tente renegociar seu papel com o par no meio da transferência.
- Carregue o novo software no dispositivo isolado e reinicie-o, depois confirme que ele realmente subiu na versão desejada com display version antes de mexer em qualquer outra coisa.
- Reative suas interfaces somente depois de confirmar a versão. Espere que ele se reintegre como espera, não ativo: um dispositivo reiniciado só tenta assumir o papel ativo depois que a configuração da placa principal é restaurada, pelo menos uma CPU está online, e pelo menos uma placa de interface que carrega o batimento voltou — e somente depois de esperar mais um minuto.
- Acione a comutação de propósito em vez de esperar uma falha não planejada para mover o tráfego — hrp switch standby no dispositivo que ainda roda a versão antiga, ou hrp switch active no dispositivo que você acabou de atualizar.
- Repita o ciclo isolar, atualizar, verificar no dispositivo que era originalmente ativo e agora está em espera.
- Execute os três testes de acionamento antes de fechar a mudança: desligar uma interface de negócio, desconectar fisicamente um cabo, e um reinício completo com corte de energia. Cada um precisa mover o tráfego para o outro dispositivo sem uma interrupção que um usuário notaria.
HRP_M[sysname] hrp switch standby
// forces this active device to yield; peer takes over as active
HRP_S[sysname] hrp switch active
// forces this standby device to take over as active
<sysname> system-view
[sysname] hrp track interface 10GE 1/0/1
// raises this device's HRP fault metric on a Down interface, for a controlled switchover test without touching live business interfacesCompare os arquivos de configuração dos dois dispositivos (uma ferramenta de diff funciona bem aqui). Tudo deveria coincidir exceto: o nome do dispositivo, o Router ID e os segmentos de rota que cada um anuncia, os endereços IP das interfaces, o estado de adesão da interface HRP, o atraso de preempção, e — apenas no modo de compartilhamento de carga — a faixa de portas NAT. Qualquer outra diferença vale a pena investigar antes de confiar no par.
Se algo der errado: o caminho de reversão
Reverter não é um reflexo de pânico — é a mesma disciplina da atualização, executada ao contrário, dentro de uma janela de mudança.
- reboot e startup system-software aparecem ambos na lista de operações perigosas por um motivo — veja Comandos perigosos de roteadores e switches. Reverter significa apontar deliberadamente startup system-software de volta para o arquivo de software anterior, ainda presente no dispositivo, e reiniciar dentro de uma janela aprovada — não como um reflexo assim que algo parecer errado.
- Se a falha parecer um problema de configuração em vez de um problema de versão de software, verifique exatamente o que mudou antes de restaurar qualquer coisa: display configuration commit changes na vista diagnose mostra os commits mais recentes, e display configuration changes start-time / end-time isola uma janela específica.
- Não exclua o pacote de software anterior com delete /unreserved até que a nova versão tenha passado na lista de verificação abaixo — essa exclusão é documentada como irrecuperável na mesma referência de operações perigosas.
- Em um par em espera ativa, reverta um dispositivo de cada vez usando a mesma sequência isolar, rebaixar, verificar, reintegrar da própria atualização; não reverta as duas metades ao mesmo tempo.
[HUAWEI] diagnose
[HUAWEI-diagnose] display configuration commit changes
Building configuration
Commit changes of commitId 1000000002 2024-12-23 07:08:24 by root
#
- sysname 11
#
+ sysname HUAWEI
[HUAWEI-diagnose] display configuration changes start-time 2025/06/18,12:01:18Lista de verificação antes de fechar a mudança
Seis verificações, executadas nos dois dispositivos de um par — a diferença entre “a atualização terminou” e “a atualização realmente funcionou”.
- display version — confirma que a versão de software e patch realmente corresponde ao plano nos dois dispositivos.
- display patch-information — confirma que o patch esperado está carregado, não apenas a imagem base.
- display license — confirma que a License está presente e ativa, não em estado Demo ou vencida em nenhum dos dispositivos.
- display hrp state — confirma que um dispositivo mostra Local role: Active, Peer role: Standby. Peer role: Unknown nos dois lados é uma divisão dual-ativa, não um par saudável.
- display hrp interface — confirma que a interface de batimento mostra running, não down, invalid ou negotiation failed.
- Interfaces de negócio fisicamente Up com contadores de tráfego se movendo nos dois dispositivos, e current-configuration comparada com o backup pré-mudança em busca de algo não intencional.
Cinco armadilhas do campo
Mesma atualização, mesmos comandos — eis o que realmente pega as pessoas.
1. A License não é compartilhada entre os dois dispositivos de um par em espera ativa
RISCOEm um par em espera ativa, os dois dispositivos não compartilham uma License; recursos como IPS, AV ou filtragem de URL que dependem dela são licenciados e aplicados de forma independente em cada dispositivo, com conjunto de recursos, quantidade de recursos e vencimento correspondentes.
PRÁTICA MAIS SEGURAAo atualizar ou renovar, verifique display license nos dois dispositivos, não apenas naquele em que você entrou por acaso — uma License que venceu silenciosamente no de espera só se torna visível no momento em que ele assume como ativo.
2. Um dispositivo recém-reiniciado não retoma o papel ativo imediatamente
RISCOUm dispositivo não retoma o papel ativo no instante em que termina de reiniciar. Ele só tenta assumir depois que a configuração da placa principal é restaurada, pelo menos uma CPU está online, e pelo menos uma placa de interface que carrega o batimento voltou — e somente após esperar mais um minuto.
PRÁTICA MAIS SEGURASe um dispositivo recém-atualizado ficar em espera por mais tempo do que o esperado, verifique se as três condições realmente foram atendidas — especificamente a placa de interface de batimento — antes de supor que a atualização falhou.
3. Isolar um dispositivo da forma errada deixa o par dual-ativo
RISCODesligar as interfaces de negócio para isolar um dispositivo para atualização está correto; lidar mal com a interface de batimento, sua zona de segurança, ou a política que permite a passagem de seus pacotes de batimento deixa os dois dispositivos acreditando que estão ativos assim que o isolado reinicia.
PRÁTICA MAIS SEGURAdisplay hrp state mostrando Local role: Active, Peer role: Unknown nos dois dispositivos é a assinatura de um par dividido — verifique display hrp interface em busca de um estado de batimento down, invalid ou negotiation failed antes de declarar a atualização concluída.
4. Uma falha na verificação de assinatura nem sempre significa que o arquivo está corrompido
RISCOcheck system-software reportando uma falha na verificação de assinatura é tratado por reflexo como “baixar o arquivo novamente”, o que desperdiça tempo se a falha real for uma transferência parcial ou interrompida em vez de um arquivo de origem genuinamente ruim.
PRÁTICA MAIS SEGURACompare um checksum — SHA256 ou MD5, obtido com certutil -hashfile no PC de origem e check file-digest no dispositivo — antes de concluir que o arquivo de origem em si está ruim e buscar uma cópia nova.
5. Excluir o pacote de software antigo remove seu caminho de reversão
RISCOdelete /unreserved é documentado como irrecuperável — usá-lo no pacote de software anterior assim que o espaço flash fica escasso remove silenciosamente a única coisa da qual uma reversão depende.
PRÁTICA MAIS SEGURALibere espaço primeiro com uma limpeza rotineira de arquivos realmente não utilizados, e mantenha pelo menos um pacote de software anterior conhecido como bom até que a nova versão tenha passado na lista de verificação completa.
Projetos de soluções relacionadas
Cinco perguntas que surgem constantemente
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Os dois firewalls de um par em espera ativa precisam rodar sempre exatamente a mesma versão?
Apenas brevemente, durante a própria janela de atualização, eles ficam intencionalmente desalinhados. O requisito mínimo para o par funcionar corretamente é que modelo de produto, versão de software, versão de patch, pacote de recursos e versão da base de assinaturas coincidam todos — então planeje concluir os dois lados na mesma janela de manutenção em vez de deixar a atualização pela metade.
O que realmente acontece com as sessões ativas durante a etapa de comutação?
hrp switch é um acionamento deliberado e controlado, não uma falha não planejada. A mesma verificação exigida pela documentação do fabricante — desligar uma interface de negócio, desconectar um cabo, e um reinício completo — sempre precisa mover o tráfego para o outro dispositivo sem uma interrupção que um usuário notaria; teste esse acionamento antes da mudança real com hrp track interface em uma interface já down em vez de supor que simplesmente funcionará no dia.
O pacote de atualização falhou na verificação de assinatura — o arquivo está definitivamente corrompido?
Não necessariamente. Uma falha na verificação de assinatura também pode significar que a própria transferência ficou incompleta ou foi interrompida. Compare um hash SHA256 ou MD5 entre o arquivo de origem e o arquivo enviado antes de concluir que a origem está ruim e buscar uma cópia nova.
Por quanto tempo devo manter o arquivo de software antigo após uma atualização bem-sucedida?
A documentação do fabricante não dá um número fixo de dias; a resposta prática é: até que a lista de verificação acima tenha passado nos dois dispositivos e o par tenha passado por pelo menos um teste de comutação planejado na nova versão. Reserve — não faça /unreserved — exclua antes disso.
Meu dispositivo de espera recém-reiniciado ainda mostra espera quando eu esperava que ele assumisse — a atualização falhou?
Não necessariamente — veja a segunda armadilha acima. Verifique se a configuração da placa principal terminou de restaurar, se pelo menos uma CPU está online, e se a placa de interface que carrega o batimento voltou, e aguarde o minuto adicional antes de tratar como uma falha.
Limites honestos desta nota
Esta nota se baseia no material de casos do manual de manutenção HiSecEngine USG6000F, USG6000G e USG12000 V600 sobre disciplina de backup, verificação de pacotes de atualização e melhores práticas de espera ativa, cruzado com o manual USG6000E/USG9500 da mesma família de plataforma, onde o mecanismo HRP subjacente e o comportamento de licenciamento por dispositivo são compartilhados. A sincronização específica de preempção na reinicialização e as regras de licenciamento descritas são próprias desta plataforma; uma implementação de alta disponibilidade de outro fabricante usará comandos e contadores diferentes, embora a ordem backup-verificação-isolamento-comutação se transponha conceitualmente. Não cobre em profundidade a substituição de placas em nível de chassi durante uma atualização, nem o rateio de License multi-vsys.
Está planejando uma atualização de firewall e quer uma segunda opinião sobre o plano?
Conte-nos o modelo do dispositivo, a versão de software atual e desejada, e se é um par em espera ativa — ajudamos você a revisar o plano antes de tocar no comando de atualização.