Cuando se implementa inicialmente un pod de Horizon Cloud en Microsoft Azure sin puerta de enlace o con solo un tipo de puerta de enlace, es posible agregar una configuración de puerta de enlace al pod mediante el flujo de trabajo Editar pod. Ese flujo de trabajo se inicia desde la página de detalles del pod.

Sugerencia: La consola es dinámica. En la interfaz de usuario, solo estarán disponibles esos flujos de trabajo y esas opciones, así como los campos que tienen sentido y que son adecuados en función de la configuración actual del pod y la configuración del entorno general.

Tal como se describe en Implementaciones de Horizon Cloud on Microsoft Azure, un pod puede tener una configuración de puerta de enlace externa, interna o ambas. Puede utilizar este flujo de trabajo para agregar el tipo que el pod aún no tenga. Al tiempo que se edita el pod para agregar una configuración de puerta de enlace, también se puede especificar la configuración de la autenticación en dos fases para esa puerta de enlace.

Importante: Cuando modifique el pod siguiendo estos pasos, tenga en cuenta los siguientes puntos:
  • Tenga en cuenta que la configuración de IP del equilibrador de carga de una puerta de enlace externa no se puede cambiar después de que se establece inicialmente la configuración de puerta de enlace externa. Al agregar una configuración de puerta de enlace externa, tiene la opción de que esta use una dirección IP privada para el equilibrador de carga de la puerta de enlace en lugar de una pública. La opción predeterminada es usar una IP pública.
  • Cuando el arrendatario está configurado para usar Universal Broker y la configuración del agente tiene habilitada la autenticación en dos fases, se debe establecer el mismo tipo de autenticación en dos fases en las puertas de enlace externas de todos los pods del grupo.
  • Durante el tiempo en que el sistema cambia la configuración del pod hasta su finalización, se aplican las siguientes limitaciones:
    • No se pueden realizar tareas de administración en el pod.
    • Los usuarios finales que no tengan sesiones conectadas a sus aplicaciones remotas o escritorios que se procesan en el pod y que intenten conectarse no podrán hacerlo.
    • Los usuarios finales que tengan sesiones conectadas que se procesan en el pod tendrán desconectadas esas sesiones activas. No se producirá pérdida de datos. Una vez finalizados los cambios de configuración, esos usuarios pueden volver a conectarse.

Requisitos previos

Nota: Si el pod tiene la alta disponibilidad habilitada y una de las máquinas virtuales del administrador de pods está desconectada, el sistema no permitirá agregar una puerta de enlace al pod. El mensaje aparecerá después de hacer clic en Guardar y salir. Para poder agregar la puerta de enlace, debe volver a conectar la máquina virtual del administrador de pods sin conexión mediante el portal de Microsoft Azure.

Al agregar una configuración de puerta de enlace a un pod existente en Microsoft Azure, para completar los campos del asistente Editar pod, es necesario proporcionar la información que se describe en Requisitos previos para las configuraciones de Unified Access Gateway. Si también se desea especificar la configuración de la autenticación en dos fases al tiempo que se agrega la puerta de enlace, es necesario proporcionar la información que se describe en Requisitos previos cuando se implementa con una configuración de autenticación de doble factor. Si va a agregar una configuración de puerta de enlace externa y desea que utilice su propia suscripción, también necesita información de esa suscripción y asegurarse de que la VNet que va a utilizar para esa puerta de enlace cumpla los requisitos de la VNet. Para conocer los requisitos de la VNet, consulte Configurar la red virtual requerida en Microsoft Azure.

Importante: Todos los certificados de la cadena de certificados deben tener intervalos de tiempo válidos. Las máquinas virtuales de Unified Access Gateway requieren que todos los certificados de la cadena, incluidos los certificados intermedios, tengan plazos válidos. Si no ha caducado ningún certificado de la cadena, se pueden producir errores inesperados más adelante al cargar el certificado en la configuración de Unified Access Gateway.

