Reiniciar servicios de Sophos Firewall con seguridad

La forma más sencilla de reiniciar un servicio concreto de Sophos Firewall es desde System services > Services. Si el servicio no aparece allí, se puede utilizar Advanced Shell. Antes, sin embargo, 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

1. Abrir System services > Services.
2. Comprobar el servicio afectado y su estado actual.
3. En Manage, hacer clic en Restart.
4. A continuación, probar el estado y la función afectada.

WebAdmin muestra, entre otros, Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, 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.

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.

Reiniciar un servicio desde Advanced Shell

Advanced Shell resulta útil cuando el servicio no está disponible en WebAdmin o Sophos Support proporciona un comando concreto. 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

Advanced Shell ofrece un acceso amplio al sistema. Por ello, primero se realizan comprobaciones de solo lectura y solo después se ejecuta un reinicio.

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

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.

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. 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. Antes de reiniciar un firewall remoto, hay que confirmar el backup, la ventana de mantenimiento y la vía de recuperación, por ejemplo un contacto local, acceso out-of-band o un nodo HA operativo. 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.