Para las operaciones en curso de Horizon Cloud, un pod recién implementado en Microsoft Azure a partir de la versión de septiembre de 2019 y versiones posteriores o actualizado al nivel de versión de septiembre de 2019 tiene requisitos específicos de puertos y protocolos que son diferentes a los de un pod implementado anteriormente. Los pods recién implementados o actualizados a la versión de septiembre de 2019 tienen versiones de manifiesto 1600 o posteriores.

Importante:

Además de los puertos y los protocolos que se describen aquí, debe cumplir con los requisitos de DNS. Para obtener más información, consulte Requisitos de DNS para un pod de Horizon Cloud en Microsoft Azure.

Puertos y protocolos requeridos por componentes clave del pod para operaciones en curso

Además de los requisitos de DNS, los puertos y protocolos en las tablas siguientes son necesarios para que el pod funcione correctamente durante las operaciones en curso después de la implementación.

En las tablas a continuación, el término "máquina virtual del administrador" hace referencia a la máquina virtual del administrador del pod. En el portal de Microsoft Azure, esta máquina virtual tiene un nombre que contiene una parte como vmw-hcs-podID, donde podID es el UUID del pod, y una parte node.

Importante: Un pod con la función de alta disponibilidad habilitada tiene dos máquinas virtuales del administrador. Un pod con la función de alta disponibilidad activada solo tiene una máquina virtual del administrador. En las tablas a continuación, cada vez que aparece el término "máquina virtual del administrador", se aplica a todas las máquinas virtuales del administrador en el pod con la función de alta disponibilidad habilitada, a menos que se indique lo contrario.

Todos los pods con la versión de manifiesto de la versión de septiembre de 2019 o posterior tienen un equilibrador de carga de pods de Microsoft Azure. Las filas de la tabla asociadas con el equilibrador de carga del pod corresponden a todos los pods en el nivel de manifiesto 1600 o posterior.

Tabla 1. Protocolos y puertos de operaciones del pod
Origen Destino Puertos Protocolo Propósito
Máquina virtual del administrador Otra máquina virtual del administrador del pod 4101 TCP Para un pod con la función de alta disponibilidad habilitada, este tráfico es el enrutamiento JMS entre las máquinas virtuales de administrador.
Máquina virtual del administrador Máquinas virtuales de Unified Access Gateway 9443 HTTPS La máquina virtual del administrador de pods utiliza este puerto a través de la subred de administración para configurar los ajustes de la configuración de Unified Access Gateway del pod. Este requisito de puerto se aplica cuando se implementa inicialmente un pod con una configuración de Unified Access Gateway y cuando se edita un pod para agregar una configuración de Unified Access Gateway o actualizar los ajustes de la configuración de Unified Access Gateway.
Equilibrador de carga de Microsoft Azure del pod Máquina virtual del administrador 8080 HTTP Comprobaciones de estado de las máquinas virtuales en el grupo back-end del equilibrador de carga. Cuando no se habilita la función de alta disponibilidad en un pod de la versión de manifiesto de esta versión, el equilibrador de carga tiene una máquina virtual del administrador para comprobar en su grupo back-end.
Máquina virtual del administrador Controlador de dominio 389 TCP

UDP

Servicios LDAP. Servidor que contiene una función de controlador de dominio en una configuración de Active Directory. Es necesario registrar el pod en Active Directory.
Máquina virtual del administrador Catálogo global 3268 TCP Servicios LDAP. Servidor que contiene la función de catálogo global en una configuración de Active Directory. Es necesario registrar el pod en Active Directory.
Máquina virtual del administrador Controlador de dominio 88 TCP

UDP

Servicios Kerberos. Servidor que contiene una función de controlador de dominio en una configuración de Active Directory. Es necesario registrar el pod en Active Directory.
Máquina virtual del administrador servidor DNS 53 TCP

UDP

