Puede ejecutar estas pruebas para comprobar que estas dos áreas relacionadas con la red estén configuradas correctamente: que el DNS pueda resolver las direcciones internas y externas, y que los puertos salientes necesarios estén abiertos. Estas pruebas se ejecutan con la máquina virtual de prueba.

El pod se basa en DNS para resolver las direcciones internas y externas. Las dos primeras pruebas aquí comprueban si el DNS configurado en el entorno de red puede resolver los FQDN conocidos para las direcciones internas y externas.

Importante: Si se dirige todo el tráfico saliente a través de la red local y solo se permite que pase el tráfico autenticado, pero no se proporcionaron valores para usar un proxy en el asistente de implementación de pods, a pesar de que todas las pruebas manuales se realicen correctamente, el tráfico enviado por un origen sin autenticar, el Jump Box, presentará un error. El síntoma de esta situación es que la implementación del pod se bloquea en estado pendiente. Si se encuentra en esta situación, debe eliminar el pod de la página Introducción, volver a ejecutar el asistente de implementación de pods y especificar la información del proxy requerida.

Requisitos previos

Antes de ejecutar estas pruebas, compruebe que haya creado una máquina virtual de prueba en la suscripción a Microsoft Azure y que esta tenga una conexión SSH, como se describe en Crear la máquina virtual de prueba en la suscripción a Microsoft Azure y Utilizar SSH para conectarse a la máquina virtual de prueba.

Obtenga las direcciones IP y los nombres de dominio completos (FQDN) para los servidores que son internos de la red que se espera que sean accesibles desde la VNet, como el controlador de dominio de Active Directory. Esta información se utilizará en la prueba de verificación de DNS.

Procedimiento

  1. Compruebe que el DNS esté funcionando en su entorno para resolver los FQDN internos utilizando el comando dlg para consultar un nombre de dominio conocido que sea interno de la VNet en Microsoft Azure.
    En la ventana de la conexión SSH, emita el comando dig para consultar el nombre de dominio de un servidor que sabe que sea interno de la red, como el controlador de dominio de Active Directory.
    dig internal-domain-name
    Donde internal-domain-name es el nombre de dominio totalmente cualificado de un servidor que sabe es interno de la red.

    dig (Domain Information Groper) es una herramienta de línea de comandos para solucionar problemas de red. Al ejecutar este comando con un nombre de host interno, el resultado verifica que la configuración del DNS pueda resolver las direcciones internas correctamente. Si la configuración del DNS puede resolver el internal-domain-name que se utiliza en el comando, la salida del comando devolverá la dirección IP correcta asociada con ese nombre de dominio.

    Por ejemplo, supongamos que la VNet está configurada con un servidor interno de Active Directory cuyo controlador de dominio de Active Directory tiene una entrada DNS de skylo.local y una dirección IP de 192.168.0.15. Al ejecutar dig skylo.local se debería comprobar si la configuración de DNS de la VNet puede resolver ese nombre de servidor interno skylo.local:
    testvmadmin@HCS-testingVM:~$ dig skylo.local
    
    ; <<>> DiG 9.10.3-P4-Ubuntu <<>> skylo.local
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64899
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4000
    ;; QUESTION SECTION:
    ;skylo.local.                   IN      A
    
    ;; ANSWER SECTION: skylo.local. 600 IN A 192.168.0.15
    
    ;; Query time: 1 msec
    ;; SERVER: 192.168.0.15#53(192.168.0.15)
    ;; WHEN: Mon Mar 26 20:58:01 UTC 2018
    ;; MSG SIZE  rcvd: 56
    
    testvmadmin@HCS-testingVM:~$
    La prueba es correcta cuando ANSWER SECTION indica que el nombre de host proporcionado se resolvió a la dirección IP que se espera para ese nombre de host.
    Nota: En ocasiones, el DNS no es totalmente fiable y algunas solicitudes resuelven correctamente mientras que otras no. Si la emisión del comando produce un error la primera vez, ejecútelo de diez a veinte iteraciones y vea si obtiene respuestas confiables cada vez.
  2. Compruebe que el DNS esté funcionando en su entorno para resolver nombres de dominio completos externos utilizando el comando dlg para consultar un nombre de dominio externo conocido.
    En la ventana de la conexión SSH, emita el comando dig para consultar un nombre de dominio externo estándar del sector, como vmware.com o microsoft.com.
    dig external-domain-name
    Donde external-domain-name es un nombre de dominio totalmente cualificado que está fuera de la VNet. Por ejemplo, al ejecutar dig vmware.com se comprueba si la configuración de DNS de la VNet pudo resolver ese nombre externo:
    testvmadmin@HCS-testingVM:~$ dig vmware.com
    
    ; <<>> DiG 9.10.3-P4-Ubuntu <<>> vmware.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38655
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4000
    ;; QUESTION SECTION:
    ;vmware.com.                    IN      A
    
    ;; ANSWER SECTION: vmware.com. 150 IN A 107.154.105.19 vmware.com. 150 IN A 107.154.106.19
    
    ;; Query time: 28 msec
    ;; SERVER: 192.168.0.15#53(192.168.0.15)
    ;; WHEN: Mon Mar 26 21:14:29 UTC 2018
    ;; MSG SIZE  rcvd: 71
    
    testvmadmin@HCS-testingVM:~
    En el ejemplo anterior, ANSWER SECTION indica que el nombre de dominio externo vmware.com se resolvió correctamente a dos direcciones IP.
    Nota: Puede repetir esta prueba usando diversos nombres de dominio externo, como azure.com o microsoft.com, para comprobar que el DNS pueda resolver diferentes nombres externos.
    Si las pruebas de DNS no funcionan, compruebe las configuraciones de red y su servidor DNS. Compruebe que haya agregado su servidor DNS a la VNet.
    Importante: Si detecta que necesita agregar el servidor DNS a la VNet o tiene que cambiar la configuración del servidor DNS de la VNet, debe reiniciar todas las máquinas virtuales que estén conectadas a esa VNet para que estas incorporen el cambio. Si cambia la configuración del servidor DNS de la VNet y no reinicia todas las máquinas virtuales conectadas a esa VNet, los cambios no se propagarán correctamente en la VNet.
  3. Compruebe que los puertos de salida obligatorios estén disponibles mediante el comando netcat.
    Horizon Cloud requiere que algunos puertos salientes estén abiertos, para que el software del pod pueda descargarse de forma segura en su entorno de Microsoft Azure y para que el pod se pueda conectar con el plano de control de Horizon Cloud. Como se describe en Requisitos de DNS para un pod de Horizon Cloud en Microsoft Azure, los siguientes puertos TCP salientes deben estar abiertos en la subred de administración del pod: el puerto 80, 443 y 11371. Si ejecuta netcat, como se indica en el siguiente comando, puede verificar que esos puertos salientes estén abiertos.
    En la ventana de la conexión SSH, ejecute los siguientes comandos (uno por puerto).
    Nota: El siguiente comando para probar el puerto 11371 especifica packages.microsoft.com para probar la conexión, mientras que las otras dos líneas prueban la conexión saliente con el plano de control de Horizon Cloud.
    testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 80
    Connection to cloud.horizon.vmware.com 80 port [tcp/http] succeeded!
    testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 443
    Connection to cloud.horizon.vmware.com 443 port [tcp/https] succeeded!
    testvmadmin@HCS-testingVM:~$ netcat -v -w 3 packages.microsoft.com 11371
    Connection to packages.microsoft.com 11371 port [tcp/hkp] succeeded!
    Cuando un puerto está abierto correctamente, el comando netcat devuelve la línea succeeded! para su prueba.
    Si los comandos netcat devuelven errores, compruebe las conexiones de red de Microsoft Azure, los grupos de seguridad de red en su suscripción y cualquier servidor de seguridad que pueda tener instalado. Asegúrese de que la configuración de red cumpla los requisitos de DNS, puertos y protocolo que el pod necesita para la implementación, como se describe en Requisitos de DNS para un pod de Horizon Cloud en Microsoft Azure.

