Planificar, desplegar y operar un Sophos ZTNA Gateway

Un Sophos ZTNA Gateway conecta a los usuarios autorizados con aplicaciones internas. Hay tres opciones de despliegue compatibles: una VM de gateway local en VMware ESXi o Microsoft Hyper-V, una VM de Sophos Cloud Gateway en uno de estos hipervisores o un Sophos Cloud Gateway en una Sophos Firewall administrada de forma centralizada. Esta guía acompaña desde la elección hasta la aceptación y la retirada segura. Para decidir previamente entre ZTNA y el acceso remoto clásico, consulte Sophos Connect o SSL VPN: ¿qué solución de acceso remoto conviene? y Zero Trust explicado de forma sencilla: ZTNA en lugar de la VPN clásica.

La interfaz actual se llama Sophos Fusion; los textos de ayuda antiguos y algunas imágenes aún utilizan Sophos Central. Si una imagen difiere, prevalecen las rutas y los nombres de campo actuales indicados aquí.

Objetivo y respuesta directa

Elija el tipo de gateway según la ruta de los datos y la responsabilidad operativa, no según el número de clics:

Una VM se puede desplegar con una interfaz o dos interfaces. Con una interfaz, el tráfico entrante y saliente utiliza la interfaz externa, lo que minimiza los cambios de infraestructura. Con dos interfaces, se separan la interfaz externa y la interna; se necesitan dos adaptadores de red y, en su caso, rutas estáticas. Según el fabricante, esta variante ofrece la mejor seguridad y el mayor rendimiento. La guía independiente Publicar un servidor mediante DNAT en Sophos Firewall explica la función subyacente de la firewall; los puertos específicos de ZTNA se indican más adelante.

Requisitos previos, licencia y roles

Licencia y roles administrativos

• Las funciones ZTNA requieren la licencia correspondiente. Las notas de versión del gateway identifican expresamente las funciones que dependen de una licencia.
• Sophos Fusion Firewall Management requiere una suscripción de pago adicional a la licencia base de la firewall.
• Para registrar una firewall en Sophos Fusion se necesita un Central Super Admin. Como alternativa, ese administrador puede generar un OTP a partir del número de serie de la firewall y entregárselo al administrador de la firewall; el OTP es válido durante 14 días.
• Los grupos de usuarios asignados deben estar sincronizados en Sophos Fusion. Se admiten Microsoft Entra ID o Active Directory como servicio de directorio. Microsoft Entra ID, Okta y Active Directory local están documentados como proveedores de identidad.
• Los grupos de Entra ID deben tener la seguridad habilitada. Los grupos creados directamente en Entra ID la tienen habilitada automáticamente; los grupos importados de AD o creados mediante el portal de Microsoft 365 pueden diferir.

La documentación del gateway consultada no especifica un rol de administrador ZTNA más granular. Si la cuenta no muestra los menús o las acciones descritas, no amplíe los permisos por ensayo y error: solicite a un administrador autorizado de Sophos Fusion que compruebe la asignación de roles específica del tenant.

Certificado

El gateway requiere un certificado wildcard. Se admiten certificados de Let’s Encrypt o de una entidad de certificación de confianza:

• RSA de al menos 2048 bits;
• ECDSA, pero no con P-384 ni P-521.

El despliegue como VM admite un único certificado wildcard. Tenga preparados el certificado y la clave privada. Puede cargarlos en Zertifikat, dentro de los detalles del gateway; como alternativa, Sophos Fusion puede generar allí un certificado de Let’s Encrypt.

La obtención práctica se explica en Crear un certificado wildcard de Let’s Encrypt. Para los certificados administrados directamente en Sophos Firewall, Administrar certificados de Let’s Encrypt en Sophos Firewall describe el procedimiento operativo independiente.

Host, hora y capacidad

Se recomiendan unidades SSD para obtener un rendimiento de E/S de disco más uniforme. La fecha y la hora del host deben ser correctas y la zona horaria debe ser UTC. El gateway toma la hora del host y no puede funcionar correctamente si esta es incorrecta.

