Solución de problemas de CLI en Sophos Firewall: comandos importantes

Al solucionar problemas en Sophos Firewall, Log Viewer suele bastar para una primera delimitación. Cuando un servicio no arranca correctamente, las conexiones VPN son inestables, algunos paquetes no llegan o el soporte necesita datos detallados, la CLI cobra importancia.

Esta guía presenta los comandos más importantes para el trabajo diario: dónde ejecutarlos, qué muestran y cuándo conviene pasar a un artículo específico. Para acceder de forma segura por SSH, primero se debe consultar Conectar con Sophos Firewall mediante SSH. Una clave pública, la verificación de la clave del host y una autorización de Device Access limitada son más importantes que poder iniciar sesión rápidamente desde cualquier lugar.

⚠️ Importante: Los comandos de CLI y Advanced Shell solo deben ejecutarse desde redes de administración de confianza y con un objetivo claro. En especial, el debug, tcpdump, las operaciones con archivos y los comandos de servicios pueden afectar al espacio disponible, al rendimiento o a las conexiones activas.

Primero WebAdmin y después la CLI

La CLI no siempre es el punto de partida más rápido. Para comprobar la coincidencia de reglas, NAT o conexiones concretas, Log Viewer, Policy Test y Packet Capture en WebAdmin suelen ofrecer antes un resultado claro.

Puntos de partida recomendados:

• ¿Qué regla de firewall se aplica? Utilizar primero Log Viewer, Policy Test y Packet Capture. La CLI solo es necesaria si Log Viewer ofrece pocos detalles o se necesitan logs en tiempo real.
• ¿Llegan los paquetes al firewall? Utilizar primero Packet Capture en WebAdmin. La CLI resulta útil cuando se necesita una captura muy específica o un archivo PCAP para soporte.
• ¿Tiene problemas un servicio? Comprobar primero el dashboard, Log Viewer y los logs del servicio. La CLI es importante cuando se debe revisar directamente el estado del servicio, el debug o los archivos de log.
• ¿Se ha cambiado algo? Consultar primero Audit Trail Logs. Después, la CLI ayuda a comparar una diferencia de configuración con logs o copias de seguridad.

El objetivo no es entrar en Advanced Shell lo antes posible. Es preferible seguir un proceso reproducible: comprobar primero los eventos visibles y abrir después el archivo de log o la captura adecuados.

Documentar los resultados de la CLI de forma útil

La salida de la CLI solo resulta útil si posteriormente queda claro a qué prueba pertenece. Los mensajes de error copiados sin intervalo de tiempo, direcciones IP o función afectada suelen provocar preguntas adicionales y análisis duplicados.

Normalmente basta con una nota breve por prueba:

• Intervalo de tiempo: inicio, fin y zona horaria de la prueba.
• Flujo de prueba: Source IP, Destination IP o FQDN, puerto, usuario o peer VPN.
• Herramienta: Device Console, Advanced Shell, Log Viewer o Packet Capture.
• Comando o filtro: comando ejecutado, término de búsqueda de grep o filtro de captura utilizado.
• Resultado: coincidencia, mensaje de error, entrada de log ausente, paquete visible o paquete no visible.
• Siguiente conclusión: por ejemplo, problema de regla, problema de DNS, ruta de retorno, fallo de servicio o caso de soporte.

Antes de enviar los datos a Sophos Support, Avanet o un partner externo, se debe comprobar si la salida contiene información sensible: direcciones IP públicas, nombres de host internos, nombres de usuario, parámetros VPN, números de serie, tokens, direcciones de correo electrónico o nombres de clientes. Para un análisis técnico no es necesario distribuir los datos de forma indiscriminada; lo importante es el fragmento mínimo que demuestra el resultado.

Antes del primer comando

La solución de problemas mediante CLI es mucho más fiable cuando el contexto está definido antes del primer comando. De lo contrario, aparecen rápidamente fragmentos de log sin referencia temporal, capturas demasiado amplias o logs de debug que después no se pueden asociar con claridad.

