Guide PoC : prise en charge du VPC partagé Google Cloud Platform (GCP) avec Citrix DaaS

Vue d’ensemble

Citrix DaaS prend en charge le VPC partagé Google Cloud Platform (GCP). Ce document couvre les éléments suivants :

• Vue d’ensemble de la prise en charge de Citrix pour les VPC partagés Google Cloud.

• Vue d’ensemble de la terminologie relative aux VPC partagés Google Cloud.

• Configuration d’un environnement Google Cloud pour prendre en charge l’utilisation des VPC partagés.

• Utilisation des VPC partagés Google pour les connexions hôtes et le provisionnement de catalogue de machines.

• Conditions d’erreur courantes et comment les résoudre.

Conditions préalables

Ce document suppose la connaissance de Google Cloud et de l’utilisation de Citrix DaaS pour le provisionnement des catalogues de machines dans un projet Google Cloud.

Pour configurer un projet GCP pour Citrix DaaS, consultez la documentation du produit.

Résumé

La prise en charge de Citrix MCS pour le provisionnement et la gestion des catalogues de machines déployés sur des VPC partagés est fonctionnellement équivalente à ce qui est pris en charge par les VPC locaux aujourd’hui.

Il y a deux façons de différer :

• Quelques autorisations supplémentaires doivent être accordées au compte de service utilisé pour créer la connexion hôte afin de permettre à MCS d’accéder aux ressources VPC partagées et de les utiliser.

• L’administrateur du site doit créer deux règles de pare-feu, une pour l’entrée et la sortie, à utiliser pendant le processus de mastering d’image.

Ces deux éléments seront examinés plus en détail plus loin dans le présent document.

VPC partagés Google Cloud

Les VPC partagés GCP se composent d’un projet hôte, à partir duquel les sous-réseaux partagés sont mis à disposition, et d’un ou plusieurs projets de service utilisant les ressources.

L’utilisation de VPC partagés est une bonne option pour les installations de grande taille car elles permettent un contrôle, une utilisation et une administration plus centralisés des ressources partagées Google Cloud d’entreprise. Google Cloud le décrit de cette façon :

« Le VPC partagé permet à une organisation de connecter les ressources de plusieurs projets à un réseau Virtual Private Cloud (VPC)commun, afin qu’elles puissent communiquer entre elles de manière sécurisée et efficace à l’aide des adresses IP internes de ce réseau. Lorsque vous utilisez un VPC partagé, vous désignez un projet en tant que projet hôte et y attachez un ou plusieurs autres projets de service. Les réseaux VPC du projet hôte sont appelés réseaux VPC partagés. Les ressources éligibles des projets de service peuvent utiliser des sous-réseaux dans le réseau VPC partagé. »

Le paragraphe ci-dessus provient du site de documentation de Google.

Nouvelles autorisations requises

Lorsque vous travaillez avec Citrix DaaS et Google Cloud, un compte de service GCP avec des autorisations spécifiques doit être fourni lors de la création de la connexion hôte. Comme indiqué ci-dessus, pour utiliser des VPC partagés GCP, certaines autorisations supplémentaires doivent être accordées à tous les comptes de service utilisés pour créer des connexions hôtes basées sur des VPC partagés.

Techniquement parlant, les autorisations requises ne sont pas « nouvelles », car elles sont déjà nécessaires pour utiliser Citrix DaaS avec GCP et des VPC locaux. La modification est que les autorisations doivent être accordées afin d’autoriser l’accès aux ressources VPC partagées. Pour ce faire, le compte de service est ajouté aux rôles IAM pour le projet hôte et sera décrit en détail dans la section « Comment faire » de ce document.

Remarque :

pour connaître les autorisations requises pour le produit Citrix DaaS actuellement livré, consultez le site de documentation Citrix décrivant les emplacements des ressources.

Au total, quatre autorisations supplémentaires au maximum doivent être accordées au compte de service associé à la connexion hôte :