Red, IPv4 y destinos permitidos

• No utilice 10.42.0.0/16, 10.43.0.0/16 ni 10.108.0.0/16 para el gateway. Estas redes están reservadas para servicios internos.
• Los gateways no admiten IPv6. En este escenario, no asigne direcciones IPv6 mediante DHCP al gateway ni a los endpoints. En los endpoints ya configurados, desactive IPv6 manualmente.
• Utilice una dirección IPv4 estática o una reserva DHCP. El gateway no puede procesar un cambio posterior de su dirección IP.
• Si los usuarios acceden a recursos ZTNA desde la misma red que el gateway, una regla SNAT de tipo MASQ evita el enrutamiento asimétrico.
• Si hay varios nodos de gateway, todos deben estar en la misma subred y tener una latencia muy baja entre sí.

Un gateway local situado detrás de una firewall debe poder acceder a los siguientes destinos, normalmente por TCP 443:

• sophos.jfrog.io
• jfrog-prod-use1-shared-virginia-main.s3.amazonaws.com
• *.amazonaws.com
• production.cloudflare.docker.com
• *.docker.io
• *.sophos.com
• login.microsoftonline.com
• graph.microsoft.com
• sentry.io
• *.okta.com, si Okta es el proveedor de identidad
• wsserver-<Gateway-FQDN>
• el FQDN del gateway configurado en los ajustes del gateway

Además, ztna.apu.sophos.com necesita TCP 22. Si una firewall situada delante descifra TLS, excluya wsserver-<Gateway-FQDN> de ese descifrado.

ZTNA controla el acceso a aplicaciones web y aplicaciones locales. Las aplicaciones locales necesitan el agente ZTNA. No se admiten aplicaciones con asignación dinámica de puertos o con un número muy elevado de puertos, como algunos productos VoIP antiguos. El agente está documentado para Windows 10 1803 o posterior y macOS Big Sur 11 o posterior.

Configuración con valores de ejemplo adaptables

Utilice sus propios valores. Los siguientes nombres solo ilustran la correspondencia:

Rutas actuales de la interfaz

Los textos de ayuda actuales en alemán indican estas rutas y acciones:

• Meine Produkte > ZTNA > Gateways y, después, Gateway hinzufügen
• Meine Produkte > ZTNA > Einstellungen > Domänen
• Geräte > Installer

1. Desplegar la imagen de la VM

Para ESXi:

1. Abra Geräte > Installer, busque Zero Trust Network Access y descargue la imagen del gateway.
2. Acepte el contrato de licencia y, si corresponde, los formularios de cumplimiento de exportaciones.
3. Despliegue el archivo OVA en vSphere mediante OVF-Vorlage bereitstellen.
4. Desactive el encendido automático. La VM no debe arrancar sin la ISO que se generará más adelante.

Para Hyper-V:

1. Abra Geräte > Installer > Zero Trust Network Access y descargue la Gateway-VM-Image für Hyper-V.
2. Extraiga el archivo VHDX. Utilice cada VHDX para una sola VM; cree copias para las demás VM.
3. Cree una VM de generación 1 con al menos 4096 MB de memoria de inicio y dos procesadores virtuales. Conecte el VHDX existente.
4. Añada un segundo adaptador de red para un despliegue con dos interfaces. Si utiliza VLAN, asigne los ID de VLAN correspondientes.

2A. Crear un gateway local

1. Abra Meine Produkte > ZTNA > Gateways > Gateway hinzufügen.
2. En Gateway-Modus, seleccione Lokal.
3. Introduzca Gateway-Name, Gateway-FQDN y Domäne für Ressourcen.
4. En Plattformtyp, seleccione VMware ESXi o Hyper-V según el host.
5. En Bereitstellungsmodus, seleccione Einarmig o Zweiarmig.
6. Configure las interfaces. Si utiliza DHCP, la reserva es obligatoria. Si utiliza Statische IP, indique la dirección IP, la subred y el servidor DNS. Si un despliegue con dos interfaces debe llegar a aplicaciones de varias redes internas, configure Statische Routen.
7. Cargue el certificado wildcard.
8. Haga clic en Speichern und Datei erstellen. El estado inicial es Warten auf Bereitstellung; se genera la ISO de arranque individual.
9. Abra únicamente TCP 80 y 443 de entrada en la firewall, cree reglas DNAT para ambos puertos hacia la IP externa del gateway o la VIP del clúster y bloquee los demás puertos entrantes. No utilice un proxy inverso.

