Sophos ZTNA Agent: resolución sistemática de problemas

Objetivo y respuesta directa

Que un recurso ZTNA no esté disponible no significa necesariamente que el agente esté defectuoso. La instalación, la política, el grupo de usuarios, el DNS, el proveedor de identidad, la puerta de enlace y la aplicación interna forman una cadena. Por tanto, la resolución de problemas debe partir del síntoma visible y modificar únicamente la capa para la que existan indicios.

La comprobación fiable más breve es la siguiente:

Anote el usuario, el dispositivo, el recurso y la hora afectados.
Compruebe la instalación y el estado local del agente.
En My Products > ZTNA (ruta completa: Sophos Central > My Products > ZTNA), coteje el recurso, el método de acceso y la política.
En ZTNA > Reports (ruta completa: Sophos Central > My Products > ZTNA > Reports), busque una autenticación correcta o el motivo por el que se denegó el acceso.
En My Environment > Alerts (ruta completa: Sophos Central > Alerts), busque algún evento del dispositivo relacionado con la instalación, las actualizaciones, las licencias o la conectividad que coincida con la hora del incidente.
Compruebe el DNS, la identidad, el estado del dispositivo o la puerta de enlace únicamente si el síntoma detectado apunta a ese componente.

Que una solicitud del navegador se complete correctamente no demuestra que se haya utilizado la ruta del agente. Del mismo modo, el Portal de usuario de ZTNA solo muestra aplicaciones sin agente; no es necesario que aparezcan en él los recursos basados en agente.

Requisitos, licencias y roles

Para realizar este diagnóstico se necesitan un usuario afectado y un dispositivo administrado, el FQDN de un recurso afectado y acceso a la configuración de ZTNA, los informes, la vista del dispositivo y las alertas del tenant correcto. Al probar un recurso basado en agente, el agente ZTNA debe estar asignado al dispositivo. En Devices > Computers o Servers, una marca de verificación verde indica que el componente ZTNA está instalado; un signo más indica que todavía se puede instalar.

Las fuentes utilizadas no especifican un nombre de licencia independiente ni un rol de administrador concreto para este procedimiento. No deduzca que dispone de permisos más amplios por el mero hecho de que un menú sea visible. Si falta alguna vista o acción necesaria, solicite la intervención del administrador del tenant en lugar de concluir que existe un problema con la licencia o el rol.

Antes de efectuar cambios, anote los siguientes datos de un único usuario y dispositivo afectados:

sistema operativo, red y hora, incluida la zona horaria;
FQDN del recurso y método de acceso, Agent o Agentless;
texto exacto del estado local de ZTNA y del mensaje del navegador;
si otros recursos ZTNA funcionan en el mismo dispositivo;
si el mismo recurso funciona para el mismo usuario desde otra red;
último cambio en la política, el grupo, el DNS, el proveedor de identidad o la puerta de enlace.

Configuración con valores de ejemplo adaptables

No aplique cambios generalizados a la configuración de producción para realizar una prueba limitada. Sustituya valores de ejemplo como <USER>, <DEVICE>, <RESOURCE-FQDN> y <TEST TIME WITH TIME ZONE> por los datos de un único caso.

En ZTNA > Reports, abra la pestaña Report Generator. Para investigar un acceso denegado, seleccione la plantilla Denied resource access, restrinja el intervalo a las inmediaciones de <TEST TIME WITH TIME ZONE> y, si las columnas disponibles lo permiten, filtre por <USER>, <DEVICE> o <RESOURCE-FQDN>. Los valores de filtro con = y != distinguen entre mayúsculas y minúsculas; ~ utiliza * como comodín y no distingue entre mayúsculas y minúsculas. Si se especifican varios filtros, deben cumplirse todos. A continuación, ejecute el informe con Create.

Si espera que el inicio de sesión se complete correctamente, utilice Authenticated users. Este informe registra a los usuarios autenticados correctamente por las puertas de enlace ZTNA, con independencia del modo de implementación de estas. Las plantillas Gateway bandwidth y Resource bandwidth sirven para atribuir el tráfico, pero no demuestran por sí solas que un intento de acceso concreto se haya completado correctamente.

En My Environment > Alerts, restrinja el intervalo y el dispositivo para que coincidan con la prueba. Una alerta puede agrupar varios eventos recurrentes. Abra el título para ver los eventos asociados y todos sus detalles. Mientras dure el análisis, no cierre la alerta únicamente para eliminarla de la lista.

Validación y resultado esperado

Una prueba solo puede considerarse satisfactoria si se cumplen todos estos criterios:

