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
Como se describe en el artículo 93762 de la base de conocimientos de VMware, la función Horizon Infrastructure Monitoring quedó obsoleta. A partir de octubre de 2023, la información de puertos y protocolos relacionada con esa función obsoleta se eliminó 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.
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 Arrendatarios de first-gen: 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 |
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
- Características relacionadas con Cloud Monitoring Service (CMS)
- Especialmente para implementación de pods y actualizaciones de pods
-
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.
- 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.
- Cuando planea utilizar funciones de App Volumes on Azure
- El implementador de pods aprovisiona una cuenta de almacenamiento de Azure para que la usen las funciones de App Volumes on Azure del pod, en el grupo de recursos de los administradores de pods. Cuando se aprovisiona, Azure Cloud asigna un nombre de dominio completo (FQDN) a esa cuenta de almacenamiento que tiene el patrón *.file.core.windows.net, donde * es el nombre generado por Azure de la cuenta de almacenamiento. El servidor DNS debe poder resolver este FQDN para que App Volumes pueda acceder y montar los recursos compartidos de archivos subyacentes a esa cuenta de almacenamiento y ofrecer la funcionalidad de App Volumes. 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. 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.
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.
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) |
| Administración |
|
443 | TCP | No | El endpoint *.blob.core.windows.net se utiliza para el acceso mediante programación a Azure Blob Storage. Este endpoint corresponde a Microsoft Azure, se encuentra en el entorno de nube de Microsoft Azure y la comunicación al endpoint se realiza directamente en el espacio de nube de Microsoft Azure. El endpoint sauron-jp.horizon.vmware.com permite que el sistema de supervisión de VMware detecte eventos de seguridad en las instancias administradas por VMware. Habilita la responsabilidad de administración de VMware de las instancias implementadas, lo cual requiere la supervisión obligatoria del sistema de VMware de dichas instancias. |
| 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. |
| Arrendatario | *.file.core.windows.net | 445 | TCP | No Este endpoint es el servicio de almacenamiento de archivos de Microsoft Azure dentro del entorno de nube de Microsoft Azure. La conexión va directa dentro del espacio de nube de Microsoft Azure. |
Se utiliza para la funcionalidad de App Volumes on Azure. Se utiliza para el acceso mediante programación al recurso compartido de archivos SMB en el grupo de recursos del administrador de pods para acceder a los AppStacks de App Volumes que se almacenan en ese recurso compartido de archivos SMB. |
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 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 el puerto 1514 (TCP y UDP) y en el puerto 1515 (TCP y UDP).
- 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 UDP) y 1515 (TCP y UDP)
- 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.
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.
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.