2B. Crear un Sophos Cloud Gateway como VM

1. Valide primero el dominio en Meine Produkte > ZTNA > Einstellungen > Domänen > Domäne hinzufügen.
2. Sophos Fusion genera un CNAME, por ejemplo 5ccdee2b04764c75ac252a0f91f161b7.cert.prod.ztna.access.sophos.com. Publique en su proveedor DNS el valor exacto generado para su tenant.
3. Espere a la propagación DNS y, en Einstellungen > Domänen, haga clic en Validieren. No continúe hasta que el estado sea validiert.
4. Haga clic en Gateway hinzufügen, en Gateway-Modus seleccione Sophos Cloud e introduzca Gateway-Name y Gateway-FQDN. Este FQDN debe coincidir con el indicado al registrar la aplicación ZTNA.
5. Seleccione la Domäne validada, el Plattformtyp adecuado, el Identitätsanbieter y, en Points of Presence, la región más cercana al centro de datos.
6. Seleccione Einarmig o Zweiarmig, configure interfaces con reserva o IP estática y, si es necesario, rutas estáticas. Cargue el certificado wildcard.
7. Haga clic en Speichern und Datei erstellen. Copie el dominio alias generado en el cuadro de diálogo Gateway hinzugefügt y publíquelo como CNAME del FQDN del gateway en el DNS público.
8. Abra únicamente TCP 443 de salida en la interfaz externa. En este modelo no se configura una publicación DNAT entrante de la VM.

Desde ZTNA 2.1 se configura de forma predeterminada un punto de presencia secundario cercano al PoP principal. Se puede desactivar en Einstellungen. Aun así, elija un PoP principal próximo al centro de datos.

2C. Crear un Sophos Cloud Gateway en Sophos Firewall

1. Compruebe que la versión sea SFOS 19.5 MR3 o posterior y que Sophos Fusion administre la firewall de forma centralizada. Si la firewall aún no está registrada, utilice Register en la firewall con credenciales de Super Admin o con el OTP generado por este.
2. Valide el dominio como en 2B.
3. Abra Meine Produkte > ZTNA > Gateways > Gateway hinzufügen y seleccione Gateway-Modus: Sophos Cloud.
4. Introduzca Gateway-Name y Gateway-FQDN, seleccione la Domäne validada y establezca Plattformtyp en Firewall.
5. En Firewall, seleccione el dispositivo SFOS. La lista solo muestra firewalls administradas de forma centralizada con versión 19.5 MR3 o posterior. Puede seleccionarse la firewall activa de un par HA; así, el tráfico y los servicios pueden transferirse durante una conmutación por error.
6. Seleccione Identitätsanbieter y Points of Presence, cargue el certificado y haga clic en Speichern. El gateway debería estar activo al cabo de unos cinco minutos.
7. Añada al proveedor de identidad la URL de redirección específica https://<externer-Gateway-FQDN>/ztna-oauth2/callback.

Limitaciones de esta variante:

• En un despliegue HA activo-activo, no se puede acceder al portal de administración web de la firewall mediante ZTNA.
• El portal de usuarios y el portal VPN de la firewall no son compatibles a través del gateway ZTNA.
• En los demás casos, el portal de administración web puede configurarse como recurso de tipo Webadmin-Portal. Para el acceso sin agente, se publica el dominio alias generado como CNAME público; para el acceso con agente, este intercepta el FQDN externo.

3. Crear opcionalmente un clúster de VM

Cree el clúster antes de descargar las ISO de arranque:

