Solución de problemas

Problema

La puerta de enlace alojada en ESXi no muestra el botón "Aprobar" en Sophos Central después del despliegue.

Qué hacer

1. Compruebe si la puerta de enlace puede conectarse a estas URL. Si no puede, permítalas. Utilice el puerto 443 a menos que se indique lo contrario.

   • sophos.jfrog.io
   • \*.amazonaws.com
   • production.cloudflare.docker.com
   • \*.docker.io
   • \*.sophos.com
   • login.microsoftonline.com
   • graph.microsoft.com
   • ztna.apu.sophos.com (Puerto 22)
   • sentry.io
   • \*.okta.com (si utiliza Okta como proveedor de identidad)

2. Asegúrese de que ESXi tiene la última versión de firmware.

3. Asegúrese de que la hora está configurada correctamente (GMT 0) en ESXi.

4. Compruebe que la unidad de CD-ROM esté conectada. Si no lo está, apague el equipo virtual y vuelva a conectarlo. Si esto falla, vuelva a crear el equipo virtual de la puerta de enlace.

5. Ejecute un sondeo TCP en la interfaz interna:6443 para asegurarse de que K3S se está ejecutando.

6. Si su puerta de enlace está detrás de Sophos Firewall, inicie sesión en el firewall, vaya a Diagnóstico > Captura de paquetes y active la captura de paquetes, o configure el filtrado web para ver qué solicitudes fallan. Esto también puede hacerse en un firewall de terceros.

Problema

Cuando añade un recurso a ZTNA, no hay grupos de usuarios a los que se pueda permitir el acceso.

Qué hacer

Compruebe que el servicio de directorio (Microsoft Entra ID (Azure AD) o Active Directory) tiene grupos de usuarios y que están sincronizados en Sophos Central.

Problema

Al abrir la página Editar puerta de enlace, no se ven los certificados que ha cargado cuando ha añadido la puerta de enlace.

Qué hacer

Está diseñado así. Ahí no se pueden ver los certificados actuales.

Problema

La creación de recursos ZTNA sin agentes falla. El mensaje que se muestra es: "El nombre no está validado". Esto se debe a que los recursos se añaden con el nombre FQDN de la puerta de enlace en lugar del nombre del dominio.

Qué hacer

Cuando cree recursos, use el nombre del dominio, no el nombre FQDN de la puerta de enlace. Por ejemplo, utilice test123.local en lugar de ztna.test123.local.

Problema

Si el usuario de AD local pertenece solo al grupo principal del servidor AD, la verificación del grupo en el servidor ZTNA falla y el usuario no puede acceder a los recursos.

Qué hacer

Añada el usuario a otros grupos de AD y configure esos grupos para acceder a los recursos en ZTNA.

Problema

El servidor AD principal y la puerta de enlace ZTNA no se conectan.

Qué hacer

Compruebe que su servidor AD principal es accesible desde la puerta de enlace ZTNA y que ha configurado correctamente su nombre de host, IP y puerto.

Problema

La configuración de su servidor AD principal no es correcta.

Qué hacer

1. Compruebe que la configuración del DN de enlace y la Contraseña de enlace es correcta.
2. Compruebe que el puerto LDAP tenga habilitado TLS. Normalmente, el puerto 389 se utiliza para realizar conexiones LDAP no seguras, y el puerto 636 para realizar conexiones LDAP seguras.

Problema

Este error puede deberse a un error tipográfico en el DN base, a alguna opción avanzada mal configurada, a parámetros de prueba incorrectos o a una configuración incorrecta del servidor AD principal.

Qué hacer

1. Compruebe que la configuración de Usuario y Grupo de usuarios es correcta.
2. Compruebe que el usuario con el que ha realizado la prueba existe en el servidor AD.
3. Compruebe si el campo de correo electrónico del usuario en el servidor AD principal contiene una dirección de correo electrónico válida. Si la dirección de correo electrónico introducida para un usuario está en blanco o no es válida, falla la conexión de prueba.
4. Si ha introducido una dirección de correo electrónico para su usuario en la configuración avanzada, pruebe la conexión con la dirección de correo electrónico en lugar de con el nombre de usuario.
5. Compruebe que su servidor AD principal es accesible desde la puerta de enlace ZTNA y que ha configurado correctamente su nombre de host, IP y puerto.
6. Asegúrese de que sus usuarios son miembros de otro grupo de usuarios además del grupo de usuarios principal en el servidor AD principal.

Problema

La comprobación del estado del servidor AD principal falla cuando los usuarios intentan acceder a una app.

Qué hacer

