Vous exécutez ces tests pour vérifier que ces deux zones liées au réseau sont configurées correctement : que le DNS peut résoudre les adresses internes et externes et que les ports sortants requis sont ouverts. Vous exécutez ces tests à l’aide de votre VM de test.

L'espace s’appuie sur DNS pour résoudre les adresses internes et externes. Les deux premiers tests ici vérifient si le serveur DNS configuré dans votre environnement réseau peut résoudre les noms de domaine complet connus pour les adresses internes et externes.

Important : Si vous acheminez tout le trafic via votre réseau sur site et n'autorisez que l'acheminement du trafic authentifié, mais que vous ne spécifiez pas les valeurs pour l'utilisation d'un proxy dans l'assistant de déploiement de l'espace, le trafic envoyé par une source non authentifiée (la VM JumpBox) échouera même en cas de réussite de ces tests manuels. Le symptôme de cette situation est que le déploiement de l'espace est bloqué dans l'état En attente. Si vous êtes dans cette situation, vous devez supprimer l'espace de la page Démarrage, réexécuter l'assistant de déploiement de l'espace et spécifier les informations de proxy requises.

Conditions préalables

Avant d’exécuter ces tests, vérifiez que vous avez créé une VM de test dans votre abonnement Microsoft Azure et que vous disposez d’une connexion SSH, comme décrit dans les sections Créer la machine virtuelle de test dans votre abonnement Microsoft Azure et Utiliser SSH pour se connecter à la machine virtuelle de test.

Obtenez les adresses IP et les noms de domaine complet des serveurs internes à votre réseau que vous prévoyez de rendre accessibles depuis le réseau virtuel, tels que le contrôleur de domaine Active Directory. Vous utiliserez ces informations dans le test de vérification de DNS.

Procédure

  1. Vérifiez que DNS fonctionne dans votre environnement afin de résoudre les noms de domaine complet internes à l’aide de la commande dlg pour interroger un nom de domaine connu interne à votre réseau virtuel dans Microsoft Azure.
    Dans la fenêtre de connexion SSH, écrivez la commande dig pour interroger le nom de domaine d’un serveur que vous savez être interne à votre réseau, tel que le contrôleur de domaine Active Directory.
    dig internal-domain-name
    internal-domain-name est le nom de domaine complet d’un serveur que vous savez être interne à votre réseau.

    dig (Domain Information Groper) est un outil de ligne de commande pour le dépannage du réseau. En exécutant cette commande à l’aide d’un nom d’hôte interne, le résultat vérifie que votre configuration DNS peut résoudre les adresses internes correctement. Si votre configuration DNS peut résoudre internal-domain-name utilisé dans la commande, le résultat de la commande renvoie la bonne adresse IP associée à ce nom de domaine.

    Par exemple, supposons que le réseau virtuel est configuré avec un serveur Active Directory interne disposant d’un contrôleur de domaine Active Directory avec l’entrée DNS skylo.local et l’adresse IP 192.168.0.15. L’envoi de la commande dig skylo.local vérifie si la configuration DNS du réseau virtuel peut résoudre ce nom de serveur skylo.local interne :
    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:~$
    Le test est réussi lorsque la section ANSWER SECTION indique que le nom d’hôte fourni a été résolu en l’adresse IP que vous prévoyez pour ce nom d’hôte.
    Note : Il arrive que DNS ne soit pas fiable à 100 %, et certaines demandes sont résolues alors que d’autres échouent. Si la commande échoue la première fois, exécutez la commande dix à vingt fois et voyez si vous obtenez des réponses fiables à chaque fois.
  2. Vérifiez que DNS fonctionne dans votre environnement afin de résoudre les noms de domaine complet externes à l’aide de la commande dlg pour interroger un nom de domaine externe connu.
    Dans la fenêtre de connexion SSH, écrivez la commande dig pour interroger un nom de domaine standard externe, par exemple vmware.com ou microsoft.com.
    dig external-domain-name
    external-domain-name est un nom de domaine complet externe à votre réseau virtuel. Par exemple, l’envoi de la commande dig vmware.com vérifie si la configuration DNS du réseau virtuel peut résoudre ce nom externe :
    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:~
    Dans l’exemple ci-dessus, la section ANSWER SECTION indique que le nom de domaine externe vmware.com a été correctement résolu en deux adresses IP.
    Note : Vous pouvez répéter ce test avec différents noms de domaine externe, comme azure.com ou microsoft.com, pour vérifier que votre DNS peut résoudre différents noms externes.
    Si les tests de DNS ne fonctionnent pas, vérifiez la configuration de votre réseau et votre serveur DNS. Vérifiez que vous avez ajouté votre serveur DNS à votre réseau virtuel.
    Important : Si vous constatez que vous devez ajouter votre serveur DNS à votre réseau virtuel ou que vous devez modifier la configuration du serveur DNS du réseau virtuel, vous devez redémarrer toutes les machines virtuelles qui sont connectées à ce réseau virtuel pour qu’elles obtiennent la modification. Si vous modifiez la configuration du serveur DNS du réseau virtuel et que vous ne redémarrez pas toutes les machines virtuelles connectées à ce réseau virtuel, les modifications ne se propagent pas correctement sur le réseau virtuel.
  3. Vérifiez que les ports sortants requis sont disponibles à l’aide de la commande netcat.
    Horizon Cloud requiert que certains ports sortants soient ouverts pour que le logiciel de l'espace puisse être téléchargé en toute sécurité dans votre environnement Microsoft Azure et pour que l'espace puisse se reconnecter au plan de contrôle d' Horizon Cloud. Comme décrit dans Conditions requises de DNS pour un espace Horizon Cloud dans Microsoft Azure, les ports TCP sortants suivants doivent être ouverts depuis le sous-réseau de gestion de l'espace : ports 80, 443 et 11371. En exécutant la commande netcat comme indiqué dans la commande ci-dessous, vous pouvez vérifier que ces ports sortants sont ouverts selon les besoins.
    Dans la fenêtre de connexion SSH, exécutez les commandes suivantes (une par port).
    Note : La commande ci-dessous pour tester le port 11371 spécifie packages.microsoft.com pour tester cette connexion, alors que les deux autres lignes testent la connexion sortante vers le plan de contrôle 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!
    Lorsqu’un port est ouvert correctement, la commande netcat renvoie la ligne succeeded! pour son test.
    Si les commandes netcat renvoient des échecs, vérifiez vos connexions au réseau Microsoft Azure, vos groupes de sécurité réseau dans votre abonnement et les pare-feu que vous pouvez avoir en place. Assurez-vous que votre configuration réseau répond aux conditions requises de DNS, ports et protocoles que l'espace requiert pour le déploiement, comme décrit dans Conditions requises de DNS pour un espace Horizon Cloud dans Microsoft Azure.