1. compute.firewalls.list - Obligatoire

   Cette autorisation est nécessaire pour permettre à Citrix MCS de récupérer la liste des règles de pare-feu présentes sur le VPC partagé (discuté en détail ci-dessous).

2. compute.networks.list - Obligatoire

   Cette autorisation est nécessaire pour permettre à Citrix MCS d’identifier les réseaux VPC partagés disponibles pour le compte de service.

3. compute.subnetworks.list — Peut être obligatoire (voir ci-dessous)

   Cette autorisation est nécessaire pour permettre à MCS d’identifier les sous-réseaux dans les VPC partagés visibles.

   Remarque :

   Cette autorisation est déjà requise pour l’utilisation de VPC locaux mais doit également être attribuée dans le projet Hôte VPC partagé.

4. compute.subnetworks.use - Peut être obligatoire (voir ci-dessous)

   Cette autorisation est nécessaire pour utiliser les ressources de sous-réseau dans les catalogues de machines provisionnés.

   Remarque :

   Cette autorisation est déjà requise pour l’utilisation de VPC locaux mais doit également être attribuée dans le projet hôte VPC partagé.

Les deux derniers éléments sont indiqués comme étant « Peut être obligatoire » parce qu’il y a deux approches différentes à prendre en compte lorsqu’on traite de ces autorisations :

• Autorisationsau niveau du projet

  • Permet l’accès à tous les VPC partagés au sein du projet hôte.

  • Nécessite que les autorisations #3 et #4 soient attribuées au compte de service.

• Autorisationsau niveau du sous-réseau

  • Permettent l’accès à des sous-réseaux spécifiques dans le VPC partagé.

  • Les autorisations #3 et #4 sont intrinsèques à l’attribution de niveau de sous-réseau et n’ont donc pas besoin d’être attribuées directement au compte de service.

Des exemples de ces deux approches sont donnés ci-dessous dans la section « Comment faire » du présent document.

L’une ou l’autre des approches fonctionnera également bien. Sélectionnez le modèle le mieux adapté aux besoins de votre organisation et aux normes de sécurité. Des informations plus détaillées concernant la différence entre les autorisations au niveau du projet et au niveau du sous-réseau peuvent être obtenues dans la documentation Google Cloud.

Projet hôte

Pour utiliser des VPC partagés dans Google Cloud, commencez par désigner et activer un projet Google Cloud comme projet hôte. Ce projet hôte contient un ou plusieurs réseaux VPC partagés utilisés par d’autres projets Google Cloud au sein de l’organisation.

La configuration du projet hôte partagé VPC, la création de sous-réseaux et le partage de l’ensemble du projet ou de sous-réseaux spécifiques avec d’autres projets Google Cloud sont purement des activités liées à Google Cloud et ne sont pas incluses dans le champ d’application de ce document. La documentation Google Cloud relative à la création et à l’utilisation de VPC partagés est disponible ici.

Règles de pare-feu

Une étape clé du traitement en coulisses qui se produit lors du provisionnement ou de la mise à jour d’un catalogue de machines est appelée mastering. Il s’agit du moment où l’image machine sélectionnée est copiée et préparée pour être le disque principal du système d’image du catalogue. Pendant le mastering, ce disque est attaché à une machine virtuelle temporaire, la machine de préparation, et démarré pour permettre l’exécution des scripts de préparation. Cette machine virtuelle doit s’exécuter dans un environnement isolé qui empêche tout le trafic réseau entrant et sortant. Ceci est réalisé grâce à une paire de règles de pare-feu Deny-All, l’une pour l’entrée et l’autre pour la sortie.

Lors de l’utilisation de VPC locaux GCP, MCS crée cette paire de règles de pare-feu à la volée dans le réseau local, les applique à la machine pour le mastering et les supprime une fois le mastering terminé.

