Para utilizar correctamente las implementaciones de Horizon Cloud on Microsoft Azure - first-gen desde el día 0, debe asegurarse de que los nombres de host que se describen en esta página de documentación puedan resolverse y resulten accesibles desde las subredes de arrendatario y administración con los protocolos y puertos específicos identificados en esta página.
Acerca de esta página
Una indicación del entorno que se tiene (next-gen o first-gen) es el patrón que aparece en el campo de URL del navegador después de iniciar sesión en el entorno y ver la etiqueta Horizon Universal Console. En entornos de next-gen, la dirección URL de la consola contiene un fragmento como /hcsadmin/. La URL de la consola de first-gen muestra una sección diferente (/horizonadmin/).
Breve introducción
El motivo por el cual esta página incluye la referencia a "nombre DNS" junto a la referencia a "nombre de host" es que DNS es un estándar de red para resolver nombres de host para que se produzca la comunicación entre esos nombres de host.
Un nombre de host es un nombre único asignado a una instancia de máquina en una red determinada . Como se describe en el sector de redes de software, los sistemas utilizan DNS para resolver los nombres de host en sus direcciones IP para fines de comunicación.
El proceso de implementación de pods requiere que las instancias implementadas tengan comunicación de red a través de la red virtual (VNet) seleccionada de la implementación con los nombres de host (nombres DNS) que se describen en esta página.
Cuando se implementa correctamente el pod en la suscripción, hay varias operaciones de servicio cotidianas que requieren acceso a la red para nombres de host específicos. El proceso de actualización del pod también requiere este tipo de acceso para actualizar el software del pod cuando se detecta nuevo software disponible.
En esta página se describen los requisitos. A veces, esta página utiliza las referencias a "nombre DNS" y "nombre de host" indistintamente.
Algunos puntos clave predominantes
- Acerca de estos nombres DNS requeridos
-
La implementación y la ejecución de un pod de
Horizon Cloud requiere acceso a la red para direcciones DNS específicas a través de las VNet de Microsoft Azure. Para que el implementador de pods funcione, debe configurar los firewalls para permitir el acceso a la red para esas direcciones. El propósito de cada dirección DNS se indica en las siguientes tablas.
Además de permitir la comunicación de red con esas direcciones DNS, la configuración de DNS en su VNet debe resolver los nombres, como se describe en este artículo.
Cuando selecciona la opción para implementar la puerta de enlace externa en su propia VNet independiente de la VNet del administrador de pods, esa subred de la VNet debe cumplir con los mismos requisitos de DNS que la subred de administración de la VNet del administrador de pods.
Además del implementador de pods y sus flujos de trabajo, varias funciones de servicio requieren acceso a direcciones DNS específicas para que esas funciones funcionen de extremo a extremo. Esos nombres DNS también se proporcionan en las siguientes tablas.
Algunos de estos nombres DNS incluyen un elemento regional.
La activación de Supervisión de la infraestructura de Horizon en un pod crea automáticamente una instancia de Dispositivo virtual de Horizon Edge en la VNet y la subred de administración del administrador de pods. Dispositivo virtual de Horizon Edge tiene sus propios requisitos de nombre DNS. Por lo tanto, antes de activar Supervisión de la infraestructura de Horizon en un pod, asegúrese de cumplir los requisitos de DNS de Dispositivo virtual de Horizon Edge como se indica en las siguientes tablas.
Como se describe en Integración estrecha en el ecosistema de VMware, puede utilizar Horizon Cloud con otros productos disponibles del amplio ecosistema de VMware. Esos otros productos pueden tener requisitos de DNS adicionales. Estos requisitos de DNS adicionales no se detallan aquí. Para saber cuáles son, consulte la documentación establecida para los productos específicos que se integrarán con el pod.
- Acerca de los puertos y protocolos después de implementar un pod para las operaciones relacionadas con el servicio en curso
- Después de que un pod se implementa correctamente, se necesitan protocolos y puertos específicos para las operaciones de Horizon Cloud en curso. Consulte los detalles en Pod de Horizon Cloud: requisitos de puertos y protocolos.
Arrendatarios de first-gen - Nombres DNS del plano de control regional
El correo electrónico de bienvenida al servicio de Horizon indicará en qué instancia del plano de control regional se creó la cuenta de arrendatario. Debido a un problema conocido que se producía al enviar el correo electrónico de bienvenida, es posible que, en el correo electrónico que reciba, se indiquen los nombres de cadena del sistema que se utilizan para las regiones en lugar de los nombres descriptivos. Si ve un nombre de cadena del sistema en el correo electrónico de bienvenida, puede utilizar la siguiente tabla para relacionar lo que se muestra en el correo electrónico con los nombres DNS del plano de control regional.
| El correo electrónico de bienvenida dice | Nombre DNS regional |
|---|---|
USA |
cloud.horizon.vmware.com |
EU_CENTRAL_1 o Europe |
cloud-eu-central-1.horizon.vmware.com |
AP_SOUTHEAST_2 o Australia |
cloud-ap-southeast-2.horizon.vmware.com |
PROD1_NORTHCENTRALUS2_CP1 o USA-2 |
cloud-us-2.horizon.vmware.com |
PROD1_NORTHEUROPE_CP1 o Europe-2 |
cloud-eu-2.horizon.vmware.com |
PROD1_AUSTRALIAEAST_CP1 o Australia-2 |
cloud-ap-2.horizon.vmware.com |
Japan |
cloud-jp.horizon.vmware.com |
UK |
cloud-uk.horizon.vmware.com |
Europe-3 |
cloud-de.horizon.vmware.com |
Para las direcciones DNS regionales que aparecen en las siguientes tablas de Dispositivo virtual de Horizon Edge, estas direcciones usan las mismas regiones que los nombres DNS del plano de control regional.
Nombres de host, requisitos de DNS para el proceso de implementación del pod predominante, la activación de varias funciones de servicio y las operaciones en curso
Para utilizar correctamente las funciones del servicio de extremo a extremo, debe asegurarse de que los nombres de host que se indican a continuación puedan resolverse y resulten accesibles desde las subredes de arrendatario y administración con los protocolos y puertos específicos que se establecen en las siguientes tablas. Estas son algunas de las funciones de servicio que requieren la capacidad de acceder a nombres de host específicos:
- El implementador de pods que implementa automáticamente un pod basado en el administrador de pods en la suscripción de Microsoft Azure
- La función de actualización de pods, que actualiza el software del pod a una versión de software más reciente
- El proceso de importación de imagen que utiliza el asistente Importar desde Marketplace
- Las funciones relacionadas con el agente, como la actualización automatizada de agentes (AAU)
- Universal Broker
- Supervisión de la infraestructura de Horizon y sus Dispositivo virtual de Horizon Edge
- Características relacionadas con Cloud Management Service (CMS)
- Sobre todo para la implementación de pods, las actualizaciones de pods y al activar Supervisión de la infraestructura de Horizon en un pod
-
Debe asegurarse de que los nombres de host que se indican a continuación puedan resolverse y resulten accesibles desde las subredes de arrendatario y administración con los protocolos y puertos específicos que se establecen en las siguientes tablas. Los dispositivos utilizados en estos flujos de trabajo utilizan puertos salientes específicos para descargar de forma segura el software que estos procesos necesitan en el entorno de Microsoft Azure. Esos nombres DNS también se utilizan para que los dispositivos adecuados relacionados con el flujo de trabajo puedan comunicarse con el plano de control de la nube.
Para las nuevas implementaciones del pod, debe configurar el firewall de red, las reglas de grupo de seguridad de red (NSG) y los servidores proxy de modo que los dispositivos clave relacionados con la implementación tengan la capacidad de ponerse en contacto con las direcciones DNS en los puertos que requieran. De lo contrario, se producirá un error en el proceso de implementación del pod.
Al activar Supervisión de la infraestructura de Horizon en un pod, se crearán instancias de Dispositivo virtual de Horizon Edge en la misma VNet y la misma subred de administración que los dispositivos del administrador de pods del pod. Debe asegurarse de que la configuración del firewall de red, las reglas de NSG y los servidores proxy permita al Dispositivo virtual de Horizon Edge conectar con los nombres de host en los puertos que precise. De lo contrario, se producirá un error en la implementación de ese dispositivo.
Nota: Actualmente no se puede usar Supervisión de la infraestructura de Horizon con pods de Horizon Cloud on Microsoft Azure en regiones de Azure China, ya que en este momento no se permite el acceso al sitio requerido de packages.cloud.google.com desde estas regiones.Actualmente no se puede usar Supervisión de la infraestructura de Horizon con pods en los que el proxy está configurado. El escenario de uso de un proxy con el Dispositivo virtual de Horizon Edge de esta función tiene carácter limitado.
- Cuando se utiliza la función para implementar la puerta de enlace externa en su propia VNet
- La subred de administración de esa VNet debe cumplir los mismos requisitos de DNS que se indican en la siguiente tabla para la subred de administración en la VNet del pod. La subred de DMZ y la subred de back-end de la VNet de la puerta de enlace externa no tienen requisitos de DNS específicos.
- Cuando se implementa el pod con una puerta de enlace externa, una puerta de enlace interna o ambas
- Debe cargar un certificado que el implementador de pods configure en esas configuraciones de puerta de enlace. Si el certificado o los certificados que proporciona para este propósito usan ajustes de CRL (Lista de revocación de certificados) o OCSP (Protocolo de estado de certificados en línea) que hacen referencia a nombres de DNS específicos, debe asegurarse de que el acceso a Internet saliente en la red virtual se pueda resolver y que se pueda acceder a ellos. Durante la configuración del certificado proporcionado en la configuración de la puerta de enlace de Unified Access Gateway, el software de Unified Access Gateway accederá a esos nombres DNS para comprobar el estado de revocación del certificado. Si no se puede acceder a esos nombres DNS, se producirá un error en la implementación del pod durante la fase de Conexión. Estos nombres dependen en gran medida de la entidad de certificación que se utilizó para obtener los certificados y, por lo tanto, no quedan bajo el control de VMware.
Requisitos de DNS para la nueva implementación de pods, las actualizaciones de pods y las operaciones de servicio que se aplican en todo el arrendatario
En la siguiente tabla se describen los requisitos de DNS para una nueva implementación de pods, las actualizaciones de pods y las operaciones de servicio que se aplican en todo el arrendatario.
Para la activación de Supervisión de la infraestructura de Horizon y los requisitos de DNS de Dispositivo virtual de Horizon Edge, consulte la siguiente sección. Dado que la función Supervisión de la infraestructura de Horizon es opcional y se activa por pod, sus requisitos de nombre de host merecen su propia tabla descriptiva.
A partir de principios de 2021, como resultado de una actualización a las instancias de plano de control regional del servicio, ya no se requiere el nombre DNS de d1mes20qfad06k.cloudfront.net para ninguna de las instancias de plano de control regional. Todas las instancias de plano de control regional ahora utilizan el nombre DNS de hydra-softwarelib-cdn.azureedge.net. El contenido de la siguiente tabla está conforme con esa realidad actual.
| Origen de subred | Destino (nombre DNS) | Puerto | Protocolo | Tráfico de proxy (si está configurado en la implementación) | Propósito |
|---|---|---|---|---|---|
| Administración | Uno de los siguientes nombres, según la instancia de plano de control que esté especificada en su cuenta de arrendatario de Horizon Cloud. La instancia regional se establece cuando se crea la cuenta, tal y como se describe en Implementaciones e incorporación a Horizon Cloud para pods de Microsoft Azure y Horizon.
|
443 | TCP | Sí | Instancia de plano de control regional
|
| Administración | softwareupdate.vmware.com | 443 | TCP | Sí | Servidor de paquete de software de VMware. Se utiliza para descargar actualizaciones del software relacionado con el agente que se usa en las operaciones relacionadas con la imagen del sistema. |
| Administración | hydra-softwarelib-cdn.azureedge.net | 443 | TCP | No El administrador de pods y los manifiestos binarios de Unified Access Gateway se almacenan en esta ubicación y se sirven desde aquí. Estos manifiestos se utilizan únicamente durante las implementaciones y actualizaciones de pods y puertas de enlace. La conexión a este endpoint está configurada como conexión directa (y no a través de un proxy). |
Servidor de distribución de contenido de Horizon Cloud. En la subred de administración, el servicio utiliza este sitio para descargar los archivos binarios necesarios que utiliza la infraestructura del pod. |
| Administración | packages.microsoft.com | 443 y 11371 | TCP | No Este sitio se encuentra fuera de la aplicación y el servicio. Por lo tanto. la conexión no utiliza el proxy configurado. Este endpoint corresponde a Microsoft Azure, se encuentra en el entorno de nube de este servicio y la conexión se realiza directamente en su espacio de nube. |
Servidor de paquete de software Microsoft. Se utiliza para descargar de forma segura el software de la interfaz de línea de comandos (CLI) de Microsoft Azure. |
| Administración | azure.archive.ubuntu.com | 80 | TCP | No Este sitio se encuentra fuera de la aplicación y el servicio. Por lo tanto. la conexión no utiliza el proxy configurado. Este endpoint corresponde a Microsoft Azure, se encuentra en el entorno de nube de este servicio y la conexión se realiza directamente en su espacio de nube. |
Servidor de paquete de software de Ubuntu. Utilizado por máquinas virtuales basadas en Linux relacionadas con el pod para las actualizaciones del sistema operativo Ubuntu. |
| Administración | api.snapcraft.io | 443 | TCP | No Este endpoint se encuentra fuera de la aplicación y el servicio. La conexión no utiliza el proxy configurado. |
Servidor de paquete de software de Ubuntu. El administrador de pods y las instancias de Unified Access Gateway ejecutan sistemas operativos Ubuntu. que están configurados para obtener sus propias actualizaciones desde este sitio de Ubuntu. |
| Administración | archive.ubuntu.com | 80 | TCP | No Este endpoint se encuentra fuera de la aplicación y el servicio. La conexión no utiliza el proxy configurado. |
Servidor de paquete de software de Ubuntu. El administrador de pods y las instancias de Unified Access Gateway ejecutan sistemas operativos Ubuntu. que están configurados para obtener sus propias actualizaciones desde este sitio de Ubuntu. |
| Administración | changelogs.ubuntu.com | 80 | TCP | No Este sitio se encuentra fuera de la aplicación y el servicio. Por lo tanto. la conexión no utiliza el proxy configurado. |
Servidor de paquete de software de Ubuntu. El administrador de pods y las instancias de Unified Access Gateway ejecutan sistemas operativos Ubuntu. Dichos sistemas están configurados para realizar un seguimiento de sus propias actualizaciones a través de este sitio de Ubuntu. |
| Administración | security.ubuntu.com | 80 | TCP | No Este endpoint se encuentra fuera de la aplicación y el servicio. La conexión no utiliza el proxy configurado. |
Servidor de paquete de software de Ubuntu. El administrador de pods y las instancias de Unified Access Gateway ejecutan sistemas operativos Ubuntu. Dichos sistemas están configurados para realizar sus propias actualizaciones de seguridad a través de este sitio de Ubuntu. |
| Administración | esm.ubuntu.com | 80 y 443 | TCP | No Este endpoint se encuentra fuera de la aplicación y el servicio. La conexión no utiliza el proxy configurado. |
Servidor de paquete de software de Ubuntu. El administrador de pods y las instancias de Unified Access Gateway ejecutan sistemas operativos Ubuntu. Dichos sistemas están configurados para realizar un seguimiento de las actualizaciones de seguridad de vulnerabilidades y exposiciones comunes (Common Vulnerabilities and Exposures, CVE) altas y críticas en su infraestructura de escalado horizontal y sistema operativo base propios a través de este sitio de Ubuntu. |
| Administración | Una de las siguientes opciones, en función de la nube de Microsoft Azure en la que va a implementar el pod:
|
443 | TCP | Sí | Esta dirección web la suelen utilizar las aplicaciones para autenticarse en los servicios de Microsoft Azure. Para algunas descripciones de la documentación de Microsoft Azure, consulte Flujo de código de autorización de OAuth 2.0, Azure Active Directory 2.0 y el protocolo de OpenID Connect y Nubes nacionales. En el tema Nubes nacionales, se describen los diferentes endpoints de autenticación de Azure AD para cada nube nacional de Microsoft Azure. |
| Administración | Una de las siguientes opciones, en función de la nube de Microsoft Azure en la que va a implementar el pod:
|
443 | TCP | Sí | Se utiliza para las solicitudes de API del pod a los endpoints del administrador de recursos de Microsoft Azure para usar los servicios de dicho administrador. El administrador de recursos de Microsoft Azure proporciona una capa de administración coherente para llevar a cabo tareas a través de Azure PowerShell, Azure CLI, el portal de Azure, la REST API y los SDK de cliente. |
| Administración | Una de las siguientes opciones, en función de la nube de Microsoft Azure en la que va a implementar el pod:
|
443 | TCP | Sí | El acceso a la API de gráfico de Azure Active Directory (Azure AD), que se utiliza para el acceso programático del pod a Azure Active Directory (Azure AD) a través de endpoints de la REST API de OData. |
| Administración | Si el firewall o el NSG admiten el uso de etiquetas de servicio, una de las siguientes opciones:
Si el firewall o el grupo de seguridad de red (NSG) no admiten el uso de etiquetas de servicio, puede utilizar el nombre de host de la base de datos. Este nombre sigue el patrón *.postgres.database.azure.com. |
5432 | TCP | No Este endpoint es el servicio de base de datos de Microsoft Azure PostgreSQL en el entorno de nube de Microsoft Azure. La conexión va directa dentro del espacio de nube de Microsoft Azure. |
Se utiliza para la comunicación del pod con el servicio de base de datos de Microsoft Azure PostgreSQL que está configurado para esta implementación de Horizon Cloud on Microsoft Azure. Para obtener información sobre las etiquetas de servicio en los grupos de seguridad, consulte el tema Etiquetas de servicio en la documentación de Microsoft Azure. |
| Administración | Uno de los siguientes nombres, según la instancia de plano de control que esté especificada en su cuenta de arrendatario de Horizon Cloud. La instancia regional se establece cuando se crea la cuenta, tal y como se describe en Implementaciones e incorporación a Horizon Cloud para pods de Microsoft Azure y Horizon.
|
443 | TCP | Sí | Instancia regional del servicio del Universal Broker.
|
| Administración | Según el plano de control regional que se aplica a la cuenta de Horizon Cloud:
|
443 | TCP | Sí | Cloud Monitoring Service (CMS) |
| Arrendatario | hydra-softwarelib-cdn.azureedge.net | 443 | TCP | No | Servidor de distribución de contenido de Horizon Cloud. En la subred del arrendatario, este sitio lo utilizan varios procesos del sistema relacionados con las imágenes, incluidos los procesos implicados en el flujo de trabajo de emparejamiento del agente y el flujo de trabajo automatizado de Importar imagen - Catálogo de soluciones del sistema. |
| Arrendatario | scapi.vmware.com | 443 | TCP | No | VMware Cloud Services, utilizado para el programa VMware Service Usage Data Program (SUDP). Saliente de la subred del arrendatario, Horizon Agent en las instancias de escritorio aprovisionadas por el pod y las instancias del servidor de granja envía información de configuración relacionada con el agente. |
Requisito obligatorio de supervisión del sistema de VMware: monitor.horizon.vmware.com
El requisito obligatorio descrito en esta sección permite que el sistema de supervisión de VMware detecte eventos de seguridad en las instancias administradas por VMware que se implementan en subredes DMZ, administración y arrendatario de la implementación de Horizon Cloud on Microsoft Azure.
Para una implementación de Horizon Cloud on Microsoft Azure, VMware controla y administra estos recursos en la implementación: instancias del administrador de pods, instancias de Unified Access Gateway, archivos de Azure relacionados con App Volumes, servicio de Azure PostgreSQL, Dispositivo virtual de Horizon Edge y, cuando sea necesario para solucionar problemas, la instancia de Jump Box relacionada con el soporte.
La responsabilidad de administración de VMware de las instancias implementadas requiere la supervisión obligatoria del sistema de VMware de dichas instancias.
Esta supervisión obligatoria del sistema de VMware requiere que se cumplan los requisitos que se describen a continuación.
En términos de descripción de nivel general, las instancias de la implementación deben poder acceder al nombre de host saliente monitor.horizon.vmware.com en los puertos 1514/TCP y 1515/TCP.
- Requisito aplicable cuando la red tiene la inspección de SSL habilitada
- Cuando la inspección de SSL está habilitada en la red, debe especificar para excluir el host monitor.horizon.vmware.com.
- Requisito aplicable cuando la implementación tiene una configuración de puerta de enlace interna
-
Debe establecer la comunicación saliente para la configuración de puerta de enlace interna siguiendo todos los pasos y la información descritos en el
artículo 90145 de la base de conocimientos. Siga el artículo de la base de conocimientos como se describe, incluidas las notas finales al final del artículo de la base de conocimientos.
A continuación, si además utiliza un proxy o un firewall para la comunicación saliente, debe cumplir con el siguiente requisito que se aplica cuando se utiliza el proxy o el firewall para la comunicación saliente.
- Requisito aplicable cuando se utiliza un proxy o un firewall para la comunicación saliente
-
Cuando utilice un proxy o un firewall para la comunicación saliente, debe permitir la comunicación en el proxy o el firewall de la siguiente manera:
- Entornos comerciales: permitir el nombre de host monitor.horizon.vmware.com en 1514/TCP y 1515/TCP
- Entornos federales de EE. UU.: abra un caso con el servicio de soporte federal de VMware para solicitar el nombre de host del sistema de supervisión.
En estos entornos, debe permitir esa comunicación mencionada para estos orígenes:
- Administración: las instancias del administrador de pods
- DMZ: las instancias de Unified Access Gateway de la configuración de puerta de enlace externa
- Arrendatario: las instancias de Unified Access Gateway de la configuración de puerta de enlace interna
Nota: Cuando la implementación tiene una configuración de puerta de enlace interna, debe cumplir el requisito descrito anteriormente que se aplica a la configuración de puerta de enlace interna, según los pasos descritos en el artículo 90145 de la base de conocimientos.
First-gen - Requisitos de DNS de Supervisión de la infraestructura de Horizon
Al activar Supervisión de la infraestructura de Horizon en un pod en un arrendatario de Horizon Cloud - first-gen, se crearán instancias del Dispositivo virtual de Horizon Edge basado en Linux en la suscripción de Microsoft Azure. Dispositivo virtual de Horizon Edge se implementa en la suscripción del pod con una NIC en la subred de administración del pod, la misma subred de administración que los dispositivos del administrador de pods del pod. En la siguiente tabla, los propósitos enumerados se encuentran en el contexto de este dispositivo virtual.
uk en esta tabla, a diferencia de la tabla anterior. Como se indica en las notas de la versión, la función
Supervisión de la infraestructura de Horizon no está disponible en el plano de control de
uk.
Actualmente no se puede usar Supervisión de la infraestructura de Horizon con pods en los que el proxy está configurado. El escenario de uso de un proxy con el Dispositivo virtual de Horizon Edge de esta función tiene carácter limitado.
| Origen de subred | Destino (nombre DNS) | Puerto/protocolo | Propósito |
|---|---|---|---|
| Administración |
|
80 y 443/TCP | Servidor de paquete de software de Ubuntu. Utilizado por el dispositivo basado en Linux para las actualizaciones del sistema operativo Ubuntu. |
| Administración | esm.ubuntu.com | 80 y 443/TCP | Servidor de paquete de software de Ubuntu. Utilizado por el dispositivo basado en Linux para realizar un seguimiento de las actualizaciones de seguridad para CVE (vulnerabilidades y exposiciones comunes) altas y críticas en el sistema operativo base Ubuntu y la infraestructura de escalado horizontal. |
| Administración |
|
443 / TCP | Se utiliza para el acceso programático a Azure Blob Storage. Se utiliza para descargar las imágenes de Docker de las direcciones DNS que requiere el módulo del dispositivo. |
| Administración | *.azure-devices.net, o uno de los siguientes nombres específicos de la región, según el plano de control regional que se aplica a la cuenta de arrendatario: América del Norte:
Europa:
Australia:
Japón:
|
443 / TCP | Se utiliza para conectar el dispositivo al plano de control de Horizon Cloud, para descargar configuraciones para el módulo del dispositivo y para actualizar el estado de tiempo de ejecución del módulo del dispositivo. |
| Administración |
|
443 / TCP | Se utiliza para descargar los archivos binarios de Docker y de Kubernetes que el dispositivo necesita.
Importante: A partir del 17 de abril de 2023, se agregarán a esta lista las URL requeridas para descargar la configuración de WeaveNet que se debe utilizar en la red de Kubernetes del dispositivo:
Tenga en cuenta que el archivo YAML existe en una ruta específica que incluye un número de versión concreto que se determina en cada versión. En el momento de redactarse este documento (el 17 de abril de 2023), el fragmento de la versión en la ruta es v2.8.1 y se refleja en la columna Destino de esta tabla. Dado que pueden publicarse versiones actualizadas del archivo YAML en el futuro, es posible que la ruta de archivo específica se actualice a lo largo del tiempo, ya que el número de versión está codificado en la ruta de destino. |
| Administración | Según el plano de control regional que se aplica a la cuenta de arrendatario: América del Norte:
Europa:
Australia:
Japón:
|
443 / TCP | Se utiliza para enviar los datos de supervisión del pod recopilados por el dispositivo al plano de control de Horizon Cloud. |
| Administración | Si el firewall o el grupo de seguridad de red (NSG) admiten el uso de etiquetas de servicio, aplique la etiqueta de servicio AzureCloud de Azure. Si el firewall o el grupo de seguridad de red (NSG) no admiten el uso de etiquetas de servicio, utilice el nombre de host:
|
1514 y 1515/TCP | Utilizado para la supervisión del sistema |
Puertos y protocolos temporales de Jump Box si 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, según corresponda para cualquier situación de soporte.
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.
- El puerto 22 de Dispositivo virtual de Horizon Edge mediante SSH, en una implementación con Supervisión de la infraestructura de Horizon configurado.
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.