Antes de realizar pruebas mediante CLI en producción se debe anotar lo siguiente:

• Hora del problema: permite buscar los logs específicamente en el intervalo de prueba.
• Source IP, Destination IP y puerto: grep, tcpdump y Packet Capture se mantienen acotados y legibles.
• Usuario o peer afectado: facilita la asignación de autenticación, VPN y User Matching.
• Módulo esperado: se busca primero en el archivo de log adecuado, no en todos los logs.
• Acción prevista: evita que el debug, la comprobación de un servicio o una captura queden activos accidentalmente.
• Criterio de reversión o cancelación: la prueba se detiene si aumenta la carga, se agota el espacio o aparecen efectos secundarios.
• Copia de seguridad actual si se harán cambios: permite proteger mejor los reinicios de servicios o los cambios de configuración.

Siempre que sea posible, el primer paso debe ser de solo lectura: revisar Log Viewer, consultar el archivo de log adecuado, leer service -S o iniciar una captura acotada. Los reinicios, el modo debug y las capturas amplias deben realizarse después, dentro de una ventana de prueba controlada.

En clústeres HA también debe estar claro qué dispositivo está activo. Los logs, el debug y las capturas se deben comprobar en el nodo por el que pasa realmente el tráfico relevante.

Ejecutar un reinicio completo solo como acción planificada

Un reinicio completo no es un comando de diagnóstico. Primero se guardan los logs relevantes, la hora del sistema, el uptime, los roles HA y el estado actual del fallo. Si solo están afectados WebAdmin o un servicio, se comprueba si basta con un reinicio específico de WebAdmin o un reinicio del servicio.

SFOS 22 documenta la siguiente sintaxis en Device Console:

system restart [all]

Los corchetes no forman parte del comando, sino que identifican el argumento opcional all. Primero se comprueba la forma ofrecida por la versión instalada con system restart ?. El comando reinicia el firewall e interrumpe sesiones, túneles VPN y el acceso de administración. Después de ejecutarlo no existe un rollback en la CLI, por lo que la ventana de mantenimiento, el acceso por consola y una ruta de retorno de administración probada deben estar preparados antes de confirmar.

Según Sophos, system restart provoca un failover en un clúster HA. Esto no garantiza conexiones sin interrupciones. El peer, la sincronización, los roles y el enlace HA deben estar estables previamente. Tras el reinicio se comprueban ambos nodos, roles, sincronización, uptime, WAN, routing, DNS, VPN, servicios publicados y un flujo real de aplicación. Un arranque correcto no demuestra que la causa original esté resuelta.

Apagar solo con una ruta de encendido preparada

Para un apagado controlado se utiliza exactamente este comando en Device Console:

system shutdown

Sophos no documenta opciones para este comando. Por tanto, no se añade all, un nombre de nodo ni un supuesto modificador HA a la sintaxis. Antes de confirmar se guardan los logs y la configuración, se informa a los equipos dependientes y se aclara cómo volver a encender el appliance mediante acceso físico, administración remota o la plataforma de virtualización. La página de shutdown no garantiza ningún comportamiento HA; por ello, un nodo del clúster solo se apaga siguiendo el procedimiento de mantenimiento HA previsto y después se comprueba expresamente el peer.

¿Device Console o Advanced Shell?

Sophos Firewall dispone de dos áreas de consola distintas. Muchos errores se deben a que un comando se introduce en el área equivocada.

Cada área tiene una función diferente:

• Device Console: CLI de Sophos para comandos de red, sistema y diagnóstico. Los comandos habituales incluyen ping, dnslookup, traceroute, tcpdump, drop-packet-capture y show.
• Advanced Shell: shell similar a Linux con acceso completo a los componentes del sistema. Este artículo la limita a los comandos de diagnóstico documentados por Sophos: cd /log, tail, grep, less y service -S.

