Planificar y crear Sophos ZTNA Gateway
Una puerta de enlace Sophos ZTNA conecta a los usuarios con aplicaciones internas sin la necesidad del acceso VPN clásico de túnel completo. Sin embargo, el beneficio real sólo surge cuando el modo de puerta de enlace, el DNS, el certificado, las reglas del firewall y la accesibilidad interna se planifican adecuadamente.
Esta guía describe cómo planificar y crear una puerta de enlace ZTNA en Sophos Central. La atención se centra en la parte de la puerta de entrada. Para la decisión básica entre VPN, ZTNA y otras variantes de acceso remoto, también encaja Sophos Connect o SSL VPN: ¿Qué solución de acceso remoto es la adecuada?.
Para la base neutral sobre Zero Trust, ZTNA y la diferencia con VPN, conviene empezar por Zero Trust explicado: ZTNA en lugar de VPN clásico.
Comprender los modos de puerta de enlace
Sophos ZTNA se puede utilizar con un Gateway local o un Sophos Cloud Gateway. Ambas variantes brindan acceso a recursos internos, pero difieren significativamente en la exposición a Internet, DNS, operaciones y resolución de problemas.
- Puerta de enlace local: Gateway VM está ubicado en su propio centro de datos o red de sitio, propia VM, DNS público propio, DNAT en el puerto 443, control más directo.
- Puerta de enlace en la nube de Sophos: Los usuarios se conectan a través de los puntos de presencia de Sophos Cloud. menos exposición directa a Internet, diferentes DNS CNAME, selección de punto de presencia.
- Sophos Firewall como puerta de enlace a la nube: Sophos Firewall asume la función de puerta de enlace para ZTNA Cloud Gateway. no hay máquina virtual de puerta de enlace separada, pero depende de SFOS, operación central y firewall.
El modo no es sólo una casilla de verificación técnica. Determina por dónde ingresa el tráfico, quién opera la ruta de datos, qué entradas DNS son necesarias y si se necesita una regla DNAT en el firewall.
Puerta de enlace local
Con una puerta de enlace local, se implementa una máquina virtual de puerta de enlace en VMware ESXi o Microsoft Hyper-V. Se puede acceder a la puerta de enlace desde Internet y acepta acceso ZTNA. En la práctica, un nombre DNS público apunta al firewall y una regla DNAT reenvía HTTPS a la puerta de enlace.
Ventajas:
- ruta de datos directa a su propia ubicación,
- control total sobre las reglas de puerta de enlace, segmento, DNS y firewall,
- no depende del plano de datos de la nube de Sophos para el punto de entrada real.
Desventajas:
- La VM de puerta de enlace debe ser operada y actualizada,
- El puerto 443 debe ser accesible desde el exterior,
- El certificado, DNS, DNAT y enrutamiento interno deben ser correctos,
- La disponibilidad depende de su ubicación, conexión a Internet e hipervisor.
Al publicar una puerta de enlace local a través de DNAT, la regla debe planificarse con tanto cuidado como otras publicaciones. Los conceptos básicos se pueden encontrar en Publicar servidores con DNAT en Sophos Firewall.
Puerta de enlace en la nube de Sophos
Con Sophos Cloud Gateway, el acceso se gestiona a través de los puntos de presencia de Sophos Cloud. El componente de puerta de enlace interna conecta Sophos Cloud con los recursos internos. Esto elimina la necesidad de que los usuarios accedan directamente a su propia IP de puerta de enlace pública.
Esto reduce la exposición directa a Internet pero mueve partes de la ruta de datos a la nube de Sophos. Por lo tanto, son importantes los siguientes:
- punto de presencia adecuado cerca del centro de datos,
- corregir registros CNAME públicos,
- resolución DNS interna en funcionamiento,
- expectativas claras en cuanto a latencia, disponibilidad y perfiles de tráfico,
- Comprobación de límites de licencia, producto y tráfico para el entorno específico.
Para aplicaciones con un uso intensivo de datos, como almacenamiento de archivos de gran tamaño, archivos CAD o descargas masivas, no debe probar ZTNA Cloud Gateway únicamente basándose en el registro. Lo que importa es cómo se comportan el uso real, la latencia y el volumen de datos en la vida cotidiana.
Sophos Firewall como puerta de enlace a la nube ZTNA
También se puede configurar un Sophos Cloud Gateway en dispositivos firewall de Sophos administrados de forma centralizada. Esto es interesante si ya existe un firewall de Sophos en la ubicación y no se va a utilizar ninguna máquina virtual de puerta de enlace independiente.
Sin embargo, esta variante no debe activarse como función secundaria. Se debe comprobar lo siguiente:
- Versión SFOS compatible y estado de administración central.
- Licenciamiento ZTNA y mapeo de usuarios.
- Accesibilidad de los recursos internos desde la perspectiva del firewall.
- Impacto en las ventanas de mantenimiento, actualizaciones de firmware y funcionamiento del firewall.
- Registro y responsabilidad por averías. Si el firewall es el nodo central de acceso remoto de todos modos, esta variante puede ser elegante. Por otro lado, si desea que ZTNA se ejecute independientemente del mantenimiento del firewall, una VM de puerta de enlace dedicada u otro diseño a veces es más limpio.
Requisitos
Antes del despliegue conviene aclarar estos puntos:
- Sophos Central Inquilino con licencia ZTNA.
- Usuarios y grupos sincronizados.
- Proveedor de identidad, por ejemplo Microsoft Entra ID.
- Decida entre la puerta de enlace local o la puerta de enlace en la nube de Sophos.
- Hipervisor o Sophos Firewall compatible, según el modo.
- DNS público para puerta de enlace y recursos.
- Certificado comodín o concepto de certificado adecuado.
- Resolución DNS interna de las aplicaciones de destino.
- Segmento de red para la puerta de enlace.
- Reglas de firewall desde la puerta de enlace a las aplicaciones.
- Propietario de operaciones, logs, certificados y cambios posteriores.
Para los certificados, un certificado comodín suele ser la opción más práctica. La obtención de un certificado comodín se describe en Let’s Encrypt cree un certificado comodín. Si los certificados se gestionan directamente en Sophos Firewall, también encaja Administrar certificados Let’s Encrypt en Sophos Firewall.
Plataforma y tamaño
Para las máquinas virtuales de puerta de enlace, VMware ESXi y Microsoft Hyper-V son las plataformas típicas. Dependiendo del modo y del estado de Sophos, otras opciones pueden ser relevantes. Es fundamental que la plataforma cuente con soporte oficial, esté actualizada y monitoreada adecuadamente.
Para configuraciones pequeñas y medianas, una máquina virtual de puerta de enlace con 2 vCPU y 4 GB de RAM es un punto de partida realista. Pero esto no reemplaza la planificación operativa. Los factores decisivos son la cantidad de usuarios, recursos, perfil de tráfico, TLS, latencia y disponibilidad.
Para entornos productivos también debes planificar:
- ¿Existe un grupo de puerta de enlace?
- ¿La puerta de enlace se ejecuta en su propia VLAN?
- ¿Cómo se realiza una copia de seguridad o se restaura la máquina virtual?
- ¿Existe supervisión del hipervisor?
- ¿Quién actualiza la puerta de enlace?
- ¿Existe una ventana de mantenimiento para reinicios?
Red y subred
La puerta de enlace ZTNA debe funcionar en su propia subred o VLAN. No debe colocarse simplemente en una red de cliente o servidor. Un segmento separado facilita las reglas de firewall, el registro, la captura de paquetes y la posterior resolución de problemas.
Estas redes no deben usarse para la puerta de enlace:
10.42.0.0/1610.43.0.0/1610.108.0.0/16
Para una puerta de enlace local, un nombre DNS público, por ejemplo ztna.example.com, apunta a la IP pública del firewall. El firewall reenvía el puerto 443 a la puerta de enlace a través de DNAT. Luego, la puerta de enlace requiere acceso a Internet y acceso a las VLAN o redes de servidores en las que se encuentran las aplicaciones publicadas.
Las entradas DNS son diferentes para Sophos Cloud Gateway. Allí, los CNAME se vuelven relevantes para la validación de dominios, alias de puerta de enlace y, según el tipo de acceso, alias de recursos. Por lo tanto, las entradas DNS públicas deben verificarse como un paso separado antes de la implementación.
Decidir antes de la implementación
Antes de hacer clic en Add gateway, se deben responder estas preguntas:
- ¿Qué aplicaciones se publican?: La aplicación web, la aplicación TCP y el almacenamiento de archivos tienen requisitos diferentes.
- ¿Acceso sin agentes o basado en agentes?: Los DNS, los CNAME y la experiencia del usuario difieren.
- ¿Puerta de enlace local o en la nube?: Decide sobre DNAT, ruta de datos y responsabilidad operativa.
- ¿A qué grupos de usuarios se les permite el acceso?: ZTNA prospera gracias a una asociación estrecha, no a grupos amplios.
- ¿Cómo se resuelve el DNS interna y externamente?: Los destinos DNS incorrectos son una de las fuentes más comunes de errores.
- ¿Qué certificado se utiliza?: Los errores de certificado actúan como una falla de ZTNA para los usuarios.
- ¿Quién revisa los registros y los cambios?: Sin un propietario, ZTNA rápidamente se vuelve difícil de mantener.
Descargar puerta de enlace ZTNA
En Sophos Central, los archivos de la máquina virtual se pueden descargar en Proteger dispositivos en el menú principal.
Implementar VM en Hyper-V o ESXi
Para una puerta de enlace local o una máquina virtual de puerta de enlace, primero se crea la máquina virtual.
Configuraciones típicas:
- Generación 1 para Hyper-V.
- 2 procesadores virtuales como valor inicial.
- 4 GB de RAM como valor inicial.
- Red en su propio segmento VLAN o gateway.
- Hyper-V: utiliza archivos
.vhdxdescargados. - ESXi: Utilice archivo OVA.
La máquina virtual no debe iniciarse hasta que se cree la imagen ISO con la configuración de la puerta de enlace. Posteriormente, esta ISO conecta la máquina virtual con Sophos Central Tenant y la configuración de la puerta de enlace.
Configuración de puerta de enlace en Sophos Central
Luego se agrega y configura la puerta de enlace en Sophos Central.
Campos importantes:
- Moda: Elija conscientemente la puerta de enlace local o la puerta de enlace en la nube de Sophos.
- Nombre: Utilice ubicación, propósito o nombre de host.
- Ubicación: Opcional, pero útil con múltiples puertas de enlace.
- FQDN: Para la puerta de enlace local, el nombre DNS público que apunta al firewall o la IP de la puerta de enlace.
- Dominio: Dominio que coincida con el certificado y los recursos.
- Tipo de plataforma: VMware ESXi, Hyper-V, AWS o variante de firewall de Sophos compatible según el modo.
- Proveedor de identidad: Seleccione el proveedor de identidad previamente configurado.
- Modo de implementación de instancia de puerta de enlace: Un brazo para escenarios DNAT simples, dos brazos para diseño WAN/LAN independiente.
- dirección IP: Prefiera direcciones IP estáticas o reservadas para puertas de enlace productivas.
- Certificado: Utilice un comodín o un certificado de puerta de enlace apropiado.
El sistema de un solo brazo suele ser más sencillo porque se utiliza una interfaz para el tráfico entrante y saliente. Dos brazos separan los lados WAN y LAN, pero requieren dos interfaces y un diseño de red más claro.
Después de guardar, Sophos Central crea una imagen ISO con la información de la puerta de enlace. Esta ISO se asigna a la VM como ISO de arranque.
Dependiendo del rendimiento y el entorno del host, el inicio inicial y el registro en Sophos Central pueden tardar algún tiempo. Tan pronto como la puerta de enlace responda, se podrá aceptar en Central.
Verificar después del inicio
Después del registro, la puerta de enlace no está lista automáticamente para la producción. Sólo estas pruebas muestran si el diseño funciona:
- Estado de la puerta de enlace: Gateway está en línea en Sophos Central y muestra una versión plausible.
- DNS público: Los FQDN o CNAME de la puerta de enlace apuntan al destino esperado.
- Certificado: El navegador y el cliente ZTNA confían en el certificado.
- Resolución DNS interna: Gateway puede resolver correctamente los recursos internos.
- Reglas del cortafuegos: Gateway sólo llega a las aplicaciones y puertos que necesita.
- DNAT local: El puerto 443 alcanza la regla de firewall y NAT esperada.
- Usuario de prueba: Un grupo piloto puede lograr exactamente los recursos planificados.
- Registros: Los registros de puerta de enlace, central y firewall muestran eventos rastreables.
Si se introduce ZTNA como alternativa a VPN, no se debería probar un piloto con solo un sitio web de muestra. Las aplicaciones de destino reales son mejores: portal web interno, salto RDP/SSH, aplicación especializada o acceso a archivos, según el uso previsto.
Errores típicos
- DNS público muestra falso: Los usuarios no pueden llegar a la puerta de enlace. A/CNAME, TTL, comprobar resolución externa.
- Falta resolución DNS interna: El inicio de sesión funciona, el recurso no se abre. Verifique DNS privado, FQDN de recurso o IP de destino.
- El certificado no encaja: Advertencia del navegador o del cliente. Verifique comodín, SAN, cadena y dominio.
- Falta DNAT en la puerta de enlace local: La puerta de enlace sigue siendo inaccesible desde el exterior. Verifique la regla NAT, el puerto 443, la IP WAN y el visor de registros.
- La puerta de enlace no puede acceder a la aplicación: El recurso permanece fuera de línea o se agota el tiempo de espera. Verifique las reglas de firewall desde el segmento de puerta de enlace hasta el destino.
- Cambios de dirección DHCP: ZTNA falla después del reinicio. Utilice una dirección IP reservada o estática.
- Grupo de usuarios demasiado amplio: Demasiados recursos visibles. Asignar grupos, políticas y recursos más estrechamente.
- Cloud Gateway con PoP incorrecto: latencia notable. Elija un punto de presencia cerca del centro de datos.
Para el análisis de reglas y NAT en Sophos Firewall, Compruebe el control del firewall con Log Viewer, Policy Test y Packet Capture y Comprender NAT en Sophos Firewall le ayudarán.
Lista de verificación operativa
- Modo de puerta de enlace documentado.
- DNS público y DNS privado probados.
- Certificado válido y renovable.
- Gateway operó en su propio segmento.
- DNAT solo configurado para la puerta de enlace local.
- Las reglas de puerta de enlace para recursos internos están estrictamente limitadas.
- Usuarios piloto y recursos piloto definidos.
- Se aclararon los registros, el propietario y el proceso de soporte.
- Ventanas de actualización y mantenimiento de la puerta de enlace programadas.
- Plan de desmantelamiento implementado si Pilot no funciona.