Guías

Audiencia y Propósito

Este documento está dirigido a administradores de TI de red y seguridad que tienen experiencia con los fundamentos de tecnologías de redes y VPN.

Como producto de seguridad y redes de próxima generación, Jamf Connect ZTNA se comporta significativamente diferente a una VPN tradicional. Esta guía tiene como objetivo ayudar a los administradores a entender los fundamentos del diseño del producto para facilitar la planificación, implementación, mantenimiento y solución de problemas.

Esta guía no es documentación del producto que describe cómo configurar el producto ZTNA de Jamf, sino que explica cómo funciona para que pueda predecir y entender el comportamiento del producto en su entorno. Si está buscando documentación, puede encontrarla en nuestra Documentación de Jamf Connect ZTNA, o si desea ver primero una descripción general técnica en video del producto, vea la presentación JNUC 2021 Jamf ZTNA Deep Dive.

Recomendamos altamente que lea (¡y guarde en marcadores!) esta guía si está utilizando Jamf Connect ZTNA en capacidad de producción dentro de su organización.

Descripción General

El producto ZTNA de Jamf fue diseñado desde el principio para adherirse a la arquitectura Software Defined Perimeter (SDP) de Cloud Security Alliance (CSA). Esta arquitectura incorpora muchos de los principios de la definición más amplia de la industria de Acceso a Red de Confianza Cero (ZTNA), incluyendo Acceso con Mínimos Privilegios, Acceso Basado en Roles, Verificación de Identidad Multifactor, Confianza del Dispositivo, y mucho más. El producto fue construido originalmente por Wandera y adquirido por la plataforma de seguridad de Jamf en julio de 2021.

Entonces, aunque Jamf Connect ZTNA comparte muchos de los mismos resultados de una VPN tradicional – como cuando la interfaz VPN se activa y los recursos remotos se vuelven disponibles – los mecanismos reales para respaldar esos resultados son completamente diferentes. Esto es resultado de cómo Connect ZTNA utiliza direccionamiento IP, DNS y tecnologías en la nube para entregar enrutamiento de cliente a servidor que representa un cambio en términos de rendimiento, escalabilidad y seguridad comparado con las arquitecturas VPN tradicionales.

Entonces, con eso en mente, comencemos con una de las diferencias más significativas e importantes entre el SDP de Jamf y una VPN tradicional: intermediación de conexiones versus enrutamiento.

Intermediación de Conexiones

Comencemos con esto: tome todo lo que sabe y asume sobre cómo funciona una VPN, y déjelo de lado por un momento. Aunque el enrutamiento final de paquetes eventualmente se parece mucho a una VPN tradicional, hay un elemento de procesamiento completamente nuevo en el proceso de conexión.

VPN Tradicional

Cuando un dispositivo se conecta a una VPN tradicional, crea un túnel seguro con un concentrador VPN, que puede existir en las instalaciones o en la nube, y ser operado por usted o un proveedor de servicios.

Independientemente de dónde esté el concentrador o quién lo opere, el comportamiento general es el mismo:

1. El dispositivo se autentica con el concentrador VPN y se establece un túnel seguro, creando una interfaz de red virtual en el endpoint.
2. El dispositivo recibe dinámicamente una dirección IP asignada por el concentrador que es válida durante la vida útil de ese túnel (a veces puede ser "asignada estáticamente" mediante vinculación DHCP).
3. Una o más rutas se configuran para la interfaz de red virtual, definiendo las subredes de red propiedad de la organización que deben enrutarse a través de la VPN. Una VPN de túnel completo enruta todo el tráfico desde el dispositivo al concentrador, eliminando todo acceso a la red local.
4. Un servidor de nombres DNS se configura en el dispositivo, que generalmente reside al otro lado de la VPN en la red del cliente.
5. Siempre que una aplicación realiza una solicitud a un recurso, DNS se resuelve a una dirección IP y el tráfico se enruta a través de la VPN si la dirección IP del paquete se encuentra dentro de una de las rutas de la interfaz virtual VPN.
6. El concentrador VPN enruta el paquete a la red del cliente. En algunos casos, se implementan listas de control de acceso de firewall en toda la red para restringir el control de acceso.