Servicios DNS.
Máquina virtual del administrador Servidor NTP 123 UDP Servicios NTP. Servidor que proporciona la sincronización de hora de NTP.
Máquina virtual del administrador Servidor de inscripción True SSO 32111 TCP Servidor de inscripción True SSO. Opcional si no utiliza las capacidades del servidor de inscripción True SSO con los pods.
Máquina virtual del administrador Servicio de Workspace ONE Access 443 HTTPS Opcional si no utiliza Workspace ONE Access con el pod. Se utiliza para crear una relación de confianza entre el pod y el servicio de Workspace ONE Access. Asegúrese de que el pod pueda comunicarse con el entorno de Workspace ONE Access que utiliza, ya sea el servicio de nube o local, en el puerto 443. Si utiliza el servicio de nube de Workspace ONE Access, consulte también la lista de direcciones IP del servicio de Workspace ONE Access a la que el pod y el conector de Workspace ONE Access deben tener acceso en el artículo de la base de conocimientos de VMware 2149884.
Máquina virtual de Jump Box transitoria Máquina virtual del administrador 22 TCP Como se describe anteriormente en Puertos y protocolos requeridos por Jump Box del pod durante las implementaciones y las actualizaciones del pod, se utiliza una máquina de Jump Box transitoria para los procesos de implementación del pod y actualización del pod. Aunque los procesos en curso no necesiten estos puertos, durante los procesos de implementación y actualización del pod, esta máquina virtual de Jump Box debe comunicarse con las máquinas virtuales del administrador mediante SSH a través del puerto 22 de las máquinas virtuales de administrador. Para obtener detalles sobre los casos en los que la máquina virtual de Jump Box necesita esta comunicación, consulte Puertos y protocolos requeridos por Jump Box del pod durante las implementaciones y las actualizaciones del pod.
Nota: Un pod que tiene la versión de manifiesto 1600 o posterior y la función de alta disponibilidad habilitada tendrá dos máquinas virtuales del administrador. En el párrafo anterior, se utiliza el término "máquinas virtuales" en plural para indicar que la máquina virtual de Jump Box debe comunicarse con todas las máquinas virtuales del administrador del pod, independientemente de que el pod tenga una sola o dos.
Máquina virtual de Jump Box transitoria Máquinas virtuales de Unified Access Gateway 9443 HTTPS La máquina virtual de Jump Box utiliza este puerto a través de la subred de administración para configurar los ajustes de la configuración de Unified Access Gateway del pod. Este requisito de puerto se aplica cuando se implementa inicialmente un pod con una configuración de Unified Access Gateway y cuando se edita un pod para agregar una configuración de Unified Access Gateway a un pod.

Requisitos de protocolos y puertos de máquina virtual del conector de puerta de enlace

Esta tabla se aplica a la máquina virtual del conector de puerta de enlace que se utiliza cuando se implementa la puerta de enlace externa en una VNet independiente. Además de los requisitos de DNS, los puertos y protocolos en la siguiente tabla son necesarios para que la puerta de enlace externa funcione correctamente durante las operaciones en curso después de la implementación.

En la siguiente tabla, el término máquina virtual del conector se refiere a la máquina virtual del conector de la puerta de enlace que administra la conexión entre el plano de administración de la nube y la puerta de enlace externa. En el portal de Microsoft Azure, esta máquina virtual tiene un nombre que contiene una parte como vmw-hcs-ID, donde ID es el ID del implementador de la puerta de enlace, y una parte node.

Tabla 2. Protocolos y puertos de operaciones del pod
Origen Destino Puertos Protocolo Propósito
Máquina virtual del conector servidor DNS 53 TCP

UDP

Servicios DNS.
Máquina virtual del conector Servidor NTP 123 UDP Servicios NTP. Servidor que proporciona la sincronización de hora de NTP.
Máquina virtual de Jump Box transitoria Máquina virtual del conector 22 TCP Como se describe anteriormente en Puertos y protocolos requeridos por Jump Box del pod durante las implementaciones y las actualizaciones del pod, se utiliza una máquina de Jump Box transitoria durante la implementación de la puerta de enlace externa y durante los procesos de actualización. Aunque los procesos en curso no necesiten estos puertos, durante los procesos de implementación y actualización, esta máquina virtual de Jump Box debe comunicarse con la máquina virtual del conector mediante SSH a través del puerto 22 de las máquinas virtuales del conector.

Requisitos de protocolos y puertos de máquina virtual de Unified Access Gateway

Además de los requisitos de DNS y los requisitos de protocolos y puertos principales anteriores, los puertos y los protocolos de las siguientes tablas se relacionan con las puertas de enlace configuradas en el pod para funcionar correctamente en las operaciones en curso después de la implementación.

