Sophos Firewall se reinicia inesperadamente: comprobar la causa

Si Sophos Firewall se reinicia sin una intervención planificada, no conviene ejecutar inmediatamente otro reboot ni reiniciar servicios por precaución. Primero hay que determinar si realmente se reinició todo el appliance o si solo falló WebAdmin, un servicio concreto o el rol HA activo. Un reinicio correcto puede restablecer el funcionamiento, pero no explica la causa.

⚠️ Guardar las pruebas antes de realizar más intervenciones: No borrar logs, no provocar otro reboot, no cambiar el estado de auto-reboot-on-hang ni iniciar por sospecha debug, acciones de servicio, fsck, Factory Reset o Reimage. Estas intervenciones pueden modificar indicios, provocar nuevas interrupciones u ocultar el fallo real.

El procedimiento rápido y seguro es el siguiente:

1. Anotar la hora con zona horaria, la duración del fallo y la última observación conocida en la que el sistema funcionaba.
2. Registrar si el tráfico, WebAdmin, SSH y la consola local se vieron afectados al mismo tiempo.
3. Guardar en Control Center el uptime, los servicios, las interfaces, las VPN y, en HA, el estado del clúster.
4. Exportar los eventos correspondientes en Log viewer > System y guardar el historial en Diagnostics > System graphs.
5. Descargar en Diagnostics > Tools un CTR, además de sysinit.log, syslog.log y, en HA, los logs locales de los nodos.
6. Consultar en la Device Console el uptime, el build y el estado de reinicio automático:

system diagnostics show uptime
system diagnostics show version-info
system auto-reboot-on-hang show

7. En HA, comparar los roles, el estado, Last status change y el uptime de ambos nodos.
8. Solo entonces comprobar la rama de causas adecuada y probar completamente el funcionamiento productivo.

system auto-reboot-on-hang show no modifica nada. SFOS activa esta función de forma predeterminada y puede reiniciar automáticamente el firewall si el kernel deja de responder. Sin embargo, un enable mostrado solo demuestra la recovery policy configurada, no que un kernel hang haya provocado este reinicio concreto.

Comprobar qué falló realmente

La interrupción observada no demuestra por sí sola un reboot completo. Estos cuatro casos requieren pasos siguientes diferentes:

• Reboot completo del appliance: El uptime vuelve a empezar, varios servicios y conexiones se interrumpieron al mismo tiempo y SFOS volvió a ejecutar el arranque del sistema. En este caso corresponde el diagnóstico del reboot descrito en este artículo.
• Solo se vio afectado WebAdmin o un servicio: El uptime continúa y el tráfico productivo puede seguir funcionando parcialmente sin cambios. En este caso, es más adecuado reiniciar de forma dirigida la GUI de WebAdmin o comprobar un servicio concreto que reiniciar el appliance.
• Failover HA: Es posible que los usuarios perciban una breve interrupción aunque solo hayan cambiado los roles. El uptime, el rol y los logs de cada nodo muestran si un dispositivo se ha reiniciado realmente. La comprobación de HA aparece más adelante.
• Modo failsafe: El firewall no arranca con normalidad y muestra un estado de recuperación en la consola. En este caso, show failure-reason del runbook sobre el modo failsafe de Sophos Firewall es el primer comando correcto.

Por tanto, el uptime es un indicio sólido del periodo del reinicio, pero no demuestra la causa. También lo restablecen una breve interrupción eléctrica, un kernel hang, un fallo de firmware y un reinicio planificado por un administrador.

Guardar las pruebas después del reinicio

Después de un reboot no planificado, es posible que ya falten datos volátiles. Aun así, hay que guardar por completo el estado accesible antes de realizar más cambios.

El incidente debe incluir al menos:

• modelo, número de serie y plataforma: hardware, VM o cloud
• versión completa de SFOS con MR y build
• hora exacta, zona horaria, duración y frecuencia del fallo
• funciones afectadas: tráfico, WebAdmin, SSH, consola, VPN y servicios publicados
• último cambio de firmware, configuración, hipervisor, almacenamiento o alimentación eléctrica
• uptime actual y estado de servicios, interfaces, VPN y HA
• en HA: nodo afectado, roles antes y después del evento y estado del peer
• eventos disponibles de UPS, PDU, hipervisor, cloud, switch y monitorización en el mismo intervalo

En Diagnostics > System graphs, se comprueban CPU, Memory, Load y Disk alrededor de la hora sospechada. Una anomalía puede acotar la búsqueda. Sin embargo, un valor actual normal no demuestra que la carga antes del reboot también fuera normal.

En Log viewer > System, se filtran y exportan los eventos de arranque, restart, shutdown y HA del mismo intervalo. Log Viewer es una fuente horaria útil, pero no una prueba completa de un crash. Los eventos que aún no se habían guardado pueden faltar después de un hang.

Consultar el estado del sistema en Device Console

Además del uptime y el build, estos comandos de solo lectura muestran el estado actual:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk

Los valores deben incluirse en la nota del incidente junto con la hora de la consulta. Describen el estado después del reinicio y no deben interpretarse retrospectivamente como su causa.

Comprobar los logs de arranque y del sistema

En la Advanced Shell, los archivos más importantes pueden leerse completos y sin modificarlos:

cd /log
less sysinit.log
less syslog.log
less applog.log
less csc.log

q cierra less. Dentro del archivo, /término-de-búsqueda inicia una búsqueda, por ejemplo /error; n salta al siguiente resultado.

• sysinit.log documenta el arranque del sistema.
• syslog.log contiene eventos del kernel y del sistema.
• applog.log y csc.log ayudan a clasificar acciones internas y cambios cercanos al evento.

En Diagnostics > Tools > Troubleshooting logs, también deben descargarse los mismos archivos para conservar los datos originales fuera del appliance. La asignación de logs de servicio de Sophos Firewall explica qué archivo de log adicional corresponde a cada servicio.

Además, en Diagnostics > Tools > Consolidated troubleshooting report, se genera un CTR con System snapshot y All log files. El CTR contiene el estado actual del sistema y numerosos logs en un archivo cifrado. Los logs de subsistemas de servicios contienen de forma predeterminada un máximo de 10'000 líneas; para periodos más largos siguen siendo importantes los logs individuales completos. El procedimiento completo se describe en Guardar logs de Sophos Firewall para soporte.

Una sección de log vacía no descarta un crash ni una interrupción eléctrica. La información que aún no se había escrito en el disco puede perderse durante un hang y los logs locales pueden rotar. Por eso son tan importantes las fuentes horarias externas y una cronología precisa del incidente.

Distinguir un failover HA de un reboot del nodo

En System services > High availability, se guardan Health, Mode, roles, estado, números de serie y Last status change. En la Device Console se ejecuta además:

system ha show details

Después se comprueba el uptime de ambos nodos. Si solo un nodo tiene un uptime corto, esto apunta a un reinicio de ese dispositivo. Si los uptimes no han cambiado, pero los roles se intercambiaron, primero hay que investigar el desencadenante de HA, como un Monitored Port o un problema del peer. Un cambio manual del rol activo también puede reiniciar el Primary anterior; por ello, una posible intervención del administrador también debe incluirse en la cronología.

Los logs HA se almacenan localmente en cada nodo y no se sincronizan. Por tanto, en ambos appliances son relevantes al menos estos archivos:

cd /log
less ha.log
less msync.log

ha.log muestra la formación del clúster y los cambios de estado; msync.log, la sincronización. No iniciar un reinicio simultáneo de ambos nodos ni forzar otro failover para reproducir el problema. El diagnóstico completo de roles y enlaces se describe en High Availability de Sophos Firewall.

Acotar la causa según el contexto

Reinicio planificado por el administrador o el firmware

Primero se comparan el calendario de cambios, las ventanas de mantenimiento, las acciones de administrador, las tareas de Sophos Central y las notificaciones con la hora del evento. Los cambios de configuración anteriores pueden clasificarse mediante los Audit Trail logs. Sophos Firewall genera eventos del sistema para un arranque, así como para restart o shutdown desde WebAdmin. Si las notificaciones por correo electrónico están configuradas, el mensaje del buzón también puede confirmar la hora y el firewall remitente.

Si el reinicio se produjo durante un proceso de firmware o hotfix, se guardan la versión de origen, la versión de destino, el build, la hora de actualización y fwmgmt.log. Un reinicio forma parte de un cambio de firmware normal; varios reboots no planificados o un build inesperado no. Para seguir con la clasificación, se utiliza el procedimiento Realizar una actualización de firmware de Sophos Firewall.

Kernel hang o fallo de software

Con auto-reboot-on-hang activado, SFOS puede reiniciarse automáticamente cuando el kernel deja de responder. La función mejora la disponibilidad, pero no siempre deja una prueba local inequívoca de la causa. El estado mostrado se documenta y no se modifica durante el diagnóstico. El caso se acota mediante la hora, los logs, System graphs, el CTR y el build exacto.

En SFOS 22.0 MR2 Build 546, Sophos corrigió varios casos independientes de crash y restart, entre ellos:

• NC-180974: kernel crash en sdwan_profile con failover HA
• NC-178354: kernel crash al aplicar la coincidencia de reglas SD-WAN
• NC-178745: reinicio automático de un dispositivo HA por out-of-memory
• NC-180433: crash repetido con tráfico multicast a través de un túnel VPN

Estas issue IDs muestran por qué El firewall se ha reiniciado todavía no es un diagnóstico. Solo si el build, la función, el tráfico y la hora del error coinciden con el caso documentado, se comprueba la ruta de actualización compatible a MR2 Build 546 o a una versión aprobada más reciente. Si el error vuelve a producirse en este build o uno más reciente, no se sigue asignando automáticamente a la misma issue ID antigua. El resto de correcciones se clasifica en el resumen de SFOS 22.0 MR2.