1. Compruebe si el usuario existe en el servidor AD.
2. Si utilizó las opciones predeterminadas de configuración avanzada cuando configuró AD local como su IDP, inicie sesión con su nombre de usuario sin añadir el nombre de dominio.

Qué hacer

Compruebe que su servidor AD principal es accesible desde la puerta de enlace ZTNA y que ha configurado correctamente su nombre de host, IP y puerto.

Qué hacer

Compruebe que la configuración de Usuario y Grupo de usuarios es correcta.

Qué hacer

Compruebe si los valores de correo, nombre e ID que definió en la configuración avanzada también están definidos en el servidor AD.

Problema

La puerta de enlace ZTNA no puede conectarse con el servidor SMTP.

Qué hacer

Si no recibe un código de confirmación para MFA, compruebe la configuración del servidor SMTP.

Problema

Al abrir Sophos Endpoint en un dispositivo administrado por Sophos Central, la página Estado muestra "Zero Trust Network Access: No configurado".

Qué hacer

Vaya a Dispositivos > Ordenadores (o Servidores). Compruebe si el agente ZTNA está instalado en el dispositivo. Si está instalado, verá una marca de verificación verde. Si no lo está, verá un signo más. Haga clic para instalar ZTNA.

Problema

Al abrir Sophos Endpoint en un dispositivo administrado por Sophos Central, la página Estado muestra "Zero Trust Network Access: Error". Esto indica que hay un problema de conexión.

Qué hacer

1. Compruebe que se haya configurado una política ZTNA en Sophos Central.

2. Compruebe que el FQDN de la puerta de enlace se puede resolver.

3. Compruebe si ha fallado la configuración del adaptador de Sophos TAP.

4. Desactive la interfaz de red IPv6 en el agente. A continuación se establecerá el túnel.

Problema

Los usuarios de un grupo de usuarios de Microsoft Entra ID (Azure AD) que anteriormente tenían acceso a una aplicación ya no pueden acceder a ella.

Causa

Si cambia el nombre de un grupo de usuarios de Microsoft Entra ID (Azure AD) al que se ha dado acceso a una aplicación, la lista Grupos de usuarios asignados de ZTNA no se actualiza para reflejar el cambio. Los usuarios no podrán acceder a la aplicación.

Qué hacer

1. Vaya a Zero Trust Network Access > Recursos y acceso.

   

2. En la página Recursos y acceso, busque la aplicación y haga clic en ella para ver los detalles.

   

3. En el cuadro de diálogo Editar recurso, haga lo siguiente:

   1. Vaya a la sección Asignar grupos de usuarios.
   2. En Grupos de usuarios disponibles, busque el grupo de usuarios cuyo nombre se ha cambiado y seleccione la casilla de verificación junto a él.
   3. Mueva el grupo a Grupos de usuarios asignados y seleccione la casilla de verificación junto a él.
   4. Haga clic en Guardar.

   

Problema

Ha añadido un usuario a un grupo de usuarios permitidos para una aplicación, pero el usuario ve un error 403 Acceso denegado.

Qué hacer

Si el usuario se ha añadido recientemente, pídale que lo vuelva a intentar más tarde. Los cambios en los grupos de usuarios pueden tardar hasta una hora en surtir efecto.

Si se trata de una aplicación web, también puede pedirle al usuario que entre en modo Incógnito o Privado en su navegador y que lo intente de nuevo.

Problema

Ha eliminado un usuario de un grupo de usuarios permitidos para una aplicación, pero todavía puede acceder a ella.

Qué hacer

Vuelva a comprobarlo más tarde. Los cambios en los grupos de usuarios permitidos pueden tardar hasta una hora en surtir efecto.

Problema

Cuando el usuario intenta acceder a una aplicación cuyo acceso se ha configurado sin agente, aparece un error 404 No encontrado.

Qué hacer

En la configuración de la administración de DNS, haga lo siguiente:

1. Compruebe que tiene un registro CNAME para la aplicación que apunta al FQDN de la puerta de enlace.

2. Asegúrese de no tener un registro CNAME para ninguna aplicación a la que se acceda a través de un agente ZTNA.

Problema

El usuario ve un error 403 Acceso denegado cuando intenta acceder a una aplicación sin agente.

Qué hacer

1. Compruebe que ha habilitado todos los permisos de API necesarios para su proveedor de identidad.

   Para Azure, necesita estos permisos de API de Microsoft Graph:

   • Directory.Read.All (permiso delegado)
   • Directory.Read.All (permiso de la aplicación)
   • Group.Read.All (permiso delegado)
   • openID (permiso delegado)
   • profile (permiso delegado)
   • User.Read (permiso delegado)
   • User.Read.All (permiso delegado)

   Actualmente también necesita un permiso de API de Microsoft Entra ID (Azure AD): Directory.ReadWrite.All (permiso de la aplicación). Consulte Registrar la aplicación ZTNA.

   Para Okta:

   • okta.groups.read
   • okta.idps.read (solo lo necesita si utiliza Sincronización de AD)

