Reiniciar servicios de Sophos Firewall con seguridad

La forma más segura de reiniciar un servicio concreto de Sophos Firewall es desde System services > Services. Si el servicio no aparece allí, eso no justifica ejecutar cualquier comando de shell: Advanced Shell solo debe usarse con instrucciones actuales de Sophos específicas para el servicio o en un caso de soporte. Primero hay que identificar el servicio afectado y determinar qué conexiones podría interrumpir el reinicio.

⚠️ Importante: Reiniciar un servicio modifica el estado del sistema y puede interrumpir VPN, routing, DNS, DHCP, el acceso web o el acceso administrativo. Hay que guardar antes el estado y los logs y disponer de una vía de acceso alternativa para las ubicaciones remotas.

Reiniciar un servicio desde WebAdmin

Antes de hacer clic, hay que anotar el estado actual, la hora exacta del error y la prueba funcional que falla. Los archivos pertinentes se pueden descargar por separado en Diagnostics > Tools > Troubleshooting logs. Para un caso de soporte, un Consolidated troubleshooting report (CTR) también incluye el estado del sistema, los procesos y el uso de recursos. En una ubicación remota, la comprobación previa debe incluir además una ventana de mantenimiento y un acceso alternativo.

1. Abrir System services > Services.
2. Comprobar el servicio afectado y su estado actual. No iniciar un servicio detenido intencionadamente o no configurado.
3. En Manage, hacer clic en Restart.
4. Esperar a que el servicio vuelva a su estado anterior Running y probar entonces la función afectada.

WebAdmin muestra, entre otros, Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, DHCPv6 server, Router advertisement service, Hotspot y Packet capture and Live connections. Si un servicio no está configurado, su botón permanece desactivado. Anti-spam requiere una política de spam entrante o saliente. Al detener Packet capture and Live connections, finalizan las capturas activas y deja de estar disponible la vista Live Connections. Si Packet Capture no se inicia aunque el interruptor esté activado, Sophos indica expresamente este reinicio mediante WebAdmin como paso de recuperación.

Un reinicio de servicio no tiene un rollback que restaure las sesiones activas. Por eso, el estado que se debe conservar es el registrado previamente. Si un servicio que estaba en ejecución no vuelve a Running, no hay que pulsar Restart repetidamente: se anota una nueva hora, se descarga el log o el CTR y se investiga el fallo o se contacta con Sophos Support.

En Control Center > System, el estado de los servicios indica si un servicio está detenido o no ha podido iniciarse. Es un buen punto de partida, pero no sustituye una prueba funcional. Si solo ha dejado de responder la interfaz de WebAdmin, sirve la guía específica Reiniciar la GUI de Sophos Firewall WebAdmin.

Servicio antivirus detenido tras fallar las actualizaciones de patrones

Si el servicio Antivirus permanece detenido después de que fallen las actualizaciones de patrones SAVI y AVIRA, no hay que pulsar Restart varias veces. Primero se guardan la versión y el build del firmware, la hora del fallo y los archivos avd.log y up2date_av.log correspondientes. En Backup & firmware > Pattern updates también se anotan la última actualización correcta y el estado actual: Ready to install, Downloading, Success o Failed. El proceso general para comprobar estos estados se describe en Configurar y comprobar los patrones de Sophos Firewall.

Sophos registra este problema como NC-180066; está corregido en SFOS 22.0 MR2 Build 546. Si los síntomas coinciden en un build anterior de SFOS 22, hay que comprobar la ruta compatible con la guía de preparación de la actualización del firmware y actualizar primero a MR2 Build 546 o a una versión posterior aprobada. En general se puede realizar un único reinicio desde System services > Services, pero Sophos no lo documenta como solución temporal ni como corrección de NC-180066, y no sustituye la actualización del firmware.

Solo después de actualizar el firmware se hace clic en Update pattern now dentro de Backup & firmware > Pattern updates. La actualización del patrón Antivirus afectado debe alcanzar Success y el servicio Antivirus debe permanecer activo. El estado mostrado del servicio no basta: la actualización del patrón también tiene que finalizar correctamente. Si el problema vuelve a aparecer en MR2 Build 546 o una versión posterior, se entregan a Sophos Support los logs y las horas guardadas en lugar de seguir suponiendo que se trata de NC-180066.

Reiniciar IPsec mediante VPN Management

El menú principal de la CLI ofrece en 6. VPN Management > Restart VPN Service un reinicio compatible del daemon del servicio VPN. Sophos advierte que esta operación desconecta todos los túneles VPN. Si solo hay que restablecer una conexión VPN, se utiliza en su lugar la acción correspondiente en WebAdmin. Antes del reinicio se guardan el estado de los túneles, la hora exacta y strongswan.log; después se comprueban de nuevo las Child SAs, los peers y el tráfico real de las aplicaciones. El reinicio no corrige errores de proposal, routing o NAT.