Resultados

Si las pruebas anteriores se realizan correctamente, podrá implementar correctamente el pod.

Nota: Si va a configurar funciones opcionales para su uso con el pod, como la autenticación en dos fases Radius o True SSO, es posible que se necesiten puertos adicionales para estos fines. Puede utilizar las técnicas de prueba de puertos de salida anteriores para comprobar que estos puertos están abiertos correctamente.

Qué hacer a continuación

Cuando haya completado la prueba, debe eliminar la máquina virtual de prueba y todos los artefactos relacionados, como su disco de máquina virtual, dirección IP, NIC, desde el entorno de Microsoft Azure. Lo ideal es que debería haber creado un grupo de recursos para la máquina virtual de prueba y simplemente elimine ese grupo de recursos para eliminar todos los artefactos de la máquina virtual. Siga los pasos descritos en Eliminar la máquina virtual de prueba después de completar las pruebas.

Importante: Si no elimina todos los artefactos de la máquina virtual de prueba del entorno de Microsoft Azure y conectó previamente dicha máquina a una de las subredes del pod, es posible que, si intenta eliminar este pod más adelante mediante la acción Eliminar correspondiente, el sistema no pueda quitarlo completamente del entorno de Horizon Cloud debido a esos artefactos conectados. De forma predeterminada, cuando se utiliza la acción Eliminar para eliminar un pod, Horizon Cloud elimina los grupos de recursos y las subredes que ha creado para el pod. Microsoft Azure impedirá la eliminación de subredes que aún están en uso. Si los artefactos de la máquina virtual de prueba están conectados a las subredes del pod, no se pueden eliminar esas subredes, y la eliminación del pod quedará incompleta. Para evitar esta situación, asegúrese de que se eliminen todos los artefactos de la máquina virtual de prueba después de que el pod se implemente correctamente.