El agente muestra el estado esperado para la ruta probada.
<RESOURCE-FQDN> se abre con el usuario, el dispositivo y la red previstos.
El informe Authenticated users contiene la autenticación correcta dentro del intervalo seleccionado.
El informe Denied resource access no contiene ninguna denegación nueva correspondiente a la misma prueba.
En My Environment > Alerts no hay ninguna alerta abierta de instalación, actualización, licencia o conectividad que coincida con la hora de la prueba y cuestione el resultado satisfactorio.

Si no aparece el registro esperado en el informe, compruebe el intervalo y la ortografía de los filtros. Después, repita la prueba una vez, cambiando una sola variable. Si aparece una denegación, el motivo determinará qué apartado debe consultar a continuación. Si la segunda prueba tampoco genera un registro útil, no intente obtener un resultado aparentemente satisfactorio mediante más cambios de configuración; conserve los registros y la SDU para remitir el caso a soporte.

Resolución de problemas por síntoma

Estado «Not configured»

En Devices > Computers o Servers, compruebe si ZTNA está instalado en el dispositivo. Una marca de verificación verde confirma que el componente está instalado; un signo más permite instalarlo. La mera presencia de Sophos Endpoint no demuestra que ZTNA se haya asignado al dispositivo.

Existe una excepción importante en Windows. Si se ha configurado Don’t intercept on-premises traffic en Global Settings > Products and Services > ZTNA y el agente de Windows detecta la red interna, deja de interceptar deliberadamente el tráfico en esa red y muestra Not Configured. Al cambiar a otra red, debería volver a mostrar Configured. Según Sophos, esta función es actualmente exclusiva de Windows; no dé por hecho que existe una función equivalente en macOS.

Este comportamiento de Windows requiere Sophos Core Agent 2025.2.1.709 o posterior. En Sophos Fusion (antes Sophos Central), abra el dispositivo y compruebe la versión instalada de Core Agent en la pestaña Summary antes de diagnosticar la detección de la red interna. Las versiones anteriores no admiten esta excepción del modo descrito.

Si la excepción no es aplicable, compruebe en Sophos Fusion la asignación de componentes, el estado de conexión y el estado de las actualizaciones. No empiece por reinstalar mientras no haya confirmado si ZTNA está asignado.

Estado «Zero Trust Network Access: Error»

Este estado indica un problema de conexión. Compruebe lo siguiente en este orden:

¿Existe una política ZTNA y está asignada al recurso?
¿El dispositivo resuelve el FQDN de la puerta de enlace según lo previsto?
¿Sophos Fusion muestra algún error de instalación o de estado del dispositivo?
En Windows, ¿está presente la configuración de Sophos TAP o la ha modificado otro software de red?

Sophos incluye la desactivación de IPv6 entre los pasos de diagnóstico. No es una medida correctiva estándar: realice esta comprobación en un solo dispositivo piloto, documente antes el estado inicial y limítela a una única prueba de reproducción. Vuelva a activar IPv6 al terminar. Si el síntoma cambia de forma inequívoca, conserve las marcas de tiempo y una SDU, e investigue el caso con el soporte de Sophos; no deje IPv6 desactivado de forma permanente ni generalizada.

Un túnel puede cerrarse cuando permanece inactivo. Según la configuración central, esto sucede al cabo de 5, 15 o 30 minutos, o de una hora; el valor predeterminado es 5 minutos. El tráfico nuevo vuelve a establecerlo. Por tanto, un túnel cerrado por inactividad no constituye por sí solo un indicio de fallo.

No aparece la ventana de inicio de sesión

En el caso de un recurso basado en agente, compruebe en este orden:

¿Puede el dispositivo conectarse a la puerta de enlace ZTNA?
¿Está en ejecución el proceso de ZTNA Agent?
¿Existe por error un CNAME público o interno que apunte del FQDN de la aplicación a la puerta de enlace? Este CNAME no debe existir para las aplicaciones basadas en agente.
¿Coinciden el recurso, el método de acceso y el FQDN en Sophos Fusion?
¿Los registros de ZTNA muestran algún error de SNTP, DNS o conexión en el momento de la prueba?

Si aparece la pantalla de inicio de sesión, pero el usuario no vuelve a la aplicación, compruebe el URI de redireccionamiento del proveedor de identidad. En Okta, Groups claim expression también distingue entre mayúsculas y minúsculas. Restablezca las cookies o las credenciales del navegador únicamente después de confirmar que el fallo se produce en la autenticación.

Un recurso basado en agente falla tras la autenticación o deja de funcionar

Si la autenticación se completa correctamente, pero una aplicación basada en agente no se abre, examine los registros de SNTP del endpoint en busca de errores y compruebe en heartbeat.xml que el certificado registrado siga siendo válido en ese momento. Una hora incorrecta en el dispositivo, un fallo de sincronización o un certificado caducado o aún no válido pueden interrumpir la ruta autenticada del agente aunque la política y el DNS parezcan correctos. Conserve los registros, el archivo y la marca de tiempo; no edite el XML ni omita la validación del certificado.