Citrix recommande de limiter au minimum le nombre de nouvelles autorisations requises pour utiliser les VPC partagés, car les VPC partagés sont des ressources d’entreprise de plus haut niveau et ont généralement des protocoles de sécurité plus rigides en place. Pour cette raison, l’administrateur du site doit créer une paire de règles de pare-feu (une entrée et une sortie) sur chaque VPC partagé avec la priorité la plus élevée et appliquer une nouvelle balise cible à chacune des règles. La valeur de la balise cible est la suivante :

citrix-provisioning-quarantine-firewall

Lorsque MCS crée ou met à jour un catalogue de machines, il recherche les règles de pare-feu contenant cette balise cible, examine les règles d’exactitude et les applique à la machine de préparation.

Si les règles de pare-feu sont introuvables, ou si les règles sont trouvées, mais que les règles ou la priorité sont incorrectes, un message de ce formulaire sera renvoyé :

Unable to find valid INGRESS and EGRESS quarantine firewall rules for VPC \<name\> in project \<project\>. Please ensure you have created deny all firewall rules with the network tagcitrix-provisioning-quarantine-firewall and proper priority. Refer to Citrix Documentation for details.

Cloud Connector

Lorsque vous utilisez un VPC partagé pour les catalogues de machines Citrix DaaS, vous allez créer deux Cloud Connector ou plus pour accéder au contrôleur de domaine qui réside dans le VPC partagé. La recommandation dans ce cas est de créer une instance de machine GCP dans votre projet local et d’ajouter une interface réseau supplémentaire à l’instance. La première interface serait connectée à un sous-réseau dans le VPC partagé. La deuxième interface réseau se connecterait à un sous-réseau de votre VPC local pour permettre l’accès pour le contrôle administratif et la maintenance via votre serveur Bastion VPC local.

Malheureusement, vous ne pouvez pas ajouter une interface réseau à une instance GCP après sa création. Il s’agit d’un processus simple et est couvert ci-dessous dans l’une des entrées How T.

Comment faire pour la section

La section suivante contient une série d’exemples didactiques pour vous aider à comprendre les étapes permettant d’effectuer les modifications de configuration nécessaires pour utiliser Google Shared VPC avec Citrix DaaS.

Les exemples présentés dans les captures d’écran de Google Console auront tous lieu dans un projet Google hypothétique nommé Shared VPC Project 1.

Procédure : créer un nouveau rôle IAM

Certaines autorisations supplémentaires doivent être accordées au compte de service utilisé lors de la création de la connexion hôte. Étant donné que le déploiement sur des VPC partagés vise à permettre le déploiement de plusieurs projets sur le même VPC partagé, l’approche la plus efficace consiste à créer un nouveau rôle dans le projet hôte avec les autorisations souhaitées, puis à attribuer ce rôle à tout compte de service nécessitant l’accès au VPC partagé.

Ci-dessous, nous allons créer le rôle de niveau projet nommé Citrix-ProjectLevel-ShareDVPcrole. Le rôle de niveau sous-réseau suit simplement les mêmes étapes pour les deux premiers jeux d’autorisations attribués.

IAM & Admin dans la console Google

Accédez à l’option de configuration IAM & Admin dans la console Google Cloud :

Créer un rôle

Sélectionnez Créer un rôle :

Écran de création de rôle vide

Un écran ressemblant au suivant s’affiche :

Remplissez le nom et ADD PERMISSION

Spécifiez le nom du rôle. Cliquez sur AJOUTER DES AUTORISATIONS pour appliquer la mise à jour :

Boîte de dialogue Ajouter des autorisations

Après avoir cliqué sur, AJOUTER DES AUTORISATIONS, un écran ressemblant à celui ci - dessous apparaît.

Notez que dans cette image le champ de saisie de texte « Tableau de filtre » a été mis en surbrillance :

Ajouter une autorisation compute.firewalls.list

Cliquez sur le champ de saisie de texte de la table filtrer pour afficher un menu contextuel :

Copiez et collez (ou tapez) la chaîne compute.firewalls.list dans le champ de texte, comme indiqué ci-dessous :