En el mismo menú se puede regenerar el par de claves RSA utilizado para la autenticación IPsec. No se trata de un reinicio del servicio, sino de un cambio de claves. En conexiones con RSA key, los peers necesitarán después la nueva clave pública; los usuarios de acceso remoto deberán volver a descargar su configuración VPN. Sophos no documenta una vuelta con un solo clic al par de claves anterior. Esta acción solo debe utilizarse como rotación planificada con un inventario completo de túneles, ventana de mantenimiento y acceso administrativo alternativo, nunca como paso general de troubleshooting. Tampoco corrige problemas de PSK o certificados.

Reiniciar un servicio desde Advanced Shell

Advanced Shell solo debe usarse cuando unas instrucciones actuales de Sophos indiquen el servicio y el comando exactos o Sophos Support los proporcione. Para el acceso SSH y la comprobación de la clave del host, se aplica la guía Conectarse a Sophos Firewall mediante SSH. SSH solo debería permitirse desde redes de administración de confianza; la configuración correspondiente se explica en Device Access y Local Service ACL. Las sesiones SSH inactivas se cierran después de 15 minutos.

Después de iniciar sesión, abrir:

5. Device Management > 3. Advanced Shell

La Device Console de la opción 4 del menú valida sus comandos documentados y está destinada a diagnósticos de red y sistema compatibles. En cambio, Advanced Shell, en 5. Device Management > 3. Advanced Shell, es una shell de Linux con acceso completo a bases de datos y servicios del sistema. Los cambios de configuración realizados allí no son persistentes ni se incluyen en los backups. Primero se realizan comprobaciones de solo lectura y el reinicio solo se ejecuta después de comprobar el nombre del servicio, el impacto, la ventana de mantenimiento y el acceso de recuperación.

1. Comprobar el nombre y el estado del servicio

Para mostrar los servicios conocidos y su estado actual:

service -S

La salida se puede filtrar por el servicio sospechoso. Para IPsec, por ejemplo:

service -S | grep -i strongswan

RUNNING significa que el servicio está en ejecución. STOPPED, UNREGISTERED o UNTOUCHED no indican automáticamente un fallo: según el firmware y la configuración, un servicio puede estar inactivo o no registrado de forma intencionada. Primero hay que comprobar si se utiliza realmente la función, la política o la licencia asociada.

Si no está claro el nombre técnico del servicio, ayuda Troubleshooting de Sophos Firewall: servicios y logs. Allí se asignan las áreas funcionales a sus archivos de log.

2. Revisar los logs antes del cambio

Un reinicio puede ocultar pistas importantes sobre la causa. Para IPsec, conviene leer primero strongswan.log y guardar los mensajes relevantes:

less /log/strongswan.log

q cierra less. Para análisis más amplios, se pueden exportar antes los logs según Guardar logs de Sophos Firewall para soporte y análisis. En clústeres HA, cada nodo solo guarda los logs del tráfico que procesa; puede ser necesario revisar ambos nodos por separado.

3. Reiniciar el servicio en un firewall independiente

El siguiente ejemplo presupone un firewall independiente. Antes de ejecutarlo, service -S | grep -i strongswan debe confirmar el servicio. El reinicio puede interrumpir conexiones IPsec site-to-site y de acceso remoto. Hay que comprobar antes los túneles, los peers remotos y la ventana de mantenimiento.

Sophos documenta este patrón:

service <service>:restart -ds nosync

Un ejemplo completo para el servicio IPsec es:

service strongswan:restart -ds nosync

La sintaxis genérica y service -S están documentados en la ayuda actual de SFOS 22, donde strongswan se asigna al servicio IPsec. Este ejemplo no se ha ejecutado en un firewall y, por tanto, no se presenta como probado en laboratorio. No se debe adivinar el nombre de ningún otro servicio a partir de una lista.

Para continuar el análisis, consulte Troubleshooting de IPsec en Sophos Firewall.

⚠️ Clúster HA: No aplicar el comando para un firewall independiente sin verificarlo. Según el servicio y la situación, las instrucciones de Sophos utilizan sync o nosync; la documentación pública no ofrece una regla general suficiente. El servicio, el nodo, el build de SFOS y el modo de sincronización deben proceder de una instrucción actual de Sophos específica para el servicio o de un caso de soporte.

Los comandos stop y start por separado solo deben utilizarse cuando Sophos Support lo indique para el servicio concreto. Entre ambos comandos, el servicio permanece completamente detenido.

