Sophos Firewall Reiniciar la GUI de WebAdmin

Si ya no se puede acceder a la GUI de WebAdmin Sophos Firewall, no es necesario reiniciar todo el firewall inmediatamente. A menudo es suficiente reiniciar los servicios WebAdmin de forma controlada mediante Advanced Shell. Esto es significativamente menos invasivo que un reinicio completo y puede ahorrar un tiempo valioso durante una ventana de soporte o mantenimiento.

Los síntomas típicos son:

• La GUI de WebAdmin muestra Internal Server Error.
• La página de inicio de sesión o el panel de control ya no se cargan por completo.
• WebAdmin responde muy lentamente o se cuelga después de un clic.
• Otros servicios como enrutamiento, VPN o reglas de firewall continúan ejecutándose.
• Aún se puede acceder a SSH o a la consola local.

En la práctica, esto puede ocurrir después de una gran carga de GUI, múltiples sesiones de administración simultáneas, un uso intensivo de captura de paquetes o problemas generales de recursos. Si el firewall es generalmente inestable, las particiones están llenas o varios servicios no funcionan, la GUI de WebAdmin no debería ser lo único a considerar. Entonces también encajan Sophos Firewall Servicios y registros, Sophos Firewall Reiniciar servicios de forma segura y Verifique el espacio de almacenamiento y administre informes.> ⚠️ Importante: Un reinicio del servicio es una intervención en el firewall. Antes de realizar cambios productivos, debe quedar claro quién está conectado, si es necesaria una ventana de mantenimiento y si hay disponible acceso alternativo a través de SSH, consola local o socio HA.

Requisitos

Para un reinicio específico necesita:

• Acceso al usuario admin.
• Acceso SSH o acceso a consola local.
• Acceso al Advanced Shell.
• Imagen de error clara: WebAdmin está afectado, pero no es necesario reiniciar completamente el firewall.
• Un tiempo de mantenimiento o diagnóstico lo más corto posible si varios administradores se ven afectados.

Si SSH aún no está preparado, Sophos Firewall conectarse vía SSH le ayudará. El acceso en sí se controla a través de Administration > Device access. Configurar Device Access correctamente es el artículo básico adecuado para proteger HTTPS/WebAdmin y SSH.

Verifique brevemente antes de reiniciar

Antes de reiniciar los servicios, debes aislar el problema:

1. Compruebe si solo WebAdmin se ve afectado o si también fallan las reglas de VPN, enrutamiento, DNS o firewall.
2. Si es posible, pruebe con un segundo navegador o ventana privada.
3. Compruebe si hay otros administradores trabajando actualmente en la GUI.
4. Inicie sesión a través de SSH y abra Advanced Shell.
5. Opcionalmente, vea brevemente los registros relevantes.

Los archivos de registro más importantes son:

• Servidor web WebAdmin: /log/apache.log y /log/apache_access.log.
• Aplicación WebAdmin: /log/tomcat.log.
• Error de GUI/Sistema: /log/error_log.log.

Ejemplo de una inspección visual rápida:

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

Si desea hacer una copia de seguridad de los registros para un caso de soporte, debe exportarlos antes de reiniciar. El proceso está en Sophos Firewall Copia de seguridad de registros para soporte y análisis.

Clasifica el patrón de error correctamente

No todos los problemas de WebAdmin son causados por tomcat o apache. Antes de reiniciar, una breve clasificación ayudará:

Clasificación típica:

• WebAdmin muestra Internal Server Error: A menudo se debe a la aplicación GUI o al servidor web. Verifique tomcat.log y apache.log y reinicie los servicios específicamente.
• El navegador informa advertencia sobre el certificado: Primero verifique el certificado, el nombre y la cadena de confianza, no reinicie los servicios directamente.
• La conexión se está ejecutando en tiempo de espera: Entonces Device Access, enrutamiento, ACL, VPN o red de administración son más probables. Consultar disponibilidad y Administration > Device access.
• El inicio de sesión funciona, el panel se bloquea después: Verifique la carga de la GUI, la sesión, los informes, la memoria o la base de datos.
• WebAdmin y SSH no son accesibles: Entonces se trata más de la ruta de acceso, Device Access o el estado del sistema. Consulte la consola local, el socio HA o la administración central.
• Varios servicios fallan al mismo tiempo: Esto sugiere un problema del sistema en lugar de un problema puro de GUI. Haga una copia de seguridad de los registros, verifique el espacio de almacenamiento y evalúe el reinicio o el caso de soporte.