La sélection de l’entrée compute.firewalls.list qui a été filtrée hors de la table des autorisations se traduit par cette boîte de dialogue :

Cliquez sur la case à bascule pour activer l’autorisation :

Cliquez sur AJOUTER.

L’écran Créer un rôle apparaît de nouveau. Notez que l’autorisation compute.firewalls.list a été ajoutée au rôle :

Ajouter l’autorisation compute.networks.list

En suivant les mêmes étapes que ci-dessus, ajoutez l’autorisation compute.networks.list. Cependant, assurez-vous de sélectionner la règle appropriée. Comme vous pouvez le voir ci-dessous, lorsque le texte d’autorisation est entré dans le champ de la table de filtre, deux autorisations sont répertoriées. Choisissez l’entrée compute.networks.list  :

Cliquez sur AJOUTER.

Les deux autorisations obligatoires ajoutées à notre rôle :

Niveau projet ou sous-réseau

Déterminez le niveau d’accès du rôle, tel que l’accès au niveau du projet ou un modèle plus restreint à l’aide de l’accès au niveau du sous-réseau. Aux fins de ce document, nous créons actuellement le rôle nommé Citrix-ProjectLevel-SharedVpc Role, nous allons donc ajouter les autorisations compute.subnetworks.list et compute.subnetworks.use en utilisant les mêmes étapes que celles utilisées ci-dessus. L’écran résultant ressemble à ceci, avec les quatre autorisations accordées, juste avant de cliquer sur Créer :

Cliquez sur CREATE.

Remarque :

Si le rôle de niveau sous-réseau a été créé ici, nous aurions cliqué sur CREATE plutôt que d’ajouter les deux autorisations compute.subnetworks.list et compute.subnetworks.use supplémentaires.

Rôle Citrix-ProjectLevel-ShareDVPC créé

Procédure : ajouter un compte de service au rôle IAM du projet hôte

Maintenant que nous avons créé le nouveau Citrix-ProjectLevel-SharedVpc Role, nous devons ajouter un compte de service dans le projet hôte. Pour cet exemple, nous utiliserons un compte de service nommé citrix-shared-vpc-service-account.

Accédez à IAM et Admin

La première étape consiste à accéder à l’écran IAM et rôles pour le projet. Dans la console, sélectionnez IAM et Admin. Sélectionnez IAM :

Écran Autorisations du projet

Ajoutez des membres avec les autorisations spécifiées. Cliquez sur AJOUTER pour afficher la liste des membres :

Panneau Ajouter des membres

Cliquez sur ADD pour afficher un petit panneau comme indiqué dans l’image ci-dessous. Les données seront saisies à l’étape suivante.

Ajouter un compte de service

Commencez à taper le nom de votre compte de service dans le champ. Au fur et à mesure que vous tapez, Google Cloud recherchera les projets auxquels vous avez des autorisations d’accès et présentera une liste restreinte de correspondances possibles. Dans ce cas, nous avons une correspondance (affichée directement en dessous du remplissage), donc nous sélectionnons cette entrée :

Sélection du rôle

Après avoir spécifié le nom de membre (dans notre cas, le compte de service), sélectionnez un rôle pour que le compte de service fonctionne comme dans le projet VPC partagé. Commencez ce processus en cliquant sur la liste indiquée :

Sélection d’un rôle

Notez que le processus Sélectionner un rôle est similaire à ceux utilisés dans la précédente Procédure - Créer un rôle IAM. Dans ce cas, plusieurs autres options sont affichées ainsi que le remplissage.

Spécifier le rôle

Puisque nous connaissons le rôle que nous voulons appliquer, nous pouvons commencer à taper. Une fois le rôle prévu apparaîtra, sélectionnez le rôle :

Sélectionner et enregistrer

Après avoir sélectionné le rôle, cliquez sur Enregistrer :

Nous avons maintenant ajouté avec succès le compte de service au projet hôte.