Tras iniciar sesión por SSH, el firewall muestra primero el menú de consola. Para abrir Device Console, normalmente se selecciona 4. Device Console. Para abrir Advanced Shell, se utiliza 5. Device Management > 3. Advanced Shell.

Device Console agrupa parámetros globales de inspección de paquetes, TCP, UDP, acceso WAN y rutas especiales bajo advanced-firewall. Sus efectos y un procedimiento seguro de cambio se explican en Comprobar Advanced Firewall Settings de forma segura.

La prueba DNS muestra bien por qué importa el entorno de consola. En Device Console, el comando documentado oficialmente es:

dnslookup host example.com

example.com es un valor de documentación seguro; para una prueba real se sustituye por el FQDN afectado. La respuesta solo confirma la resolución desde el firewall. Ante un fallo del cliente, también se comprueban su servidor DNS, la respuesta y la ruta de red.

La ayuda oficial de la CLI de Sophos admite Tab y ? para comprobar la sintaxis. Esto resulta útil en Device Console porque no todos los comandos tienen la misma estructura.

Especialmente en Device Console, no se deben ejecutar comandos incompletos ni basados en suposiciones. Sophos advierte de que un comando incompleto puede bloquear access_server. Por ello, primero se muestra la sintaxis con Tab o ? y después se ejecuta conscientemente el comando completo.

Los cambios directos de configuración realizados en Advanced Shell no son persistentes ni se incluyen en las copias de seguridad. Por eso, esta guía solo la utiliza para comandos de diagnóstico.

Antes del acceso de emergencia: Obtener aprobación expresa para el objetivo, la persona responsable, el appliance afectado y una ventana de emergencia breve con hora de finalización y criterio de cancelación; prever la interrupción del reenvío a internet. Abrir realmente antes una vía de recuperación independiente y comprobar el acceso de administración, por ejemplo mediante una consola local, la consola de la plataforma de virtualización o administración fuera de banda. Este acceso no debe depender de la ruta de red averiada ni del modo de emergencia y debe seguir disponible para desactivarlo. No activar sin aprobación o sin una vía de recuperación independiente que funcione; acordar primero la recuperación con la persona responsable o Sophos Support.

Un comando especial de emergencia es system appliance_access enable. Este comando anula la configuración de Device Access y permite acceder a todos los servicios locales del firewall, incluidos servicios heredados como Telnet. Importante: mientras este modo está activo, el firewall deja de reenviar tráfico saliente a internet. No es un paso normal de solución de problemas, sino una medida para emergencias breves. Antes de activarlo, se debe comprobar el estado:

El default documentado es Disable. Con enable, todos los puertos aceptan conexiones entrantes y se elimina temporalmente la restricción normal de alcance de Device Access. La autenticación de cada servicio sigue siendo un control independiente, pero no convierte esta exposición amplia en algo inocuo.

system appliance_access show

En cuanto se haya restablecido el acceso completo de administración previsto, desactivar inmediatamente el modo de emergencia en 4. Device Console y volver a comprobar el estado; no esperar a que terminen otros diagnósticos. Desactivarlo también mediante la vía de recuperación independiente preparada si se cancela el procedimiento o se alcanza la hora de finalización aprobada:

system appliance_access disable
system appliance_access show

Después, show debe confirmar Disable. Comprobar además un nuevo inicio de sesión en WebAdmin o SSH desde la red de administración prevista bajo las reglas normales de Device Access y confirmar que los accesos anteriormente bloqueados siguen bloqueados. Desde un cliente afectado situado detrás del firewall, probar una conexión saliente real a internet, por ejemplo una solicitud HTTPS a un destino aprobado, y verificar una respuesta correcta; un ping desde el firewall o show por sí solos no demuestran que se haya restablecido el reenvío. Si las comprobaciones fallan o el estado no está claro, no cerrar el caso como resuelto: mantener abierta la vía de recuperación independiente, guardar la respuesta de la CLI y los resultados de la prueba y coordinarse con la persona responsable o Sophos Support, en lugar de reactivar el acceso amplio de emergencia como solución permanente.