En el caso de las conexiones donde se utiliza un pod con la función de alta disponibilidad habilitada y configurado con instancias de Unified Access Gateway, se debe permitir el tráfico desde las instancias de Unified Access Gateway del pod hacia los destinos que se indican en la siguiente tabla. Durante la implementación del pod, se crea un grupo de seguridad de red (NSG) en el entorno de Microsoft Azure para que sea utilizado por el software de Unified Access Gateway del pod.

Tabla 3. Requisitos de puertos para el tráfico desde las instancias de Unified Access Gateway del pod
Origen Destino Puerto Protocolo Propósito
Unified Access Gateway Equilibrador de carga de Microsoft Azure del pod 8443 TCP Tráfico de autenticación de inicio de sesión. El tráfico procedente de las instancias de Unified Access Gateway llega a las máquinas virtuales del administrador del pod a través del equilibrador de carga del pod.
Unified Access Gateway Horizon Agent en las máquinas virtuales RDSH de granja o escritorio 4172 TCP

UDP

PCoIP
Unified Access Gateway Horizon Agent en las máquinas virtuales RDSH de granja o escritorio 22443 TCP

UDP

Blast Extreme

De forma predeterminada, cuando se utiliza Blast Extreme, el tráfico de redireccionamiento de unidades cliente (CDR) y el tráfico USB se canaliza en este puerto. Si lo prefiere, puede separar el tráfico de CDR hacia el puerto TCP 9427 y el tráfico de redireccionamiento USB hacia el puerto TCP 32111.

Unified Access Gateway Horizon Agent en las máquinas virtuales RDSH de granja o escritorio 9427 TCP Opcional para el redireccionamiento de unidades cliente (CDR) y el tráfico de redireccionamiento multimedia (MMR).
Unified Access Gateway Horizon Agent en las máquinas virtuales RDSH de granja o escritorio 32111 TCP Opcional para el tráfico de redireccionamiento USB.
Unified Access Gateway La instancia RADIUS 1812 UDP Cuando se usa la autenticación en dos fases RADIUS con la configuración de Unified Access Gateway. El valor predeterminado de RADIUS se muestra aquí.

Puertos y protocolos necesarios para el Universal Broker

Para admitir el uso de Universal Broker para brokering de las asignaciones de usuarios finales desde un pod, debe configurar el puerto 443 como se describe en la tabla siguiente. El administrador de pods activo establece una conexión persistente de WebSocket con el servicio de Universal Broker a través del puerto 443 y recibe solicitudes de conexión del servicio de Universal Broker a través de un puerto seleccionado de forma aleatoria.

Tabla 4. Requisitos de puerto para Universal Broker
Origen Puerto de origen Destino Puerto de destino Protocolo Propósito
Administrador de pods activo Seleccionado de forma aleatoria desde los puertos disponibles Servicio de Universal Broker 443 Inicialmente HTTPS, posteriormente WebSocket Establece una conexión persistente de WebSocket con el servicio de Universal Broker

Requisitos de protocolos y puertos de tráfico de conexión de usuario final

Para obtener información detallada acerca de los distintos clientes de Horizon Client que los usuarios finales pueden utilizar con el pod de Horizon Cloud, consulte la página de la documentación de Horizon Client en https://docs.vmware.com/es/VMware-Horizon-Client/index.html. Los puertos que deben estar abiertos para el tráfico desde las conexiones de los usuarios finales para acceder a sus aplicaciones remotas y escritorios virtuales aprovisionados por el pod dependerán de la selección que realice respecto de cómo se conectarán los usuarios finales:

Cuando elige la opción de implementador para tener una configuración de puerta de enlace externa en la propia VNet del pod
El implementador implementa instancias de Unified Access Gateway en el entorno de Microsoft Azure, junto con un recurso de equilibrador de carga de Microsoft Azure, para esas instancias en el grupo de back-end del equilibrador de carga. El equilibrador de carga se comunica con las NIC de esas instancias en la subred DMZ y se configura como un equilibrador de carga público en Microsoft Azure. En el diagrama Ilustración de la Arquitectura Horizon Cloud pod para un pod con alta disponibilidad habilitada y con configuraciones de puerta de enlace externa e interna, la puerta de enlace externa implementada en la misma VNet que el pod, tres NIC en las máquinas virtuales de puerta de enlace externa, dos NIC en las máquinas virtuales de puerta de enlace interna y una IP pública habilitada para el equilibrador de carga de la puerta de enlace externa, se describe la ubicación de este equilibrador de carga público y las instancias de Unified Access Gateway. Cuando el pod tiene esta configuración, el tráfico de los usuarios finales de Internet se enruta a ese equilibrador de carga, el cual distribuye las solicitudes a las instancias de Unified Access Gateway. En el caso de esta configuración, debe asegurarse de que las conexiones de usuarios finales puedan alcanzar ese equilibrador de carga a través de los puertos y protocolos enumerados a continuación. Luego de la implementación, el equilibrador de carga de la puerta de enlace externa se encuentra en el grupo de recursos con el nombre vmw-hcs-podID-uag, donde podID es el UUID del pod.
Cuando elige la opción de implementador para tener una configuración de Unified Access Gateway interna
De forma predeterminada, se implementa una configuración de puerta de enlace interna en la propia VNet del pod. El implementador implementa instancias de Unified Access Gateway en el entorno de Microsoft Azure, junto con un recurso de equilibrador de carga de Microsoft Azure, a esas instancias en su grupo de back-end. El equilibrador de carga se comunica con las NIC de esas instancias en la subred de tenant y se configura como un equilibrador de carga interno en Microsoft Azure. En el diagrama Ilustración de la Arquitectura Horizon Cloud pod para un pod con alta disponibilidad habilitada y con configuraciones de puerta de enlace externa e interna, la puerta de enlace externa implementada en la misma VNet que el pod, tres NIC en las máquinas virtuales de puerta de enlace externa, dos NIC en las máquinas virtuales de puerta de enlace interna y una IP pública habilitada para el equilibrador de carga de la puerta de enlace externa, se describe la ubicación de este equilibrador de carga interno y las instancias de Unified Access Gateway. Cuando el pod tiene esta configuración, el tráfico de los usuarios finales de la red corporativa se enruta a ese equilibrador de carga, el cual distribuye las solicitudes a las instancias de Unified Access Gateway. En el caso de esta configuración, debe asegurarse de que las conexiones de usuarios finales puedan alcanzar ese equilibrador de carga a través de los puertos y protocolos enumerados a continuación. Luego de la implementación, el equilibrador de carga de la puerta de enlace interna se encuentra en el grupo de recursos con el nombre vmw-hcs-podID-uag-internal, donde podID es el UUID del pod.
Cuando elige las opciones de implementador para tener una configuración de puerta de enlace externa en su propia VNet y no los pods, o la opción para utilizar su propia suscripción (que es un subcaso especial de uso de su propia VNet, puesto que las VNet no abarcan suscripciones)
El implementador implementa instancias de Unified Access Gateway en el entorno de Microsoft Azure, junto con un recurso de equilibrador de carga de Microsoft Azure, para esas instancias en el grupo de back-end del equilibrador de carga. El equilibrador de carga se comunica con las NIC de esas instancias en la subred DMZ y se configura como un equilibrador de carga público en Microsoft Azure. El diagrama Ilustración de los elementos de la arquitectura de la puerta de enlace externa cuando la puerta de enlace externa se implementa en su propia VNet, independiente de la VNet del pod describe la ubicación de este equilibrador de carga público y las instancias de Unified Access Gateway en la propia VNet de la puerta de enlace. Cuando el pod tiene esta configuración, el tráfico de los usuarios finales de Internet se enruta a ese equilibrador de carga, el cual distribuye las solicitudes a las instancias de Unified Access Gateway. En el caso de esta configuración, debe asegurarse de que las conexiones de usuarios finales puedan alcanzar ese equilibrador de carga a través de los puertos y protocolos enumerados a continuación. Después de la implementación, el equilibrador de carga de la puerta de enlace externa se encuentra en el grupo de recursos denominado vmw-hcs-ID-uag, donde ID es el valor que aparece en el campo ID de implementador de la página de detalles del pod. Tal y como se describe en la Guía de administración, puede acceder a la página de detalles del pod desde la página Capacidad de la consola.
Cuando elige tener configuraciones de cero Unified Access Gateway en el pod, por ejemplo, cuando está integrando Workspace ONE Access con el pod o permitiendo que los usuarios internos se conecten directamente a través de VPN
Atención: En los sistemas de producción, para el acceso de usuarios internos, la práctica recomendada es usar una configuración interna de puerta de enlace de Unified Access Gateway en el pod, y no las conexiones directas con el pod.
Cuando Workspace ONE Access está integrado con el pod, por lo general, los usuarios finales se conectan a través de Workspace ONE Access. Cuando Workspace ONE Access está integrado con un pod de Horizon Cloud en Microsoft Azure, debe configurarlo para que señale directamente al pod. No se necesita ninguna configuración de Unified Access Gateway en el pod cuando los usuarios finales se conectan a los recursos aprovisionados por pod mediante Workspace ONE Access. Para trabajar con esta configuración, debe cargar un certificado SSL en las máquinas virtuales del administrador de pods desde la página de resumen de dicho pod en la consola, tal y como se describe en la Guía de administración de VMware Horizon Cloud Service. A continuación, complete los pasos para integrar Workspace ONE Access con el pod.
Tabla 5. Protocolos y puertos de conexiones de usuario final externos cuando la configuración del pod tiene instancias externas de Unified Access Gateway
Origen Destino Puerto Protocolo Propósito
Horizon Client Equilibrador de carga de Microsoft Azure para estas instancias de Unified Access Gateway 443 TCP Tráfico de autenticación de inicio de sesión. También puede transportar el tráfico de túnel RDP, el redireccionamiento USB, el redireccionamiento multimedia (MMR) y el redireccionamiento de unidades de cliente (CDR).