Procédure : Autorisations au niveau du sous-réseau

Si vous avez choisi d’utiliser l’accès au niveau du sous-réseau plutôt que l’accès au niveau projet, vous devez ajouter les comptes de service à utiliser avec le VPC partagé en tant que membres pour chaque sous-réseau représentant les ressources à accéder. Pour cette section Comment faire, nous allons fournir le compte de service nommé sharedvpc-sa\@citrix-mcs-documentation.iam.gserviceaccount.com avec accès à un seul sous-réseau dans notre VPC partagé.

Accédez à VPC > VPC partagé

La première étape consiste à accéder à l’écran VPC partagé dans Google Console :

Écran VPC partagé initial

Il s’agit de la page de destination de l’écran VPC partagé de Google Cloud Console. Ce projet présente cinq sous-réseaux. Le compte de service dans cet exemple requiert l’accès au deuxième sous-réseau (le dernier sous-réseau de la liste ci-dessous).

Activez la case à cocher en regard du deuxième sous-réseau de sous-réseau :

Sélectionnez le sous-réseau pour accéder au compte de service

Maintenant que la case à cocher du dernier sous-réseau a été cochée, notez que l’option ADD MEMBER apparaît en haut à droite de l’écran.

Il est également utile pour cet exercice de prendre note du nombre d’utilisateurs avec lesquels ce sous-réseau a été partagé. Comme indiqué, un utilisateur a accès à ce sous-réseau.

Cliquez sur AJOUTER UN MEMBRE :

Remplissez le nom du nouveau membre

Similaire aux étapes requises pour ajouter le compte de service au projet hôte dans la section Procédure d’exécution précédente, le nom du nouveau membre doit également être fourni ici. Après avoir renseigné le nom, Google Cloud répertorie tous les éléments associés (comme précédemment) afin que nous puissions sélectionner le compte de service approprié. Dans ce cas, il s’agit d’une seule entrée.

Double-cliquez sur le compte de service pour le sélectionner :

Sélectionner un rôle pour le nouveau membre

Une fois qu’un compte de service a été sélectionné, un rôle pour le nouveau membre doit également être choisi :

1. Dans la liste, cliquez sur Sélectionner un rôle.

2. Double-cliquez sur le rôle d’utilisateur réseau de calcul.

Rôle sélectionné

L’image montre que le compte de service et le rôle ont été spécifiés. La seule étape restante consiste à cliquer sur ENREGISTRER pour valider les modifications :

L’utilisateur a été ajouté au sous-réseau

Une fois les modifications enregistrées, l’écran principal du VPC partagé apparaît. Notez que le nombre d’utilisateurs qui ont accès au dernier sous-réseau a, comme prévu, augmenté à deux :

Procédure : ajouter un compte de service Project CloudBuild au VPC partagé

Chaque abonnement Google Cloud possède un compte de service nommé d’après le numéro d’ID du projet suivi de cloudbuild.gserviceaccount. Un exemple de nom complet (en utilisant un ID de projet confectionné) est :

705794712345@ cloudbuild.gserviceaccount.

Ce compte de service cloudbuild doit également être ajouté en tant que membre du VPC partagé, de la même manière que le compte de service que vous utilisez pour créer des connexions hôtes l’a été à l’étape 3 de How To : Add Service Account to Host Project IAM Role.

Vous pouvez déterminer le numéro d’ID de projet pour votre projet en sélectionnant Accueil et Tableau de bord dans le menu Google Cloud Console :

Recherchez le numéro de projet sous la zone Infos sur le projet de l’écran.

Entrez la combinaison numéro de projet/cloudbuild.gserviceaccount dans le champ Ajouter un membre. Attribuer un rôle d’ utilisateur du réseau informatique :

Sélectionnez Enregistrer.

Procédure : Règles de pare-feu

La création des règles de pare-feu nécessaires est un peu plus facile que la création des rôles.

Sélectionner le projet hôte

