Locataires de première génération - Dépannage si vous rencontrez des problèmes de déploiement de l'espace Horizon Cloud de première génération ou de liaison de domaine pour la première fois

Si la mise en réseau de votre environnement n'est pas configurée correctement pour une utilisation avec l'espace Horizon Cloud de première génération dans Microsoft Azure, le processus de création de l'espace peut rester bloqué dans l'état EN ATTENTE ou l'action post-déploiement de liaison de domaine à votre environnement Active Directory peut échouer. Les deux causes relatives au réseau les plus courantes sont l’échec d’ouverture des ports sortants requis et l’échec d’activation du DNS pour résoudre les adresses internes et externes. En suivant ces étapes de dépannage, vous pouvez exécuter des tests pour vérifier que les ports sortants requis sont ouverts et que le DNS peut résoudre les adresses internes et externes.

Important : Ces informations s'appliquent uniquement lorsque vous avez accès à un environnement de locataire de première génération dans le plan de contrôle de première génération. Comme décrit dans l' article 92424 de la base de connaissances, le plan de contrôle de première génération a atteint la fin de disponibilité (EOA). Pour plus d'informations, consultez cet article.

Les conditions requises générales de mise en réseau pour déployer un espace sont indiquées dans la liste de vérification des conditions préalables et décrites dans Locataires de première génération - Configurer les paramètres du serveur DNS requis par la topologie du réseau virtuel que vous utiliserez pour vos espaces Horizon Cloud dans Microsoft Azure et Locataires de première génération - Déploiements d'Horizon Cloud on Microsoft Azure - Conditions requises de résolution de noms d'hôtes, Noms DNS. Si la mise en réseau de votre environnement ne répond pas à ces conditions requises, vous rencontrez l’un de ces problèmes ou les deux :

Problèmes Causes communes

Problèmes	Causes communes
La page Démarrage indique que l'espace est dans l’état d’attente et il ne passe jamais dans l’état de connexion. En général, un espace est dans l’état d’attente pendant environ 10 minutes (sauf lors du déploiement d’un espace dans le cloud Microsoft Azure Chine, ce qui prend plus de temps). Même si l'espace s’est déployé correctement, lorsque vous tentez d’enregistrer votre annuaire Active Directory, l’étape de liaison de domaine échoue avec l’erreur `Unable to register Active Directory`	Les ports sortants requis ne sont pas ouverts ou sont bloqués par votre environnement de pare-feu. Si les ports sortants requis ne sont pas ouverts ou sont bloqués par un pare-feu, cela empêche le téléchargement sécurisé du logiciel de l'espace dans l’environnement de cloud Microsoft Azure et la reconnexion avec le plan de contrôle du cloud Horizon Cloud. Par conséquent, cela entraîne le problème d’état en attente. Le serveur DNS de réseau virtuel n’est pas correctement configuré pour pointer vers un serveur DNS valide qui peut résoudre des noms de machine internes et externes. Même si le serveur DNS de réseau virtuel pointe bien vers un serveur DNS, ce dernier ne peut pas résoudre les noms de machines internes et externes. Si aucune résolution DNS des noms de machines externes n’est fournie au réseau virtuel, le problème d’état en attente et le problème de liaison de domaine peuvent se produire. Par exemple, si le serveur DNS ne peut pas résoudre l'annuaire Active Directory sur les contrôleurs de domaine, l’étape de liaison de domaine échoue. Pour plus d’informations sur la configuration du DNS de réseau virtuel, reportez-vous à la section Locataires de première génération - Configurer les paramètres du serveur DNS requis par la topologie du réseau virtuel que vous utiliserez pour vos espaces Horizon Cloud dans Microsoft Azure.

La page Démarrage indique que l'espace est dans l’état d’attente et il ne passe jamais dans l’état de connexion. En général, un espace est dans l’état d’attente pendant environ 10 minutes (sauf lors du déploiement d’un espace dans le cloud Microsoft Azure Chine, ce qui prend plus de temps).
Même si l'espace s’est déployé correctement, lorsque vous tentez d’enregistrer votre annuaire Active Directory, l’étape de liaison de domaine échoue avec l’erreur Unable to register Active Directory