Si un comando no se reconoce, se debe comprobar primero el área de consola. Es más probable que se esté utilizando el área equivocada a que el comando esté defectuoso.

Consultar logs en Advanced Shell

Los principales archivos de log se encuentran en /log. Sophos documenta primero el cambio a este directorio en Advanced Shell:

cd /log

Comandos básicos útiles:

• Seguir un log en directo: tail -f ips.log. La salida continua solo se mantiene durante la ventana de prueba documentada.
• Leer un archivo de log: less ips.log. Así se muestran las líneas por secciones.
• Buscar un término: grep error ips.log. Adaptar el término y el archivo al fallo.

La relación entre módulos y archivos de log se resume en Sophos Firewall: servicios y logs para la solución de problemas.

Al consultar logs en tiempo real, la prueba debe mantenerse breve y se debe anotar la hora. Esto es especialmente importante si después se entrega un archivo de logs a Sophos Support o Avanet.

Device Console para comprobaciones rápidas de red

Device Console es adecuada para realizar pruebas rápidas desde la perspectiva del firewall. Permite comprobar si DNS, el routing o la conectividad funcionan en principio.

Comprobaciones rápidas:

• Comprobar un host: ping 192.0.2.10 count 4 comprueba la conectividad ICMP.
• Comprobar DNS en Device Console: dnslookup host example.com comprueba la resolución de nombres desde la perspectiva del firewall.
• Comprobar la ruta: traceroute 192.0.2.10 muestra el recorrido hasta el destino.
• Consultar el estado de las interfaces: show interfaces muestra información sobre las interfaces.
• Iniciar Drop Capture: drop-packet-capture 'host 192.0.2.10' muestra los paquetes descartados por las reglas de firewall.
• Iniciar una captura de paquetes: tcpdump 'host 192.0.2.10 and port 443' comprueba si los paquetes son visibles en el firewall.

Para IPv6 están disponibles los comandos equivalentes ping6, dnslookup6 y traceroute6.

tcpdump y drop-packet-capture continúan hasta que se detienen con Ctrl+C. Antes de iniciarlos se deben definir el filtro y la ventana de prueba, observar la salida y detener la captura inmediatamente después. Estos comandos no cambian la configuración, pero su carga depende del volumen de tráfico, la amplitud del filtro y el tiempo de ejecución.

drop-packet-capture resulta especialmente útil cuando no está claro si el firewall descarta paquetes de forma activa. Sin embargo, no sustituye un análisis de la aplicación. Si un servidor responde pero la aplicación sigue sin funcionar, también se deben revisar Log Viewer, NAT, Packet Capture o los logs de la aplicación.

Para capturas más largas y archivos PCAP resulta más adecuado el artículo Sophos Firewall: recopilar logs con TCPDump para su análisis. También se debe planificar el tamaño máximo del archivo, dónde se guardará y cómo se transferirá de forma segura.

Comprobaciones de red en WebAdmin sin CLI

En Diagnostics > Tools se pueden responder las mismas preguntas básicas sin acceso a la consola. Ping permite seleccionar IPv4 o IPv6, la interfaz de salida y el tamaño del paquete. Sophos utiliza 32 bytes de forma predeterminada y admite valores de 1 a 65.507 bytes. Un ping correcto confirma la conectividad ICMP desde la interfaz seleccionada del firewall, pero no que funcione un servicio de aplicación.

Para Ping en SFOS 22 y SFOS 23, IP address or hostname puede contener una dirección IPv4, una dirección IPv6 o un FQDN. IP family define la familia de direcciones, Interface la interfaz de salida y Size el tamaño del paquete. Un FQDN requiere además la resolución de nombres; para delimitar un problema de DNS, comparar también la misma prueba utilizando la dirección IP esperada.