Esta clasificación evita que los servicios WebAdmin se reinicien innecesariamente en caso de un problema de acceso a la red o al dispositivo. Si solo falla el acceso desde una red específica, Device Access y Local Service ACL a Sophos Firewall suele ser más importante que reiniciar el servicio.

¿Cuándo es mejor posponer el reinicio?

Reiniciar tomcat y apache es relativamente específico, pero sigue siendo una intervención en el nivel administrativo del firewall. En estas situaciones, primero debe estabilizar o documentar brevemente:

• Actualización de firmware, hotfix o actualización de patrón en ejecución: No intervenga en los servicios WebAdmin al mismo tiempo mientras el proceso de actualización esté activo.
• El clúster HA se está sincronizando actualmente: Verifique primero la función HA, la sincronización y el nodo activo.
• Se está ejecutando la depuración de soporte o la recopilación de registros: Primero guarde los registros relevantes y luego reinicie los servicios.
• La tarea central está actualmente activa: Verifique la cola de tareas para que un cambio central en curso no se mezcle con un problema de GUI local.
• Solo un navegador de administrador se ve afectado: Pruebe primero la sesión privada, el segundo navegador u otro cliente.

Este breve freno ahorra trabajo de explicación posterior. Si inmediatamente después de reiniciar ya no queda claro si el error proviene de WebAdmin, Central, HA o de una actualización en curso, el análisis se vuelve innecesariamente difícil.

Reiniciar los servicios WebAdmin

La GUI de WebAdmin depende principalmente de dos servicios:

• tomcat: Aplicación WebAdmin.
• apache: Servidor web WebAdmin.

En Advanced Shell ambos servicios se pueden reiniciar uno tras otro:

service tomcat:restart -ds nosync
service apache:restart -ds nosync

Luego espere unos segundos y abra nuevamente la GUI de WebAdmin. Si el inicio de sesión funciona nuevamente, aún debe verificar si hay errores recurrentes visibles en Log Viewer o en los registros del sistema.

Verificar estado

Si reiniciar no es suficiente, puedes comprobar el estado de los servicios:

service tomcat:status -ds nosync
service apache:status -ds nosync

También puedes comprobar si los servicios aparecen en la lista de servicios:

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

La asignación general de servicios, módulos y archivos de registro se encuentra en Sophos Firewall Solución de problemas: servicios y registros. También explica cuándo Log Viewer, Advanced Shell o archivos de registro individuales son la mejor fuente de análisis.

Validar después de reiniciar

Si WebAdmin se carga nuevamente, el problema aún no se ha resuelto por completo. Debería comprobar brevemente si la GUI permanece estable y si la causa vuelve a ser visible.

Control de seguimiento útil:

1. Abra WebAdmin desde la red de administración deseada.
2. Inicie sesión con una cuenta de administrador y un panel de prueba, Log Viewer y una página de configuración no crítica.
3. Verifique tomcat.log, apache.log y error_log.log nuevamente para detectar nuevos errores.
4. Verifique el espacio de almacenamiento y los informes locales si la GUI anteriormente estaba lenta o vacía.
5. Excluya las sesiones de administración abiertas, la caché del navegador o el acceso de administrador paralelo como causa.
6. Restringir temporalmente el SSH permitido o el acceso al dispositivo nuevamente.
7. Para clústeres HA, verifique si está trabajando en el nodo esperado.

Si el problema vuelve a ocurrir, no debe reiniciar tomcat y apache todos los días. Luego se necesita un análisis de la causa raíz: espacio de almacenamiento, estado de la base de datos, informes, errores de GUI, carga del sistema, función de alta disponibilidad y cambios recientes en la configuración. Para cambios poco antes del error, Sophos Firewall Verificar registros de seguimiento de auditoría es útil.

Si WebAdmin aún no está disponible