Les ports sortants requis ne sont pas ouverts ou sont bloqués par votre environnement de pare-feu. Si les ports sortants requis ne sont pas ouverts ou sont bloqués par un pare-feu, cela empêche le téléchargement sécurisé du logiciel de l'espace dans l’environnement de cloud Microsoft Azure et la reconnexion avec le plan de contrôle du cloud Horizon Cloud. Par conséquent, cela entraîne le problème d’état en attente.
Le serveur DNS de réseau virtuel n’est pas correctement configuré pour pointer vers un serveur DNS valide qui peut résoudre des noms de machine internes et externes.
Même si le serveur DNS de réseau virtuel pointe bien vers un serveur DNS, ce dernier ne peut pas résoudre les noms de machines internes et externes.

Si aucune résolution DNS des noms de machines externes n’est fournie au réseau virtuel, le problème d’état en attente et le problème de liaison de domaine peuvent se produire. Par exemple, si le serveur DNS ne peut pas résoudre l'annuaire Active Directory sur les contrôleurs de domaine, l’étape de liaison de domaine échoue. Pour plus d’informations sur la configuration du DNS de réseau virtuel, reportez-vous à la section Locataires de première génération - Configurer les paramètres du serveur DNS requis par la topologie du réseau virtuel que vous utiliserez pour vos espaces Horizon Cloud dans Microsoft Azure.

Pour exécuter des tests qui vérifient que la configuration DNS peut résoudre les noms internes et externes et vérifier que les ports sortants requis sont ouverts, vous déployez une petite machine virtuelle de test dans votre abonnement Microsoft Azure et vous utilisez cette machine virtuelle pour exécuter ces tests de mise en réseau. Voici les étapes générales de dépannage :

Créer une paire de clés SSH.
Créez la machine virtuelle de test dans votre abonnement Microsoft Azure.
Se connecter à cette machine virtuelle de test.
Exécuter les tests de mise en réseau.
Lorsque le test est terminé, supprimez la VM de test et tous les artefacts liés au test qui ont été créés dans votre environnement Microsoft Azure pour effectuer ce dépannage.

Note : Si vous ne supprimez pas les artefacts liés au test et que vous utilisez ultérieurement l'action Supprimer de la console pour supprimer l'espace, des résultats inattendus peuvent se produire. Lorsque vous supprimez un espace, le système contrôle les sous-réseaux de l'espace pour vérifier que tous les éléments connectés aux sous-réseaux appartiennent à l'espace lui-même en fonction de l'ID de l'espace. Si le système détermine que d'autres VM, disques de VM, adresses IP ou autres artefacts sont connectés aux sous-réseaux de l'espace, il ne peut pas supprimer correctement l'espace.

Pour plus d’informations sur l’exécution des tests de dépannage, reportez-vous aux sections suivantes.

Important : Même si tous ces tests manuels réussissent, si vous dirigez tout le trafic via votre réseau sur site et autorisez uniquement l'acheminement du trafic authentifié, mais que vous n'avez pas fourni de valeurs pour l'utilisation d'un proxy dans l'assistant de déploiement de l'espace, ce déploiement peut rester bloqué à l'état En attente. Si cette description correspond à votre cas, 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.

Dépannage du déploiement de l'espace Horizon Cloud - Créer une paire de clés SSH

Dans le cadre de ce dépannage, une VM Linux de test est déployée dans votre abonnement Microsoft Azure. Pour vous authentifier sur la VM Linux de test, une paire de clés SSH est requise. Vous pouvez créer la paire de clés sur le système que vous utilisez pour vous connecter par SSH à la VM de test. Cette étape est facultative si ce système contient déjà une paire de clés.

Pour créer cette paire de clés SSH, vous pouvez utiliser un système Microsoft Windows ou Linux. Les étapes pour les deux types de systèmes sont décrites ici. Sélectionnez les étapes les plus adaptées à votre cas.

Créer une paire de clés SSH sur un système Microsoft Windows

Suivez ces étapes lorsque vous prévoyez d’utiliser un système Microsoft Windows pour vous connecter par SSH à la VM Linux de test que vous allez déployer dans votre abonnement Microsoft Azure.