Este reinicio tampoco tiene un rollback que conserve el estado: las Security Associations y sesiones desconectadas no se pueden restaurar. El criterio seguro para detenerse es comparar con la comprobación previa. Si strongswan no vuelve al estado anterior o los túneles no se restablecen, no se ejecuta un segundo reinicio; se guardan los logs y el CTR y se escala el problema.

4. Validar el resultado

Después del reinicio se comprueban el estado, el log y la función real:

service -S | grep -i strongswan
tail -f /log/strongswan.log
grep -i 'error' /log/strongswan.log

tail -f muestra continuamente los mensajes nuevos y se detiene con Ctrl+C. Los mensajes se comparan con la hora anotada antes del reinicio; un grep sin filtro también puede mostrar errores antiguos. Después se comprueban los túneles IPsec y se prueba un host en la ubicación remota. El estado RUNNING por sí solo no demuestra que la conexión vuelva a funcionar.

Si falla el reinicio, también se debe revisar csc.log. En problemas de HA, según los síntomas, también pueden ser relevantes ha.log, msync.log y applog.log.

Servicios habituales y pruebas funcionales adecuadas

El nombre exacto del servicio debe confirmarse en el firewall afectado con service -S. Las asignaciones más importantes son:

• strongswan: IPsec site-to-site y de acceso remoto. Después, comprobar el estado de los túneles, strongswan.log y la conectividad con la ubicación remota.
• dnsd: Servicio DNS. Después, probar la resolución de nombres interna y externa, dnsd.log y las DNS Request Routes configuradas.
• dhcpd: Servidor DHCP. Durante el reinicio, los clientes nuevos o que renuevan pueden no recibir respuesta. Después, probar la asignación de leases y dhcpd.log.
• awed: Comunicación entre el firewall y dispositivos AP/APX. Después, comprobar el estado de conexión de los access points y awed.log.
• zebra: Instala rutas dinámicas y estáticas en el kernel. Por ello, un reinicio es invasivo y solo debe realizarse con una instrucción concreta de Sophos; después, probar la tabla de routing, los gateways y las rutas reales.
• smtpd: Proxy SMTP en modo MTA. El proxy transparente heredado utiliza otro servicio; antes de intervenir, comprobar el modo de funcionamiento y los logs smtpd_*. Después, probar de forma controlada el envío y la recepción de correo.

Para WAF, Web proxy, IPS, Authentication y los servicios disponibles en WebAdmin, el reinicio desde System services > Services suele ser más claro que un comando de shell.

Cuándo no conviene reiniciar un servicio

Reiniciar un servicio concreto es adecuado cuando un módulo específico está afectado y el resto del firewall permanece estable. No hay que reiniciar servicios a ciegas cuando:

• la causa o el servicio afectado todavía no están claros;
• fallan a la vez varios servicios centrales;
• ese servicio proporciona el único acceso remoto disponible;
• el error es reproducible y aún no se han guardado los logs;
• el mismo servicio ya se ha reiniciado varias veces;
• no están claros el rol HA, el nodo o el modo de sincronización necesario.

Si hay varios servicios afectados, primero hay que revisar la carga del sistema, el almacenamiento, el estado de la base de datos, HA y los últimos cambios de configuración o firmware. Los reinicios repetidos a menudo solo ocultan la causa.

Un reinicio completo del sistema es más invasivo y solo debe considerarse cuando el firewall sigue inestable en general, lo exige un proceso de firmware o hotfix, o lo indica Sophos Support. En Device Console, system restart reinicia el firewall; en un clúster HA, el comando provoca un failover. En cambio, system shutdown solo lo apaga. Antes de cualquiera de las dos acciones hay que verificar el dispositivo y el nodo HA de destino, el backup, la ventana de mantenimiento y el acceso local u out-of-band; para un apagado, ese método de recuperación debe permitir realmente encender el dispositivo. Después del reinicio se comprueban el rol y la sincronización HA, el estado de los servicios y las rutas de datos afectadas. Las sesiones interrumpidas no se pueden restaurar. Si el dispositivo no vuelve a estar disponible, no se repite el comando: se utiliza el acceso de recuperación preparado y se contacta con Sophos Support si es necesario. Consulte Planificar correctamente el backup y la restauración de Sophos Firewall.

Documentar brevemente el cambio

Para problemas recurrentes o un caso de soporte basta con una nota breve. Más adelante permite saber si el reinicio resolvió el problema de forma duradera o solo ocultó un síntoma:

Date/time and time zone:
Firewall / HA node:
Service and command:
Reason:
Users/sites affected:
Logs checked before restart:
Result after restart:
Next action:

Antes del cambio se anotan la hora, la función afectada y los mensajes de log relevantes. Después se registran el estado del servicio, la prueba funcional y la siguiente acción. Las reglas temporales de SSH o Device Access y los modos de debug se eliminan después del análisis.