Résultats

Si les tests ci-dessus réussissent, vous pourrez déployer correctement votre espace.

Note : Si vous allez configurer des fonctionnalités facultatives pour une utilisation avec votre espace, telles que l’authentification à deux facteurs Radius ou l’authentification unique réelle, des ports supplémentaires peuvent être nécessaires à ces fins. Vous pouvez utiliser les techniques de test des ports sortants ci-dessus pour vérifier que ces ports sont ouverts.

Que faire ensuite

Lorsque vous aurez terminé le test, vous devez supprimer la VM de test et tous ses artefacts associés, tels que son disque de machine virtuelle, l’adresse IP et la carte réseau de votre environnement Microsoft Azure. De préférence, vous avez créé un groupe de ressources pour la VM de test et vous le supprimez simplement pour supprimer tous les artefacts de la machine virtuelle. Effectuez la procédure décrite dans la section Supprimer la VM de test une fois les tests terminés.

Important : Si vous ne supprimez pas tous les artefacts de la machine virtuelle de test de votre environnement Microsoft Azure et si vous avez connecté la machine virtuelle à l'un des sous-réseaux de l'espace, il est possible que le système ne puisse pas supprimer entièrement l'espace si vous tentez de le supprimer ultérieurement de votre environnement Horizon Cloud à l'aide de l'action Supprimer, en raison de ces artefacts connectés restants. Lorsque vous utilisez, par défaut, l'action Supprimer pour supprimer un espace, Horizon Cloud supprime ces groupes de ressources et sous-réseaux qu'il a créés pour l'espace. Microsoft Azure empêchera la suppression des sous-réseaux qui sont en cours d’utilisation. Si les artefacts de la machine virtuelle de test sont connectés aux sous-réseaux de l'espace, vous ne pouvez pas supprimer ceux-ci et la suppression de l'espace sera incomplète. Pour éviter cette situation, assurez-vous que tous les artefacts de la machine virtuelle de test sont supprimés après avoir déployé votre espace.