Procedimiento

  1. En la consola, vaya a Configuración > Capacidad y haga clic en el nombre del pod para abrir su página de detalles.
  2. En la página de detalles del pod, haga clic en Editar.
  3. En el paso Suscripción, si va a agregar una configuración de puerta de enlace externa y desea utilizar una suscripción independiente de la del pod, habilite Utilizar una suscripción diferente para la puerta de enlace externa e introduzca la información de la suscripción.
  4. Haga clic en Siguiente hasta que llegue al paso Configuración de puerta de enlace.
    Este paso tiene una sección para la configuración de puerta de enlace externa y una sección para la configuración de puerta de enlace interna. La interfaz de usuario refleja la configuración actual del pod y la configuración de puerta de enlace que ya tiene.
  5. Para agregar una puerta de enlace externa, active la opción ¿Habilitar UAG externa? y rellene los campos de la sección UAG externa.
    Opción Descripción
    ¿Habilitar puerta de enlace externa? Controla si el pod tiene una configuración de puerta de enlace externa. La configuración externa de puerta de enlace proporciona acceso a escritorios y aplicaciones para los usuarios ubicados fuera de la red corporativa. El pod incluye un recurso de equilibrador de carga de Microsoft Azure e instancias de Unified Access Gateway para proporcionar este acceso.
    Nota: Se recomienda dejar la opción predeterminada habilitada.

    Cuando esta opción está desactivada, los clientes deben conectarse a través del Workspace ONE Access con su dispositivo de conector integrado directamente con el administrador de pods, o conectarse directamente al equilibrador de carga del administrador de pods, o bien conectarse a través de una configuración de puerta de enlace interna. En los dos primeros escenarios mencionados, de clientes que se conectan a través de Workspace ONE Access integrado con el pod o que se conectan directamente al equilibrador de carga, se requerirán algunos pasos posteriores a la implementación. En esos escenarios, después de implementar el pod, cargue certificados SSL en las máquinas virtuales del administrador de pods siguiendo los pasos descritos en Configurar certificados SSL directamente en las máquinas virtuales del administrador de pods.

    FQDN Introduzca el nombre de dominio completo (FQDN) necesario, como ourOrg.example.com, que el implementador de pods especificará en la configuración de las instancias de Unified Access Gateway de la puerta de enlace. Debe ser propietario de dicho nombre de dominio y tener un certificado en formato PEM que pueda validar ese FQDN.

    Horizon Cloud espera que este FQDN especificado para la configuración de la puerta de enlace externa se pueda resolver públicamente. Si desactiva la opción ¿Habilitar IP pública? para especificar una dirección IP de la configuración de NAT o firewall, el usuario es responsable de garantizar que este FQDN esté asignado a esa dirección IP en la configuración de firewall o NAT. Este FQDN se utiliza para las conexiones PCoIP a la puerta de enlace.

    Importante: Este FQDN no puede contener caracteres de subrayado. En esta versión, se generará un error con las conexiones a las instancias de Unified Access Gateway cuando el FQDN contenga caracteres de subrayado.
    Direcciones de DNS Opcionalmente, introduzca las direcciones de otros servidores DNS que Unified Access Gateway pueda usar para la resolución de nombres, separadas por comas.

    Al establecer esta configuración de Unified Access Gateway externa para utilizar la autenticación en dos fases con un servidor de autenticación en dos fases que se encuentra fuera de la topología de la VNet en la que se implementan las instancias de Unified Access Gateway, se especifica la dirección de un servidor DNS que puede resolver el nombre de host del servidor de autenticación. Por ejemplo, cuando la autenticación en dos fases está establecida localmente, introduzca un servidor DNS que pueda resolver el nombre del servidor de autenticación.

    Como se describe en los requisitos previos de implementación de Requisitos previos para todas las implementaciones, la topología de VNet utilizada para la implementación de Horizon Cloud on Microsoft Azure debe poder comunicarse con el servidor DNS deseado, proporcionando la resolución de nombres externos durante la implementación de las instancias de Unified Access Gateway y para sus operaciones en curso.

    De forma predeterminada, se utiliza el servidor DNS que está configurado en la VNet en la que se implementan las instancias.

    Cuando se especifican direcciones en Direcciones DNS, las instancias de Unified Access Gateway implementadas utilizan dichas direcciones además de la información del servidor DNS en la configuración de la VNet.

    Rutas Opcionalmente, especifique rutas personalizadas a otras puertas de enlace que desee que las instancias de Unified Access Gateway implementadas utilicen para resolver el enrutamiento de red del acceso de usuario final. Las rutas especificadas se utilizarán para que Unified Access Gateway pueda resolver el enrutamiento de red, como para la comunicación con servidores de autenticación en dos fases.

    Al configurar este pod para utilizar la autenticación en dos fases con un servidor de autenticación en dos fases local, debe introducir la ruta correcta que las instancias de Unified Access Gateway pueden usar para acceder al servidor. Por ejemplo, si el servidor de autenticación local utiliza 10.10.60.20 como dirección IP, escriba 10.10.60.0/24 y su dirección de puerta de enlace de ruta predeterminada como una ruta personalizada. Obtenga la dirección de puerta de enlace de ruta predeterminada de la configuración de la ruta exprés o de una VPN que utilice para esta implementación de Horizon Cloud on Microsoft Azure.

    Especifique las rutas personalizadas como una lista separada por comas en el formulario ipv4-network-address/bits ipv4-gateway-address, por ejemplo: 192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2.

    Heredar servidores NTP del pod Esta opción está habilitada de forma predeterminada para que las instancias de Unified Access Gateway utilicen el mismo servidor NTP que se especifica para las instancias del administrador de pods. Se recomienda encarecidamente mantener esta opción habilitada.

    Se recomienda utilizar el mismo servidor NTP para las instancias del administrador de pods, las instancias de Unified Access Gateway y los servidores de Active Directory. Pueden producirse sesgos horarios cuando estas instancias utilizan servidores NTP diferentes. Estos sesgos horarios posteriormente pueden provocar errores cuando la puerta de enlace intenta autenticar las sesiones de usuario final en sus escritorios y aplicaciones.

    Cuando esta opción está habilitada y se implementa la puerta de enlace externa en su propia red virtual independiente de la red virtual del pod, asegúrese de que se pueda acceder a los servidores NTP especificados para las instancias del administrador de pods desde la red virtual seleccionada para la implementación de la puerta de enlace externa.

    Modelo de máquina virtual Seleccione un modelo que se utilizará para las instancias de Unified Access Gateway. Debe asegurarse de que la suscripción de Microsoft Azure especificada para este pod pueda proporcionar la capacidad para dos máquinas virtuales del modelo seleccionado.
    Importante: En la versión de servicio actual, el modelo de máquina virtual utilizado por estas instancias no se puede cambiar fácilmente después de implementar la configuración de la puerta de enlace. Cambiar el modelo de máquina virtual después de la implementación requiere eliminar la configuración de la puerta de enlace y volver a implementarla. Si prevé que el entorno se ampliará a 2000 sesiones por pod, seleccione F8s_v2. Como se indica en Límites del servicio de VMware Horizon Cloud Service on Microsoft Azure, el modelo de máquina virtual de A4_v2 solo es suficiente para pruebas de concepto (PoC), pruebas piloto o entornos más pequeños en los que se sabe que no se superarán las 1000 sesiones activas en el pod.
    Certificado Cargue el certificado en formato PEM que Unified Access Gateway usará para admitir que los clientes confíen en conexiones con instancias de Unified Access Gateway que se ejecuten en Microsoft Azure. El certificado debe basarse en el FQDN especificado y estar firmado por una entidad de certificación de confianza. El archivo PEM debe contener la cadena de certificados completa y la clave privada: el certificado SSL, los certificados intermedios, el certificado de CA raíz y la clave privada.
    Puerto TCP de Blast Extreme Seleccione el puerto TCP que se utilizará en el ajuste de Blast Extreme dentro de la configuración de Unified Access Gateway. El ajuste se relaciona con Blast Extreme a través de la puerta de enlace segura de Blast en Unified Access Gateway para el tráfico de datos enviado por el cliente. Es preferible el puerto 8443 porque es más eficaz, proporciona un mejor rendimiento y utiliza menos recursos en las instancias de Unified Access Gateway. Por estos motivos, el asistente tiene 8443 como valor predeterminado. La otra opción, 443, es menos eficaz, de menor rendimiento y provoca congestión de CPU en las instancias, lo cual puede provocar retrasos de tráfico observables en los clientes de los usuarios finales. La opción 443 debe utilizarse solo si una organización ha establecido restricciones del lado del cliente, como por ejemplo, si una organización solo permite 443 de salida.
    Nota: El puerto UDP utilizado para Blast Extreme no se ve afectado por esta configuración y siempre es UDP 8443.
    Conjuntos de claves de cifrado Si bien en casi todos los casos no es necesario cambiar la configuración predeterminada, Unified Access Gateway ofrece esta función para especificar de manera opcional los algoritmos criptográficos que se utilizan para cifrar las comunicaciones entre los clientes y los dispositivos de Unified Access Gateway.

    Se debe seleccionar al menos un conjunto de claves de cifrado de la lista que aparece en pantalla. La lista que aparece en pantalla muestra los conjuntos de claves de cifrado admitidos para la implementación de Horizon Cloud on Microsoft Azure.

    Especifique la configuración del equilibrador de carga de Microsoft de esta puerta de enlace.

    Opción Descripción
    ¿Desea habilitar la dirección IP pública? Controla si el tipo de equilibrio de carga de esta puerta de enlace está configurado como privado o público. Si está activado, el recurso de equilibrador de carga de Microsoft Azure implementado se configura con una dirección IP pública. Si está desactivado, el recurso de equilibrador de carga de Microsoft Azure se configura con una dirección IP privada.
    Importante: En esta versión, no puede cambiar más adelante el tipo de equilibrio de carga de la puerta de enlace externa de público a privado o de privado a público. La única forma de hacer ese cambio sería eliminar completamente la configuración de puerta de enlace del pod implementado y, a continuación, editar el pod y volver a agregarlo con la configuración opuesta.

    Si desactiva esta opción, se mostrará el campo IP pública el FQDN de Horizon.

    IP pública para el FQDN de Horizon Cuando haya elegido no configurar el equilibrador de carga de Microsoft Azure implementado con una IP pública, debe proporcionar la dirección IP a la que va a asignar el FQDN que especificó en el campo FQDN. Las instancias de Horizon Client de los usuarios finales utilizarán este FQDN para las conexiones PCoIP con la puerta de enlace. El implementador configurará esta dirección IP en las opciones de configuración de Unified Access Gateway.

    Especifique la configuración de red de la puerta de enlace externa.

    Opción Descripción
    Utilizar una red virtual diferente Esta opción controla si la puerta de enlace externa se implementará en su propia VNet, independiente de la VNet del pod.

    Las siguientes filas describen los diferentes casos.

    Nota: Cuando especificó utilizar una suscripción diferente para la puerta de enlace externa en el primer paso del asistente, esta opción está habilitada de forma predeterminada. Debe elegir una VNet para la puerta de enlace en ese caso.

    Cuando esta opción está activada y la opción Heredar servidores NTP del pod está activada, asegúrese de que se pueda acceder a los servidores NTP especificados para las instancias del administrador de pods desde la red virtual seleccionada para la implementación de la puerta de enlace externa.

    Usar una red virtual diferente: desactivado Cuando esta opción está desactivada, la puerta de enlace externa se implementará en la VNet del pod. En este caso, debe especificar la subred DMZ.
    • Subred DMZ: cuando Utilizar subred existente se habilita en el paso del asistente de configuración del pod, en Subred DMZ, se muestran las subredes disponibles en la VNet seleccionada para la Red virtual. Seleccione la subred existente que desea utilizar para la subred de DMZ del pod.
      Importante: Seleccione una subred vacía que no tenga otros recursos conectados a ella. Si la subred no está vacía, es posible que se produzcan resultados inesperados durante el proceso de implementación o las operaciones del pod.
    • Subred DMZ (CIDR): cuando Utilizar subred existente se desactiva en el paso anterior del asistente, introduzca la subred (en notación CIDR) para la red DMZ (zona desmilitarizada) que se configurará a fin de conectar las instancias de Unified Access Gateway al equilibrador de carga público de Microsoft Azure de la puerta de enlace.
    Usar una red virtual diferente: habilitado Cuando esta opción está habilitada, la puerta de enlace externa se implementará en su propia VNet. En este caso, debe seleccionar la VNet que se va a utilizar y, a continuación, especificar las tres subredes necesarias. Habilite la opción Usar la subred existente para seleccionar las subredes que haya creado previamente en la VNet especificada. De lo contrario, especifique las subredes en notación CIDR.
    Importante: Seleccione subredes vacías que no tengan otros recursos conectados a ellas. Si las subredes no están vacías, es posible que se produzcan resultados inesperados durante el proceso de implementación o las operaciones del pod.

    En este caso, la VNet de la puerta de enlace y la VNet del pod están emparejadas. La práctica recomendada es que las subredes se creen por adelantado y no usen aquí las entradas de CIDR. Consulte Requisitos previos cuando se implementa con una configuración de Unified Access Gateway externa que utiliza su propia VNet o una suscripción independiente de la de la VNet o suscripción del pod.

    • Subred de administración: especifique la subred que se utilizará para la subred de administración de la puerta de enlace. Se requiere un CIDR de al menos /27. Esta subred debe tener el servicio Microsoft.SQL configurado como un endpoint de servicio.
    • Subred de back-end: especifique la subred que se utilizará para la subred de back-end de la puerta de enlace. Se requiere un CIDR de al menos /27.
    • Subred de front-end: especifique la subred de la subred de front-end que se configurará para conectar las instancias de Unified Access Gateway al equilibrador de carga público de Microsoft Azure de la puerta de enlace.
  6. (opcional) En la sección Implementación, utilice la opción para seleccionar un grupo de recursos existente en el que desea que el implementador despliegue los recursos para la configuración de puerta de enlace externa.
    Esta opción se muestra cuando se ha especificado que se utilice una suscripción diferente para la puerta de enlace externa en el primer paso del asistente. Al habilitar la opción, aparece un campo en el que puede buscar y seleccionar el grupo de recursos.
  7. Para agregar una puerta de enlace interna, active la opción ¿Habilitar UAG interna? y rellene los campos de la sección UAG interna.
    Opción Descripción
    ¿Desea habilitar la puerta de enlace interna? Controla si el pod tiene una configuración de puerta de enlace interna. La configuración interna proporciona acceso de confianza a escritorios y aplicaciones para las conexiones de HTML Access (Blast) a los usuarios que se encuentran dentro de la red corporativa. El pod incluye un recurso de equilibrador de carga de Azure e instancias de Unified Access Gateway para proporcionar este acceso. De forma predeterminada, el tipo de equilibrio de carga de esta puerta de enlace es privado. El equilibrador de carga se configura con una dirección IP privada.
    FQDN Introduzca el nombre de dominio totalmente cualificado (FQDN) necesario, como ourOrg.example.com, que utilizarán sus usuarios finales para acceder al servicio. Debe ser propietario de dicho nombre de dominio y tener un certificado en formato PEM que pueda validar ese FQDN.
    Importante: Este FQDN no puede contener caracteres de subrayado. En esta versión, se generará un error con las conexiones a las instancias de Unified Access Gateway cuando el FQDN contenga caracteres de subrayado.
    Direcciones de DNS Opcionalmente, introduzca las direcciones de otros servidores DNS que Unified Access Gateway pueda usar para la resolución de nombres, separadas por comas.

    Al establecer esta configuración de Unified Access Gateway interna para utilizar la autenticación en dos fases con un servidor de autenticación en dos fases que se encuentra fuera de la topología de la VNet en la que se implementan las instancias de Unified Access Gateway, se especifica la dirección de un servidor DNS que puede resolver el nombre de host del servidor de autenticación. Por ejemplo, cuando la autenticación en dos fases está establecida localmente, introduzca un servidor DNS que pueda resolver el nombre del servidor de autenticación.

    Como se describe en los requisitos previos de implementación de Requisitos previos para todas las implementaciones, la topología de VNet utilizada para la implementación de Horizon Cloud on Microsoft Azure debe poder comunicarse con el servidor DNS deseado, proporcionando la resolución de nombres externos durante la implementación de las instancias de Unified Access Gateway y para sus operaciones en curso.

    De forma predeterminada, se utiliza el servidor DNS que está configurado en la VNet en la que se implementan las instancias.

    Cuando se especifican direcciones en Direcciones DNS, las instancias de Unified Access Gateway implementadas utilizan dichas direcciones además de la información del servidor DNS en la configuración de la VNet.

    Rutas Opcionalmente, especifique rutas personalizadas a otras puertas de enlace que desee que las instancias de Unified Access Gateway implementadas utilicen para resolver el enrutamiento de red del acceso de usuario final. Las rutas especificadas se utilizarán para que Unified Access Gateway pueda resolver el enrutamiento de red, como para la comunicación con servidores de autenticación en dos fases.

    Al configurar este pod para utilizar la autenticación en dos fases con un servidor de autenticación en dos fases local, debe introducir la ruta correcta que las instancias de Unified Access Gateway pueden usar para acceder al servidor. Por ejemplo, si el servidor de autenticación local utiliza 10.10.60.20 como dirección IP, escriba 10.10.60.0/24 y su dirección de puerta de enlace de ruta predeterminada como una ruta personalizada. Obtenga la dirección de puerta de enlace de ruta predeterminada de la configuración de la ruta exprés o de una VPN que utilice para este entorno.

    Especifique las rutas personalizadas como una lista separada por comas en el formulario ipv4-network-address/bits ipv4-gateway-address, por ejemplo: 192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2.

    Heredar servidores NTP del pod Esta opción está habilitada de forma predeterminada para que las instancias de Unified Access Gateway utilicen el mismo servidor NTP que se especifica para las instancias del administrador de pods. Se recomienda encarecidamente mantener esta opción habilitada.

    Se recomienda utilizar el mismo servidor NTP para las instancias del administrador de pods, las instancias de Unified Access Gateway y los servidores de Active Directory. Pueden producirse sesgos horarios cuando estas instancias utilizan servidores NTP diferentes. Estos sesgos horarios posteriormente pueden provocar errores cuando la puerta de enlace intenta autenticar las sesiones de usuario final en sus escritorios y aplicaciones.

    Modelo de máquina virtual Seleccione un modelo que se utilizará para las instancias de Unified Access Gateway. Debe asegurarse de que la suscripción de Microsoft Azure especificada para este pod pueda proporcionar la capacidad para dos máquinas virtuales del modelo seleccionado.
    Importante: En la versión de servicio actual, el modelo de máquina virtual utilizado por estas instancias no se puede cambiar fácilmente después de implementar la configuración de la puerta de enlace. Cambiar el modelo de máquina virtual después de la implementación requiere eliminar la configuración de la puerta de enlace y volver a implementarla. Si prevé que el entorno se ampliará a 2000 sesiones por pod, seleccione F8s_v2. Como se indica en Límites del servicio de VMware Horizon Cloud Service on Microsoft Azure, el modelo de máquina virtual de A4_v2 solo es suficiente para pruebas de concepto (PoC), pruebas piloto o entornos más pequeños en los que se sabe que no se superarán las 1000 sesiones activas en el pod.
    Certificado Cargue el certificado en formato PEM que Unified Access Gateway usará para admitir que los clientes confíen en conexiones con instancias de Unified Access Gateway que se ejecuten en Microsoft Azure. El certificado debe basarse en el FQDN especificado y estar firmado por una entidad de certificación de confianza. El archivo PEM debe contener la cadena de certificados completa y la clave privada: el certificado SSL, los certificados intermedios, el certificado de CA raíz y la clave privada.
    Puerto TCP de Blast Extreme Seleccione el puerto TCP que se utilizará en el ajuste de Blast Extreme dentro de la configuración de Unified Access Gateway. El ajuste se relaciona con Blast Extreme a través de la puerta de enlace segura de Blast en Unified Access Gateway para el tráfico de datos enviado por el cliente. Es preferible el puerto 8443 porque es más eficaz, proporciona un mejor rendimiento y utiliza menos recursos en las instancias de Unified Access Gateway. Por estos motivos, el asistente tiene 8443 como valor predeterminado. La otra opción, 443, es menos eficaz, de menor rendimiento y provoca congestión de CPU en las instancias, lo cual puede provocar retrasos de tráfico observables en los clientes de los usuarios finales. La opción 443 debe utilizarse solo si una organización ha establecido restricciones del lado del cliente, como por ejemplo, si una organización solo permite 443 de salida.
    Nota: El puerto UDP utilizado para Blast Extreme no se ve afectado por esta configuración y siempre es UDP 8443.
    Conjuntos de claves de cifrado Si bien en casi todos los casos la configuración predeterminada es suficiente, Unified Access Gateway ofrece esta función para especificar los algoritmos criptográficos que se utilizan para cifrar las comunicaciones entre los clientes y los dispositivos de Unified Access Gateway.

    Se debe seleccionar al menos un conjunto de claves de cifrado de la lista que aparece en pantalla. La lista que aparece en pantalla muestra los conjuntos de claves de cifrado admitidos para la implementación de Horizon Cloud on Microsoft Azure.

  8. En la sección de la puerta de enlace que planea agregar, si desea configurar de forma opcional los escritorios de los usuarios finales para que estos usen la autenticación en dos fases, siga los pasos indicados en Habilitar la autenticación en dos fases en las puertas de enlace del pod de Horizon Cloud.
  9. En la sección Etiquetas de recursos de Azure, si desea especificar etiquetas de recursos para los grupos de recursos relacionados con la puerta de enlace que son diferentes de los que se especifican en los otros grupos de recursos del pod, desactive la opción Heredar etiquetas del pod y especifique las etiquetas en los campos que aparecen.
    Para obtener una descripción de los campos Etiquetas de recursos de Azure, consulte Arrendatarios de first-gen: especificar la configuración de puerta de enlace del pod de Horizon Cloud. Se utilizará el mismo conjunto de etiquetas para ambos tipos de puertas de enlace en el pod.
  10. Haga clic en Guardar y salir.
    Aparece un mensaje de confirmación que le pide que confirme el inicio del flujo de trabajo.
  11. Haga clic en para iniciar el flujo de trabajo.