Si el acceso funcionaba y deja de hacerlo, efectúe las mismas comprobaciones en los registros de SNTP y sobre la validez del certificado en heartbeat.xml; además, examine el dispositivo en Sophos Fusion. Un estado Endpoint health en rojo es una pista para el diagnóstico: corrija la causa indicada y vuelva a realizar la prueba, en lugar de relajar la política de ZTNA.

«403 Access Denied / No Access», «Device Health» o «Policy Off»

El informe Denied resource access permite acotar la siguiente comprobación:

403 Access Denied / No Access: El usuario no pertenece de forma efectiva a un grupo asignado al recurso, o el grupo de Microsoft Entra ID no tiene habilitada la seguridad. Compruebe la importación del grupo, si este tiene habilitada la seguridad y los permisos de API del proveedor de identidad. Los cambios en los grupos permitidos pueden tardar hasta una hora en aplicarse.
Device Health: El dispositivo no cumple los requisitos de estado de la política de agente asignada. Corrija el problema de estado concreto en lugar de relajar la política de forma generalizada.
Policy Off: Abra la política afectada en My Products > ZTNA > Policies y compruebe Policy is enforced.
Upstream request error para Agentless: La puerta de enlace no puede acceder a la aplicación interna, la aplicación no está disponible, su FQDN o dirección IP se resuelve de forma incorrecta, o el puerto configurado no es el correcto. Esto no demuestra que el agente del endpoint esté defectuoso.
404 Not Found para Agentless: Compruebe el CNAME de la aplicación que apunta al FQDN de la puerta de enlace. No aplique esta regla de DNS a los recursos basados en agente.

Si el usuario acaba de añadirse a un grupo, no repita la prueba hasta que haya transcurrido el intervalo de replicación documentado. Una ventana privada del navegador permite descartar que una aplicación web esté utilizando un estado obsoleto del navegador, pero no acelera la replicación de grupos.

Fallos de DNS después de la instalación

El adaptador ZTNA TAP puede convertirse en el predeterminado para nslookup. En ese caso, una consulta sobre un destino ajeno a la puerta de enlace ZTNA puede fallar aunque la resolución de nombres funcione correctamente en general. Para realizar la comparación, Sophos indica que se especifique expresamente el servidor DNS previsto:

nslookup <FQDN> <DNS-SERVER>

Compare la respuesta obtenida mediante el servidor DNS corporativo previsto y, a continuación, la solicitud real de la aplicación. No cambie de forma especulativa el orden de los adaptadores, las métricas ni las direcciones de los servidores DNS. Para los recursos basados en agente, asegúrese también de que no exista ningún CNAME que apunte de la aplicación a la puerta de enlace.

Sophos DNS Protection utiliza una ruta de datos independiente. Si también está en uso, consulte Configurar Sophos DNS Protection para endpoints para configurar la política y las exclusiones; no considere que el DNS de ZTNA y Endpoint DNS Protection son la misma función.

ZTNA junto con una VPN o software de acceso remoto

No elimine adaptadores TAP, cambie vinculaciones ni establezca métricas de red fijas como solución general. Primero, pruebe de forma controlada el acceso al mismo recurso con y sin el otro cliente, y anote la hora, la respuesta DNS y el estado de ZTNA.

Para ZTNA 2026.1 con Sophos DNS Protection, Sophos documenta un método de coexistencia concreto: habilite DNS Protection y active Retry with system- or application-configured DNS services when DNS Protection returns NXDOMAIN en la política de endpoint correspondiente. Este método requiere la versión, la licencia y la configuración de DNS Protection pertinentes; no es una solución universal para cualquier producto VPN.

Casos específicos de macOS

En macOS Sequoia, Chrome puede bloquear las aplicaciones situadas detrás de una on-premises gateway tras una instalación nueva en la que solo se haya instalado ZTNA si el navegador no dispone de acceso a la red local. Solo ante este síntoma, compruebe en System Settings > Privacy & Security > Local Network si Google Chrome tiene permiso para detectar dispositivos locales. Sophos Cloud Gateway no se ve afectado por este caso documentado. Esto no supone una recomendación general de conceder el permiso ni garantiza una función de «acceso privado» en macOS.

Un uso elevado de la CPU después de una implementación mediante MDM puede deberse a la existencia de varios perfiles VPN cuyos nombres empiezan por Sophos ZTNA. Busque perfiles duplicados en System Settings > VPN. Conserve exactamente uno; los perfiles instalados mediante MDM no se pueden eliminar de forma local, por lo que debe conservarse el instalado mediante MDM. Reinicie el Mac y vuelva a comprobar el uso de la CPU y el acceso a ZTNA. Esta limpieza solo es aplicable a este caso confirmado de macOS, no a los adaptadores TAP de Windows.