Lorsque vous créez la VM de test dans Microsoft Azure, vous utiliserez le contenu du fichier de clé publique généré. Si vous disposez déjà d’une paire de clés SSH existante sur le système Microsoft Windows que vous utiliserez pour vous connecter à la VM de test, vous pouvez ignorer cette étape et passer à la création de la VM de test, comme décrit dans la section Créer la machine virtuelle de test dans votre abonnement Microsoft Azure.

En suivant ces étapes, vous générez la paire de clés SSH, copiez le contenu du fichier de clé publique afin de pouvoir l’utiliser lors de la création de la VM de test et chargez la clé privée dans l’outil Pageant de PuTTY. Pageant est un agent d’authentification SSH qui peut conserver vos clés privées en mémoire. Comme la clé privée est conservée en mémoire, elle est automatiquement appliquée à chaque session SSH depuis ce système Microsoft Windows, ce qui rend l’utilisation plus facile.

Conditions préalables

Un logiciel de paire de clés SSH n’est pas installé par défaut sur un système Microsoft Windows. Vérifiez qu’un logiciel de génération de paire de clés SSH est installé sur le système que vous prévoyez d’utiliser. Vous pouvez utiliser n'importe quel logiciel de génération de paire de clés SSH. Les étapes ci-dessous décrivent l’utilisation du logiciel PuTTY sur Microsoft Windows afin de créer la paire de clés SSH. Vous pouvez obtenir le logiciel PuTTY sur le site www.putty.org. Après l’installation, la suite d’outils PuTTY est disponible. La capture d'écran suivante montre un exemple des outils PuTTY dans le menu Démarrer.

Capture d'écran des outils PuTTY, tels qu'ils s'affichent dans le menu Démarrer de Microsoft Windows 10

Procédure

Sur votre système Microsoft Windows, lancez PuTTYgen (le générateur de clés PuTTY).
La fenêtre PuTTY Key Generator s’affiche. Comme indiqué sur la capture d’écran suivante, l’objectif consiste à générer une paire de clés privée/publique, de type RSA SSH-2 et de disposer de 2 048 bits.
Vérifiez que SSH-2RSA est sélectionné, que 2048 est défini comme nombre de bits, puis cliquez sur Generate. La fenêtre devient la fenêtre Key qui affiche une barre de progression.
Suivez les instructions à l'écran pour déplacer le curseur de manière aléatoire dans la zone vierge sous la barre de progression. Comme l'indique l'interface utilisateur de PuTTY, le déplacement du curseur dans la zone ajoute le caractère aléatoire requis au processus.
Enregistrez la clé privée dans le système en entrant une phrase secrète de clé, puis cliquez sur Save private key.

Note : L’utilisation d’une phrase secrète de clé est facultative. Toutefois, si vous cliquez sur Save private key sans saisir une phrase secrète de clé, une fenêtre contextuelle vous demande de confirmer si vous voulez sauvegarder la clé privée sans phrase secrète de clé.

La clé privée est enregistrée en tant que fichier PPK. Après avoir cliqué sur Save private key, vous pouvez accéder à un répertoire dans le système local, entrer un nom de fichier et enregistrer le fichier.
Utilisez le bouton Save public key pour enregistrer la clé publique dans un emplacement où vous pouvez la copier au moment de la création de la VM de test.
Lancez Pageant, l’agent d’authentification SSH de PuTTY.
Sur un système Windows 10, l'icône Pageant est chargée dans la barre d'état système.
Ajoutez votre clé privée à Pageant en cliquant avec le bouton droit sur cette icône de barre d’état système, en cliquant sur Add Key et en utilisant la fenêtre de sélection de fichier pour accéder à votre fichier de clé privée (PPK) enregistré et le sélectionner.

Note : Si vous avez spécifié une phrase secrète de clé lorsque vous avez enregistré le fichier de clé privée précédemment, une boîte s’affiche dans laquelle vous pouvez entrer cette phrase secrète.

Résultats