Aunque esto ciertamente funciona, el problema de seguridad principal con esta arquitectura es que esencialmente todos los recursos dentro de las subredes enrutadas se vuelven disponibles para el dispositivo. Esto permite conectividad a servicios de TI y servidores que la mayoría de los endpoints no tienen ninguna razón de conectarse. Si es un actor malicioso y logra explotar el endpoint, puede usar esta conexión VPN para encontrar puntos débiles en servidores que están "seguros" detrás del firewall y pueden no estar completamente parcheados o de otra manera bloqueados adecuadamente.

Ciertamente, puede implementar reglas de control de acceso en la red, pero eso es difícil y propenso a errores. Usualmente tales reglas deben ser gestionadas a nivel de dirección IP, por lo que tienden a ser frágiles y peligrosas de cambiar. Esto resulta en políticas de seguridad a nivel de red que rápidamente son superadas por la tasa requerida de cambio para nuevas y evolucionantes aplicaciones que son críticas para la misión en la red. Tampoco tiene una muy buena manera de monitorear y auditar informes de una manera que acople estrechamente la identidad de un usuario con sus conexiones. Entonces, ¿qué hacen la mayoría de las organizaciones? ¿Dejarlo abierto y unir el informe cuando hay un incidente?

Entonces, ¿cómo soluciona usted estos desafíos? Ingrese SDP e "intermediación" de conexiones de red.

SDP: Intermediación de Conexiones

Cuando Jamf's ZTNA está conectado en un dispositivo endpoint, hay algunas diferencias significativas desde el principio:

1. Se crea una interfaz de red Wireguard sin estado después de un apretón de manos inicial muy ligero. N.b. dependiendo de su implementación de ZTNA, los dispositivos Apple pueden usar HTTP/3 en lugar de Wireguard.
2. Un conjunto simple de rutas IPv6 – negociadas fuera de banda del establecimiento de la interfaz – se configuran para la interfaz VPN de red. Por defecto, estas rutas no pertenecen al cliente, sino que son rangos IPv6 reservados gestionados por Jamf (fd53:1c5a::/32, fddd:dddd::/128). La interfaz de red virtual también se asigna una dirección IPv6 estática que también fue negociada fuera de banda. ¡No hay direcciones IPv4 o rutas asignadas a la interfaz de red virtual por defecto!
3. Un servidor de nombres DNS gestionado por Jamf fddd:dddd:: se configura en el dispositivo.

¿Vaya? ¿Qué? Sí, leyó bien: sin direcciones IP, subredes o servidores de nombres DNS del lado empresarial publicados en la tabla de rutas del dispositivo del usuario final. ¡Ni siquiera ninguna dirección IPv4! Este es un bloque de construcción clave de la intermediación de conexiones SDP tal que el endpoint y el usuario no tienen conciencia de la topología de red interna y no pueden conectarse a IPs de red interna aunque lo intenten.

Entonces, ¿cómo se conecta una aplicación en el dispositivo a una aplicación en un servidor que vive en una de esas subredes IPv4 internas? Ahí es donde entra la intermediación de conexiones, facilitada por la magia de DNS, NAT, y tecnologías de enrutamiento de Jamf.

Información: Nota sobre Acceso Directo a IP y Subred

Más allá de los beneficios de seguridad de no publicar subredes internas a endpoints – mucho menos cualquier dirección IPv4 – también ayuda a evitar solapamientos de segmentos de red que los usuarios pueden experimentar en redes no corporativas gestionadas (por ejemplo, hogar, cafetería, etc.). Esto es crítico para permitir trabajo remoto transparente desde cualquier lugar.

Sin embargo, hay algunos casos de uso específicos donde una dirección IPv4 o subred debe ser utilizable directamente y no puede depender de la intermediación de conexiones basada en DNS. Para esas situaciones, Connect ZTNA soporta configurar acceso "IP Directo". Consulte la sección "Excepciones de Conexiones Intermediadas" de esta guía para más detalles.

Asumamos que el usuario está intentando conectarse a App, que vive en app.acmeinc.com, y tiene una dirección IP interna de 10.0.1.22. Aquí es lo que sucede para facilitar esa conexión desde un dispositivo habilitado para Jamf ZTNA (el siguiente ejemplo muestra una conexión TCP a la aplicación de destino pero un flujo similar se usa para conexiones UDP):