2. Compruebe que la política ZTNA permite el acceso a la aplicación.

3. Compruebe que el usuario se encuentra en un grupo de usuarios asignado para la aplicación.

4. Compruebe que tiene conectividad de red con el proveedor de identidad:

   Para Azure:

   • login.microsoftonline.com
   • graph.microsoft.com

   Para Okta:

   • *.okta.com

Problema

El usuario ve un error de solicitud de subida cuando intenta acceder a una aplicación sin agente.

Qué hacer

1. Compruebe que la aplicación es accesible desde la red en la que se encuentra la puerta de enlace ZTNA.

2. Compruebe que la aplicación sigue ejecutándose.

3. Si se muestra el FQDN interno o la dirección IP interna, asegúrese de que se resuelve en la aplicación.

4. Si utiliza un servidor DNS privado, compruebe que se está ejecutando y se resuelve en el FQDN externo de la aplicación.

5. Compruebe que los números de puerto especificados para la aplicación son correctos.

Problema

El usuario está autenticado pero no puede acceder a una aplicación.

Qué hacer

1. Compruebe si hay errores en los registros SNTP.

2. Compruebe que los certificados son válidos en heartbeat.xml.

Problema

El usuario podía acceder anteriormente a una aplicación pero ya no puede hacerlo.

Qué hacer

1. Compruebe si hay errores en los registros SNTP.

2. Compruebe que los certificados son válidos en heartbeat.xml.

3. Compruebe si ZTNA tiene un estado de seguridad de color rojo en la interfaz de usuario de Sophos Endpoint.

Problema

El IDP debería pedir al usuario que inicie sesión la primera vez que intente acceder a las aplicaciones. Si no, el usuario no podrá acceder a las aplicaciones.

Qué hacer

Compruebe que el dispositivo del usuario puede ponerse en contacto con la puerta de enlace ZTNA.

Problema

El usuario debería ver una ventana emergente que le pide que inicie sesión cuando intenta acceder a una aplicación que necesita el agente ZTNA. Si no aparece, no puede acceder a la aplicación.

Qué hacer

1. Compruebe si hay errores en los registros SNTP.

2. Compruebe la configuración de DNS. El servidor DNS no debe tener un registro CNAME para la aplicación.

3. Compruebe que el proceso del agente ZTNA se está ejecutando.

Problema

El usuario puede acceder a una aplicación pero los enlaces a otras aplicaciones no funcionan.

Qué hacer

Añada las otras aplicaciones a ZTNA como se describe en Añadir recursos. Esto permite a ZTNA dar acceso al usuario cuando hace clic en los enlaces.

Problema

El usuario ve la pantalla de inicio de sesión y se autentica, pero no es redirigido a la aplicación a la que intentó acceder.

Qué hacer

1. Compruebe que ha especificado el URI de redirección correcto en la configuración del proveedor de identidad (IdP).

   • Si el proveedor de identidad es Microsoft Entra ID (Azure AD), usted especificó el URI de redirección al registrar la aplicación ZTNA. Consulte Registrar la aplicación ZTNA.
   • Si el proveedor de identidad es Okta, especificó el Sign-in redirect URI al crear una integración de aplicaciones en Okta. Consulte las instrucciones de Okta en Configurar un proveedor de identidad.

2. Si el proveedor de identidad es Okta, compruebe que haya introducido la "Groups claim expression" respetando mayúsculas y minúsculas. Esta expresión distingue entre mayúsculas y minúsculas.

Problema

El usuario ve un error 403 Acceso denegado cuando intenta acceder a un recurso interno, por ejemplo, un servidor web interno.

Qué hacer

1. Asegúrese de que el usuario forme parte de un grupo de usuarios asignado al recurso.
2. Asegúrese de que la configuración del grupo sea correcta en la configuración del servicio de directorio. Por ejemplo, en Microsoft Entra ID (Azure AD), asegúrese de que los grupos de usuarios importados tengan habilitada la seguridad.
3. Asegúrese de activar la política ZTNA en Sophos Central.

Problema

El usuario no puede ver ninguna aplicación en el portal de usuario de ZTNA.

Qué hacer

1. Asegúrese de que los grupos de usuarios importados tengan habilitada la seguridad.

2. Vaya a Recursos y acceso y haga clic en una aplicación para editar su configuración.

3. Compruebe que el usuario está en los grupos de usuarios asignados para las aplicaciones que necesita. Los usuarios solo pueden ver las aplicaciones a las que están autorizados a acceder.