1. Abra el gateway nuevo y haga clic en Instanzen hinzufügen/bearbeiten > Eine weitere Instanz hinzufügen. La agrupación en clúster se activa automáticamente.
2. Introduzca una IP virtual de clúster que no esté en uso y pertenezca al mismo rango IP que las instancias. En un despliegue con dos interfaces y balanceador de carga externo, deje vacía la VIP externa del clúster.
3. Introduzca el nombre de la VM y la IP de la interfaz; en despliegues con dos interfaces, indique las IP interna y externa.
4. Repita el proceso hasta disponer de al menos tres instancias. Se admiten de tres a nueve instancias, siempre en número impar.
5. Configure el DNAT de un gateway local hacia la VIP externa del clúster. Al menos la mitad de los nodos debe permanecer activa.

4. Conectar la ISO de arranque y aprobar el registro

Cada ISO se asigna de forma exclusiva a un gateway o una instancia y no debe reutilizarse.

• ESXi: Monte la ISO en la unidad de CD/DVD y seleccione Verbinden y Beim Einschalten verbinden. Puede eliminar un dispositivo serie existente.
• Hyper-V: En la configuración de la VM, seleccione IDE Controller 1 > Image-Datei en la unidad de DVD y monte la ISO.
• Solo entonces arranque la VM. La ISO debe permanecer conectada incluso después de un arranque correcto.
• Abra los detalles del gateway. El estado cambia de Warten auf Bereitstellung a Warte auf Genehmigung o Warten auf Gateway-Genehmigung.
• Haga clic en Genehmigen. En un clúster, apruebe solo la primera instancia; las demás se administrarán a continuación.
• La aprobación puede tardar hasta diez minutos. Compruebe el estado final correspondiente a la plataforma: local en ESXi Verbunden, local en Hyper-V Aktiv, Sophos Cloud en ESXi Aktiv y Verbunden, y Sophos Cloud en Hyper-V Aktiv.

Comprobar correctamente el DNS y la ruta de los datos

Los servidores DNS públicos y privados cumplen funciones diferentes:

Gateway local

• Con agente: El agente intercepta la solicitud para la aplicación privada y le asigna una dirección del rango 100.64.x.x. Para establecer el túnel, resuelve el FQDN del gateway mediante un registro A público hacia la IP del gateway. Después, el gateway resuelve el FQDN de la aplicación mediante el servidor DNS privado.
• Sin agente: Un CNAME público de la aplicación apunta al FQDN del gateway; su registro A público apunta a la IP del gateway. El gateway consulta al servidor DNS privado para obtener el destino interno de la aplicación.

Sophos Cloud Gateway

• Con agente: El DNS público resuelve la aplicación privada hacia el dominio alias asignado. Este conduce al gateway a través del PoP de Sophos Cloud. A continuación, el gateway resuelve el destino interno mediante el DNS privado.
• Sin agente: El CNAME público del recurso apunta al dominio alias generado por Sophos. Por cada nuevo recurso sin agente, el gateway inicia un túnel nuevo hacia el PoP por TCP 443. El PoP utiliza el alias para asociar la solicitud con el gateway.

La conexión del agente con el gateway o el PoP utiliza TLS mutuo. Están documentados TLS 1.2 y versiones posteriores, así como protocolos de cifrado con longitudes de clave de hasta 256 bits.

El agente ZTNA modifica el adaptador TAP predeterminado. Por eso, nslookup puede parecer que falla con nombres ajenos a ZTNA. Indique expresamente el servidor DNS responsable:

nslookup <FQDN> <DNS-Server>

Validación y resultado esperado

No dé por concluida la validación solo porque el estado del gateway aparezca en verde. Utilice un usuario de prueba con permisos limitados y exactamente un recurso de prueba.