Comme indiqué précédemment dans ce document, les deux règles de pare-feu doivent être créées dans le projet hôte.

Assurez-vous que vous avez sélectionné le projet hôte.

Réseau VPC > Pare-feu

Dans le menu Google Console, accédez à VPC > Pare-feu, comme illustré ci-dessous :

Bouton Créer une règle de pare-feu

La partie supérieure de l’écran Pare-feu de Google Console comprend un bouton permettant de créer une nouvelle règle.

Cliquez sur Créer une règle de pare-feu :

Créer un écran de pare-feu

L’écran utilisé pour créer une nouvelle règle de pare-feu est illustré ci-dessous :

Règle d’entrée : Remplir les données

Tout d’abord, créez la règle de déni d’entrée nécessaire en ajoutant ou en modifiant des valeurs dans les champs suivants :

• Nom

  Donnez un nom à votre règle de pare-feu Deny-All Ingress. Par exemple, citrix-deny-all-ingress-rule.

• Réseau

  Sélectionnez le réseau VPC partagé auquel la règle de pare-feu d’entrée sera appliquée. Par exemple, gcp-test-vpc.

• Priority

  La valeur de ce champ est critique. Dans le monde des règles de pare-feu, plus la valeur de priorité est faible, plus la règle est prioritaire. C’est pourquoi toutes les règles par défaut ont une valeur de 66536, de sorte que toutes les règles personnalisées, qui auront une valeur inférieure à 65536, prendront la priorité sur toutes les règles par défaut.

  Pour ces deux règles, nous avons besoin qu’elles aient les règles de priorité la plus élevée sur le réseau. Nous allons utiliser une valeur de 10.

• Direction de la circulation

  La valeur par défaut pour créer une nouvelle règle est Ingress, qui doit déjà être sélectionnée.

• Action sur le match

  Cette valeur est par défaut Autoriser. On doit le changer en Deny.

• Cibles

  C’est l’autre domaine très critique. Le type de cibles par défaut est Spécifiés tags cibles, ce qui est précisément ce que nous voulons. Dans la zone de texte intitulée Tags cibles, entrez la valeur citrix-provisioning-quarantine-firewall.

• Filtre source

  Pour le filtre source, nous conserverons le type de filtre par défaut des plages IP et entrez une plage qui correspondra à tout le trafic. Pour cela, nous utilisons une valeur de 0.0.0.0/0.

• Protocoles et ports

  Sous Protocoles et ports, sélectionnez Refuser tout.

L’écran terminé devrait ressembler à ceci :

Cliquez sur CREATE et générez la nouvelle règle.

Règle de sortie : Remplir les données

La règle de sortie est presque identique à la règle d’entrée créée précédemment. Utilisez à nouveau la RULE CREATE FIREWALL comme cela a été fait ci-dessus et remplissez les champs comme indiqué ci-dessous :

• Nom

  Donnez un nom à votre règle de pare-feu Deny-All Egress. Ici, nous allons l’appeler la règle citrix-deny-tout-sortie.

• Réseau

  Sélectionnez ici le même réseau VPC partagé que celui utilisé lors de la création de la règle de pare-feu d’entrée ci-dessus. Par exemple, gcp-test-vpc.

• Priority

  Comme indiqué ci-dessus, nous utiliserons une valeur de 10.

• Direction de la circulation

  Pour cette règle, nous devons changer de la valeur par défaut et sélectionner Egress.

• Action sur le match

  Cette valeur est par défaut Autoriser. On doit le changer en Deny.

• Cibles

  Entrez la valeur citrix-provisioning-quarantine-firewall dans le champ Tags cibles.

• Filtre source

  Pour le filtre source, nous conserverons le type de filtre par défaut des plages IP et entrez une plage qui correspondra à tout le trafic. Pour cela, nous utilisons une valeur de 0.0.0.0/0.

• Protocoles et ports

  Sous Protocoles et ports, sélectionnez Refuser tout.

L’écran terminé devrait ressembler à ceci :