1. El usuario inicia una conexión a app.acmeinc.com desde su navegador de preferencia o cualquier aplicación nativa.
2. La aplicación le pide al SO que resuelva ese nombre de host para obtener una dirección IP a la que conectarse. Con Jamf Connect ZTNA activo, el servidor de nombres DNS a usar es fddd:dddd::, que es una dirección IPv6 virtual vinculada al motor de política de Jamf Connect ZTNA.
3. El SO realiza una serie de solicitudes DNS a fddd:dddd:: para app.acmeinc.com, incluyendo tipos A, AAAA, y HTTPS.
4. El servidor de nombres DNS de Jamf Connect ZTNA realiza una búsqueda ascendente del FQDN, primero buscando ver si se ha configurado una Zona DNS Personalizada para el dominio (*.acmeinc.com con 10.0.1.10 como servidor de nombres autorizado en este ejemplo). Si no se encuentra una Zona DNS Personalizada, el servicio usa una serie de resolutores DNS públicos ascendentes.
   1. Nota: El servicio solo solicita un registro A ascendente, con AAAA y HTTPS ignorados en este momento. Esto solo es un problema potencial para servidores que son solo alcanzables vía IPv6, que es extraordinariamente raro hoy en día en la mayoría de redes públicas y privadas.
5. Al recibir las respuestas DNS A de un servidor autorizado (en este caso A 10.0.1.22 del servidor de nombres interno del cliente a través de una configuración de Zona DNS Personalizada), el servidor de nombres DNS de Jamf Connect ZTNA identifica al usuario y dispositivo solicitando el recurso y busca una Política de Acceso coincidente que defina app.acmeinc.com como criterio de coincidencia de tráfico.
   1. Esta política de acceso evalúa la membresía de grupo del usuario y la salud del dispositivo para determinar si se debe otorgar acceso al recurso.
   2. También definido en la política es cómo debe enrutarse el tráfico a través de la nube de Jamf. En este caso, asumiremos que el cliente ha configurado una puerta de enlace de interconexión IPSec para servir como la ruta privada para alcanzar esta aplicación interna.
6. Asumiendo que se encuentra la política de acceso, y el dispositivo y usuario pasan todos los criterios requeridos para conectarse al recurso, el tejido de enrutamiento de Jamf Connect ZTNA crea un "mapeo de flujo en la nube" que asigna un IPv6 efímero dentro de la subred IPv6 reservada publicada al endpoint (por ejemplo, fd53:1c5a::aaaa:bbbb ↔ 10.0.1.22).
   1. Este flujo es único por conexión y usuario, y no puede ser reutilizado más allá de su vida útil o por ningún otro dispositivo.
7. Esta dirección IPv6 fd53:1c5a::aaaa:bbbb se devuelve al endpoint como la respuesta AAAA de DNS.
   1. ¡El servicio no devuelve una respuesta A ni HTTPS por defecto! Esto es muy importante tener en cuenta al solucionar problemas de respuestas DNS usando utilidades como dig.
8. Se crea un nuevo socket a fd53:1c5a::aaaa:bbbb, y como esa IP existe dentro de la subred asignada a la interfaz VPN de Jamf Connect ZTNA, ese socket y todos los paquetes posteriores se reenvían hacia atrás a través de un túnel Wireguard a la Nube de Seguridad de Jamf.
9. Al recibir el paquete, el tejido de enrutamiento de Jamf Connect ZTNA realiza verificaciones de seguridad adicionales, luego localiza el mapeo de flujo en la nube para la dirección IPv6 de destino.
10. El tejido de enrutamiento de Jamf Connect ZTNA enruta los paquetes a través de nuestra red troncal en la nube global, finalmente alcanzando la interconexión IPSec según se define en la política de acceso. Antes de que el paquete se reenvíe a través del túnel IPSec, ocurre una traducción NAT64 según el mapeo de flujo en la nube, resultando en un paquete con la dirección IPv4 original (10.0.1.22) como su IP de destino.
    1. La dirección IP de origen del paquete se establece en una dirección IP dentro de la subred definida por el lado "Nube de Seguridad de Jamf" en la configuración IPSec. Todo el tráfico enviado a la red del cliente aparecerá de una IP pseudo-aleatoria dentro de esta subred.
    2. Si está utilizando un centro de datos regional para salida NAT basada en la nube, la dirección IP de origen será dinámicamente balanceada en los direcciones IP globales del centro de datos.
11. Todas las conexiones intermediadas coincidentes se registran contra el usuario, dispositivo y aplicación, y están disponibles para revisión en el Registro de Eventos de Acceso en RADAR, entre otros informes.

Como puede ver, hay un acoplamiento estricto de DNS, enrutamiento IP, y NAT que simplemente no existe nativamente en configuraciones VPN tradicionales.