Si se confirma la presencia de credenciales obsoletas, los procedimientos de restablecimiento de Sophos solo deben utilizarse para depuración o demostraciones, no para cerrar sesión de forma habitual en producción. En macOS, la herramienta de diagnóstico de Endpoint ofrece ZTNA > Reset; los scripts para borrar cookies del navegador o la eliminación manual de los datos de sitios web de Safari deben corresponder exactamente a la puerta de enlace y al proveedor de identidad. En Windows, el procedimiento de Sophos exige desactivar la protección contra manipulaciones y ejecutar con privilegios elevados el archivo clearcreds.bat adjunto al artículo de la base de conocimiento. No utilice scripts de limpieza de terceros ni invente rutas de eliminación manual. Los archivos originales y las limitaciones se encuentran en Sophos ZTNA: cerrar sesión en el agente.

Reversión o retirada seguras

Las fuentes de diagnóstico y elaboración de informes utilizadas no documentan un procedimiento general para reparar, desinstalar o revertir el agente. Por tanto, el punto seguro en el que detenerse es el siguiente:

Los filtros de prueba y Report Generator no modifican la ruta de datos; las plantillas o programaciones guardadas únicamente para el diagnóstico pueden eliminarse en Saved templates o Scheduled exports.
Después de una prueba comparativa con IPv6, restablezca de inmediato el estado inicial documentado.
No deje como solución permanente una política que se haya relajado temporalmente, un grupo modificado, una configuración de DNS distinta ni una comprobación de certificados alterada. Si realizó alguno de estos cambios al margen de este procedimiento, restablezca el estado documentado previamente y repita la prueba con el mismo caso.
No elimine el agente ni los adaptadores TAP, y no omita la validación de certificados mientras no se haya identificado el origen del fallo. Si no existe un procedimiento de reversión documentado, deténgase y remita el caso a soporte junto con los indicios conservados.

Después de cada reversión, el estado del agente, la respuesta DNS, la solicitud real al recurso y el informe de ZTNA correspondiente deben volver a coincidir con el estado inicial. Si no es así, no efectúe un segundo cambio.

Operaciones, revisión y ciclo de vida

Los informes y las alertas de ZTNA aportan indicios operativos; no son medidas correctivas. Para las revisiones periódicas, guarde una plantilla de informe filtrada o programe una exportación. Los informes programados pueden generarse a diario, semanalmente o mensualmente en formato PDF, CSV o HTML; Sophos Central admite un máximo de 200 programaciones. Las exportaciones, tanto manuales como automáticas, se eliminan al cabo de 90 días. Si un informe contiene datos personales, es preferible enviar por correo electrónico un enlace en lugar de un archivo adjunto, ya que para abrir el enlace es necesario iniciar sesión en Sophos Central.

Las alertas muestran la gravedad, el estado, los eventos y el dispositivo. Los eventos recurrentes pueden agruparse en una sola alerta; un evento posterior puede cerrar automáticamente una alerta con el estado Resolved. Por ello, durante un incidente debe revisar siempre los eventos incluidos y sus marcas de tiempo. Mark as acknowledged elimina una alerta de la lista, pero no resuelve la causa. Mark as resolved tampoco sustituye la corrección técnica del problema.

Antes de reinstalar, eliminar perfiles o introducir más cambios en la red, recopile lo siguiente:

dispositivo, usuario, sistema operativo y componentes realmente instalados;
recurso, método de acceso, política y grupo asignado;
mensaje exacto, estado local de ZTNA y marca de tiempo, incluida la zona horaria;
resultado con un segundo usuario, dispositivo o red, cambiando una sola variable cada vez;
respuestas DNS para los FQDN del recurso y de la puerta de enlace;
eventos pertinentes de Sophos Central y registros de ZTNA, SNTP e instalación;
un informe de ZTNA filtrado o una exportación correspondiente al intervalo de la prueba;
archivo SDU actualizado.

Tienen prioridad las versiones vigentes de la ayuda y de los componentes. Este procedimiento no permite extraer conclusiones sobre transiciones históricas de ZTNA, la retirada de derechos anteriores, plazos de migración, la retirada del producto ni fechas exactas de fin de vida.

Guías relacionadas

Para conocer la arquitectura y las dependencias, consulte Configurar Sophos ZTNA: descripción general y secuencia. Este artículo se centra en el estado del agente y los indicios de conexión; la implementación de la puerta de enlace y una supuesta reparación general del agente quedan fuera de su alcance.

Sophos Endpoint: diagnóstico con SDU explica cómo recopilar los datos de forma segura. A continuación, abra un caso de soporte de Sophos y adjunte los indicios conservados. No copie credenciales, tokens ni cookies del navegador en tickets o archivos adjuntos sin protección.