Resultados

Hasta que el sistema termine de implementar los elementos de la puerta de enlace, la sección de la página de resumen del pod para ese tipo de configuración mostrará el estado Pendiente. Además, no puede realizar actividades adicionales relacionadas con el flujo de trabajo Editar pod hasta que el sistema finalice con sus acciones para implementar la puerta de enlace.

Cuando se complete el flujo de trabajo, el estado se mostrará como Listo y el FQDN del equilibrador de carga se mostrará en la página.

Nota: Al ejecutar este flujo de trabajo para un pod de Microsoft Azure China, el proceso puede tardar más de una hora en completarse. El proceso está sujeto a problemas de red geográficos que pueden provocar bajas velocidades de descarga dado que los archivos binarios se descargan desde el plano de control de nube.

Qué hacer a continuación

Importante: Para que los usuarios finales puedan comenzar a utilizar la puerta de enlace recién agregada, primero debe completar las siguientes tareas.
  • Para la configuración de puerta de enlace recién agregada, asegúrese de tener un registro CNAME en el servidor DNS para asignar el equilibrador de carga implementado en la configuración al FQDN que introdujo en el asistente de implementación. Consulte los detalles en Cómo obtener la información del equilibrador de carga de puerta de enlace del pod de Horizon Cloud para asignarlo en el servidor DNS.
  • Si especificó una autenticación en dos fases para la puerta de enlace agregada, debe realizar estas tareas:
    • Si la puerta de enlace externa del pod tiene configurada la autenticación en dos fases y no se puede acceder al servidor de autenticación en dos fases dentro de la misma topología de VNet en la que se implementan las instancias Unified Access Gateway de la puerta de enlace, configure ese servidor de autenticación en dos fases para permitir la comunicación desde la dirección IP del equilibrador de carga de la puerta de enlace externa.

      En este escenario, donde no se puede acceder al servidor de autenticación en dos fases dentro de la misma topología de VNet que la implementación de puerta de enlace, las instancias de Unified Access Gateway intentan ponerse en contacto con ese servidor mediante la dirección del equilibrador de carga. Para permitir el tráfico de comunicación, asegúrese de que la dirección IP del recurso del equilibrador de carga que se encuentra en el grupo de recursos de la puerta de enlace externa esté especificada como un cliente o como un agente registrado en la configuración del servidor de autenticación en dos fases. Consulte la documentación del servidor de autenticación en dos fases para obtener información específica sobre cómo permitir esa comunicación.

    • Si se puede acceder al servidor de autenticación en dos fases dentro de la misma topología de VNet, configure el servidor de autenticación en dos fases para permitir la comunicación desde las NIC adecuadas que se crearon para las instancias de Unified Access Gateway de la implementación en Microsoft Azure.

      El administrador de red determina la visibilidad de red del servidor de autenticación en dos fases para la topología de VNet de Azure y sus subredes utilizadas para la implementación. El servidor de autenticación en dos fases debe permitir la comunicación desde las direcciones IP de las NIC de las instancias de Unified Access Gateway que corresponden a la subred para la que el administrador de red ha otorgado visibilidad de red hacia el servidor de autenticación en dos fases.

      El grupo de recursos de la puerta de enlace en Microsoft Azure tiene cuatro NIC que corresponden a esa subred: dos que están activas actualmente para las dos instancias de Unified Access Gateway, y dos que están inactivas y se convertirán en las instancias activas después de que se actualice el pod y sus puertas de enlace.

      Si desea admitir el tráfico de comunicación entre la puerta de enlace y el servidor de autenticación en dos fases para las operaciones del pod en curso y después de cada actualización del pod, asegúrese de que las direcciones IP de esas cuatro NIC estén especificadas como clientes o como agentes registrados en la configuración del servidor. Consulte la documentación del servidor de autenticación en dos fases para obtener información específica sobre cómo permitir esa comunicación.

    Para obtener información sobre cómo obtener esas direcciones IP, consulte Actualizar el sistema de autenticación en dos fases con la información requerida de puerta de enlace del pod de Horizon Cloud.