À ce stade, la clé privée est chargée dans Pageant. Vous pouvez utiliser le choix View Keys dans le menu Action pour afficher la clé dans la liste des clés chargées. Lorsque vous démarrez une session SSH à l’aide de PuTTY, ce dernier récupère la clé automatiquement auprès de Pageant et l’utilise pour vous authentifier. Vous n’avez donc pas à entrer votre phrase secrète. Plus tard, lorsque vous avez fini d’exécuter des sessions SSH et que vous voulez arrêter Pageant, utilisez le choix Exit dans le menu contextuel de l'icône de barre d’état système de Pageant.

Que faire ensuite

Créez la VM de test en suivant les étapes de la section Créer la machine virtuelle de test dans votre abonnement Microsoft Azure.

Créer une paire de clés SSH sur un système Linux

Suivez cette procédure lorsque vous prévoyez d’utiliser un système Linux pour établir une connexion SSH à la machine virtuelle Linux de test que vous allez déployer dans votre abonnement Microsoft Azure.

Dans les étapes de création de la machine virtuelle de test dans Microsoft Azure, vous utiliserez le contenu du fichier de clé publique généré. Si vous disposez déjà d’une paire de clés SSH existante sur le système Linux que vous utiliserez pour vous connecter à la machine virtuelle de test, vous pouvez ignorer cette étape et passer à la création de la machine virtuelle de test, en suivant la procédure décrite dans la section Créer la machine virtuelle de test dans votre abonnement Microsoft Azure.

Conditions préalables

Avant d’effectuer ces étapes, assurez-vous que vous ne remplacerez pas une paire de clés SSH existante que vous souhaitez conserver à d’autres fins. Sur un système Linux, les fichiers de clés SSH publique et privée sont créés dans le répertoire Linux ~/.ssh/id_rsa par défaut. Si une paire de clés SSH existe dans ce répertoire et que vous utilisez le même nom de fichier lorsque vous exécutez cette commande, ou si vous spécifiez un emplacement différent dans la commande et qu’une paire de clés SSH existe déjà à cet emplacement, la paire existante est remplacée.

Procédure

Sur votre système Linux, ouvrez un interpréteur de commandes Bash.
Dans l’interpréteur de commandes Bash, tapez la commande suivante :
```
ssh-keygen -t rsa -b 2048
```
Suivez les instructions à l’écran pour entrer un fichier dans lequel enregistrer la clé, pour entrer une phrase secrète et pour confirmer celle-ci.
Voici un exemple d’instructions à l’écran, où mykey a été entré comme fichier dans lequel enregistrer la clé.
```
-bash-4.1$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/mts-cm/home/user1/.ssh/id_rsa): mykey
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
```
Note : Utiliser une phrase secrète de clé est une meilleure pratique facultative.
La clé privée est enregistrée dans le fichier que vous spécifiez et la clé publique est enregistrée dans un fichier portant le même nom et une extension .pub. En utilisant l’exemple ci-dessus où mykey est entré comme fichier, l’exemple de sortie serait :
```
Your identification has been saved in mykey.
Your public key has been saved in mykey.pub.
```

Que faire ensuite

Créez la machine virtuelle de test en suivant la procédure décrite dans la section Créer la machine virtuelle de test dans votre abonnement Microsoft Azure.

Créer la machine virtuelle de test dans votre abonnement Microsoft Azure

Vous utiliserez une machine virtuelle Linux de test dans votre environnement Microsoft Azure pour exécuter les tests qui vérifient la connectivité réseau qui est configurée pour votre espace Horizon Cloud.

Conditions préalables

Vérifiez que vous disposez de la clé publique SSH que vous avez créée comme décrit dans la section Dépannage du déploiement de l'espace Horizon Cloud - Créer une paire de clés SSH. Vous fournirez cette clé publique dans l’assistant de création de la VM pour que cette dernière fasse confiance aux connexions SSH provenant du système qui possède la clé privée correspondante.

Vérifiez que le nom du réseau virtuel que vous possédez est le même que celui que vous utilisez pour déployer votre espace, comme décrit dans la section Horizon Cloud de première génération - Configurer le réseau virtuel requis dans Microsoft Azure.