La salida de Ping muestra si se reciben respuestas, cuántos paquetes se han enviado y recibido, la pérdida de paquetes y el tiempo de ida y vuelta (RTT). La RTT es el tiempo de la solicitud y la respuesta, no la latencia en un solo sentido. Si no se recibe ninguna respuesta, se muestra una pérdida de paquetes del 100 por ciento. Esto por sí solo no demuestra que el host esté apagado: comprobar la dirección de destino, la interfaz seleccionada, el routing y si se permite ICMP y, si es necesario, utilizar un Packet Capture acotado. Una prueba correcta debe seguir correspondiendo al flujo real de la aplicación.

Traceroute también admite IPv4, IPv6 o un FQDN y una interfaz de salida elegida de forma consciente. La ausencia de respuesta de algunos saltos no demuestra una interrupción si responden saltos posteriores o el destino. Para analizar una ruta se consideran conjuntamente la conectividad del destino, el último salto que responde y el flujo de paquetes medido en paralelo.

En WebAdmin, en Diagnostics > Tools > Traceroute, definir el destino en IP address or hostname, la familia de direcciones en IP version y la interfaz de salida en Interface; iniciar la consulta con Traceroute. Para SFOS 22 y SFOS 23, Sophos describe la salida con los routers atravesados, el número máximo de saltos y el tiempo total de retorno del paquete en milisegundos. El número máximo de saltos limita la búsqueda de la ruta; no demuestra que se haya alcanzado el destino. Los valores de tiempo describen las respuestas de diagnóstico y no demuestran el rendimiento de transferencia de una aplicación. En 4. Device Console, traceroute6 2001:db8::10 complementa el ejemplo de IPv4 anterior; sustituir la dirección de documentación por la dirección IPv6 de destino real.

Las denominaciones Name lookup y Lookup using all configured servers que aparecen a continuación se aplican a SFOS 22. Las denominaciones modificadas de SFOS 23, DNS lookup y All configured servers, así como las opciones adicionales de servidor y sus requisitos, se explican en Comparar resolvers individuales en Diagnostics.

Name lookup consulta un servidor DNS seleccionado. Lookup using all configured servers permite comparar todos los servidores DNS configurados en el firewall y sus tiempos de respuesta. Un único resultado rápido no justifica todavía cambiar la prioridad DNS; también deben ser correctos el contenido de la respuesta, la fiabilidad y la ruta del cliente afectado.

Route lookup muestra por qué interfaz enrutaría el firewall una dirección de destino IPv4 o IPv6. No demuestra la regla de firewall, NAT, la decisión SD-WAN ni un camino de retorno funcional. Para la validación se utilizan después una conexión real, Connection List o Packet Capture.

Comprobar conexiones sin modificar su estado

Filtre las conexiones IPv4 e IPv6 actuales en Current activities > Live connections y Diagnostics > Connection list. Connection list muestra, entre otros datos, interfaces de entrada y salida, origen y destino, Rule ID, NAT ID, direcciones traducidas, estado y contadores Rx/Tx. Es un mejor primer paso que una herramienta no documentada de Advanced Shell.

En Device Console también está documentada esta utilidad de conexiones:

system diagnostics utilities connections

Antes de ejecutarla, compruebe los argumentos disponibles con system diagnostics utilities connections ?. Como Connection list es una instantánea, reproduzca el flujo de prueba mientras actualiza la vista. Si la conexión sigue sin aparecer, realice un Packet Capture acotado; si aparece, continúe con Rule ID, NAT ID, interfaces, traducción y contadores de respuesta.

Comprobar el espacio disponible y el estado del sistema

Antes de activar debug, generar archivos de logs grandes o realizar capturas prolongadas, se debe comprobar el espacio disponible.

Device Console ofrece las siguientes comprobaciones de sistema de solo lectura y documentadas oficialmente:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk
system diagnostics show uptime
system diagnostics show version-info

