Reiniciar la GUI de WebAdmin de Sophos Firewall

Si la GUI de WebAdmin de Sophos Firewall deja de responder, no es necesario reiniciar inmediatamente todo el firewall. Mientras el enrutamiento, la VPN y las reglas de firewall sigan funcionando, y SSH o la consola local continúen accesibles, se pueden comprobar y reiniciar de forma específica los dos servicios de WebAdmin: tomcat y apache.

Los siguientes comandos están pensados para un firewall independiente. En un clúster HA, el modo de sincronización correcto depende del servicio, el nodo, la compilación de SFOS y el problema concreto. No se debe utilizar -ds nosync en HA sin comprobar antes que sea apropiado.

⚠️ Reiniciar un servicio cambia el estado del sistema, finaliza las sesiones de WebAdmin activas y también puede interrumpir brevemente el User Portal. Primero hay que guardar los registros relevantes, informar a los demás administradores y disponer de un acceso alternativo en las ubicaciones remotas.

Procedimiento rápido para un firewall independiente

Este procedimiento es adecuado cuando WebAdmin muestra un Internal Server Error, un HTTP 503, una página de inicio de sesión incompleta o una interfaz que no responde de forma permanente, mientras SSH y las demás funciones del firewall siguen disponibles.

1. Iniciar sesión como admin mediante SSH o la consola local. Si SSH todavía no está configurado, Conectarse a Sophos Firewall mediante SSH explica cómo preparar un acceso seguro.
2. Abrir 5. Device Management > 3. Advanced Shell.
3. Mostrar los últimos errores de WebAdmin y copiar las salidas relevantes para la documentación del cambio o un caso de soporte:

tail -n 80 /log/tomcat.log
tail -n 80 /log/apache.log
tail -n 80 /log/error_log.log

4. Comprobar el estado actual de los servicios:

service -S | grep -iE 'tomcat|apache'

5. Si un servicio muestra STOPPED, ejecutar únicamente el comando de inicio correspondiente:

# Si tomcat está STOPPED:
service tomcat:start -ds nosync

# Si apache está STOPPED:
service apache:start -ds nosync

6. Si un servicio muestra DEAD, reiniciar únicamente ese servicio. Si ambos muestran RUNNING pero WebAdmin sigue sin poder utilizarse, comenzar por tomcat:

service tomcat:restart -ds nosync

Volver a probar WebAdmin. Solo si apache muestra DEAD o el problema continúa después de reiniciar tomcat, ejecutar:

service apache:restart -ds nosync

7. Esperar unos segundos, volver a abrir WebAdmin desde la red de administración prevista y comprobar de nuevo el estado de los servicios:

service -S | grep -iE 'tomcat|apache'

Ambos servicios deberían mostrar RUNNING. Sin embargo, lo decisivo es la prueba funcional: el inicio de sesión, el panel, Log Viewer y una página de configuración no crítica deben cargarse de forma estable. Que un proceso esté en ejecución no demuestra por sí solo que WebAdmin funcione correctamente.

Las sesiones SSH inactivas se cierran después de 15 minutos. Por ello, conviene preparar la comprobación de los registros, el reinicio y la validación antes de entrar en Advanced Shell, para que una sesión caducada no interrumpa el procedimiento.

Comprobar si un reinicio del servicio es apropiado

Detrás del nombre de servicio tomcat se encuentra el servidor de aplicaciones web Jetty; apache es el servidor HTTP Apache. WebAdmin y User Portal utilizan ambos componentes. Sus registros se encuentran en Advanced Shell:

• Servidor de aplicaciones: /log/tomcat.log
• Servidor web: /log/apache.log y /log/apache_access.log
• Otros errores del servidor web: /log/error_log.log

No todos los problemas de WebAdmin se originan en estos servicios. El tipo de error determina el siguiente paso:

• Internal Server Error, HTTP 503 o una página de inicio de sesión incompleta: Comprobar tomcat, apache y los registros indicados. En este caso, un reinicio específico es razonable.
• Advertencia de certificado: Comprobar el nombre, la validez y la cadena de confianza del certificado. Reiniciar un servicio no corrige un certificado incorrecto.
• Tiempo de espera agotado o acceso fallido solo desde una red: Comprobar la ruta, la red de administración y Administration > Device access. Los servicios locales del firewall se autorizan mediante Device Access, no con una regla de firewall convencional. Device Access y Local Service ACL explica la configuración segura.
• Solo afecta a un navegador: Probar una sesión privada, un segundo navegador u otro cliente de administración antes de intervenir en el firewall.
• WebAdmin, SSH, VPN u otros servicios fallan a la vez: Esto apunta más bien a la carga del sistema, el almacenamiento, la base de datos, HA o un problema general del sistema. No se deben reiniciar servicios al azar.