Si la GUI aún no está disponible después de reiniciar tomcat y apache, no debe reiniciar tantos servicios como desee. Una limitación estructurada tiene más sentido:

• Compruebe Device Access: ¿Se permite HTTPS/WebAdmin desde la zona y fuente actuales?
• Excluir navegador: Prueba de caché, sesión privada o segundo navegador.
• Comprobar certificado: Un certificado caducado o incorrecto puede dificultar el acceso, pero normalmente no produce un error interno real del servidor.
• Compruebe la carga del sistema: El uso elevado de CPU, RAM o disco puede afectar a WebAdmin.
• Verifique el espacio en disco: Las particiones llenas pueden causar problemas con la GUI y los informes.
• Verificar registros: Escanee tomcat.log, apache.log y error_log.log en busca de errores actuales.
• Nota sobre el contexto de HA: Para los clústeres de HA, verifique en qué nodo está trabajando y qué nodo está activo.
• Verifique los cambios recientes: Audit Trail y Config Studio pueden mostrar si Device Access, el certificado, la interfaz o la configuración de administrador se cambiaron recientemente.

Si no se puede acceder a WebAdmin y SSH, según la ubicación, solo quedan la consola local, la administración Sophos Central, la conmutación por error de HA o un reinicio planificado. En entornos productivos, este caso debe prepararse en el proceso de operación y recuperación.

Sitios remotos y clústeres de HACon un único firewall en la ubicación principal, el reinicio de WebAdmin suele ser fácil de controlar. Para ubicaciones remotas o clústeres de HA, debe verificar con más detalle de antemano qué ruta se realiza el acceso y qué nivel de respaldo está disponible.

Preguntas importantes:

• ¿El acceso es directamente desde la red de administración, a través de VPN, a través de Sophos Central o a través de un host de salto?
• ¿Es realmente accesible SSH o solo funciona una sesión existente de WebAdmin?
• ¿Hay alguien en el lugar que pueda revisar el aparato si es necesario?
• Para HA: ¿En qué nodo está trabajando y qué nodo es actualmente principal?
• ¿Una conmutación por error planificada creará más riesgo que el reinicio dirigido de tomcat y apache?
• ¿Se documentan los registros y el tiempo antes de que una conmutación por error o un reinicio dificulten el análisis?En entornos HA, no debe realizar una conmutación por error automática solo porque WebAdmin está colgado en el nodo activo. Si el tráfico continúa, un reinicio del servicio GUI dirigido suele ser menos invasivo. Sin embargo, si varios servicios se ven afectados, el nodo activo parece inestable o el acceso se pierde por completo, el caso pertenece a un proceso controlado de recuperación del sitio o HA.

Cuando un reinicio completo tiene más sentido

Un reinicio no es la primera medida para que la GUI de WebAdmin se cuelgue. Pero puede resultar útil si:

• varios servicios centrales ya no responden
• el firewall permanece inestable después de que se reinicia el servicio
• Se resolvieron los problemas de memoria o base de datos y se requiere un inicio limpio
• El soporte de Sophos o una ventana de mantenimiento especifica esto
• un clúster HA puede realizar conmutación por error de forma controlada

Antes de reiniciar, se deben conocer las copias de seguridad, las ventanas de mantenimiento, el acceso a la ubicación y el impacto en los servicios VPN, enrutamiento, RED, inalámbricos y publicados.

Lista de verificación- Imagen de error documentada: Internal Server Error, tiempo de espera o página WebAdmin vacía.

• SSH o consola local disponible.
• Advanced Shell abierto.
• tomcat.log y apache.log revisados ​​brevemente.
• service tomcat:restart -ds nosync ejecutado.
• service apache:restart -ds nosync ejecutado.
• WebAdmin volvió a realizar la prueba.
• Se revisó el espacio de almacenamiento, Device Access y los registros del sistema para detectar errores recurrentes.
• Registros guardados para soporte en caso de interrupciones productivas.
• Se comprobaron las actualizaciones en curso, la sincronización de HA, las tareas centrales o la depuración de soporte antes de reiniciar.
• Se han eliminado nuevamente los recursos compartidos temporales de acceso a dispositivos o SSH.
• Los errores recurrentes no sólo se ocultan con los reinicios del servicio.

Preguntas frecuentes