system diagnostics show version-info también muestra el número de serie y el Device ID. Estos identificadores se ocultan antes de compartir salidas o capturas.

Otros destinos de solo lectura son interrupts, syslog, sysmsg, subsystem-info y ctr-log-lines. Responden a preguntas diferentes y no deben tratarse como valores de estado intercambiables:

system diagnostics show interrupts
system diagnostics show syslog
system diagnostics show sysmsg
system diagnostics show subsystem-info
system diagnostics show ctr-log-lines

En XGS Appliances también está disponible system diagnostics selftest para pruebas básicas de la tarjeta de red. El comando no se aplica a otras plataformas y no sustituye una prueba de cable, una medición de rendimiento ni una captura de paquetes. Como Sophos no indica en la página del comando el impacto sobre el tráfico productivo, la prueba solo se ejecuta de forma planificada o por indicación del soporte y se compara con el estado del enlace, los contadores de interfaz y el tráfico real.

En system diagnostics utilities, SFOS agrupa otras herramientas para ARP, ancho de banda, conexiones, DNS, captura de descartes, configuración de red, ping, procesos, rutas y traceroute, incluidas variantes IPv6 cuando Sophos las ofrece. La sintaxis exacta se comprueba en la compilación instalada mediante finalización con Tab. Algunas herramientas solo leen el estado, mientras que otras generan tráfico de prueba o inician una salida continua.

Para una comprobación adicional de solo lectura, Sophos documenta en Advanced Shell:

service -S
service -S | grep ips

La primera variante muestra muchos estados de servicio; la segunda usa el ejemplo de IPS documentado por Sophos. La ausencia de resultados no indica que se deba reiniciar: primero se cotejan el nombre del servicio y el archivo de log con la lista actual de Sophos.

Si el espacio disponible ya es escaso, no se debe activar debug ni iniciar una captura prolongada. Primero hay que aclarar qué logs o informes se pueden guardar y eliminar de forma segura.

Recopilar logs de debug solo con una salida confirmada

Para SFOS 22 y SFOS 23, la activación y desactivación del debug de subsistemas de servicio mostrado aquí está documentada en Device Console, no en WebAdmin. Pktcapd es el ejemplo documentado, no un interruptor general para todos los servicios. Antes de empezar, anotar la compilación instalada, el nodo HA afectado, el espacio libre, la ventana de prueba y el procedimiento de desactivación adecuado; comprobar la sintaxis y el subsistema disponible con ? o Tab. El debug aumenta el tamaño de los archivos de log y permanece activo hasta que se desactiva. Activarlo solo durante una ventana de análisis breve y acordada:

Antes de debug on: Determinar y documentar el estado de depuración existente para ese subsistema exacto en ese nodo HA exacto mediante un método de solo lectura compatible con la compilación instalada o con Sophos Support. Aclarar además quién es responsable de un diagnóstico existente y si hay una recopilación en curso. system diagnostics show subsystem-info es solo una comprobación complementaria del sistema; la sintaxis documentada no garantiza un campo uniforme de estado de depuración ni una prueba fiable de que la depuración esté desactivada.

Detenerse si la depuración está activa o si el estado inicial o la responsabilidad no están claros: No ejecutar este procedimiento de activación/desactivación y, en particular, no utilizar preventivamente debug off para establecer un estado inicial. Primero acordar con el responsable del diagnóstico o con Sophos Support el propósito, la responsabilidad y el procedimiento de desactivación; continuar únicamente con un estado inicial inactivo confirmado y expresamente aprobado. Una ventana de pruebas acordada por sí sola no autoriza a finalizar otra recopilación de diagnóstico en curso. Solo entonces activar la depuración por primera vez para este procedimiento y dejar constancia de la responsabilidad propia sobre su activación y desactivación:

system diagnostics subsystems Pktcapd debug on