No se reproduce intencionadamente un kernel crash mediante pruebas de carga, multicast, cambios de SD-WAN o un failover forzado. Se documentan la configuración y los patrones de tráfico y después se evalúan con Sophos Support.

Carga, espacio o almacenamiento

El historial de CPU, Memory, Load y Disk puede mostrar si ya existía una anomalía persistente antes del reboot. Además, Sophos indica /log/system-monitor/cpu_trigger.log para los estados del sistema registrados automáticamente cuando hay una alta carga de CPU. La documentación de SFOS 22 añade /log/system-monitor/memory_trigger.log para una alta carga de memoria; no debe presuponerse este archivo en SFOS 21.5.

Un disco lleno, una carga de I/O elevada y un fallo del SSD son problemas diferentes. Por eso no deben borrarse reports ni logs por sospecha. Para la comprobación de solo lectura y la limpieza prevista se utiliza Comprobar el almacenamiento y los reports de Sophos Firewall; Comprobar el estado del SSD de Sophos Firewall mediante SMART explica el estado de hardware del dispositivo de almacenamiento.

Corriente, temperatura o hardware

En una XGS física se comprueban la alimentación eléctrica, las fuentes de alimentación, la UPS/PDU, la temperatura del rack, el flujo de aire, los ventiladores, los LED, el SSD y la consola local. La ausencia de una traza de shutdown limpio puede encajar con un evento eléctrico abrupto, pero no lo demuestra. Lo decisivo es la cronología conjunta del firewall, la UPS/PDU, la monitorización y el entorno.

Una temperatura actual después del reboot también es solo un valor puntual. La comprobación de la temperatura, los ventiladores y xgs-healthmond.log explica la rama de causas térmicas. Los errores recurrentes de arranque, I/O, fuente de alimentación, NPU o ventilador deben incluirse con los datos guardados en la preparación de un caso de hardware y RMA.

Firewall virtual o cloud appliance

En una VM, también se comprueban a la misma hora los eventos del hipervisor, reinicios del host, latencia del datastore, tareas de snapshot o backup, vCPU, RAM, discos y vNIC. En AWS o Azure, los eventos de la plataforma, el estado de la instancia y los mantenimientos planificados forman parte de la cronología del incidente.

Un evento del host o la plataforma puede reiniciar la VM sin que SFOS sea la causa. A la inversa, un hipervisor sin anomalías no demuestra que el guest esté libre de fallos. Por eso se evalúan conjuntamente ambas cronologías. Sophos Firewall como hardware, VM o cloud appliance explica las diferencias actuales entre plataformas y recursos.

Comprobar el funcionamiento después del reinicio

Una página de inicio de sesión accesible todavía no es una prueba de aceptación completa. Después de guardar las pruebas, se comprueban según el entorno:

• Control Center sin nuevas advertencias de servicios, interfaces, VPN o rendimiento; además, comprobar System graphs y Notifications para detectar anomalías de Memory y Disk
• WAN, routing, DNS y acceso a Internet por la ruta esperada
• conexiones VPN importantes Site-to-Site y Remote Access
• publicaciones centrales DNAT, WAF o de servidores
• DHCP, RED y Wireless, si el firewall presta estos servicios
• en HA: Health, roles, sincronización y uptime de ambos nodos
• nuevos errores del sistema, kernel o hardware desde el arranque

Los flujos de negocio reales más importantes deben probarse de forma deliberada y documentarse con la hora. Si el uptime permanece estable, esto solo muestra que no se ha producido otro reboot. La causa original no se considera aclarada hasta que la cronología, los logs y las observaciones de la plataforma proporcionan una explicación sólida.

Preparar el caso de soporte y la detección futura

Conviene abrir un ticket de soporte de Sophos si el reboot sigue sin explicación, vuelve a producirse, ha causado un fallo de HA o del sitio, o existen indicios relacionados con el kernel, la memoria, el almacenamiento, la NPU o el hardware. El caso debe incluir la hora del incidente con zona horaria, la plataforma, el build completo, el uptime, las funciones afectadas, los últimos cambios, los roles HA, el CTR, los logs relevantes completos y la cronología externa de alimentación o hipervisor.

Una monitorización preparada mejora las pruebas disponibles para el siguiente incidente:

• Configurar notificaciones por correo electrónico para System started, Restart/Shutdown y cambios de estado HA.
• Enviar los eventos del sistema y HA a Syslog o SIEM para conservar la cronología fuera del firewall.
• Monitorizar el uptime y el estado del hardware mediante monitorización SNMP.
• Operar las alertas de UPS/PDU, hipervisor y cloud con el mismo servidor horario y una asignación clara al sitio.

De este modo, en el siguiente evento se puede decidir con mayor rapidez si el fallo lo provocó el propio SFOS, un nodo concreto, la plataforma o el entorno eléctrico y de hardware.