Cliquez sur CREATE pour générer la nouvelle règle.

Les deux règles de pare-feu nécessaires ont été créées. Si plusieurs VPC partagés seront utilisés lors du déploiement de catalogues de machines, répétez les étapes ci-dessus. Créez deux règles pour chacun des VPC partagés identifiés dans leurs projets hôtes respectifs.

Procédure : ajouter une interface réseau aux instances Cloud Connector

Lors de la création de Cloud Connector pour une utilisation avec le VPC partagé, une interface réseau supplémentaire doit être ajoutée à l’instance lors de sa création.

Des interfaces réseau supplémentaires ne peuvent pas être ajoutées une fois l’instance existante. Pour ajouter la deuxième interface réseau :

Le panneau Paramètres réseau initial d’une instance GCP

Il s’agit du panneau initial pour les paramètres réseau présentés lors de la création d’une instance réseau

Puisque nous voulons utiliser la première instance réseau pour le VPC partagé, cliquez sur l’icône Crayon pour entrer en mode Edition.

L’écran étendu des paramètres réseau est ci-dessous. Un élément clé à noter est que nous pouvons maintenant voir l’option pour Réseaux partagés avec moi (à partir du projet hôte : citrix-shared-vpc-project-1) directement sous la bannière de l’ Interface réseau  :

Le panneau Paramètres réseau avec VPC partagé sélectionné affiche les éléments suivants :

• Sélectionner le réseau VPC partagé.

• Sélectionner le sous-réseau de bon sous-réseau.

• Modifié le paramètre sur une adresse IP externe sur Aucun.

Cliquez sur Terminé pour enregistrer les modifications. Cliquez sur Ajouter une interface réseau.

Ajouter une deuxième interface réseau

Nous avons maintenant notre première interface connectée au VPC partagé (comme indiqué). Nous pouvons configurer la deuxième interface en utilisant les mêmes étapes que celles qui seraient normalement utilisées lors de la création d’un nouveau Cloud Connector. Sélectionnez un réseau, un sous-réseau, prendre une décision sur une adresse IP externe, puis cliquez sur Terminé :

Procédure : Création d’une connexion hôte et d’une unité d’hébergement

La création d’une connexion hôte pour une utilisation avec des VPC partagés n’est pas très différente de ce qu’elle est pour la création d’une connexion à utiliser avec un VPC local. La différence réside dans la sélection des ressources à associer à la connexion hôte. Lors de la création d’une connexion hôte pour accéder aux ressources VPC partagées, utilisez les fichiers JSON de compte de service liés au projet sur lequel résident les machines provisionnées.

Informations d’identification et nom de connexion

La création d’une connexion hôte pour l’utilisation de ressources VPC partagées est similaire à la création d’une autre connexion hôte liée à GCP :

Sélectionner le projet et la région

Une fois que votre projet, présenté en tant que projet développeur dans la figure suivante, a été ajouté à la liste qui peut accéder au VPC partagé, vous pouvez voir votre projet et le projet VPC partagé dans Studio. Il est important de vous assurer que vous sélectionnez le projet dans lequel le catalogue de machines déployé doit résider et non le VPC partagé :

Sélectionner les ressources

Sélectionnez les ressources associées à la connexion hôte.

Tenez compte des considérations suivantes :

• Le nom donné pour les ressources est ShareDVPCResources.

• La liste des réseaux virtuels à choisir inclut ceux du projet local, ainsi que ceux du VPC partagé, comme indiqué par (partagé) ajouté aux noms de réseau.

Remarque :

Si aucun réseau partagé n’est ajouté au nom, cliquez sur le bouton Précédent et vérifiez que vous avez choisi le projet approprié. Si vous vérifiez que le projet choisi est correct et que vous ne voyez toujours aucun VPC partagé, quelque chose est mal configuré dans la console Google Cloud. Reportez-vous à la section Problèmes et erreurs fréquemment rencontrés plus loin dans ce document.