Reproducir el fallo una vez. Los logs individuales se seleccionan en Diagnostics > Tools > Troubleshooting logs y se descargan con Download como un archivo comprimido. Para obtener un Consolidated troubleshooting report (CTR), seleccionar en su lugar las opciones necesarias System snapshot y All log files en Diagnostics > Tools > Consolidated troubleshooting report, introducir el motivo y seleccionar Generate y después Download. El CTR se descarga cifrado; System snapshot no requiere el modo debug. En algunos logs del CTR, la configuración de la CLI limita las líneas de log incluidas, por lo que un CTR no contiene automáticamente todo el historial de logs.

Inmediatamente después de la descarga, desactivar el modo de depuración en 4. Device Console exclusivamente para los subsistemas de servicio cuya depuración haya sido activada por este procedimiento desde el estado inicial inactivo confirmado y siga bajo su responsabilidad. Dejar sin cambios el estado de otros diagnósticos en curso. Para el ejemplo activado de este modo, el procedimiento exacto de desactivación es:

system diagnostics subsystems Pktcapd debug off

Si se interrumpe la reproducción, falla la descarga, la carga es elevada o queda poco espacio de almacenamiento, finalizar la prueba y desactivar exclusivamente la depuración que este procedimiento haya activado desde el estado inicial inactivo confirmado y que siga bajo su propia responsabilidad, en lugar de esperar a que la exportación se complete correctamente. No finalizar recopilaciones de diagnóstico ajenas en curso; si la responsabilidad no está clara, coordinarse con el responsable del diagnóstico o con Sophos Support, no desactivar por mera sospecha. Finalizar una sesión SSH o descargar los registros no sustituye al comando de desactivación propio. Los registros y los informes no se sincronizan entre nodos HA; recopilar y limpiar en el nodo en el que este procedimiento haya activado la depuración.

Documentar los comandos de activación y desactivación, la hora, el nodo y la respuesta completa de la CLI. Después del comando de desactivación, comprobar si la CLI confirma la desactivación o comunica un error; como comprobación complementaria, comparar la salida de la comprobación de sistema de solo lectura system diagnostics show subsystem-info con el estado registrado antes de la prueba. La sintaxis documentada no garantiza un campo uniforme de estado del debug en todas las compilaciones. Si no hay una confirmación inequívoca, no dar el estado por «desactivado», sino aclarar la salida con Sophos Support. Si se rechaza el comando, comprobar la sintaxis con ? y no continuar con comandos de subsistema, reinicio o servicio basados en suposiciones. En particular, no aplicar la sintaxis de subsistemas de servicio a CSC, cuyo comando de debug está documentado de otra forma. El debug en Advanced Shell se omite aquí deliberadamente porque la sintaxis genérica de servicios no ofrece un comando de desactivación uniforme para todos los modos de debug.

Para reinicios de servicios y sus efectos, consulte Cómo reiniciar servicios de Sophos Firewall. Reiniciar servicios VPN, IPS, web o de autenticación puede interrumpir sesiones o inicios de sesión activos.

Proporcionar logs de forma segura

En casos complejos, los fragmentos individuales de log no suelen ser suficientes. Para Sophos Support, Avanet o un análisis externo, un archivo de logs completo suele resultar más útil.

En lugar de escribir credenciales en comandos de shell, recopilar los archivos en WebAdmin: seleccionar Diagnostics > Tools > Troubleshooting logs para los archivos de log individuales y elegir Download. Para crear un CTR, utilizar Diagnostics > Tools > Consolidated troubleshooting report, seleccionar las opciones necesarias System snapshot y All log files e introducir un motivo; después, seleccionar Generate y Download. Antes de compartir los datos, comprobar que el archivo comprimido o el informe cifrado se haya descargado realmente y entregarlo únicamente a través del portal de soporte acordado. Una exportación fallida no es motivo para dejar activa la depuración que este procedimiento haya activado desde un estado inicial inactivo confirmado y que siga bajo su propia responsabilidad; esto no debe dar lugar a que se finalice otra recopilación de diagnóstico en curso. La guía correspondiente se encuentra en Guardar logs de Sophos Firewall para soporte y análisis.