Aunque a pesar de estas diferencias, Jamf Connect ZTNA maneja paquetes extremadamente eficientemente ya que todo el enrutamiento ocurre nativamente en la capa 3, soportando fácilmente aplicaciones en tiempo real como VoIP y video. Como toda la encapsulación ocurre usando los protocolos de encapsulación UDP de HTTP/3 o Wireguard ultra rápidos y eficientes, no hay "colapsos" de protocolo de transmisión que son comunes cuando se enrutan conexiones TCP dentro de un túnel basado en TCP/mTLS en redes con pérdida.

Información: SDP, VPN y Cifrado End-to-End de Aplicación

Jamf Connect ZTNA ha sido diseñado para proporcionar capacidades rápidas y dinámicas de redes definidas por software usando tecnologías modernas de encapsulación y cifrado para permitirle fácilmente dirigir y aplicar política al tráfico desde endpoints hasta prácticamente cualquier destino con algunos clics en una interfaz web.

Aunque como cualquier tecnología VPN que cifra tráfico una vez que ya está en vuelo, es imposible que Jamf proporcione verdadero cifrado end-to-end de datos desde aplicación cliente a aplicación servidor.

Por lo tanto, para cualquier aplicación que contenga cualquier nivel de datos sensibles, SIEMPRE debe configurar tales aplicaciones para usar tecnologías de cifrado a nivel de aplicación como HTTPS o TLS. Esta es práctica estándar ahora para todas las aplicaciones. Esta es la única manera de asegurar que un intermediario no autorizado sea incapaz de acceder en ningún punto a lo largo de la red de Jamf o cliente.

Esta técnica de intermediación de conexiones ha probado operar a rendimiento y escala de nivel empresarial en la plataforma Jamf ZTNA. Todos los sistemas operativos modernos soportan nativamente IPv6 (incluso si el dispositivo tiene una conexión de red solo IPv4), y la gran mayoría de aplicaciones y usuarios soportan IPv6 y usan DNS para todas sus conexiones.

Eso es excepto para aquellas que no... por lo cual necesitará definir configuración especial para que esos casos atípicos funcionen a través de Connect ZTNA.

Disponibilidad y Conmutación por Error

Jamf ZTNA está arquitecturado con consideración para fragmentación de red y dispositivos siendo incapaces de conectarse a la Nube de Seguridad de Jamf. Lo hace usando una variedad de métodos superpuestos:-

Detección de Puerta de Enlace Muerta

Jamf Trust puede detectar conexiones peligrosas o inestables que a menudo resultan de portales cautivos inseguros. Estos portales cautivos pueden interceptar tráfico que crea problemas de conectividad.

Con detección de puerta de enlace muerta (DGD), la aplicación Jamf Trust puede proporcionar notificaciones en dispositivos de usuario final respecto al estado actual de su conexión. DGD usa verificaciones de conectividad generales, como verificaciones de portal cautivo y verificaciones de conectividad web, mientras usa resoluciones de endpoint de Acceso a Red de Confianza Cero (ZTNA) para detectar una puerta de enlace muerta. Para soportar directamente DGD, modo de derivación en Jamf Trust previene que tráfico peligroso pase a través del túnel VPN. Esto permite a usuarios finales navegar por Internet de forma segura sin su VPN o aplicaciones de trabajo.

Ubicaciones de ingreso balanceadas por carga y regionales

Al detectar una conexión activa, Jamf Trust solicita endpoints IP locales determinados del proveedor DNS de la red local (generalmente proporcionado por DHCP). El TTL (time-to-live) para estos endpoints es 60 segundos. Si uno de estos endpoints se vuelve no disponible, se elimina del grupo en 60 segundos. Esto resulta en un RTO (Objetivo de Tiempo de Recuperación) de hasta 60 segundos, pero cuando se empareja con Detección de Puerta de Enlace Muerta, la recuperación de una falla de un solo endpoint es inmediata.

Almacenamiento en caché de política local

Como se describe en SDP: Intermediación de Conexiones, Jamf usa sustitutos DNS locales para redirigir tráfico de dispositivo al recurso apropiado. Estos registros DNS locales también tienen un TTL de 60 segundos. Si se promulga un cambio de política (ya sea automáticamente debido a política basada en riesgo, o desde un cambio de administración), el período más largo antes de actualización de política localmente en el dispositivo es 60 segundos. N.b. la política no vive localmente en el dispositivo, pero debido al almacenamiento en caché de DNS puede parecer que una actualización de política se empuja cada 60 segundos.