1. Administración: En Meine Produkte > ZTNA > Gateways, el gateway figura como Aktiv o Verbunden. En Gateway-Details, compruebe la versión del software y, si hay un clúster, todos los nodos.
2. DNS público: Para un gateway local, el registro A del gateway y, en su caso, el CNAME del recurso devuelven la IP pública prevista. Para un Cloud Gateway, los CNAME de validación del dominio, del gateway y de los recursos coinciden exactamente con los valores generados por Sophos.
3. DNS privado: El gateway puede resolver el FQDN del recurso interno a la IP interna del servidor.
4. Certificado: Coinciden el FQDN, el alcance del wildcard, la cadena, el período de validez y la clave privada. Ni el navegador ni el agente muestran advertencias de confianza.
5. Red: En un gateway local, TCP 80 y 443 llegan a las reglas DNAT previstas y los demás puertos entrantes están bloqueados. En un Cloud Gateway, el túnel saliente por TCP 443 funciona sin publicación entrante.
6. Acceso: El usuario piloto autorizado solo puede acceder a la aplicación asignada. Un usuario de prueba no autorizado no obtiene acceso.
7. Aplicación: Compruebe no solo el inicio de sesión, sino también una transacción real y limitada. La ruta de retorno funciona y la aplicación ve el origen de conexión esperado.
8. Estabilidad: Pruebe el acceso desde fuera y, si está previsto, desde la misma red que el gateway. La segunda prueba confirma, en particular, MASQ y la ruta de retorno.
9. Clúster: No detenga ningún nodo fuera de una prueba de mantenimiento y conmutación por error aprobada. Durante una prueba planificada, al menos la mitad de las instancias permanece activa y las solicitudes se encaminan a través de los nodos restantes.

Si no obtiene el resultado esperado, consulte más abajo el apartado correspondiente al síntoma. No cambie DNS, certificado, NAT y política al mismo tiempo.

Para analizar por separado la capa de firewall, consulte Probar una regla de firewall con Log Viewer, Policy Test y Packet Capture y Entender NAT en Sophos Firewall.

Diagnóstico según el síntoma

El gateway permanece en «Warten auf Bereitstellung» o no llega a Sophos Fusion

1. Compruebe que la ISO exclusiva esté conectada a la VM correcta y que Beim Einschalten verbinden esté activado.
2. Compruebe la hora del host y la zona horaria UTC.
3. Compruebe la IP estática o la reserva DHCP, el DNS y los destinos permitidos; ztna.apu.sophos.com necesita TCP 22.
4. Compruebe que exista una excepción al descifrado TLS para wsserver-<Gateway-FQDN>.
5. Ejecute el diagnóstico de la VM en vSphere o Hyper-V Manager, según corresponda.

El estado indica que está esperando aprobación

Abra los detalles del gateway y haga clic en Genehmigen. Espere hasta diez minutos. Si hay un clúster, apruebe solo la primera instancia. Si el estado no cambia, compruebe primero la conectividad y la hora, en lugar de volver a crear las demás instancias.

El gateway deja de funcionar tras un cambio de DHCP o de red

El gateway no procesa cambios en su dirección IP. Restablezca la asignación de dirección original y configure una reserva DHCP o una dirección estática. Después, compruebe DNS, DNAT y, si hay un clúster, los destinos de la VIP. Un cambio de IP planificado no es una simple modificación en funcionamiento y debe tratarse como un nuevo despliegue.

El inicio de sesión funciona, pero el recurso no

1. Resuelva el FQDN del recurso directamente en el servidor DNS privado.
2. Compruebe la ruta y la regla de acceso de la firewall desde el gateway hacia el puerto de destino documentado.
3. En despliegues con dos interfaces, compruebe las rutas estáticas hacia otras redes internas.
4. Si se accede desde la misma red que el gateway, compruebe la regla MASQ y el enrutamiento asimétrico.
5. Compruebe si la aplicación utiliza puertos dinámicos o muchos puertos; esas aplicaciones no son compatibles.

Falla el acceso externo a un gateway local

Compruebe el registro A público, TCP 80 y 443, ambas reglas DNAT y su IP de destino o VIP del clúster. Asegúrese de que no haya un proxy inverso delante. Los demás puertos entrantes deben permanecer bloqueados.

No se puede acceder al Cloud Gateway o a un recurso sin agente

Compruebe, en este orden:

1. que el estado del dominio sea validiert;
2. el CNAME del gateway y el CNAME del recurso frente a los dominios alias generados en Sophos Fusion;
3. la salida por TCP 443 desde el gateway hacia el PoP;
4. la resolución DNS privada desde el gateway hacia la aplicación;
5. la región PoP correcta y, para gateways en firewall, la URL especial de redirección OAuth2.

nslookup devuelve resultados incorrectos tras instalar el agente

El agente establece el adaptador TAP de ZTNA como predeterminado. Repita la consulta indicando expresamente el servidor DNS. Un fallo a través del adaptador TAP no demuestra que el servidor DNS habitual desconozca el nombre.

Errores de certificado

Compruebe el alcance del wildcard, la cadena completa, la clave privada y el algoritmo. No se admiten P-384/P-521 con ECDSA ni RSA de menos de 2048 bits. Compare el FQDN del gateway, el dominio de recursos y los nombres del certificado antes de cargar uno nuevo.

Paquete de diagnóstico para Sophos Support

Para gateways VM en ESXi o Hyper-V:

1. Abra Gateway-Details > Fehlerbehebungsprotokolle.
2. Haga clic en Protokolle generieren. La generación puede tardar unos minutos.
3. Descargue la nueva entrada de la columna Fehlerbehebungsprotokoll. Caduca al cabo de una hora.
4. Si es necesario, habilite temporalmente el acceso de soporte en los detalles del gateway y entregue el token mostrado exclusivamente a Sophos Support.

Esta función de registros no se aplica al gateway integrado en Sophos Firewall.

Retirada segura o baja del servicio

Distinga entre un cambio de configuración, una actualización del gateway VM, un cambio de firmware de la firewall y la eliminación definitiva. No comparten el mismo procedimiento de reversión.

Antes de cualquier cambio

• Registre el modo del gateway, el FQDN, las IP, la VIP del clúster, la plataforma, la versión, el certificado, los registros CNAME/A públicos, DNAT/SNAT, las rutas estáticas, los recursos asignados y el grupo piloto.
• Compruebe qué recursos y usuarios dependen del gateway y acuerde una ventana de mantenimiento.
• En la prueba piloto, cambie solo una capa por paso. Anote los últimos valores de DNS y firewall que funcionaban.

Trasladar recursos a un gateway en firewall

Para la migración documentada desde un gateway existente a uno en firewall:

1. Configure completamente el gateway en firewall.
2. Añada su nueva URL de redirección OAuth2 en el proveedor de identidad.
3. Abra Ressourcen und Zugriff, seleccione el recurso y establezca Gateway en el gateway de la firewall.
4. Para el acceso sin agente, publique el nuevo dominio alias de la firewall como CNAME público.
5. Valide el acceso con un usuario de permisos limitados. No elimine el valor DNS anterior ni el gateway antiguo hasta superar la prueba de la aplicación.

Eliminar un gateway

La opción Gateway löschen está disponible en los detalles del gateway. Sin embargo, las fuentes consultadas no describen cómo restaurar un gateway eliminado ni un procedimiento automático y transaccionalmente seguro para revertir DNS, NAT, recursos y certificados. Por tanto:

1. No utilice la eliminación como primer paso de reversión.
2. Traslade o desactive primero los recursos dependientes durante la ventana de cambios acordada y compruebe que ya no pase tráfico de producción por el gateway.
3. Después, elimine los registros DNS públicos y las reglas de firewall obsoletos según la lista recopilada previamente.
4. Elimine el gateway solo después de recibir la autorización de los responsables de la aplicación y la red.
5. Si las dependencias o el procedimiento de recuperación no están claros, deténgase antes de Gateway löschen y escale el caso a Sophos Support.

Reversión de actualizaciones

Las instrucciones consultadas no describen cómo volver a una versión anterior tras actualizar un gateway VM. Si falla una actualización, no intente restaurar una imagen mediante un procedimiento no documentado; genere registros, mantenga el acceso mediante la instancia sin modificar o el clúster y escale el caso a Sophos Support.

Para un gateway integrado en Sophos Firewall se aplica el procedimiento documentado de reversión del firmware:

1. Compruebe que la suscripción de soporte esté vigente y haga una copia de seguridad de la configuración de la firewall.
2. Antes del cambio, compruebe si la versión de destino admite el número de gateways configurados; los gateways sobrantes deben eliminarse antes de cambiar el firmware.
3. Programe el cambio fuera de las horas punta. La firewall cierra las sesiones y se reinicia.
4. En Backup and firmware > Firmware, puede cargar una versión compatible y arrancarla con Upload and boot, o arrancar una imagen ya inactiva mediante Boot firmware image.
5. El firmware activo y el anterior se encuentran en particiones separadas, cada uno con su configuración respectiva. Por eso, revertir al firmware anterior también devuelve la configuración a su estado anterior.
6. Tras el reinicio, inicie sesión y compruebe el firmware activo en la esquina superior izquierda del Control Center; después, verifique el estado del gateway, el DNS y el acceso piloto.

Operación, revisión y ciclo de vida

Actualizar un gateway VM

En Gateways, una marca de verificación verde junto al número de versión indica que hay una versión disponible para la VM. Haga clic en el número de versión, elija la versión de destino y programe la actualización o seleccione Jetzt. Si es necesario reiniciar, la interfaz muestra una advertencia; planifique el reinicio durante una ventana de mantenimiento. Esta función solo se aplica a gateways ESXi y Hyper-V. Los gateways en firewall se actualizan mediante el firmware SFOS.

Las notas de versión consultadas incluyen ZTNA 2.2 del 13 de enero de 2026 para ESXi y Hyper-V, tanto en despliegues locales como en Sophos Cloud, y califican la actualización de obligatoria por las nuevas capacidades requeridas. Aun así, antes de la ventana de mantenimiento compruebe siempre la versión de destino ofrecida en Sophos Fusion y las notas de versión actuales; no deduzca de esa referencia histórica ni una fecha de fin de vida ni la versión de destino vigente hoy.

El historial de versiones también menciona un tiempo de espera por inactividad configurable para los túneles entre el agente y el gateway y la desactivación de Resource Connection Pooling a partir de 2.1.2. Para 2.2 documenta correcciones de conexiones intermitentes de recursos con agente a través de un gateway local, un estado Updating que permanecía bloqueado tras actualizar imágenes, mensajes de diagnóstico engañosos sobre pods de clúster y una condición de carrera en pods de Kubernetes. Utilice este historial para evaluar cambios y errores, no como sustituto de la vista actual de detalles del gateway.

Revisión periódica

Compruebe al menos con la periodicidad de mantenimiento de su organización:

• el estado del gateway y de los nodos, así como la versión instalada y la ofrecida;
• la vigencia y la cadena completa del certificado;
• los CNAME públicos de validación de dominio, del gateway y de los recursos;
• la resolución DNS privada y las rutas, reglas DNAT, SNAT y de firewall que sigan siendo necesarias;
• la región PoP, el PoP secundario y la latencia real del Cloud Gateway;
• los grupos de usuarios sincronizados con seguridad habilitada y el proveedor de identidad;
• las asignaciones de recursos a gateways y los gateways que ya no se necesiten;
• los procedimientos de diagnóstico y soporte, las ventanas de mantenimiento y las personas responsables.

No publique afirmaciones sobre períodos de transición o migración, retirada del producto o fin de vida (EOL) sin un comunicado actual y legible del producto. Las fuentes disponibles respaldan la operación y el estado de las versiones, pero no esas fechas del ciclo de vida.

Otras guías relacionadas

Esta guía termina deliberadamente en los límites del gateway. La configuración completa del servicio de directorio y del proveedor de identidad, la instalación o eliminación del agente ZTNA, el diagnóstico específico del agente, las reglas de acceso a recursos y los diseños especiales con varios controladores de dominio corresponden a sus respectivas guías existentes. Los fundamentos enlazados anteriormente sobre Zero Trust, acceso remoto, certificados, DNAT y diagnóstico de la firewall complementan el procedimiento del gateway sin duplicar esos procesos independientes.