SSL (acceso HTTPS) está habilitado de forma predeterminada para las conexiones cliente. En algunos casos, puede utilizarse el puerto 80 (acceso HTTP). Consulte el tema Comprender en qué consiste el redireccionamiento de contenido de URL en la Guía de administración de VMware Horizon Cloud Service.

Horizon Client Equilibrador de carga de Microsoft Azure para estas instancias de Unified Access Gateway 4172 TCP

UDP

PCoIP a través de la puerta de enlace segura de PCoIP de Unified Access Gateway
Horizon Client Equilibrador de carga de Microsoft Azure para estas instancias de Unified Access Gateway 443 TCP Blast Extreme a través de la puerta de enlace segura de Blast Extreme en Unified Access Gateway para el tráfico de datos.
Horizon Client Equilibrador de carga de Microsoft Azure para estas instancias de Unified Access Gateway 443 UDP Blast Extreme a través de Unified Access Gateway para el tráfico de datos.
Horizon Client Equilibrador de carga de Microsoft Azure para estas instancias de Unified Access Gateway 8443 UDP Blast Extreme a través de la puerta de enlace segura de Blast en Unified Access Gateway para el tráfico de datos (transporte adaptativo).
Navegador Equilibrador de carga de Microsoft Azure para estas instancias de Unified Access Gateway 443 TCP HTML Access
Tabla 6. Protocolos y puertos de conexiones de usuario final internos cuando la configuración del pod tiene instancias externas de Unified Access Gateway
Origen Destino Puerto Protocolo Propósito
Horizon Client Equilibrador de carga de Microsoft Azure para estas instancias de Unified Access Gateway 443 TCP Tráfico de autenticación de inicio de sesión. También puede transportar el tráfico de túnel RDP, el redireccionamiento USB, el redireccionamiento multimedia (MMR) y el redireccionamiento de unidades de cliente (CDR).

SSL (acceso HTTPS) está habilitado de forma predeterminada para las conexiones cliente. En algunos casos, puede utilizarse el puerto 80 (acceso HTTP). Consulte el tema Comprender en qué consiste el redireccionamiento de contenido de URL en la Guía de administración de VMware Horizon Cloud Service.

Horizon Client Equilibrador de carga de Microsoft Azure para estas instancias de Unified Access Gateway 4172 TCP

UDP