Ressources sélectionnées

La figure suivante montre que le réseau virtuel gcp-test-vpc (partagé) a été sélectionné à l’étape précédente. Il montre également que le sous-réseau nommé subnet-good a été sélectionné. Cliquez sur Suivant :

Écran de synthèse

Après avoir cliqué sur Suivant, l’ écran Résumé apparaît. Dans cet écran, considérez :

• Le projet est un projet de développeur.

• Le réseau virtuel est gcp-test-vpc, un provenant du VPC partagé.

• Le sous-réseau est bon pour le sous-réseau.

Procédure : Création d’un catalogue

Tout à partir de ce stade, comme la création de catalogue, le démarrage ou l’arrêt de machines, la mise à jour des machines, etc., est effectué exactement de la même manière que lors de l’utilisation de VPC locaux.

Problèmes et erreurs couramment rencontrés

Travailler avec n’importe quel système complexe avec des interdépendances peut entraîner des situations inattendues. Vous trouverez ci-dessous quelques problèmes et erreurs courants qui peuvent être rencontrés lors de l’installation et de la configuration pour utiliser Citrix DaaS et GCP Shared VPC.

Règles de pare-feu manquantes ou incorrectes

Si les règles de pare-feu ne sont pas trouvées ou si les règles sont trouvées mais que les règles ou la priorité sont incorrectes, un message de ce formulaire sera renvoyé :

« Impossible de trouver des règles de pare-feu de quarantaine INGRESS et EGRESS valides pour le VPC  <name> dans le projet <project>. « Veuillez vous assurer que vous avez créé des règles de pare-feu ‘deny all’ avec la balise réseau ‘citrix-provisioning-quarantine-firewall’ et la priorité appropriée. » « Reportez-vous à la documentation Citrix pour plus de détails. »

Si ce message est rencontré, vous devez consulter les règles de pare-feu, leurs priorités et les réseaux auxquels elles s’appliquent. Pour plus de détails, reportez-vous à la section How To - Firewall Rules.

Ressources partagées manquantes lors de la création d’une connexion hôte

Il y a quelques raisons pour lesquelles cette situation peut se produire :

Le projet incorrect a été sélectionné lors de la création de la connexion hôte

Par exemple, si le projet hôte partagé du VPC a été sélectionné lors de la création de la connexion hôte au lieu de votre projet, vous verrez toujours les ressources réseau du VPC partagé, mais elles ne seront pas ajoutées (partagées) à elles.

Si vous voyez les sous-réseaux partagés sans ces informations supplémentaires, la connexion hôte a probablement été établie avec le mauvais compte de service.

Voir How To -Creating Host Connection and Hosting Unit.

Un rôle incorrect a été attribué au compte de service

Si le rôle incorrect a été attribué au compte de service, il se peut que vous ne puissiez pas accéder aux ressources souhaitées dans le VPC partagé. Consultez How To - Add Service Account to Host Project IAM Role.

Autorisations incomplètes ou incorrectes accordées au rôle

Le rôle correct peut être attribué au compte de service, mais le rôle lui-même peut être incomplet. Consultez How To — Create a New IAM Role.

Compte de service non ajouté en tant que membre de sous-réseau

Si vous utilisez l’accès au niveau sous-réseau, assurez-vous que le compte de service a été correctement ajouté en tant que membre (utilisateur) des ressources de sous-réseau souhaitées. Consultez How To -Subnet-Level Permissions.

Impossible de trouver l’erreur de chemin dans Studio

Si vous recevez une erreur lors de la création d’un catalogue dans Studio du formulaire :

Cannot find path “XDHyp:\\Connections …” because it does not exist

Il est très probable qu’un nouveau Cloud Connector n’ait pas été créé pour faciliter l’utilisation des ressources VPC partagées. C’est une chose simple à négliger après avoir traversé toutes les étapes ci-dessus pour tout configurer. Reportez-vous à la section Cloud Connector pour connaître les points importants concernant leur création.