Si vous n'avez pas utilisé l'option Ajouter un espace de l'assistant pour utiliser vos propres sous-réseaux nommés pour l'espace et que vous avez plutôt entré les CIDR pour les sous-réseaux, le système de déploiement de l'espace crée le sous-réseau de gestion de l'espace. Au moment de l'échec du processus de déploiement, le processus a peut-être déjà créé le sous-réseau de gestion de l'espace dans le réseau virtuel.

Si le système de déploiement a déjà créé ce sous-réseau de gestion, il est recommandé de déployer la VM de test sur ce sous-réseau. Pour savoir si le sous-réseau de gestion de l'espace existe sur le réseau virtuel, connectez-vous au portail Microsoft Azure, accédez à ce réseau virtuel et examinez la liste des sous-réseaux qu'il comporte. Si vous aviez configuré le système de déploiement de l'espace pour qu'il crée automatiquement les sous-réseaux de l'espace (vous n'avez pas utilisé l'option pour utiliser vos propres sous-réseaux nommés pour l'espace), le sous-réseau de gestion de l'espace aura un nom dans le modèle vmw-hcs-podID-net-management, où podID est l'UUID de l'espace. Sinon, le sous-réseau de gestion de l'espace est celui que vous avez créé pour le déploiement de l'espace.
Si le processus de déploiement en échec n'a pas créé de sous-réseau de gestion de l'espace sur le réseau virtuel, vous pouvez choisir n'importe quel sous-réseau disponible sur le réseau virtuel ou créer un sous-réseau que la VM de test utilisera.

Procédure

Connectez-vous au portail Microsoft Azure.
Dans le portail, créez une VM de calcul à partir d'Azure Marketplace et basez-la sur un type de modèle Serveur Ubuntu LTS.
Au moment de la rédaction de ce document, il était possible de sélectionner le modèle Serveur Ubuntu 20.04 LTS dans Azure Marketplace.

Lors de la création de cette VM Linux de test, suivez l'interface utilisateur de l'assistant et configurez les options requises. Veillez à configurer les éléments suivants, comme indiqué ci-dessous.


Option	Description
Abonnement	Faites correspondre celui que vous avez sélectionné dans l'assistant Ajouter un espace pour votre espace.
Groupe de ressources	Il est recommandé de créer un groupe de ressources pour la VM de test. Suivez l'invite à l'écran pour créer un groupe de ressources. Même si vous pouvez utiliser un groupe de ressources existant avec cette VM de test, un groupe de ressources spécifique pour la VM de test est recommandé, car il est plus facile de supprimer la VM et ses artefacts connexes simplement en supprimant le groupe de ressources complet une fois que vous avez terminé les tests.
Région	Faites correspondre celui que vous avez sélectionné dans l'assistant Ajouter un espace pour votre espace.
Taille	Comme cette VM sera de courte durée, utilisée uniquement pour effectuer les tests de vérification, vous pouvez choisir n'importe quelle taille. Toutefois, comme les tailles plus petites ont en général des coûts associés inférieurs dans Microsoft Azure, il convient de choisir une petite taille pour la VM de test, par exemple un modèle à 2 vCPU.
Nom d'utilisateur	Notez ce nom, car vous en aurez besoin pour un usage ultérieur.
Type d'authentification	Sélectionnez Clé publique SSH.
Source de clé publique SSH	Sélectionnez Utiliser la clé publique existante. Le champ Clé publique SSH s'affiche avec cette sélection, et vous pouvez le coller dans la clé publique SSH.
Clé publique SSH	Dans ce champ, collez la clé publique SSH que vous avez créée lorsque vous avez créé la paire de clés SSH. Le contenu collé doit commencer par la ligne `---- BEGIN SSH2 PUBLIC KEY ----` et se terminer par la ligne `---- END SSH2 PUBLIC KEY ----` de votre clé publique.
Ports entrants publics	Autorisez le port SSH (22) sélectionné afin de pouvoir effectuer les tests avec cette VM de test.
Réseau virtuel	Sélectionnez le même réseau virtuel que celui qui a été utilisé pour le déploiement de l'espace en échec.
Sous-réseau	Si vous avez déjà tenté de déployer l'espace et que le processus a échoué, le sous-réseau de gestion de l'espace peut avoir été créé dans le réseau virtuel. Si le sous-réseau est présent, il est recommandé de sélectionner ce sous-réseau pour cette VM de test. Cliquez sur le choix Sous-réseau pour accéder aux sous-réseaux qui existent sur le réseau virtuel sélectionné. Vous devrez peut-être survoler le sous-réseau pour voir son nom complet dans l'info-bulle. Si le processus de déploiement de l'espace n'a pas créé le sous-réseau de gestion de l'espace sur le réseau virtuel, sélectionnez le sous-réseau sur votre réseau virtuel que vous avez identifié afin de l’utiliser pour la VM de test (comme décrit dans les conditions préalables ci-dessus). Note : Si l'espace a été correctement déployé, mais que vous résolvez des problèmes de jonction de domaine, vous pouvez sélectionner le sous-réseau de poste de travail de l'espace pour la VM de test au lieu du sous-réseau de gestion, car des opérations de jonction de domaine sont utilisées avec les images de poste de travail qui se connectent à ce sous-réseau de poste de travail.
Adresse IP publique	Sélectionnez ce choix pour qu’une adresse IP publique soit attribuée à la VM de test créée. Le fait d’avoir une adresse IP publique vous permet de vous y connecter sur le réseau étendu (WAN). Note : L'utilisation d'une adresse IP publique peut ne pas être techniquement possible dans votre configuration réseau. Si vous ne pouvez pas créer la VM de test avec une adresse IP publique, vous devrez disposer d’une connectivité réseau depuis votre système local vers le sous-réseau que vous avez sélectionné dans le champ Sous-réseau, ou vous devrez vous connecter à une autre machine sur votre réseau, puis vous connecter en entrée à la VM de test.