PCoIP a través de la puerta de enlace segura de PCoIP de Unified Access Gateway
Horizon Client Equilibrador de carga de Microsoft Azure para estas instancias de Unified Access Gateway 443 TCP Blast Extreme a través de la puerta de enlace segura de Blast Extreme en Unified Access Gateway para el tráfico de datos.
Horizon Client Equilibrador de carga de Microsoft Azure para estas instancias de Unified Access Gateway 443 UDP Blast Extreme a través de Unified Access Gateway para el tráfico de datos.
Horizon Client Equilibrador de carga de Microsoft Azure para estas instancias de Unified Access Gateway 8443 UDP Blast Extreme a través de la puerta de enlace segura de Blast en Unified Access Gateway para el tráfico de datos (transporte adaptativo).
Navegador Equilibrador de carga de Microsoft Azure para estas instancias de Unified Access Gateway 443 TCP HTML Access
Tabla 7. Protocolos y puertos de conexiones de usuarios finales internos al utilizar conexiones directas del pod, por ejemplo, a través de VPN
Origen Destino Puerto Protocolo Propósito
Horizon Client Equilibrador de carga de Microsoft Azure del pod 443 TCP Tráfico de autenticación de inicio de sesión. El tráfico procedente de los clientes llega a las máquinas virtuales del administrador del pod a través del equilibrador de carga del pod.
Horizon Client Horizon Agent en las máquinas virtuales RDSH de granja o escritorio 4172 TCP

UDP

PCoIP
Horizon Client Horizon Agent en las máquinas virtuales RDSH de granja o escritorio 22443 TCP

UDP

Blast Extreme
Horizon Client Horizon Agent en las máquinas virtuales RDSH de granja o escritorio 32111 TCP Redireccionamiento USB
Horizon Client Horizon Agent en las máquinas virtuales RDSH de granja o escritorio 9427 TCP Redireccionamiento de unidades cliente (CDR) y redireccionamiento multimedia (MMR)
Navegador Horizon Agent en las máquinas virtuales RDSH de granja o escritorio 443 TCP HTML Access

Requisitos de puertos y protocolos para el tráfico desde Horizon Agent en la máquina virtual base, las máquinas virtuales de escritorio VDI y las máquinas virtuales RDSH de granja

Los siguientes puertos deben permitir el tráfico desde el software relacionado con Horizon Agent que se instaló en las máquinas virtuales base, las de escritorio y las máquinas virtuales RDSH de granja, hacia las máquinas virtuales del administrador de pods.

Origen Destino Puerto Protocolo Propósito
Horizon Agent en la máquina virtual importada base, las imágenes maestras, las máquinas virtuales de escritorio y las máquinas virtuales RDSH de granja Máquina virtual del administrador 4001 TCP El agente utiliza Java Message Service (JMS sin SSL) en la máquina virtual para comunicarse con el pod como parte del proceso de verificación mediante huella digital de certificado e intercambio para proteger una conexión SSL con el pod. Una vez que las claves se negocian e intercambian entre la máquina virtual y el administrador de pods, el agente utiliza el puerto 4002 para crear una conexión SSL segura. Por ejemplo, la acción Restablecer emparejamiento de agente en la página Máquinas virtuales importadas requiere la comunicación a través del puerto 4001 para ese flujo de trabajo de emparejamiento del agente entre la máquina virtual base importada y el pod.
Nota: Los puertos 4001 y 4002 son necesarios para las operaciones de estado estable. El puerto 4001 debe mantenerse abierto porque es posible que, en ciertas ocasiones, el agente tenga que regenerar la clave con el pod.
Horizon Agent en la máquina virtual importada base, las imágenes maestras, las máquinas virtuales de escritorio y las máquinas virtuales RDSH de granja Máquina virtual del administrador 4002 TCP El agente utiliza Java Message Service (JMS con SSL) en estas máquinas virtuales para comunicarse con el pod mediante una conexión SSL segura.
Agente de FlexEngine (agente para VMware Dynamic Environment Manager) en las máquinas virtuales RDSH de granja o de escritorio Los recursos compartidos de archivo configurados para ser utilizados por el agente de FlexEngine que se ejecuta en las máquinas virtuales RDSH o de escritorio 445 TCP Acceso del agente de FlexEngine a los recursos compartidos de archivo de SMB si se utilizan capacidades de VMware Dynamic Environment Manager.

Como parte del proceso de implementación del pod, el implementador crea grupos de seguridad de red (NSG) en las interfaces de red (NIC) de todas las máquinas virtuales implementadas. Para obtener más información sobre las reglas definidas en los NSG, consulte la Guía de administración de Horizon Cloud.

Nota: En lugar de enumerar los nombres DNS, las direcciones IP, los puertos y los protocolos en un artículo de la base de conocimientos (KB) de Horizon Cloud, los proporcionamos aquí como parte de la documentación principal de Horizon Cloud.