No outono de 2019, a Check Point deixou de suportar as versões R77.XX, sendo necessária uma atualização. Muito já se falou sobre a diferença entre as versões, os prós e os contras de mudar para o R80. Vamos falar melhor sobre como realmente atualizar os dispositivos virtuais Check Point (CloudGuard para VMware ESXi, Hyper-V, KVM Gateway NGTP) e o que pode dar errado.
Então, tínhamos 2 engenheiros CCSE, mais de uma dezena de clusters virtuais Check Point R77.30, várias nuvens, alguns hotfixes e todo um mar de vários bugs, falhas e tudo mais, de todas as cores e tamanhos, e também prazos muito apertados. Vamos!
Conteúdo:
Esta é a aparência da infraestrutura em nuvem de um cliente típico com Check Point virtual
Treinamento
O primeiro passo é verificar se há recursos suficientes para a atualização. Os requisitos mínimos recomendados para R80.20 atualmente são assim:
dispositivo
CPU
RAM
HDD
Gateway de Segurança
núcleo 2
4 Gb
A partir de 15GB
SMS
núcleo 2
6 Gb
-
As recomendações estão descritas no documento .
Mas seremos realistas. Se isso for suficiente na configuração mínima, então, como mostra a prática, geralmente temos a inspeção https habilitada, SmartEvent rodando em SMS, etc., o que, é claro, requer capacidades completamente diferentes. Mas, em geral, não mais do que R77.30.
Mas existem nuances. E dizem respeito, em primeiro lugar, ao tamanho da memória física. Muitas operações diretamente durante o processo de atualização exigirão espaço no disco rígido.
Para o servidor de gerenciamento, o tamanho do espaço livre em disco dependerá muito do volume dos logs atuais (se quisermos salvá-los) e do número de revisões de banco de dados salvas, embora não precisemos mais delas em grandes quantidades. Obviamente, para nós de cluster (a menos que você também armazene logs localmente), tudo isso não importa. Veja como verificar se você tem o espaço necessário:
- Conectamos ao Smart Management Server via ssh, vamos para o modo especialista e digitamos o comando:
[Especialista@cp-sms:0]# df -h
- Na saída veremos algo parecido com esta configuração:
Tamanho do sistema de arquivos usado Disponibilidade Uso% Montado em
/dev/mapper/vg_splat-lv_current 30G 7.4G 21G 27% /
/dev/sda1 289M 24M 251M 9% /inicialização
tmpfs 2.0G 0 2.0G 0% /dev/shm
/dev/mapper/vg_splat-lv_log 243G 177G 53G 78% /var/log - Atualmente estamos interessados na seção / var / log
Observe que dependendo da política de armazenamento e exclusão de arquivos de log antigos, bem como do tamanho do banco de dados exportado, poderá ser necessário mais espaço. Se, ao criar um arquivo, houver menos espaço livre do que o especificado na política de armazenamento de arquivos de log, o sistema começará a apagar os logs antigos e NÃO os incluirá no arquivo.
Além disso, para o processo de atualização em si, o sistema precisará de pelo menos 13 GB de espaço não alocado no disco rígido. Você pode verificar sua presença com o comando:
[Especialista@cp-sms:0]# pvs
Veremos algo assim:
PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G
Neste caso temos 43 GB. Existem recursos suficientes. Você pode começar a atualizar.
Atualizando o servidor de gerenciamento Check Point SMS
Antes de começar a trabalhar, você precisa fazer o seguinte:
- Instale o pacote Ferramentas de Migração no servidor de gerenciamento. Para fazer isso, você precisa baixar a imagem do portal.
- Carregue o arquivo para o servidor de gerenciamento via WinSCP na pasta /var/log/UpgradeR77.30_R80.20 (se necessário, crie primeiro uma pasta).
- Conecte-se ao servidor de gerenciamento via SSH e vá até a pasta com o arquivo:cd /var/log/UpgradeR77.30_R80.20/
- Descompacte o arquivo:tar -zxvf ./<nome do arquivo>.tgz
- Lançamos o utilitário pre_upgrade_verifier com o comando: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- Após a execução do comando, será gerado um relatório sobre configurações incompatíveis. Está disponível em: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). É mais conveniente fazer upload via SCP e assisti-lo através de um navegador.
Para resolver quaisquer configurações incompatíveis, use. - Em seguida, execute novamente o utilitário pre_upgrade_verifier para certificar-se de que todas as causas de incompatibilidade foram eliminadas.
- A seguir, coletamos informações sobre interfaces de rede, a tabela de roteamento e carregamos a configuração do GAIA:
ip a > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
ip r > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
clish -c "mostrar configuração" > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt - Carregue o arquivo resultante via SCP.
- Tiramos um instantâneo no nível de virtualização.
- Aumentamos o tempo limite da sessão SSH para 8 horas. Depende da sua sorte: dependendo do tamanho do banco de dados exportado, pode durar de vários minutos a várias horas. Por esta:
[Expert@HostName]# clish -c "mostrar tempo limite de inatividade" veja o tempo limite atual,[Expert@HostName]# clish -c "definir tempo limite de inatividade 720" especifique o novo tempo limite clish (em minutos),
[Especialista@NomedoHost]# echo $TMOUT veja o modo especialista de tempo limite atual,
[Especialista@HostName]# exportação TMOUT=3600 especifique o novo modo especialista de tempo limite (em segundos); se você definir o valor como 0, o tempo limite será desabilitado.
- Baixamos e montamos a imagem de instalação SMS.iso na máquina virtual.
Antes da próxima etapa, CERTIFIQUE-SE de verificar se você tem espaço não alocado suficiente no disco rígido (lembre-se, você precisa de 13 GB).
- Antes de começar a exportar a configuração, altere o arquivo de log com o comando: interruptor de registro de transmissão
Exportar configuração e registros
- Execute o utilitário Migrate_export para fazer download da configuração. Para fazer isso, acesse a pasta criada anteriormente: cd /var/log/UpgradeR77.30_R80.20/ e use o comando: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
ou
vá para a pasta: cd $FWDIR/bin/upgrade_tools/ и
execute o comando a partir daí: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - Removemos a soma de verificação do arquivo: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Salve o valor resultante no bloco de notas.
- Conectamos ao SMS via SCP e carregamos o arquivo com a configuração para a estação de trabalho. Certifique-se de usar a transferência de arquivos em formato binário.
Exportar banco de dados SmartEvent
Aqui precisamos da versão SMS pré-instalada R80. Qualquer teste serve.
- Do SMS precisamos de um script localizado aqui:$RTDIR/bin/eva_db_backup.csh
- Carregue o script via SCP eva_db_backup.csh para a pasta: /var/log/AtualizaçãoR77.30_R80.20/
- Conecte-se via SSH ao SMS. Copie o arquivo para a pasta: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - Alterando a codificação: dos2unix $RTDIR/bin/eva_db_backup.csh
- Adicionando o proprietário: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Adicionar direitos: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Vamos começar a exportar o banco de dados SmartEvent: $RTDIR/bin/eva_db_backup.csh
- Faça upload dos arquivos recebidos via SCP: $RTDIR/bin/<data>-db-backup.backup и $RTDIR/bin/eventiaUpgrade.tar para a estação de trabalho.
Обновление
- Ir para WebUI GAIA SMS → CPUSE → Mostrar todos os pacotes.
- Se o CPUSE apresentar um erro ao conectar-se à nuvem Check Point, verifique as configurações de DGW, DNS e Proxy.
- Se tudo estiver correto e o erro não desaparecer, então você precisa atualizar o CPUSE manualmente, guiado por.
- Baixe a imagem e acesse Verificador. Se necessário, eliminamos inconsistências.
Como resultado, você deverá ver esta mensagem:
- selecionar R80.20 Nova instalação e atualização para gerenciamento de segurança.
- Ao instalar a atualização, selecione Instalação limpa. Após a instalação, o sistema será reinicializado.
- Passamos pela primeira vez Mago.
- Depois de obter acesso, verificamos as contas.
- Nós nos conectamos ao SMS via SSH e alteramos o shell do nosso usuário para /bin/bash/:
definir usuário <nome de usuário> shell /bin/bash/
salvar configuração (caso queiramos deixar bin/bash/ como shell padrão após a reinicialização).
- A seguir nos conectamos ao SMS via SCP e transferimos o arquivo com a configuração em modo Binário SMS_w_logs_export_r77_r80.tgz para a pasta /var/log/AtualizaçãoR77.30_R80.20/
- Removemos a soma de verificação do arquivo: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz e compare com o valor anterior. A soma de verificação deve corresponder.
- Aumentamos o tempo limite da sessão SSH para 8 horas. Por esta:
[Expert@HostName]# clish -c "mostrar tempo limite de inatividade" veja o tempo limite atual,
[Expert@HostName]# clish -c "definir tempo limite de inatividade 720" especifique o novo tempo limite clish (em minutos),
[Especialista@NomedoHost]# echo $TMOUT veja o modo especialista de tempo limite atual,
[Especialista@HostName]# exportação TMOUT=3600 especifique o novo modo especialista de tempo limite (em segundos). Se você definir o valor como 0, o tempo limite será desabilitado.
- Para importar configurações, execute o utilitário de importação de migração. Para fazer isso, vá para a pasta: cd $FWDIR/bin/upgrade_tools/e execute a importação: ./migrate imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Vamos aproveitar a vida nas próximas horas. NÃO DESCONECTE SUA SESSÃO SSH durante o procedimento. No final, o processo de migração exibirá uma mensagem de sucesso ou um erro.
Lista de verificação após atualização
- Disponibilidade de recursos.
- SIC com GW.
- Licenças. Se as licenças forem exibidas incorretamente ou não forem exibidas no SMS, execute o comando vsec_central_licence para distribuição de licenças.
- Definindo a política.
Importando banco de dados SmartEvent
- Ative a lâmina SmartEvent.
- Conectamos via WinSCP ao SMS e transferimos arquivos baixados anteriormente em modo binário <data>-db-backup.backup и eventiaUpgrade.tar para a pasta /var/log/AtualizaçãoR77.30_R80.20/
- Executamos o script com o comando: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
- Verificando o status: assista -n 10 eventiaUpgrade.sh
- Verificando os logs no SmartEvent. SONHAR!
Atualizando o cluster Check Point GW (ativo/backup)
Antes de começar o trabalho
- Salvamos a configuração GAIA de cada nó do cluster em um arquivo, para isso use o comando: clish -c "mostrar configuração" > ./<Nome do arquivo>.txt
- Upload de arquivos usando WinSCP.
- Conecte-se à WebUI de ambos os nós e vá para a aba CPUSE → Mostrar todos os pacotes.
- Encontrando o pacote de atualização para a versão R80.20 Nova Instalaçãoempurrar Download.
- Verificamos se o protocolo CCP está funcionando no modo Transmissão, para fazer isso, digite o comando: cphaprob -a se
Se o modo estiver selecionado multicast, substitua-o pelo comando: transmissão cphaconf set_ccp (o comando é executado em cada nó). - Instalamos Downtime para os nós envolvidos em seu sistema de monitoramento.
- Verificamos se os parâmetros estão habilitados no nível de virtualização Alteração de endereço MAC и Transmissões Forjadas para uma rede de sincronização.
Обновление
- Conectamos via ssh ao nó ativo e executamos o comando para monitorar o status do cluster: assista -n 2 cphaprob stat
- Retornar à guia de nós WebUI Stanby CPU e para o pacote selecionado R80.20 Nova Instalação lançar Verificador.
- Vamos analisar o relatório do Verificador. Se a instalação for permitida, siga em frente.
- Selecione um pacote R80.20 Nova Instalação e começar Atualizar. Durante o processo de atualização, o sistema será reinicializado. As configurações do GAIA são salvas. No momento da reinicialização, monitoramos o estado do cluster. Após o carregamento, o status do nó atualizado deverá mudar para PRONTO. Em vários casos, encontramos um momento em que um nó que ainda não havia sido atualizado mudou para o status de Atenção Ativa e parou de exibir o status do nó atualizado. Não se assuste - esta opção também é aceitável.
- Assim que a atualização for concluída, abra Painel inteligente.
- Abra o objeto de cluster e altere a versão do cluster de R77.30 para R80.20. Clique OK. Se aparecer um erro ao salvar as alterações:
Ocorreu um erro interno. (Código: 0x8003001D, não foi possível acessar o arquivo para operação de gravação),
seguir. Depois disso, salve as alterações e clique em Instalar política. - Nas configurações, desmarque a opção Para clusters de gateway, se a instalação em um membro de cluster falhar, não instale nesse cluster.
- Nós definimos a política. O sistema irá gerar um erro para um nó ativo que ainda não foi atualizado.
- Conectamos ao nó atualizado via ssh e executamos o comando para monitorar o estado do cluster: assista -n 2 cphaprob stat
- Conecte-se ao nó WebUI Active e vá para a guia CPUSE → Mostrar todos os pacotes.Encontrando o pacote de atualização para a versão R80.20 Nova Instalação, clique Download.
- Instalamos Downtime para os nós envolvidos em seu sistema de monitoramento.
- Retorne à guia Nós ativos do WebUI CPU e para o pacote selecionado R80.20 Nova Instalação lançar Verificador.
- Vamos analisar o relatório do Verificador. Se a instalação for permitida, siga em frente.
- Selecione um pacote R80.20 Nova Instalação e começar Atualizar. Durante o processo de atualização, o sistema será reinicializado. As configurações do GAIA são salvas. No momento da reinicialização, monitoramos o estado do cluster no nó já atualizado. Após a reinicialização, o estado do cluster no nó atualizado mudará de PRONTO para ATIVO.
- Quando o processo de atualização for concluído, inicie o SmartDashboard e defina a política.
Lista de verificação após atualização
- Logs de eventos no SmartLog, status dos túneis VPN.
- Configurações GAIA.
- Restaurar um cluster após um failover de teste.
- Licenças e contratos. Se as licenças forem exibidas incorretamente ou não forem exibidas no SMS, execute o comando. vsec_central_licence para distribuição de licenças.
- CoreXL.
- SeguroXL.
- Hotfix e CPinfo em dois nós.
Conclusão
Em geral, isso é tudo – você foi atualizado.
Para nós, todo o processo demorou em média de 6 a 12 horas, dependendo do tamanho dos bancos de dados exportados. O trabalho foi realizado em duas noites: uma para atualização de SMS e outra para cluster.
Não houve interrupção do tráfego, apesar de termos verificado nós mesmos todos os erros mencionados acima.
Claro, às vezes podem surgir dificuldades completamente novas durante o processo de atualização, mas este é o Check Point e, como todos sabemos, sempre há um hotfix!
Boas noites pretas e rosa e atualizações!
Fonte: habr.com