À l'étape finale du résumé, vérifiez que les informations clés (abonnement, emplacement régional, réseau virtuel et sous-réseau) correspondent à celles que vous utilisez pour l'espace, puis envoyez-les pour créer la VM.

Utiliser SSH pour se connecter à la machine virtuelle de test

Établissez une connexion SSH (Secure Shell) à la machine virtuelle de test afin de pouvoir exécuter les tests de connectivité réseau dans votre environnement Microsoft Azure.

Se connecter par SSH à la VM de test à partir d’un système Microsoft Windows

Vous effectuez cette connexion à partir du système Microsoft Windows qui dispose de la clé privée correspondant à la clé publique que vous avez spécifiée lorsque vous avez créé la VM de test.

Conditions préalables

Vérifiez que vous disposez de l’adresse IP et du nom d’utilisateur de la VM de test que vous avez spécifiés lorsque vous avez créé la VM.

Sur un système Microsoft Windows, PuTTY est généralement utilisé. Pour faciliter le chargement de votre clé privée par PuTTY lorsque vous démarrez la session SSH, avant de démarrer PuTTY, démarrez Pageant comme décrit dans la section Créer une paire de clés SSH sur un système Microsoft Windows et ajoutez la clé privée SSH à la liste de clés de Pageant. La clé privée SSH doit correspondre à la clé publique que vous avez spécifiée lors de la création de la VM de test. Lorsque la clé privée est chargée dans Pageant, la session SSH de PuTTY utilisera automatiquement cette clé privée.

Procédure

Lancez PuTTY ().
La fenêtre PuTTY Configuration s’ouvre.
Dans la fenêtre PuTTY Configuration, spécifiez le nom d’hôte, sélectionnez SSH, puis cliquez sur Open.
Dans le champ Host Name de la fenêtre PuTTY Configuration, entrez une chaîne qui suit le modèle
```
testvm_username@testvmip
```
en remplaçant le nom d’utilisateur et l’adresse IP de la VM de test par testvm_username et testvmip dans la chaîne.
Important : Lorsque vous cliquez sur Open, s’il s'agit de votre première connexion à la VM de test, un message de sécurité de PuTTY s’affiche indiquant que la clé d’hôte du serveur n’est pas mise en cache et affiche l’empreinte digitale de clé rsa2 du serveur. Vous pouvez continuer à établir la connexion en cliquant sur Yes pour ajouter la clé d’hôte du serveur au cache de PuTTY ou sur No pour vous connecter sans ajouter la clé au cache de PuTTY. Si vous pensez que la connexion n'atteint pas votre VM de test, cliquez sur Cancel pour abandonner la connexion et revenir à la fenêtre PuTTY Configuration pour vérifier votre saisie du nom d’hôte.
La capture d'écran suivante illustre la fenêtre utilisant cet exemple
```
[email protected]
```

