Reiniciar servicios de Sophos Firewall con seguridad
Reiniciar servicios concretos de Sophos Firewall puede ayudar cuando un módulo ya no responde correctamente, un log deja de mostrar entradas nuevas o Sophos Support solicita un reinicio dirigido. Pero no sustituye un troubleshooting limpio. Un reinicio de servicio equivocado puede interrumpir brevemente túneles VPN, routing, WebAdmin, DNS, DHCP, reporting u otras funciones.
Este artículo explica cómo reiniciar servicios mediante WebAdmin o Advanced Shell, revisar antes los logs adecuados y comprobar después si el servicio vuelve a funcionar correctamente. Si primero no está claro qué servicio técnico corresponde a qué módulo, ayuda la vista general Sophos Firewall Troubleshooting: servicios y logs. Para seguridad básica de CLI, debug y tcpdump, también encaja Sophos Firewall CLI Troubleshooting: comandos importantes.
⚠️ Importante: Los reinicios de servicios en entornos productivos deberían planificarse. Antes debe estar claro qué servicio está afectado, qué usuarios o túneles pueden interrumpirse y si existe un acceso alternativo a la firewall.
Cuándo tiene sentido reiniciar un servicio
Un reinicio de servicio dirigido tiene sentido cuando un módulo concreto está afectado y el resto de la firewall funciona básicamente de forma estable.
Ejemplos típicos:
- WebAdmin ya no carga, pero routing y reglas de firewall siguen funcionando.
- Un servicio VPN está colgado, mientras otras funciones de firewall no muestran anomalías.
- Un log muestra errores actuales de un servicio concreto.
- Sophos Support nombra un servicio concreto que debe reiniciarse.
- Un servicio no quedó activo correctamente después de un cambio de configuración.
No tiene sentido reiniciar varios servicios a ciegas solo porque el problema todavía no está claro. En ese caso conviene revisar primero logs, carga del sistema, espacio en disco, estado HA, routing y módulos afectados.
Cuándo no se deberían reiniciar servicios
Un reinicio de servicio resulta tentador porque actúa rápido. Pero en algunas situaciones empeora el análisis o genera interrupciones adicionales.
| Situación | Por qué tener cuidado |
|---|---|
| La causa todavía es totalmente desconocida | El reinicio cambia el estado y puede ocultar pistas importantes en logs o salidas de estado. |
| Varios servicios centrales fallan al mismo tiempo | Entonces a menudo el problema no es un servicio individual, sino carga del sistema, espacio en disco, base de datos, HA o estado de plataforma. |
| Solo se puede acceder a la firewall mediante exactamente ese servicio | Un reinicio puede hacer perder el último acceso remoto. |
| Están afectados servicios productivos de VPN, routing o DHCP | Usuarios, sedes o leases existentes pueden interrumpirse brevemente. |
| Debug ya está activo y el error es reproducible | Primero guardar los logs relevantes y después reiniciar. |
| El servicio ya se ha reiniciado varias veces | Entonces hace falta análisis de causa, no repetición. |
Si aun así el reinicio es necesario, antes conviene anotar como mínimo el momento actual, usuarios o sedes afectadas, nombre de servicio, archivo de log y efecto esperado.
Revisar antes del reinicio
Antes de reiniciar un servicio conviene documentar brevemente qué está afectado. Esto ahorra tiempo si el error vuelve o si hace falta un caso de soporte.
Revisión práctica previa:
- Delimitar el módulo afectado, por ejemplo WebAdmin, IPsec, DNS, DHCP, IPS o WAF.
- Comprobar si la firewall en conjunto está estable o si fallan varios servicios.
- Comprobar si en ese momento hay administradores, usuarios VPN o sedes críticas conectados.
- En clústeres HA, comprobar en qué node se trabaja y qué node está activo.
- Abrir el archivo de log adecuado y guardar los últimos mensajes.
- Revisar el espacio en disco si participan debug, logs grandes o archivos PCAP.
- Exportar logs antes del reinicio si es necesario.
- Definir un criterio de cancelación: cuándo se detiene, pospone o escala el reinicio?
Para entornos HA también es relevante entender las variantes de Sophos Firewall HA Cluster. Si se necesitan logs para un análisis externo, encaja guardar logs de Sophos Firewall para soporte y análisis.
Documentar el reinicio en un caso de soporte
Si un reinicio de servicio forma parte de un caso de soporte, una ventana de mantenimiento o un problema recurrente, conviene documentar brevemente la acción. No tiene que ser un informe largo. Lo importante es que más tarde siga claro qué servicio se reinició, cuándo, por qué y con qué resultado.
Plantilla práctica de nota:
Date/time and time zone:
Firewall / HA node:
Service:
Command:
Reason:
Users/sites affected:
Logs checked before restart:
Result after restart:
Next action:
Esta nota es especialmente útil si un error vuelve después de unas horas o días. Entonces se ve de inmediato si siempre está afectado el mismo servicio, si el reinicio solo ayuda a corto plazo o si se vuelve más probable un problema más profundo como espacio en disco, estado de base de datos, comportamiento HA o un product bug.
Reiniciar servicios mediante WebAdmin
Algunos servicios se pueden reiniciar directamente mediante WebAdmin. Es la forma más sencilla si la GUI sigue accesible y el servicio deseado aparece allí.
El punto exacto del menú depende de la versión y de la vista. Lo decisivo es: WebAdmin solo sirve para servicios que realmente se ofrecen allí. Para troubleshooting más profundo, análisis de logs o servicios sin acción de GUI, se necesita la Advanced Shell.
Si solo la propia GUI WebAdmin ya no responde, este artículo general no debería ser el primer paso. Para eso existe la guía específica reiniciar la GUI WebAdmin de Sophos Firewall.
Abrir Advanced Shell
Para comandos de servicio se necesita la Advanced Shell. El acceso se realiza normalmente por SSH con el usuario admin.
Si SSH todavía no está preparado, ayuda conectar con Sophos Firewall por SSH. El acceso SSH solo debería permitirse desde redes de administración confiables. Antes del login conviene comprobar el SSH fingerprint, especialmente después de un reimage, cambio de hardware o cambio de IP. El hardening adecuado está en Device Access y Local Service ACL en Sophos Firewall.
Después del login, se abre la Advanced Shell mediante:
5. Device Management > Advanced Shell
La Advanced Shell ofrece acceso amplio al sistema. Los comandos solo deberían ejecutarse allí si el servicio afectado y el efecto esperado están claros.
Si solo se quiere revisar el estado o leer un archivo de log, conviene quedarse primero en comandos de solo lectura. Reinicios, Stop/Start y debug son intervenciones y pertenecen a una ventana de análisis consciente.
Listar servicios
La lista de servicios disponibles se muestra con:
service -S
Si se busca un servicio concreto, se puede filtrar la salida:
service -S | grep strongswan
service -S | grep zebra
service -S | grep dns
Los nombres técnicos de servicios no siempre son autoexplicativos. zebra pertenece al routing estático, strongswan a IPsec, dnsd a DNS y awed al Wireless Controller. La asignación más detallada está en Sophos Firewall Troubleshooting: servicios y logs.
Reiniciar servicio
El patrón básico para un reinicio es:
service <service>:restart -ds nosync
Ejemplo para el servicio de routing zebra:
service zebra:restart -ds nosync
Importante es la sintaxis con espacio: -ds nosync. Variantes como -dsnosync no son lo mismo y no deberían copiarse de notas antiguas.
Durante un reinicio, el servicio se detiene y vuelve a iniciarse. Según el servicio, esto puede interrumpir conexiones activas. En routing, VPN, DNS, DHCP, Web Proxy, WAF o Wireless conviene evaluar antes quién puede verse afectado.
Si el servicio pertenece a un módulo relevante para la seguridad, después del reinicio no basta con comprobar el estado. Lo decisivo es si la función de protección o de conexión esperada vuelve a trabajar y si aparecen nuevos errores en el log.
Detener e iniciar un servicio
Si un servicio no reacciona correctamente a restart o Sophos Support lo indica así, Stop y Start pueden ejecutarse por separado:
service zebra:stop -ds nosync
service zebra:start -ds nosync
Entre Stop y Start no conviene esperar innecesariamente si el servicio se necesita en producción. Después debería comprobarse el estado y realizarse una prueba funcional.
Comprobar el estado del servicio
service zebra:status -ds nosync
Además, conviene revisar el archivo de log adecuado. En routing sería, por ejemplo:
tail -n 80 /log/zebra.log
Un estado correcto no siempre basta. Lo decisivo es si la función afectada vuelve a trabajar: los túneles VPN conectan, DNS responde, DHCP asigna leases, WebAdmin carga o routing funciona.
Ejemplos de servicios frecuentes
Los siguientes ejemplos muestran reinicios típicos de servicios y no sustituyen un análisis de la causa.
Reiniciar Wireless Controller
service awed:restart -ds nosync
Reiniciar SMTP Service
service smtpd:restart -ds nosync
Reiniciar VPN IPsec Service
service strongswan:restart -ds nosync
Reiniciar DNS Service
service dnsd:restart -ds nosync
En problemas IPsec conviene usar además Sophos Firewall IPsec Troubleshooting. En problemas DNS, a menudo configurar DNS Request Routes en Sophos Firewall o la asignación DNS/DHCP en Sophos Firewall Troubleshooting: servicios y logs es más relevante que un simple reinicio de servicio.
Tratar áreas de servicio sensibles de forma consciente
No todos los reinicios de servicio tienen el mismo efecto. Algunos servicios afectan solo a una interfaz de administración, otros están directamente en el data path o controlan autenticación, VPN, routing o servicios locales. Cuanto más cerca esté un servicio del tráfico productivo, más importantes son ventana de mantenimiento, revisión de logs y plan de retorno.
| Área de servicio | Posible efecto | Precaución en operación |
|---|---|---|
| IPsec / SSL VPN | Túneles o sesiones de Remote Access pueden desconectarse | Informar antes a usuarios y sedes, y revisar activamente los túneles después |
| DNS / DHCP | Resolución de nombres o asignación de leases puede verse afectada brevemente | Planificar prueba de cliente y revisión de logs después del reinicio |
| Routing / SD-WAN | Pueden verse afectados paths, Gateway Monitoring o conexiones entre sedes | Revisar tabla de routing, estado de gateways y accesibilidad |
| Web Proxy / IPS / TLS Inspection | Accesos web o inspection pueden verse influidos brevemente | Controlar Log Viewer y policies afectadas después del reinicio |
| WAF / Reverse Proxy | Aplicaciones publicadas pueden dejar de estar accesibles brevemente | Probar URL externa y accesibilidad del backend |
| WebAdmin | El acceso administrativo se interrumpe brevemente | Tener preparado acceso alternativo por SSH o consola local |
| Reporting / base de datos / almacenamiento | Análisis, reports o estabilidad de GUI pueden verse afectados | no reiniciar a ciegas, primero revisar espacio en disco y logs |
Si un área de servicio no está clara, conviene revisar primero Sophos Firewall Troubleshooting: servicios y logs antes de ejecutar un reinicio. En temas de base de datos, almacenamiento o reporting, un reinicio no dirigido rara vez es la mejor primera medida.
Validar después del reinicio
Después de reiniciar un servicio no conviene comprobar solo si el comando vuelve sin mensaje de error. Lo importante es la prueba funcional.
Checks útiles:
- comprobar el estado del servicio con
service <service>:status -ds nosync. - revisar el archivo de log adecuado en
/logpor nuevos errores. - validar la función afectada con una prueba real.
- revisar Log Viewer si están afectadas reglas de firewall, NAT, web, IPS o VPN.
- en clústeres HA, comprobar si el node activo sigue trabajando como se espera.
- desactivar debug si estaba activado antes o durante el reinicio.
- eliminar permisos temporales de SSH o Device Access si se establecieron solo para el caso de soporte.
- en errores recurrentes, guardar logs y analizar la causa en lugar de reiniciar servicios repetidamente.
Según el servicio, otra prueba funcional tiene sentido:
| Área de servicio | Prueba funcional útil |
|---|---|
IPsec / strongswan | estado de túnel, Log Viewer, strongswan.log, accesibilidad de un host en el lado remoto |
DNS / dnsd | resolución de nombres interna y externa, DNS Request Routes, dnsd.log |
Routing / zebra | tabla de routing, Gateway Monitoring, ping o traceroute por el path afectado |
| WAF / Reverse Proxy | probar URL publicada externamente, reverseproxy.log, accesibilidad del backend |
WebAdmin / tomcat y apache | revisar login, dashboard, Log Viewer y tomcat.log |
DHCP / dhcpd | revisar asignación de lease con cliente de prueba y dhcpd.log |
Cuándo es mejor un reboot
Un reboot completo es más invasivo que un reinicio de servicio, pero puede tener sentido si varios servicios centrales están colgados, se han resuelto problemas de almacenamiento o base de datos, Sophos Support lo solicita o la firewall sigue inestable después de reinicios dirigidos.
La decisión no debería tomarse por intuición. Un reinicio de servicio es mejor si un módulo individual está claramente afectado y la firewall trabaja estable por lo demás. Un reboot encaja más si el estado del sistema es globalmente poco claro o sigue dañado después de un reinicio dirigido.
| Situación | Más bien reinicio de servicio | Más bien reboot |
|---|---|---|
| Un servicio individual está colgado | Sí, si el servicio y el efecto están claros | Solo si el reinicio no ayuda |
| Varios servicios muestran errores | Primero revisar logs y espacio en disco | Sí, si el estado del sistema es inestable en conjunto |
| Hay una ventana de firmware o hotfix en curso | No como sustituto de un reinicio planificado | Sí, si el proceso de update lo prevé |
| El clúster HA está inestable | Solo después de revisar roles y con aprobación de soporte | Solo con ventana de mantenimiento y plan HA |
| Se ha limpiado espacio en disco o base de datos | Solo para el servicio afectado | Sí, si Sophos Support lo exige como cierre |
| El acceso remoto es incierto | Con cuidado, el último acceso puede cortarse | Solo con acceso local o alternativo |
Antes de un reboot deberían estar claros backup, ventana de mantenimiento, acceso al sitio, comportamiento HA y efectos sobre VPN, RED, Wireless, routing y servicios publicados. En sedes remotas también hace falta una vía de retorno por si la firewall no vuelve online correctamente después del reinicio: contacto local, acceso out-of-band, contraparte HA funcional o un proceso de soporte claro.
Después del reboot debería realizarse la misma validación que tras un reinicio de servicio, solo que más amplia: estado HA, estado de licencia, túneles VPN, gateways SD-WAN, logs centrales, WebAdmin, conexión Central y los servicios publicados más importantes. Para temas de recovery encaja además planificar correctamente backup y restore de Sophos Firewall.
Checklist operativo
- Módulo afectado y nombre de servicio identificados.
- Archivo de log adecuado revisado antes del reinicio.
- Posibles efectos sobre usuarios, VPN, routing o sedes evaluados.
- Ventana de mantenimiento o contexto HA aclarado si hace falta.
- Acceso SSH y revisión de host key preparados correctamente si se necesita Advanced Shell.
- Servicio reiniciado de forma dirigida.
- Estado y archivo de log revisados después del reinicio.
- Función validada con una prueba real.
- Debug y accesos temporales retirados después del análisis.
- Errores recurrentes documentados y no ocultados mediante reinicios repetidos.
FAQ
¿Cómo se listan los servicios de Sophos Firewall?
service -S muestra los servicios disponibles. Con grep se puede filtrar la lista, por ejemplo service -S | grep strongswan.¿Qué comando reinicia un servicio de Sophos Firewall?
service <service>:restart -ds nosync, por ejemplo service strongswan:restart -ds nosync para IPsec.