Excepciones de Conexiones Intermediadas

Aunque la mayoría de aplicaciones y servicios operan nativamente y sin consideración especial a través del servicio Jamf ZTNA, hay algunos casos de uso específicos y clases de aplicaciones que requieren conectividad no soportada por el enfoque de conexión intermediada.

Aplicaciones/servicios que no usan DNS

Como aprendió arriba, si una aplicación o usuario no está usando un FQDN para conectarse a un recurso, bueno, eso simplemente no va a funcionar.

Esto es porque sin una solicitud DNS para iniciar la conexión, una dirección IPv6 intermediada nunca será emitida. Y como la dirección IPv4 del destino no se agrega a la tabla de rutas del dispositivo, ese paquete simplemente irá a Internet y nunca regresará.

Aunque poco común en conjunto, escenarios de conexión que no implican FQDNs/DNS es común para:

• Administradores de TI intentando conectarse a equipos de red directamente
• Desarrolladores conectando a nuevas instancias de instancias virtuales que no están registradas con DNS
• Aplicaciones heredadas que se conectan vía una dirección IPv4, no FQDN

Es por esta razón que Jamf Connect ZTNA soporta la definición opcional de "IPs Directas y Subredes" en la Política de Acceso de una aplicación.

Error: Seguridad e Excepciones de IP Directo y Subred

Solo recomendamos configurar acceso basado en IP para usuarios y aplicaciones que absolutamente deben tener acceso a recursos de esta manera. Y si lo configura, las subredes que define están delimitadas lo más estrechamente posible (por ejemplo, 10.0.1.0/29) versus (10.0.0.0/16).

Esto es porque al establecer enrutamiento en un nivel tan amplio, está efectivamente negando muchos de los beneficios de seguridad de un modelo de conectividad basada en intermediación, revirtiendo al comportamiento de una VPN tradicional. Esto deja a su organización vulnerable a los mismos tipos de ataques que impactan VPNs tradicionales causados por permitir acceso excesivo a recursos de red.

Cuando configura una o más direcciones IP de esta manera, las subredes CIDR definidas serán publicadas a la tabla de rutas de dispositivos asignados a esa política. Esto significa que además de la subred IPv6 predeterminada fd53, la interfaz VPN de red también contendrá todas las subredes IPv4 definidas en todas las políticas de acceso aplicables.

Al guardar una política de acceso con estas direcciones IP definidas, puede tomar hasta 30 minutos para que esos cambios se propaguen a todos los dispositivos. Habilitar y deshabilitar Jamf Connect ZTNA activará una actualización inmediata de estas políticas.

Ahora, asumiendo que se agregó 10.0.1.22 a la misma política de acceso App, un usuario final de Jamf ZTNA sería capaz de conectarse vía http://10.0.1.22 o ping 10.0.1.22.

Vale la pena notar que aunque la conexión no sea intermediada vía DNS, la capacidad de conectarse al recurso todavía está sujeta a todas las condiciones definidas en la Política de Acceso.

Aplicaciones que usan FQDN, pero no soportan IPv6

Hay un subconjunto de aplicaciones por ahí que por cualquier número de razones simplemente no les gusta IPv6:

• Algunas aplicaciones modernas tienen pilas de redes complejas/personalizadas que simplemente no son compatibles con IPv6 (por ejemplo, Docker para macOS)
• Aplicaciones heredadas que no tienen idea de que IPv6 existe, y son incapaces de utilizar una respuesta AAAA y fallan trabajar cuando no hay respuesta A.

Para estas aplicaciones, es capaz de configurar una política de acceso para usar enrutamiento "Compatible" en lugar de "Optimizado". Hacer esto resultará en lo siguiente:

• Los endpoints sujetos a la política de acceso serán presionados una subred IPv4 única de Jamf Cloud que opera de manera idéntica en naturaleza al rango IPv6 para intermediación de conexiones
  • Este mismo rango se usa para una o más políticas de acceso configuradas de esta manera.
  • Puede tomar hasta 10 minutos para que esta nueva ruta sea publicada a todos los dispositivos, o la VPN puede ser reiniciada para activar la actualización inmediatamente.