Si se está ejecutando una actualización de firmware, hotfix o patrones, una sincronización de HA, una sesión de depuración de soporte o una tarea activa de Central, primero hay que identificar y, cuando sea posible, completar ese proceso. De lo contrario, más tarde será difícil determinar si el problema procedía de la actualización, Central, HA o el reinicio del servicio.

Conservar evidencias antes de la intervención

Un reinicio puede desplazar los mensajes de error actuales fuera del contexto visible. Para un problema recurrente o un caso de soporte, hay que registrar como mínimo la hora, la compilación de SFOS, la ruta de acceso afectada y los últimos mensajes de tomcat.log, apache.log y error_log.log.

Si WebAdmin todavía funciona parcialmente, es posible descargar registros individuales o un Consolidated Troubleshooting Report en Diagnostics > Tools. Si solo está disponible la shell, Guardar los registros de Sophos Firewall para soporte y análisis explica el procedimiento. En un clúster HA, cada nodo almacena sus propios registros; cuando sea necesario, hay que comprobar Primary y Auxiliary por separado.

Antes de un reinicio en producción, también se debe confirmar:

• si hay otros administradores o un cambio activo afectados;
• si SSH, la consola local, Sophos Central u otra conexión de administración proporcionan una vía de retorno;
• si WebAdmin es el único servicio afectado;
• si para un clúster HA se dispone del nodo correcto y de instrucciones actuales de Sophos específicas para el servicio.

Reiniciar de forma segura los servicios de Sophos Firewall explica el manejo general de los nombres de servicio, su estado, los registros y los límites de HA. Solución de problemas de Sophos Firewall: servicios y registros incluye más correspondencias entre funciones y archivos de registro.

Verificar el resultado y analizar los problemas recurrentes

Después del reinicio, hay que volver a leer los registros. Los errores nuevos que aparecen inmediatamente después del inicio son más útiles que los mensajes antiguos sin una referencia temporal:

tail -n 80 /log/tomcat.log
tail -n 80 /log/apache.log
tail -n 80 /log/error_log.log

A continuación, abrir el panel, Log Viewer y una página no crítica. Cualquier acceso SSH o Device Access permitido temporalmente debe volver a limitarse a los orígenes de administración previstos.

Si el problema reaparece, el reinicio del servicio solo ha sido una recuperación temporal. El análisis de la causa debe abarcar:

• espacio libre en las particiones, informes locales y estado de la base de datos;
• carga de CPU y RAM, además de registros del sistema anómalos;
• sesiones de administración simultáneas o uso intensivo de la captura de paquetes;
• tareas de Central activas o fallidas;
• función HA, sincronización y nodo afectado;
• cambios de configuración, certificado, interfaz o Device Access inmediatamente anteriores al problema.

Administrar el almacenamiento y los informes de Sophos Firewall ayuda con los problemas de almacenamiento e informes. Los cambios realizados antes del fallo se pueden rastrear con los registros de Audit Trail de Sophos Firewall.

Una breve nota operativa evita que un problema recurrente se trate únicamente con reinicios repetidos:

Fecha, hora y zona horaria:
Firewall y nodo HA, si corresponde:
Versión y compilación de SFOS:
Síntomas:
Registros comprobados:
Comando ejecutado:
Resultado y siguiente medida:

Si WebAdmin sigue sin estar disponible

Si un servicio permanece en STOPPED o DEAD, el reinicio devuelve un error o el problema reaparece inmediatamente, hay que guardar tomcat.log, apache.log, error_log.log, el estado del sistema y el CTR para analizarlos con Sophos Support. Reiniciar otros servicios al azar probablemente empeore las evidencias.

Si no se puede acceder ni a WebAdmin ni a SSH, la vía de recuperación depende del entorno: la consola local mediante un cable de consola o Micro-USB en los modelos compatibles, Sophos Central, una alternativa HA preparada o un reinicio planificado. En ubicaciones remotas, hay que determinar quién puede obtener acceso local si el firewall no arranca correctamente. En un clúster HA, no se debe iniciar una conmutación por error sin comprobarla únicamente porque WebAdmin no responda mientras el tráfico de producción siga fluyendo con normalidad.

Un reinicio completo es más invasivo que reiniciar los servicios afectados. Solo debe considerarse cuando haya varios servicios centrales afectados, el firewall siga inestable, un proceso de firmware o hotfix lo requiera o Sophos Support lo indique. Primero hay que confirmar la copia de seguridad, la ventana de mantenimiento y los efectos sobre VPN, enrutamiento, RED, wireless y los servicios publicados. Planificar correctamente la copia de seguridad y restauración de Sophos Firewall explica la preparación.