Résultats

Lorsque la connexion SSH est établie, une fenêtre de ligne de commande s'affiche.

Que faire ensuite

Maintenant que vous êtes connecté à la VM de test, vous pouvez exécuter les tests pour vérifier la connectivité réseau dans votre environnement Microsoft Azure. Suivez les étapes décrites dans la section Exécuter les tests pour vérifier la mise en réseau dans votre environnement Microsoft Azure.

Établir une connexion SSH à la machine virtuelle de test depuis un système Linux

Vous effectuez cette connexion depuis le système Linux disposant de la clé privée qui correspond à la clé publique spécifiée lors de la création de la machine virtuelle de test.

Conditions préalables

Vérifiez que vous disposez de l’adresse IP de la machine virtuelle de test et du nom d’utilisateur que vous avez spécifié lorsque vous avez créé la machine virtuelle.

Procédure

Ouvrez un interpréteur de commandes Bash.
À l’invite $ de l’interpréteur de commandes Bash, entrez la commande ssh comme ci-dessous, en remplaçant l’adresse IP de la machine virtuelle de test et le nom d’utilisateur par testvmip et testvm_username dans la commande :
```
ssh testvm_username@testvmip
```
Par exemple,en utilisant les détails de la machine virtuelle de test des exemples dans Créer la machine virtuelle de test dans votre abonnement Microsoft Azure, l’exemple de commande serait :
```
ssh [email protected]
```

Résultats

Lorsque la connexion SSH est établie, une fenêtre de ligne de commande s’affiche, semblable à la capture d’écran suivante.

Que faire ensuite

Maintenant que vous êtes connecté à la machine virtuelle de test, vous pouvez exécuter les tests pour vérifier la connectivité réseau dans votre environnement Microsoft Azure. Suivez la procédure décrite dans la section Exécuter les tests pour vérifier la mise en réseau dans votre environnement Microsoft Azure.

Exécuter les tests pour vérifier la mise en réseau dans votre environnement Microsoft Azure

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.

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

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
```
Où 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.
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
```
Où 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.
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 Locataires de première génération - Déploiements d'Horizon Cloud on Microsoft Azure - Conditions requises de résolution de noms d'hôtes, Noms DNS, 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 Locataires de première génération - Déploiements d'Horizon Cloud on Microsoft Azure - Conditions requises de résolution de noms d'hôtes, Noms DNS.

Résultats

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

Note : Si vous prévoyez de configurer des fonctionnalités facultatives à utiliser avec votre espace, telles que l'authentification unique réelle ou l'authentification à deux facteurs avec un serveur d'authentification, 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.

Supprimer la VM de test une fois les tests terminés

Lorsque vous aurez terminé les tests de vérification de votre configuration réseau de Microsoft Azure et que vous n'aurez plus besoin de la machine virtuelle de test, vous devrez la supprimer ainsi que tous ses artefacts associés de votre environnement Microsoft Azure.

Procédure

Connectez-vous au portail Microsoft Azure.
Utilisez l’une des méthodes suivantes pour supprimer la VM de test, en fonction de la méthode de déploiement que vous avez utilisée.
- Si vous avez déployé la VM de test dans son propre groupe de ressources et que vous n’utilisez pas ce groupe à d’autres fins, vous pouvez supprimer le groupe de ressources complet.
  Attention : Pour éviter de supprimer d’autres éléments par inadvertance, assurez-vous que le groupe de ressources contient uniquement votre VM de test et ses objets associés, tels que son disque et ses adaptateurs réseau, avant de supprimer le groupe de ressources.
- Si vous devez supprimer la VM de test sans supprimer un groupe de ressources complet, vous pouvez utiliser la zone de recherche du portail pour rechercher le nom de la VM de test. Les résultats de cette recherche affichent la VM et tous ses objets associés (disque, interfaces réseau, adresse IP publique, etc.). Supprimez ensuite chaque objet un par un.