Los archivos de log pueden contener información sensible: direcciones IP internas y públicas, nombres de host, nombres de usuario, parámetros VPN y mensajes de error. Antes de compartirlos, debe quedar claro quién recibirá los datos y durante cuánto tiempo se conservarán.

Errores habituales al solucionar problemas mediante CLI

• Comando en el área de consola equivocada: Device Console y Advanced Shell utilizan sintaxis distintas. Comprobar primero el área.
• Dejar activa la depuración propia después del análisis: Los registros crecen innecesariamente y pueden consumir espacio de almacenamiento. Desactivar de nuevo inmediatamente solo la depuración que este procedimiento haya activado desde un estado inicial inactivo confirmado y que siga bajo su propia responsabilidad; no finalizar recopilaciones de diagnóstico ajenas.
• tcpdump amplio sin filtro: Mucha salida, carga elevada y datos difíciles de analizar. Limitar el host, puerto, interfaz o número de paquetes.
• Credenciales FTP en el historial de la shell: Las credenciales pueden aparecer en logs, capturas de pantalla o el historial. Utilizar una transferencia segura y credenciales temporales.
• Comprobar un único archivo de log: Muchos problemas afectan a varios módulos. Combinar Log Viewer, los logs de servicio adecuados y Packet Capture.
• No documentar la hora: El soporte debe buscar en intervalos de log innecesariamente amplios. Anotar la hora, la acción de prueba y las direcciones IP implicadas.
• No limpiar después de la prueba: La depuración, los archivos temporales o los accesos amplios permanecen activos. Desactivar solo la depuración que este procedimiento haya activado desde un estado inicial inactivo confirmado y que siga bajo su propia responsabilidad, revisar los archivos y retirar las autorizaciones temporales de acceso SSH; no finalizar recopilaciones de diagnóstico ajenas.

Lista de comprobación

• Acceso SSH permitido solo desde redes de administración de confianza.
• Fingerprint SSH y acceso admin comprobados antes del análisis.
• Área de consola correcta seleccionada: Device Console o Advanced Shell.
• Hora del problema, Source IP, Destination IP, puerto y usuario documentados.
• Resultado de la CLI documentado con intervalo de tiempo, comando, filtro y resultado.
• Primero se utilizaron comandos de solo lectura antes de iniciar debug, reinicios de servicios o capturas prolongadas.
• Log Viewer comprobado en primer lugar.
• Archivo de log adecuado identificado en /log.
• tail, grep o less utilizados con un término de búsqueda específico.
• Para problemas de red se han usado de forma específica dnslookup, ping, traceroute, drop-packet-capture o tcpdump en Device Console.
• Antes de activar la depuración de subsistemas de servicio en SFOS 22/23, se aclararon el estado existente y el responsable del diagnóstico para el subsistema y el nodo HA exactos, y se confirmó y documentó un estado inicial inactivo expresamente aprobado; si el estado estaba activo o no estaba claro, no se ejecutó el procedimiento de activación/desactivación, sino que se coordinó con el responsable o con Support. Solo desde ese estado inicial se activó brevemente la depuración en 4. Device Console; en el ejemplo, con system diagnostics subsystems Pktcapd debug on y, después, con system diagnostics subsystems Pktcapd debug off se desactivó exclusivamente la depuración activada por este procedimiento y que seguía bajo su propia responsabilidad. Se dejaron sin cambios las recopilaciones de diagnóstico ajenas. Se comprobaron la respuesta de desactivación y el estado complementario del sistema; si el estado no estaba claro, se aclaró con Support, sin darlo por desactivado.
• Espacio disponible comprobado antes de debug o PCAP.
• Archivo de logs transferido de forma segura y archivos temporales eliminados.
• Excepciones temporales de Device Access o SSH eliminadas después del caso de soporte.

Preguntas frecuentes