4. Compruebe que el administrador haya seleccionado Mostrar el recurso en el portal del usuario cuando añadió las aplicaciones.

Problema

El usuario intenta acceder al portal de usuario de ZTNA y se muestra la pantalla de inicio de sesión del proveedor de identidad. Después de iniciar sesión, no se le devuelve al portal de usuario.

Qué hacer

Compruebe que ha especificado el URI de redirección correcto en la configuración del proveedor de identidad (IdP).

Si el proveedor de identidad es Microsoft Entra ID (Azure AD), usted especificó el URI de redirección al registrar la aplicación ZTNA. Consulte Configurar servicio de directorio.

Si el proveedor de identidad es Okta, especificó el Sign-in redirect URI al crear una integración de aplicaciones en Okta. Consulte las instrucciones de Okta en Configurar un proveedor de identidad.

Problema

Después de instalar el agente ZTNA, si se utiliza nslookup para hacer una búsqueda de DNS, a veces falla.

Qué hacer

Especifique el adaptador de red que se debe usar la búsqueda.

La instalación del agente ZTNA cambia el adaptador TAP predeterminado. Si utiliza nslookup para realizar una búsqueda de DNS, ahora utiliza el adaptador TAP de ZTNA de forma predeterminada. Las búsquedas de aplicaciones que no están detrás de la puerta de enlace ZTNA fallarán.

Para evitar este problema, añada el adaptador correcto al comando nslookup. Por ejemplo:

nslookup <FQDN-to-be-resolved><DNS-Server>

Qué hacer

Compruebe que el archivo ISO descargado de Sophos Central está adjunto.

Qué hacer

Verifique la configuración de la interfaz de red. Si necesita editar la configuración de red de la puerta de enlace, cree una nueva instancia de la puerta de enlace en Sophos Central y descargue un nuevo archivo ISO.

Qué hacer

Verifique la configuración de la interfaz de red. Si necesita editar la configuración de red de la puerta de enlace, cree una nueva instancia de la puerta de enlace en Sophos Central y descargue un nuevo archivo ISO.

Qué hacer

Compruebe la configuración del servidor DNS y asegúrese de que ntp.ubuntu.com se pueda resolver.

Qué hacer

Compruebe la configuración del servidor DNS y asegúrese de que sophos.jfrog.io se pueda resolver.

Qué hacer

Verifique la configuración de la interfaz de red. Si no se puede acceder a ntp.ubuntu.com, los servicios ZTNA no se iniciarán.

Qué hacer

Asegúrese de que se permiten todas las URL mencionadas en los requisitos de ZTNA: Sitios web permitidos.

Qué hacer

Una vez iniciada la puerta de enlace, el servicio puede tardar hasta 10 minutos en iniciarse. Siga los pasos que se indican a continuación si el servicio no se inicia transcurridos 10 minutos.

Asegúrese de que la hora de la puerta de enlace está sincronizada con la hora de Kubernetes. Además, asegúrese de que la zona horaria es UTC.

Compruebe que la puerta de enlace puede conectarse a Internet.

Si configura su clúster de puerta de enlace en modo DHCP, asegúrese de que las direcciones IP de sus puertas de enlace no hayan cambiado.

Si la plataforma de puerta de enlace es VMware ESXi, compruebe que el CD-ROM está conectado a la instancia de VM cuando la inicie.

Cerciórese de que al menos la mitad de los nodos del clúster de puerta de enlace están activos.

Si el servicio sigue sin iniciarse, póngase en contacto con el servicio de soporte de Sophos.

Qué hacer

Póngase en contacto con el soporte de Sophos para obtener más ayuda.

Qué hacer

Póngase en contacto con el soporte de Sophos para obtener más ayuda.

Qué hacer

Compruebe la conectividad con Sophos Central.

Qué hacer

Compruebe que la puerta de enlace se ha registrado correctamente y verifique la conectividad con Sophos Central.

Qué hacer

Apruebe la puerta de enlace en Sophos Central.

Qué hacer

Compruebe la ISO asignada al iniciar la puerta de enlace. Asegúrese de que se utiliza la ISO más reciente y vuelva a desplegar la puerta de enlace.

Qué hacer

Compruebe que la configuración del firewall está actualizada para asegurarse de que se resuelve la URL dinámica mostrada.

Qué hacer

Compruebe la conectividad con Sophos Central.

Qué hacer

Verifique la configuración en la plataforma de la puerta de enlace. Un desajuste horario provoca problemas de conectividad.

Qué hacer

Verifique la configuración en la plataforma de la puerta de enlace. Un desajuste horario provoca problemas de conectividad.