• Los endpoints sujetos a la política de acceso serán asignados una dirección IPv4 en la interfaz VPN de red.
• Cuando se recibe una solicitud DNS que coincide con una Política de Acceso establecida en modo "Compatible", la respuesta AAAA estará vacía, pero se devolverá una respuesta A usando un mapeo de flujo en la nube IPv4 en lugar de un IPv6 como se usa cuando se selecciona "Optimizado".
• La aplicación incompatible con IPv6 / heredada usará la dirección IPv4 devuelta en la respuesta del registro A, y establecerá un socket a esa dirección que será enrutado a través de la interfaz VPN de Jamf ZTNA gracias a las rutas IPv4 publicadas.

El resultado es una experiencia de usuario casi idéntica al enrutamiento Optimizado, menos algo de eficiencias menores inherentes a usar IPv4 versus IPv6 en la pila de red.

Túnel Dividido Dinámico

Para todas las conexiones que no coinciden con una política de acceso – ya sea vía una conexión DNS intermediada o IP directo – la respuesta DNS A/AAAA/HTTPS se devuelve exactamente como se devolvió por el resolutor DNS ascendente. En otras palabras, el resultado sería equivalente a intentar conectarse a la aplicación como si Jamf ZTNA estuviera deshabilitado en el dispositivo.

En este caso, no se crea mapeo de flujo en la nube para estas solicitudes, ni registro realizado (la excepción es si también ha configurado Filtrado de Contenido de Jamf y/o Protección contra Amenazas Web por lo cual las solicitudes pueden ser registradas o bloqueadas basado en políticas de Internet o Seguridad).

Esto resulta en un comportamiento de túnel dividido "dinámico" porque a diferencia de un túnel dividido tradicional construido usando rangos CIDR estáticos, el tráfico encapsulado (o no) por el túnel puede cambiar en tiempo real. Esto es logrado gracias al método de conexión intermediada descrito arriba, donde un mapeo de flujo en la nube se devuelve, o la respuesta DNS pública se usa, completamente basado en configuración activa y contexto instantáneo del dispositivo.

Redes Locales

¡Buenas noticias! A menos que haya agregado IPs Directas/Subredes que se superpongan con la subred de la red local de un usuario, entonces ¡la mayoría de conectividad de red local para el dispositivo funciona genial! Esto es importante para dispositivos locales como impresoras, pero particularmente para dispositivos móviles donde muchos usuarios esperan ser capaces de usar de forma transparente sus aplicaciones inteligentes o entretenimiento cuando están en su red doméstica.

La mayoría de redes locales no tienen una zona DNS autorizada, entonces los dispositivos en su lugar confían en mDNS para descubrir y conectarse a otros dispositivos locales. mDNS no es impactado cuando el servidor DNS de Jamf ZTNA se establece en la interfaz VPN de red, dejando este comportamiento para funcionar normalmente.

Políticas de Acceso Wildcard / No-Totalmente-ZTNA

Aunque las promesas de seguridad de ZTNA es convincente, moverse desde una implementación VPN tradicional completamente abierta a un entorno ZTNA granular a nivel de aplicación va a tomar algo de tiempo. Es poco realista que la mayoría de organizaciones esperen ser capaces de cortar hacia una VPN basada en ZTNA (como la de Jamf) sin una cantidad increíble de pruebas anticipadas y/o dolor del usuario final.

Por lo tanto, Jamf Connect ZTNA se ha adaptado a esta realidad para permitir que funcione mucho como una VPN tradicional en varios caminos importantes.

Wildcard de FQDN

La configuración de seguridad más granular y del mejor caso es configurar tantas Políticas de Acceso como tenga aplicaciones, con los FQDNs y nombres de host específicos siendo usados para cada uno. Por ejemplo, para la aplicación App puede tener app.acmeinc.com e images.app.acmeinc.com.

Sin embargo, simplemente descubrir todos estos nombres de host, mucho menos configurarlos en una Política de Acceso, puede tomar una cantidad significativa de tiempo.

Por lo tanto, especialmente si está probando o simplemente comenzando con Jamf Connect ZTNA, recomendamos crear una Política de Acceso con un nombre como "Acme Inc Wildcard Default", y configurar un nombre de host como *.acmeinc.com. Esta regla única "atrapará" todas las solicitudes realizadas a cualquier FQDN que use acmeinc.com como su dominio.

Esta es una excelente manera de poner su infraestructura de prueba en funcionamiento para que pueda obtener tráfico fluyendo a sus aplicaciones internas (asumiendo que ha configurado las apropiadas [Zonas DNS Personalizadas](https://learn.jamf.com/en