Esta página es una referencia para todos los puertos y protocolos posibles utilizados para la comunicación dentro de una implementación típica de Horizon Cloud Service on Microsoft Azure first-gen. Utilice estas tablas para asegurarse de que la configuración de la red y los firewalls permitan el tráfico de comunicación que se requiere para una implementación correcta del pod y las operaciones diarias.
Acerca de esta página
Los puertos y protocolos específicos requeridos para su implementación particular dependerán en parte de las funciones que seleccione para su implementación de Horizon Cloud Service on Microsoft Azure. Si tiene pensado no utilizar un componente o protocolo específico, el tráfico de comunicación requerido no es necesario para sus fines y puede ignorar los puertos asociados con ese componente. Por ejemplo, si los usuarios finales solo van a utilizar el protocolo de visualización Blast Extreme, no es necesario permitir los puertos PCoIP.
El tráfico de red debe alcanzar nombres de host específicos. Si la implementación está configurada para utilizar un proxy, se espera que algunos servicios de red lo utilicen y que otros se ejecuten de forma directa. Si desea obtener más información sobre el tráfico de red para los nombres de host, consulte Arrendatarios de first-gen - Implementaciones de Horizon Cloud on Microsoft Azure: requisitos de resolución de nombres de host, nombres DNS.
Para obtener información sobre otros puertos compatibles con productos VMware, visite VMware Ports and Protocols.
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 estos NSG, consulte Reglas predeterminadas de grupo de seguridad de red para las máquinas virtuales en un pod de Horizon Cloud.
Puertos y protocolos requeridos por componentes clave del pod para operaciones en curso
Además de los requisitos de DNS, en la tabla siguiente se indican los puertos y protocolos necesarios para que el pod funcione correctamente durante las operaciones en curso después de la implementación. Algunas de estas tablas también indican los puertos y los protocolos necesarios para escenarios específicos o cuando se han habilitado funciones concretas en el pod.
En el portal de Microsoft Azure, los nombres de las máquinas virtuales del administrador de pods tienen una parte similar a vmw-hcs-podID, donde podID es el UUID del pod, y otra parte node.
El uso por parte del sistema de un equilibrador de carga de Microsoft Azure con las máquinas virtuales del administrador de pods se inició desde el manifiesto 1600, en la versión de servicio de septiembre de 2019. Por lo tanto, todos los pods nuevos implementados desde el manifiesto 1600 en adelante tienen un equilibrador de carga de Microsoft Azure. Los pods que se implementaron por primera vez antes del manifiesto 1600 y que se actualizaron posteriormente a manifiestos posteriores también tienen un equilibrador de carga de pods de Microsoft Azure. Las filas de la tabla que mencionan el equilibrador de carga del pod se aplican a todos los pods.
| Origen | Destino | Puertos | Protocolo | Propósito |
|---|---|---|---|---|
| Máquina virtual del administrador de pods | Otra máquina virtual del administrador de pods del pod | 4101 | TCP | Este tráfico es el enrutamiento JMS entre las máquinas virtuales del administrador de pods. |
| Máquina virtual del administrador de pods | 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 de pods | 8080 | HTTP | Comprobaciones de estado de las máquinas virtuales en el grupo back-end del equilibrador de carga. En el caso de los pods implementados antes de la versión 2204 en los que no se estableció la opción de alta disponibilidad y aún no está agregada esta función, el equilibrador de carga tiene una máquina virtual del administrador de pods en su grupo de back-end que comprobar. |
| Máquina virtual del administrador de pods | Controlador de dominio | 389 | TCP UDP |
Es necesario registrar el tenant de Horizon Cloud en Active Directory. El flujo de trabajo para registrar un dominio de AD de la consola debe realizarse después de incorporar el primer pod. Este puerto es necesario para los servicios LDAP, si se va a especificar LDAP en ese flujo de trabajo. LDAP es el valor predeterminado para la mayoría de los tenants. El destino es el servidor que contiene una función de controlador de dominio en la configuración de Active Directory. |
| Máquina virtual del administrador de pods | Catálogo global | 3268 | TCP | Es necesario registrar el tenant de Horizon Cloud en Active Directory. El flujo de trabajo para registrar un dominio de AD de la consola debe realizarse después de incorporar el primer pod. Este puerto es necesario para los servicios LDAP, si LDAP va a ser el protocolo especificado en ese flujo de trabajo. LDAP es el valor predeterminado para la mayoría de los tenants. El destino es el servidor que contiene la función de catálogo global en la configuración de Active Directory. |
| Máquina virtual del administrador de pods | Controlador de dominio | 88 | TCP UDP |
Servicios Kerberos. El destino es el 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 de pods | Controlador de dominio | 636, 3269 | TCP | Es necesario registrar el tenant de Horizon Cloud en Active Directory. El flujo de trabajo para registrar un dominio de AD de la consola debe realizarse después de incorporar el primer pod. Estos puertos son necesarios para los servicios de LDAP sobre SSL (LDAPS) solo si LDAPS va a ser el protocolo especificado en la configuración de esa instancia de AD registrada. LDAPS solamente se puede especificar en la instancia de AD registrada si el tenant está habilitado para usar la función LDAPS del servicio. De lo contrario, LDAP es el requisito de forma predeterminada. |
| Máquina virtual del administrador de pods | servidor DNS | 53 | TCP UDP |
Servicios DNS. |
| Máquina virtual del administrador de pods | Servidor NTP | 123 | UDP | Servicios NTP. Servidor que proporciona la sincronización de hora de NTP. |
| Máquina virtual del administrador de pods | Servidor de inscripción True SSO | 32111 | TCP | Servidor de inscripción True SSO. Se requiere si utiliza True SSO con los pods de Horizon. 32111 es el puerto predeterminado que se utiliza en la instalación del servidor de inscripción. Este número de puerto se puede configurar durante el proceso de instalación del servidor de inscripción según sus requisitos. Consulte también la sección Administración de True SSO y certificados e implementaciones de Horizon Cloud on Microsoft Azure de este tema. |
| Máquina virtual del administrador de pods | Servicio de Workspace ONE Access | 443 | HTTPS |
Nota: Esta fila se aplica a entornos con una configuración de agente de pod único. Esta información no está destinada a entornos con una configuración Universal Broker. En un entorno configurado con agente de pod único,
Workspace ONE Access Connector se comunica con un pod para obtener las autorizaciones de usuario final (las asignaciones).
Opcional si no se integra Workspace ONE Access con el pod. En un entorno configurado de agente de pod único, esta conexión se utiliza para crear una relación de confianza entre el pod y el servicio de Workspace ONE Access, donde Workspace ONE Access Connector se sincroniza con el pod. Asegúrese de que el pod pueda comunicarse con el entorno de Workspace ONE Access que se utiliza en el puerto 443. Cuando se utiliza el servicio de nube de Workspace ONE Access, consulte también en el artículo 2149884 de la base de conocimientos de VMware la lista de direcciones IP del servicio de Workspace ONE Access a la que Workspace ONE Access Connector y el pod deben tener acceso. |
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.
| 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. |
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 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 de pods a través del equilibrador de carga del pod. |
| Unified Access Gateway | Servidor NTP | 123 | UDP | Servicios NTP. Servidor que proporciona la sincronización de hora de NTP. Cuando el arrendatario esté configurado para utilizar Universal Broker, asegúrese de que se cumplan estos puntos:
El motivo es que, si el servicio detecta que hay un desfase horario entre los dispositivos de Unified Access Gateway y el servidor NTP del Universal Broker que ejecuta UTC (hora universal coordinada), se le enviará un correo electrónico para solicitarle que solucione el desfase horario. Los desfases de tiempo entre Universal Broker y los dispositivos de Unified Access Gateway pueden provocar errores en las conexiones de los usuarios finales. Cuando las configuraciones de Unified Access Gateway internas no están conectadas a un servidor NTP desde la subred del arrendatario, es más probable que experimenten estas desviaciones horarias, ya que, sin un servidor NTP, esos dispositivos de Unified Access Gateway dependerán del tiempo de la máquina virtual subyacente. Si el servidor NTP que desea utilizar es un servidor NTP interno y no se permite comunicarse desde la interfaz de DMZ, abra una solicitud de servicio para que el equipo de VMware Horizon Cloud Service pueda ayudar a agregar rutas a la configuración de Unified Access Gateway después de la implementación, para que Unified Access Gateway pueda comunicarse con el servidor NTP. El equipo de VMware Horizon Cloud Service tiene llamadas de API para agregar las rutas por usted.
Sugerencia: Cuando el arrendatario está configurado para utilizar brokering de pod único, los puntos anteriores se consideran las prácticas recomendadas, ya que, en el escenario de agente de pod único, la discrepancia horaria con los dispositivos de Unified Access Gateway no afecta a las conexiones de los usuarios finales.
|
| 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í. |
| Unified Access Gateway | Servidor del administrador de autenticación RSA SecurID | 5555 | TCP | Cuando se usa la autenticación en dos fases RSA SecurID con la configuración de Unified Access Gateway. Aquí se muestra el valor predeterminado que se utiliza para el puerto de comunicación de agentes de la API de autenticación de RSA SecurID para la autenticación del agente. |
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.
| 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 conectarse a sus aplicaciones remotas y escritorios virtuales aprovisionados por el pod desde sus dispositivos, los usuarios finales utilizan un VMware Horizon Client compatible instalado o su navegador (denominado cliente de Horizon HTML Access). Los puertos que deben estar abiertos para que el tráfico de los clientes de los usuarios finales acceda 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 Cloud Pod de Horizon para un pod con alta disponibilidad habilitada y configurado con la dos configuraciones de Unified Access Gateway, externa e interna 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 arrendatario y se configura como un
equilibrador de carga interno en Microsoft Azure.
En el diagrama Ilustración de la arquitectura Cloud Pod de Horizon para un pod con alta disponibilidad habilitada y configurado con la dos configuraciones de Unified Access Gateway, externa e interna, 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 no hay configuraciones de Unified Access Gateway en el pod
-
Nota: Para los entornos de producción en los que el arrendatario está configurado para utilizar brokering de pod único, la práctica recomendada para las conexiones de usuario final internas es utilizar una configuración de puerta de enlace de Unified Access Gateway interna en el pod. Esas conexiones se dirigirían a esa configuración de puerta de enlace en el escenario de brokering de pod único.En una configuración en la que tenga un brokering de pod único y Workspace ONE Access integrado con el pod, por lo general, los usuarios finales se conectan a través de Workspace ONE Access. En este escenario, se debe configurar Workspace ONE Access y Workspace ONE Access Connector apuntando directamente al pod. Los usuarios finales se conectan a los recursos aprovisionados mediante pod por medio de 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 Configurar certificados SSL directamente en las máquinas virtuales del administrador de pods, como cuando se integra el dispositivo de Workspace ONE Access Connector con el pod de Horizon Cloud en Microsoft Azure, para que Connector pueda confiar en las conexiones con las máquinas virtuales del administrador de pods. A continuación, complete los pasos para integrar Workspace ONE Access con el pod.
| 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). |
| 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 | 8443 o 443, según lo que esté configurado en la implementación | 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 desde Horizon Client. Para un pod de Horizon Cloud, este puerto se selecciona mediante el menú Puerto TCP de Blast Extreme en el asistente de implementación. Asegúrese de que las redes permitan a los clientes el acceso saliente a lo que especificó para la puerta de enlace externa. Los clientes utilizan esta URL para establecer la sesión de Horizon Blast en las instancias de Unified Access Gateway, a través del equilibrador de carga que se encuentra frente a esas instancias. A partir de la versión de servicio de octubre de 2021, para las nuevas implementaciones de una configuración de puerta de enlace, el implementador proporciona la capacidad de seleccionar 8443 o 443 para el puerto TCP de Blast Extreme que el implementador configurará en la configuración de Unified Access Gateway correspondiente. Anteriormente, el implementador configuraba 443 de forma predeterminada, sin proporcionar una opción. Si la configuración de la puerta de enlace se implementó antes de la fecha de la versión de servicio de octubre de 2021, esa configuración suele tener el puerto 443 establecido en el campo URL externa de Blast en la configuración de administración de Unified Access Gateway.
Nota: 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. El puerto 443 es menos eficaz y de menor rendimiento. El uso del puerto 443 provocará una congestión de la CPU en las instancias. El puerto 443 se utilizará en la implementación solo si la organización ha establecido restricciones en el lado del cliente, por ejemplo, si la organización solo permite la salida 443 y no la 8443.
|
| 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 | 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). |
| Navegador | Equilibrador de carga de Microsoft Azure para estas instancias de Unified Access Gateway | 8443 o 443, según lo que esté establecido en la implementación | 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 desde el cliente HTML Access de Horizon (cliente web). Para un pod de Horizon Cloud, este puerto se selecciona mediante el menú Puerto TCP de Blast Extreme en el asistente de implementación. Asegúrese de que las redes permitan a los clientes el acceso saliente a lo que especificó para la puerta de enlace externa. El cliente HTML Access de Horizon utiliza esta URL en el navegador para establecer la sesión de Blast de Horizon en las instancias de Unified Access Gateway, a través del equilibrador de carga que se encuentra frente a esas instancias. A partir de la versión de servicio de octubre de 2021, para las nuevas implementaciones de una configuración de puerta de enlace, el implementador proporciona la capacidad de seleccionar 8443 o 443 para el puerto TCP de Blast Extreme que el implementador configurará en la configuración de Unified Access Gateway correspondiente. Anteriormente, el implementador configuraba 443 de forma predeterminada, sin proporcionar una opción. Si la configuración de la puerta de enlace se implementó antes de la fecha de la versión de servicio de octubre de 2021, esa configuración suele tener el puerto 443 establecido en el campo URL externa de Blast en la configuración de administración de Unified Access Gateway.
Nota: 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. El puerto 443 es menos eficaz y de menor rendimiento. El uso del puerto 443 provocará una congestión de la CPU en las instancias. El puerto 443 se utilizará en la implementación solo si la organización ha establecido restricciones en el lado del cliente, por ejemplo, si la organización solo permite la salida 443 y no la 8443.
|
| 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 Agente de pod único: pods de Horizon Cloud y la función Redireccionamiento de contenido URL. |
| 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 | 8443 o 443, según lo que esté establecido en la implementación | 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 desde Horizon Client. Para un pod de Horizon Cloud, este puerto se selecciona mediante el menú Puerto TCP de Blast Extreme en el asistente de implementación. Asegúrese de que las redes permitan a los clientes el acceso saliente a lo que especificó para la puerta de enlace externa. Los clientes utilizan esta URL para establecer la sesión de Horizon Blast en las instancias de Unified Access Gateway, a través del equilibrador de carga que se encuentra frente a esas instancias. A partir de la versión de servicio de octubre de 2021, para las nuevas implementaciones de una configuración de puerta de enlace, el implementador proporciona la capacidad de seleccionar 8443 o 443 para el puerto TCP de Blast Extreme que el implementador configurará en la configuración de Unified Access Gateway correspondiente. Anteriormente, el implementador configuraba 443 de forma predeterminada, sin proporcionar una opción. Si la configuración de la puerta de enlace se implementó antes de la fecha de la versión de servicio de octubre de 2021, esa configuración suele tener el puerto 443 establecido en el campo URL externa de Blast en la configuración de administración de Unified Access Gateway.
Nota: 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. El puerto 443 es menos eficaz y de menor rendimiento. El uso del puerto 443 provocará una congestión de la CPU en las instancias. El puerto 443 se utilizará en la implementación solo si la organización ha establecido restricciones en el lado del cliente, por ejemplo, si la organización solo permite la salida 443 y no la 8443.
|
| 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 | 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). |
| Navegador | Equilibrador de carga de Microsoft Azure para estas instancias de Unified Access Gateway | 8443 o 443, según lo que esté establecido en la implementación | 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 desde el cliente HTML Access de Horizon (cliente web). Para un pod de Horizon Cloud, este puerto se selecciona mediante el menú Puerto TCP de Blast Extreme en el asistente de implementación. Asegúrese de que las redes permitan a los clientes el acceso saliente a lo que especificó para la puerta de enlace externa. El cliente HTML Access de Horizon utiliza esta URL en el navegador para establecer la sesión de Blast de Horizon en las instancias de Unified Access Gateway, a través del equilibrador de carga que se encuentra frente a esas instancias. A partir de la versión de servicio de octubre de 2021, para las nuevas implementaciones de una configuración de puerta de enlace, el implementador proporciona la capacidad de seleccionar 8443 o 443 para el puerto TCP de Blast Extreme que el implementador configurará en la configuración de Unified Access Gateway correspondiente. Anteriormente, el implementador configuraba 443 de forma predeterminada, sin proporcionar una opción. Si la configuración de la puerta de enlace se implementó antes de la fecha de la versión de servicio de octubre de 2021, esa configuración suele tener el puerto 443 establecido en el campo URL externa de Blast en la configuración de administración de Unified Access Gateway.
Nota: 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. El puerto 443 es menos eficaz y de menor rendimiento. El uso del puerto 443 provocará una congestión de la CPU en las instancias. El puerto 443 se utilizará en la implementación solo si la organización ha establecido restricciones en el lado del cliente, por ejemplo, si la organización solo permite la salida 443 y no la 8443.
|
| 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 de pods 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 agentes instalados 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 el agente 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 de pods | 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 de pods | 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. |
| Horizon Agent en las máquinas virtuales RDSH de granja o las máquinas virtuales de escritorio | Nombre de host de VMware Cloud Services scapi.vmware.com | 443 | TCP | Se utiliza para el programa Programa VMware Service Usage Data Program (SUDP). Saliente desde la subred del arrendatario, el tráfico desde Horizon Agent enviado al nombre de host de VMware Cloud Services scapi.vmware.com. |
| 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. |
Puertos y protocolos necesarios para las funciones de App Volumes
Como se indica en Aplicaciones de App Volumes para Horizon Cloud on Microsoft Azure: descripción general y requisitos previos, para admitir el uso de las funciones de App Volumes compatibles para su uso con un pod de Horizon Cloud, debe configurar el puerto 445 para el tráfico de protocolo TCP en la subred de arrendatario del pod. El puerto 445 es el puerto SMB estándar para acceder a los recursos compartidos de archivos SMB en Microsoft Windows. Las AppStacks se almacenan en un recurso compartido de archivos SMB ubicado en el grupo de recursos de la máquina virtual del administrador de pods.
Además, como se describe en Arrendatarios de first-gen - Implementaciones de Horizon Cloud on Microsoft Azure: requisitos de resolución de nombres de host, nombres DNS, cuando Azure Cloud aprovisiona ese recurso compartido de archivos SMB, Azure Cloud asigna un nombre de dominio completo (FQDN) según el patrón *.file.core.windows.net, donde * es el nombre de almacenamiento generado por Azure de la cuenta de almacenamiento del recurso compartido de archivos SMB. El servidor DNS debe poder resolver este FQDN para que App Volumes pueda acceder a esos recursos compartidos de archivos, montarlos y recuperar las AppStacks. Debe asegurarse de que el servidor DNS resuelva ese FQDN en todo momento para los procesos de App Volumes Manager que se ejecutan dentro de las instancias del administrador de pods y para la instancia de App Volumes Agent que se ejecuta en los escritorios VDI.
| Origen | Destino | Puerto | Protocolo | Propósito |
|---|---|---|---|---|
| El agente de App Volumes 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 | Recurso compartido de archivos SMB en el grupo de recursos del administrador de pods | 445 | TCP | En la subred de arrendatario del pod, para acceder a las AppStacks de App Volumes almacenadas en el recurso compartido de archivos SMB. |
Integración con Workspace ONE Assist for Horizon: requisitos de DNS, puertos y protocolo
Workspace ONE Assist for Horizon es un producto de la línea de productos de Workspace ONE UEM. A partir de la versión de agosto de 2021 de Horizon Cloud, una vez que se cumplan los requisitos específicos, puede integrar el uso de ese producto con escritorios VDI aprovisionados desde los pods del inquilino de Horizon Cloud. Para obtener más información sobre los requisitos, consulte la guía de VMware Workspace ONE Assist for Horizon que se encuentra en el área de documentación de VMware Workspace ONE Assist.
El uso de las funciones de asistencia requiere comunicación saliente entre las máquinas virtuales de escritorio VDI y el servidor de Workspace ONE Assist que admite la integración con el arrendatario de Horizon Cloud.
- Requisitos de DNS
- Asegúrese de que el nombre DNS de su servidor de Workspace ONE Assist se pueda resolver y se pueda acceder a él desde las subredes de arrendatario del pod en las que residirán las máquinas virtuales de escritorio VDI. La guía de VMware Workspace ONE Assist for Horizon mencionada anteriormente proporciona los nombres DNS de los servidores de Workspace ONE Assist.
- Requisitos de puertos y protocolos
- El tráfico saliente que utiliza el puerto 443, TCP y HTTPS debe permitirse desde las máquinas virtuales de escritorio VDI en las que esté instalada la aplicación de Workspace ONE Assist for Horizon.
Puertos y protocolos temporales de Jump Box cuando se necesitan para una solicitud de soporte activa
Si realiza una solicitud de soporte a VMware y el equipo de asistencia determina que la forma de abordar esa solicitud es implementar una máquina virtual temporal de Jump Box para la comunicación SSH con los dispositivos administrados por VMware, ese Jump Box requiere los puertos y los protocolos que se describen aquí.
Se le solicitará permiso para realizar una implementación de Jump Box relacionada con la asistencia. El equipo de soporte de VMware le informará de los requisitos de comunicación, según corresponda para cualquier situación de asistencia.
Esta máquina virtual de Jump Box relacionada con la asistencia está diseñada para comunicarse como origen con los siguientes destinos.
- El puerto 22 de las máquinas virtuales del administrador de pods del pod mediante SSH y el puerto 22.
- El puerto 9443 de las máquinas virtuales de Unified Access Gateway mediante HTTPS.
- El puerto 22 de la máquina virtual del conector de puerta de enlace mediante SSH, en una implementación en la que la puerta de enlace externa se implementa en su propia VNet.
La naturaleza de la solicitud de soporte y los dispositivos utilizados en la implementación determinan qué dispositivos específicos administrados por VMware deben permitirse como destino de la comunicación.
| Origen | Destino | Puertos | Protocolo | Propósito |
|---|---|---|---|---|
| Máquina virtual de Jump Box |
|
22 | SSH | Si el equipo de soporte de VMware requiere esta comunicación con uno o varios de los dispositivos enumerados para procesar la solicitud de soporte, la máquina virtual de Jump Box se comunica a través de la subred de administración con el puerto 22 en el dispositivo de destino. |
| Máquina virtual de Jump Box | Máquinas virtuales de Unified Access Gateway | 9443 | HTTPS | Si el equipo de soporte de VMware requiere esta comunicación para procesar la solicitud de soporte, la máquina virtual de Jump Box se comunica a través de la subred de administración para configurar los ajustes de Unified Access Gateway. |
Debido a que a estas máquinas virtuales se les asignan direcciones IP de forma dinámica, las siguientes reglas de red pueden dar lugar a las comunicaciones descritas. Durante las actividades de solicitud de soporte, busque siempre la orientación y supervisión del servicio de soporte de VMware para conocer los requisitos de la implementación de Jump Box relacionada con la asistencia.
- El CIDR de subred de administración como el origen y el destino, con el puerto de destino 22, el puerto de origen cualquiera y el protocolo TCP.
- El CIDR de subred de administración como el origen y el destino, con el puerto de destino 9443, el puerto de origen cualquiera y el protocolo TCP, cuando se implica una configuración de Unified Access Gateway.
Administración de True SSO y certificados e implementaciones de Horizon Cloud on Microsoft Azure
Las máquinas virtuales de escritorio de Horizon Cloud aprovisionadas por el pod no se comunican directamente con el servidor de inscripción. La máquina virtual activa del administrador de pods de la implementación de Horizon Cloud on Microsoft Azure retransmite las solicitudes de certificado al servidor de inscripción. Una vez obtenido el certificado, Horizon Agent en las máquinas virtuales de escritorio usa ese certificado para realizar la operación de inicio de sesión de certificado en nombre del usuario de escritorio.
La arquitectura de solicitud-respuesta es la misma para una máquina virtual del administrador de pods de una implementación de Horizon Cloud on Microsoft Azure que para la instancia de Horizon Connection Server de una implementación de Horizon. En una implementación de Horizon Cloud on Microsoft Azure, las máquinas virtuales del administrador de pods tienen conexiones a las máquinas virtuales de escritorio en la subred de máquina virtual principal (también denominada subred de arrendatario) y en cualquier subred de máquina virtual adicional que el administrador de VDI pueda haber agregado mediante el flujo de trabajo Editar pod.
Varios componentes validarán dos clases de certificados: certificados de usuario y certificados de canal. True SSO agrega un certificado de usuario validado por el servidor de autenticación. En el caso de una implementación de Horizon Cloud on Microsoft Azure, ese servidor de autenticación es un servidor de Microsoft Active Directory. Debido a que la arquitectura de Microsoft determina qué números de puerto se pueden utilizar para esta validación de certificados, se puede usar un amplio rango de números de puerto para esta validación, ya que los puertos forman parte de la propia arquitectura de Microsoft y no son específicos de la implementación de Horizon Cloud on Microsoft Azure.
Cuando se utiliza True SSO en una implementación de Horizon Cloud on Microsoft Azure, Horizon Agent genera una CSR y la envía a la máquina virtual del administrador de pods activa de la implementación a través del canal de comunicación que ya existe entre esa máquina virtual del administrador de pods y esa instancia de Horizon Agent. La máquina virtual del administrador de pods retransmite la solicitud al servidor de inscripción a través de un canal TCP seguro cifrado con SSL (puerto 32111 o el puerto configurado por el cliente en la instalación del servidor de inscripción). El servidor de inscripción genera una solicitud de CMC, anexa la CSR y el nombre de usuario proporcionados por el administrador de pods, firma la CMC mediante el certificado del agente de inscripción y la envía a la entidad de certificación mediante el protocolo MS-DCOM (RPC).
Horizon Agent recibe el certificado y lo serializa como una credencial de inicio de sesión y lo envía al proceso de inicio de sesión de Windows. El componente LSASS de Windows recibe el certificado, lo valida (comprueba que sea válido y de confianza, y que la máquina local contiene la clave privada del certificado) y, a continuación, lo envía a un controlador de dominio (DC). El DC puede optar por comprobar la CRL según se especifica en el certificado de usuario.
Diagramas de redes visualmente enriquecidos
Para obtener una descripción detallada de las relaciones entre estos componentes, puertos y protocolos, consulte los diagramas de red y las descripciones de la zona tecnológica de VMware Digital Workspace en https://techzone.vmware.com/resource/vmware-horizon-cloud-service-microsoft-azure-network-ports-diagrams.
