En el otoño de 2019, Check Point dejó de admitir las versiones R77.XX y necesitaba ser actualizado. Ya se ha dicho mucho sobre la diferencia entre las versiones, los pros y los contras de la transición al R80. Hablemos sobre cómo actualizar realmente el Check Point del dispositivo virtual (CloudGuard para VMware ESXi, Hyper-V, KVM Gateway NGTP) y qué podría salir mal.
Entonces, teníamos 2 ingenieros de CCSE, más de una docena de clústeres virtuales Check Point R77.30, varias nubes, algunas pequeñas revisiones y un mar entero de varios errores, fallas y todo eso, todos los colores y tamaños, y también plazos muy ajustados. Vamos!
Contenido:
Preparación
Actualización del servidor de administración
Actualización del clúster
Así es como se ve una infraestructura de nube de cliente típica con Check Point virtualPreparación
En primer lugar, debe verificar la suficiencia de recursos para la actualización. Los requisitos mínimos recomendados para R80.20 ahora se ven así:
Las recomendaciones se describen en CP_R80.20_GA_Release_Notes .Pero seremos realistas. Si esto es suficiente en la configuración mínima, entonces, como muestra la práctica, generalmente tenemos activada la inspección https, SmartEvent funciona para SMS, etc., lo que, por supuesto, requiere capacidades completamente diferentes. Pero en general no es más grande que para el R77.30.
Pero hay matices. Y se refieren, en primer lugar, a los tamaños de la memoria física. Muchas operaciones directamente durante el proceso de actualización requerirán espacio en el disco duro.
Para el servidor de administración, la cantidad de espacio libre en disco dependerá en gran medida del volumen de los registros actuales (si queremos guardarlos) y del número de revisiones de la base de datos guardadas, aunque no las necesitaremos en grandes cantidades. Por supuesto, para los nodos del clúster (a menos que almacene registros localmente también), todo esto no importa. Aquí le mostramos cómo verificar si tiene el espacio correcto:
- Nos conectamos al Smart Management Server a través de ssh, ingresamos al modo experto e ingresamos el comando:
[Experto @ cp-sms: 0] # df -h - En la salida, veremos algo como esta configuración:
Tamaño del sistema de archivos utilizado Disponible Uso% montado en
/ dev / mapper / vg_splat-lv_current 30G 7.4G 21G 27% /
/ dev / sda1 289M 24M 251M 9% / boot
tmpfs 2.0G 0 2.0G 0% / dev / shm
/ dev / mapper / vg_splat-lv_log 243G 177G 53G 78% / var / log - Actualmente estamos interesados en la sección / var / log
Tenga en cuenta que, según la política de almacenamiento y eliminación de archivos de registro antiguos, así como el tamaño de la base de datos exportada, es posible que se requiera más espacio. Si al crear el archivo el espacio libre se reduce a lo indicado en la política para almacenar archivos de registro, el sistema comenzará a borrar los registros antiguos y NO los incluirá en el archivo.
Además, para el proceso de actualización en sí, el sistema necesitará un mínimo de 13 GB de espacio sin asignar en el disco duro. Puede verificar su presencia con el comando:
[Experto @ cp-sms: 0] # pvsVeremos aproximadamente la siguiente conclusión:
PV VG Fmt Attr PSize PFree
/ dev / sda3 vg_splat lvm2 a- 141.69G 43.69GEn este caso, tenemos 43 GB. Hay suficientes recursos Puedes comenzar a actualizar.
Actualización de Check Point SMS Management Server
Antes de comenzar a trabajar, haga lo siguiente:
- Instale el paquete de Herramientas de migración en el servidor de administración. Para hacer esto, debe cargar la imagen desde el portal Check Point .
- Descargue el archivo en el servidor de administración a través de WinSCP en la carpeta /var/log/UpgradeR77.30_R80.20 (si es necesario, cree primero una carpeta).
- Nos conectamos al servidor de administración a través de SSH y vamos a la carpeta de archivo: cd /var/log/UpgradeR77.30_R80.20/
- Descomprima el archivo: tar -zxvf ./ <nombre de archivo> .tgz
- Lanzamos la utilidad pre_upgrade_verifier con el comando: ./pre_upgrade_verifier -p $ FWDIR -c R77 -t R80.20
- Al completar el comando, se generará un informe sobre configuraciones incompatibles. Está disponible en /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Es más conveniente descargarlo a través de SCP y mirar a través del navegador.
Para eliminar todas las configuraciones incompatibles, use SK117237 . - Luego, vuelva a ejecutar la utilidad pre_upgrade_verifier para verificar que se hayan resuelto todas las causas de incompatibilidad.
- A continuación, recopilamos información sobre las interfaces de red, la tabla de enrutamiento y cargamos la configuración de 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 configuración"> /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt - Cargue el archivo recibido a través de SCP.
- Hacemos instantáneas a nivel de virtualización.
- Aumentamos el tiempo de espera de la sesión SSH a 8 horas. Así de afortunado: dependiendo del tamaño de la base exportada, puede durar desde varios minutos hasta varias horas. Para hacer esto:
[Expert @ HostName] # clish -c "mostrar inactividad-tiempo de espera" mira el tiempo de espera actual clish,
[Expert @ HostName] # clish -c "set inactivity-timeout 720" especifica un nuevo tiempo de espera clish (en minutos),
[Expert @ HostName] # echo $ TMOUT mira el modo experto de tiempo de espera actual,
[Expert @ HostName] # export TMOUT = 3600 especifique un nuevo modo experto de tiempo de espera (en segundos), si establece el valor en 0, el tiempo de espera se desactivará. - Cargamos y montamos la imagen de instalación de SMS.iso en la máquina virtual.
Antes del siguiente paso, asegúrese de verificar nuevamente que tenga suficiente espacio sin asignar en su disco duro (le recuerdo que necesita 13 GB).
- Antes de comenzar la exportación de la configuración, cambiamos el archivo de registro con el comando: fw logswitch
Exportar configuración y registros- Ejecute la utilidad migrate_export para descargar la configuración. Para hacer esto, vaya a la carpeta creada anteriormente: cd /var/log/UpgradeR77.30_R80.20/ y use el comando: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
cualquiera
vaya a la carpeta: cd $ FWDIR / bin / upgrade_tools / y
ejecute el comando desde allí: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Si la base exportada es grande, entonces el procedimiento puede llevar varias horas.
NO DESCONECTE la SESIÓN SSH durante el procedimiento.
En el proceso, GAIA mostrará este mensaje:
Puede ir a tomar café y almorzar de manera segura.
Después de que veamos un mensaje de error como este:
O un mensaje sobre la finalización exitosa de la operación:
Si el proceso ha estado sucediendo durante un par de horas, puede verificarlo. Sin desconectar la sesión actual, configure una sesión paralela a través de ssh e ingrese el comando superior. Entre los procesos, se debe mostrar el proceso de migración.
Si sin desconectar la sesión SSH de ninguna manera, use: yes | nohup ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
En este caso, puede desconectar la sesión, pero será inconveniente monitorear el progreso: tendrá que verificar la finalización del proceso con el comando superior, y en caso de un problema no habrá un mensaje de error. Por lo tanto, recomendamos esta opción. - Eliminar la suma de comprobación del archivo: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Guardamos el valor recibido en un cuaderno.
- Nos conectamos a SMS a través de SCP y cargamos el archivo con la configuración a la estación de trabajo. Asegúrese de utilizar la transferencia de archivos en formato binario.
Exportar base de datos SmartEventAquí necesitamos una versión de SMS preinstalada R80. Cualquier prueba servirá.
- Desde SMS, necesitamos un script ubicado aquí: $ RTDIR / bin / eva_db_backup.csh
- A través de SCP, cargue el script eva_db_backup.csh en la carpeta: /var/log/UpgradeR77.30_R80.20/
- Nos conectamos a través de SSH a SMS. Copie el archivo a la carpeta: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$ RTDIR / bin / eva_db_backup.csh
- Cambie la codificación: dos2unix $ RTDIR / bin / eva_db_backup.csh
- Agregar propietario: chown -v admin: root $ RTDIR / bin / eva_db_backup.csh
- Agregar permisos: chmod -v 0755 $ RTDIR / bin / eva_db_backup.csh
- Comenzamos a exportar la base SmartEvent: $ RTDIR / bin / eva_db_backup.csh
- Cargamos los archivos recibidos a través de SCP: $ RTDIR / bin / <date> -db-backup.backup y $ RTDIR / bin / eventiaUpgrade.tar a la estación de trabajo.
Actualización- Vaya a WebUI GAIA SMS → CPUSE → Mostrar todos los paquetes.
- En el caso de que CPUSE genere un error de conexión en la nube de puntos de conexión, verificamos la configuración de DGW, DNS y Proxy.
- Si todo es correcto, pero el error persiste, debe actualizar CPUSE manualmente, guiado por sk92449 .
- Descarga la imagen y ve a través de Verifier. Si es necesario, elimine las inconsistencias.
Como resultado, debería ver este mensaje:
- Elija R80.20 Instalación nueva y actualización para la gestión de seguridad.
- Al instalar la actualización, seleccione Instalación limpia. Después de la instalación, el sistema se reiniciará.
- Pasamos el primer asistente de tiempo .
- Después de obtener acceso, verificamos las cuentas.
- Nos conectamos a SMS a través de SSH y cambiamos nuestro shell de usuario a / bin / bash /:
establecer usuario <nombre de usuario> shell / bin / bash /
guardar configuración (en caso de que queramos dejar bin / bash / como shell predeterminado y después de reiniciar). - A continuación, nos conectamos a SMS a través de SCP y en modo binario transferimos el archivo con la configuración SMS_w_logs_export_r77_r80.tgz a la carpeta /var/log/UpgradeR77.30_R80.20/
- Eliminamos la suma de comprobación del archivo: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz y la comparamos con el valor anterior. La suma de control debe coincidir.
- Aumentamos el tiempo de espera de la sesión SSH a 8 horas. Para hacer esto:
[Expert @ HostName] # clish -c "mostrar inactividad-tiempo de espera" mira el tiempo de espera actual clish,
[Expert @ HostName] # clish -c "set inactivity-timeout 720" especifica un nuevo tiempo de espera clish (en minutos),
[Expert @ HostName] # echo $ TMOUT mira el modo experto de tiempo de espera actual,
[Expert @ HostName] # export TMOUT = 3600 especifica el nuevo modo experto de tiempo de espera (en segundos). Si establece el valor en 0, el tiempo de espera se desactivará. - Para importar la configuración, ejecute la utilidad de importación de migración. Para hacer esto, vaya a la carpeta: cd $ FWDIR / bin / upgrade_tools / y ejecute la importación: ./migrate imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Disfruta la vida durante las próximas dos horas. NO DESCONECTE la SESIÓN SSH durante el procedimiento. Al final, el proceso de migración devolverá un mensaje de éxito o un error.
Lista de verificación después de las actualizaciones- Disponibilidad de recursos.
- SIC con GW.
- Licencias Si las licencias se muestran incorrectamente o no se muestran en SMS, ejecute el comando vsec_central_licence para distribuir las licencias.
- Establecimiento de políticas.
Importar base de datos SmartEvent- Habilite SmartEvent Blade.
- Nos conectamos a través de WinSCP a SMS y en modo binario transferimos los archivos <date> -db-backup.backup y eventiaUpgrade.tar previamente descargados a la carpeta /var/log/UpgradeR77.30_R80.20/
- Comenzamos el script con el comando: $ RTDIR / bin / eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
- Comprobación del estado: watch -n 10 eventiaUpgrade.sh
- Verifique los registros en SmartEvent. SUEÑO!
Actualizar cluster Check Point GW (Activo / Copia de seguridad)
Antes de comenzar a trabajar- Guardamos la configuración de GAIA de cada nodo del clúster en un archivo. Para hacer esto, use el comando: clish -c "show configuration"> ./ <File name> .txt
- Subimos archivos usando WinSCP.
- Nos conectamos a la WebUI de ambos nodos y vamos a la pestaña CPUSE → Mostrar todos los paquetes.
- Encontramos el paquete de servicio para la versión R80.20 Instalación fresca , haga clic en Descargar.
- Verificamos que el protocolo CCP funciona en modo Broadcast , para esto ingresamos el comando: cphaprob -a if
Si se selecciona el modo Multicast , cámbielo con el comando: cphaconf set_ccp broadcast (el comando se ejecuta en cada nodo). - Establezca el tiempo de inactividad para los nodos involucrados en su sistema de monitoreo.
- Verificamos que en el nivel de virtualización, los parámetros de cambio de dirección MAC y transmisiones falsificadas para la red de sincronización estén habilitados.
Actualización- Nos conectamos a través de ssh al nodo Activo y ejecutamos el comando para monitorear el estado del clúster: watch -n 2 cphaprob stat
- Regresamos a los nodos WebUI Stanby en la pestaña CPUSE y ejecutamos Verifier para el paquete R80.20 Fresh Install seleccionado .
- Analizamos el informe del verificador. Si la instalación está permitida, continúe.
- Seleccione el paquete R80.20 Fresh Install y ejecute Upgrade . Durante el proceso de actualización, el sistema se reiniciará. La configuración de GAIA se guarda. En el momento del reinicio, monitoreamos el estado del clúster. Después de cargar, el estado del nodo actualizado debe cambiar a LISTO. En algunos casos, tuvimos un momento en que un nodo aún no actualizado entró en estado de Atención activa y dejó de mostrar el estado del nodo actualizado. No se alarme: esta opción también es válida.
- Al finalizar la actualización, abra SmartDashboard.
- Abra el objeto del clúster y cambie la versión del clúster de R77.30 a R80.20. Haz clic en Aceptar. Si se produce un error al guardar los cambios:
Ha ocurrido un error interno. (Código: 0x8003001D, no se pudo acceder al archivo para la operación de escritura),
siga el SK119973 . Después de eso, guarde los cambios y haga clic en Instalar política. - En la configuración, desactive el parámetro Para los clústeres de puerta de enlace, si falla la instalación en un miembro del clúster, no instale en ese clúster.
- Establecemos una política. El sistema generará un error para el nodo Activo, que aún no se ha actualizado.
- Nos conectamos al nodo actualizado a través de ssh y ejecutamos el comando para monitorear el estado del clúster: watch -n 2 cphaprob stat
- Nos conectamos a los nodos activos de WebUI y vamos a la pestaña CPUSE → Mostrar todos los paquetes. Encontramos el paquete de servicio para la versión R80.20 Instalación fresca , haga clic en Descargar.
- Establezca el tiempo de inactividad para los nodos involucrados en su sistema de monitoreo.
- Regresamos a los nodos activos de WebUI en la pestaña CPUSE y ejecutamos Verifier para el paquete R80.20 Fresh Install seleccionado .
- Analizamos el informe del verificador. Si la instalación está permitida, continúe.
- Seleccione el paquete R80.20 Fresh Install y ejecute Upgrade. Durante el proceso de actualización, el sistema se reiniciará. La configuración de GAIA se guarda. En el momento del reinicio, monitoreamos el estado del clúster en un nodo ya actualizado. Después del reinicio, el estado del clúster en el nodo actualizado cambiará de LISTO a ACTIVO.
- Cuando se complete el proceso de actualización, inicie SmartDashboard e instale la política.
Lista de verificación después de las actualizaciones- Registros de eventos en SmartLog, estado de los túneles VPN.
- Configuración de GAIA.
- Recuperación de clúster después de la conmutación por error de prueba.
- Licencias y contratos. Si las licencias se muestran incorrectamente o no se muestran en SMS, ejecute el comando. vsec_central_licence para la distribución de licencias.
- CoreXL.
- SecureXL.
- Revisión y CPinfo en dos nodos.
ConclusiónEn general, en este punto, todo: has actualizado.
Todo nuestro proceso tomó un promedio de 6 a 12 horas, dependiendo del tamaño de las bases de datos exportadas. El trabajo se llevó a cabo durante dos noches: una para actualizar SMS, la segunda para el clúster.
No hubo tiempo de inactividad del tráfico, a pesar del hecho de que verificamos todos los errores anteriores en nosotros mismos.
Por supuesto, a veces pueden surgir dificultades completamente nuevas durante el proceso de actualización, pero esto es Check Point y, como todos sabemos, ¡siempre hay una revisión!
¡Buena suerte con tus noches y actualizaciones rosas y rosas!