Configurer Agent Gateway avec la connectivité VPC

Ce document vous guide tout au long du processus de configuration de la connectivité VPC lors du déploiement d'une Agent Gateway afin qu'elle puisse communiquer de manière privée avec un réseau VPC de votre organisation.

La configuration de la connectivité VPC vous permet d'effectuer les opérations suivantes :

• Appliquer la sortie VPC pour le trafic : acheminez le trafic provenant de vos agents via votre rattachement de réseau Private Service Connect vers votre réseau VPC en mode PRIVATE_RANGES_ONLY ou ALL_TRAFFIC.
• Plage d'adresses IP sources statiques : le trafic sortant utilise la plage d'adresses IP privées du sous-réseau de rattachement de votre réseau Private Service Connect comme adresse IP source. Cette plage d'adresses IP sources statiques vous permet de configurer des stratégies de pare-feu pour votre réseau VPC afin de régir le trafic provenant de la passerelle.
• Résolution DNS personnalisée : résolvez les noms de domaine privés internes et les noms de domaine externes directement depuis vos agents à l'aide du peering Cloud DNS.
• Sécurité du périmètre : protégez les communications de l'agent à l'aide des périmètres de service VPC Service Controls.
• Validation de certificats privés ou autosignés : connectez-vous à des destinations qui utilisent des autorités de certification privées ou des certificats autosignés.

Pour configurer la connectivité VPC, vous devez créer un modèle de connectivité Agent Gateway (AgentConnectivityTemplate) dans lequel vous définissez et gérez les paramètres réseau de sortie pour vos instances Agent Gateway.

Fonctionnement de la connectivité VPC

Lorsque vous déployez une Agent Gateway avec un modèle de connectivité, la passerelle utilise une interface Private Service Connect pour acheminer le trafic sortant de l'agent vers le réseau VPC désigné.

Modes de sortie VPC

Vous configurez la façon dont la passerelle achemine le trafic via votre rattachement de réseau à l'aide du paramètre vpcEgress dans votre modèle de connectivité.

• Trafic vers les plages d'adresses IP privées (PRIVATE_RANGES_ONLY) : achemine le trafic destiné uniquement aux plages d'adresses IP privées vers votre réseau VPC. Le trafic sortant n'est acheminé vers votre réseau VPC que si l'adresse IP de destination se trouve dans l'une des plages suivantes :

  • RFC 1918 : 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
  • RFC 6598 : 100.64.0.0/10
  • Classe E : 240.0.0.0/4
  • private.googleapis.com : 199.36.153.8/30
  • restricted.googleapis.com : 199.36.153.4/30
  • Points de terminaison PSC pour les API Google : si vous déployez un point de terminaison Private Service Connect personnalisé pour les API Google à l'aide d'une adresse IP privée interne dans votre réseau VPC, le trafic vers ce point de terminaison est acheminé via votre réseau VPC. Assurez-vous que le peering Cloud DNS est configuré dans le modèle de connectivité afin que l'Agent Gateway résolve correctement les domaines de l'API Google en adresse IP de votre point de terminaison PSC interne.

  Les requêtes adressées aux API Google publiques standards sont traitées automatiquement à l'aide de l'accès privé à Google, et le trafic destiné à Internet est acheminé directement via Agent Gateway plutôt que via votre réseau VPC.

• Trafic vers toutes les plages d'adresses IP (ALL_TRAFFIC) : achemine tout le trafic sortant provenant de vos agents via votre réseau VPC, y compris l'Internet public, les API SaaS externes et les adresses non-RFC 1918.

  • Routage et sécurité : comme ce paramètre route tout le trafic sortant vers votre VPC, vous êtes responsable de la gestion de son routage et de sa sécurité. Assurez-vous que votre réseau VPC dispose d'une route par défaut (0.0.0.0/0) pour transférer ce trafic vers vos passerelles sortantes ou vos dispositifs de sécurité (tels que les pare-feu de prochain saut ou les interfaces Cloud Interconnect).
  • Sortie vers l'Internet public : l'Agent Gateway envoie le trafic sortant vers votre réseau VPC, où il sort vers l'Internet public via une passerelle Cloud NAT sur le sous-réseau de rattachement de réseau Private Service Connect. Si vous attribuez des adresses IP externes statiques à la passerelle Cloud NAT, les services à distance peuvent ajouter le trafic sortant de vos agents à une liste d'autorisation en fonction de ces adresses IP sources.
  • VPC Service Controls : le mode Sortie doit être défini sur ALL_TRAFFIC pour prendre en charge les périmètres de service VPC Service Controls.

Résolution DNS et routage du trafic

Par défaut, Agent Gateway résout les noms de domaine à l'aide du DNS récursif public. Si vos agents doivent accéder à des charges de travail internes, à des outils privés ou à des API Google hébergées sur des noms de domaine privés dans votre réseau VPC (tels que corp.internal. ou des points de terminaison PSC), vous pouvez configurer l'appairage Cloud DNS pour transférer les requêtes DNS vers les zones privées gérées par Cloud DNS de votre réseau.

Le tableau suivant récapitule les exigences relatives au peering Cloud DNS et le comportement de routage du trafic pour différentes destinations lorsque la connectivité VPC est configurée en mode ALL_TRAFFIC :

Exigences concernant les certificats TLS

Lors du routage du trafic de sortie sur HTTPS, Agent Gateway valide la chaîne de certificats TLS du serveur de destination lors du handshake TLS. Les exigences relatives aux certificats pour les connexions HTTPS dépendent du fait que vos points de terminaison cibles utilisent des autorités de certification (CA) publiques de confiance ou des CA privées/autosignées.

• Autorités de certification publiques : par défaut, Agent Gateway approuve les certificats émis par des autorités de certification (AC) approuvées publiquement qui répondent aux exigences standards concernant les certificats de serveur (y compris un autre nom de l'objet (SAN) correspondant au nom d'hôte cible).

• AC privées et certificats autosignés : si votre destination cible (agents, outils ou serveurs MCP dans votre réseau VPC) utilise une AC privée ou une PKI interne, vous pouvez configurer des ancres de confiance personnalisées à l'aide du paramètre tlsConfig dans votre modèle de connectivité. En référençant une ressource TrustConfig Certificate Manager, vous pouvez configurer Agent Gateway pour qu'il n'approuve que des autorités de certification privées spécifiques, ou combiner des autorités de certification racine privées avec des autorités de certification approuvées publiquement pour établir une relation de confiance pour les points de terminaison publics et privés.

  Lorsque vous utilisez des trustConfig pour acheminer le trafic vers des destinations qui utilisent des CA privées, vous devez faire tourner les fichiers PEM manuellement. La rotation automatisée des fichiers PEM à l'aide de gestionnaires de secrets, tels que Secret Manager deCloud de Confiance, n'est pas prise en charge.

Si Agent Gateway ne parvient pas à valider la chaîne de certificats, la connexion échoue.

Rôles et autorisations nécessaires

Pour configurer la connectivité VPC pour Agent Gateway, assurez-vous que l'identité utilisée pour le provisionnement et l'agent de service de la passerelle disposent des rôles requis.

Déploiements de projets autonomes

Dans un projet autonome où la passerelle, le rattachement de réseau et le réseau VPC résident dans le même projet, les autorisations standards de l'Agent Gateway s'appliquent. Pour en savoir plus, consultez Autorisations requises.

Déploiements de VPC partagé ou inter-projets

Si vous utilisez un VPC partagé ou une configuration inter-projets dans laquelle le réseau VPC cible, le rattachement de réseau ou les zones DNS privées résident dans un projet hôte central (TARGET_VPC_PROJECT_ID), les rôles suivants sont requis en plus des autorisations standards de l'Agent Gateway :

Configurer la connectivité VPC

Pour déployer un Agent Gateway avec un modèle de connectivité, procédez comme suit :

1. Créez un rattachement de réseau Private Service Connect dans votre réseau VPC cible.

   Assurez-vous que votre rattachement de réseau répond aux exigences suivantes :

   • Préférences de connexion : configurez le rattachement de réseau pour accepter automatiquement les connexions (--connection-preference=ACCEPT_AUTOMATIC).
   • Exigence concernant le même réseau VPC : le sous-réseau du rattachement de réseau et le réseau cible configuré pour l'appairage DNS (targetNetwork) doivent se trouver exactement dans le même réseau VPC. Si le sous-réseau du rattachement de réseau appartient à un réseau différent de celui du réseau cible de l'appairage DNS, la validation de la configuration échoue.
   • Exigences concernant les sous-réseaux : notez les exigences suivantes concernant le sous-réseau de l'association réseau :
     • Plage de sous-réseaux : le sous-réseau de rattachement de réseau est compatible avec toutes les plages valides.
     • Taille du sous-réseau : Agent Gateway nécessite un sous-réseau /28 minimum pour le rattachement de réseau. Un sous-réseau /28 fournit 12 adresses IP utilisables, ce qui est suffisant pour une seule instance Agent Gateway. Si vous prévoyez de connecter plusieurs passerelles au même rattachement de réseau ou sous-réseau, utilisez un sous-réseau plus grand (tel que /26 ou /24) pour éviter l'épuisement des adresses IP.
     • Exigence concernant l'accès privé à Google : vous devez activer l'accès privé à Google (private_ip_google_access = true) sur le sous-réseau hébergeant le rattachement de réseau.
   • Déploiements de VPC partagé : pour les déploiements de VPC partagé, consultez Topologies de déploiement de VPC partagé.

   Notez l'URI du rattachement de réseau. Vous en aurez besoin lorsque vous mettrez à jour l'attribut PSC_NETWORK_ATTACHMENT_URI de la ressource de modèle de connectivité lors d'une prochaine étape.

2. Configurer l'appairage DNS (facultatif) : l'appairage DNS permet à Agent Gateway de résoudre les noms DNS à l'aide des enregistrements d'une zone gérée privée Cloud DNS dans votre réseau VPC. L'appairage DNS n'est requis que lorsque vos agents doivent résoudre des noms de domaine internes privés (tels que corp.internal.) ou appliquer VPC Service Controls pour les API Google (googleapis.com.). Il n'est pas requis pour les domaines Internet publics ni pour les API Google standards sans VPC Service Controls.

   Agent Gateway n'accepte l'appairage DNS transitif que jusqu'à un seul saut transitif, ce qui signifie un maximum de trois réseaux VPC. Par exemple, vpc-net-a (réseau locataire de la passerelle d'agent) peut s'appairer à vpc-net-b (réseau associé), qui à son tour s'appaire à vpc-net-c (réseau distant) pour résoudre les requêtes DNS dans la chaîne.

   Pour configurer le peering DNS, procédez comme suit :

   1. Configurez votre zone DNS privée dans votre réseau VPC cible. Pour ajouter des enregistrements DNS à votre zone DNS privée, consultez Ajouter un ensemble d'enregistrements de ressources.

   2. Rassemblez les informations suivantes pour configurer le modèle de connectivité afin d'activer l'appairage :

      • URI du réseau cible (targetNetwork) : URI complet de la ressource du réseau VPC cible. Il doit s'agir du même réseau VPC que celui contenant le rattachement de réseau.

      • Noms de domaine : un ou plusieurs suffixes de domaine pour l'appairage DNS. Chaque domaine doit se terminer par un point (.), par exemple corp.internal. ou googleapis.com..

        Pour obtenir des conseils supplémentaires sur la configuration du champ domains, consultez Modèles de domaines pour le peering DNS. Pour les déploiements inter-projets tels que le VPC partagé, consultez Exigences concernant l'appairage et les zones DNS inter-projets.

3. Configurez la configuration de confiance TLS (uniquement pour les destinations avec des autorités de certification privées et des certificats autosignés) :

   Si votre destination cible utilise une autorité de certification privée ou un certificat autosigné, vous devez créer une ressource TrustConfig dans le gestionnaire de certificats. La ressource TrustConfig définit les ancres de confiance et les certificats qu'Agent Gateway utilise pour valider les connexions TLS.

   1. Préparez vos fichiers de certificat au format PEM :

      • Magasin de confiance : certificats CA racines ou intermédiaires au format PEM. Agent Gateway approuve tout certificat de serveur dont la chaîne de confiance mène à l'un de ces certificats d'autorité de certification. Le magasin de confiance doit contenir au moins un certificat CA racine ou intermédiaire.
      • Certificats autorisés (facultatif) : certificats de serveur au format PEM que vous souhaitez approuver explicitement, comme un certificat autosigné.

   2. Exécutez la commande suivante pour créer la ressource TrustConfig. Le TrustConfig doit être créé dans le même projet et la même région que la passerelle d'agent et le modèle de connectivité.

      gcloud certificate-manager trust-configs create TRUST_CONFIG_NAME \
        --location=LOCATION \
        --trust-store="trust-anchors=ROOT_CERT_FILE" \
        --allowlisted-certificates=ALLOWLISTED_CERT_FILE
      

      Remplacez les éléments suivants :

      • TRUST_CONFIG_NAME : nom de la ressource TrustConfig.
      • LOCATION : région de la configuration de l'approbation (par exemple, europe-west1). Elle doit être identique à celle de l'Agent Gateway et du modèle de connectivité.
      • ROOT_CERT_FILE : chemin d'accès à votre certificat CA racine ou intermédiaire encodé au format PEM.
      • ALLOWLISTED_CERT_FILE : (facultatif) chemin d'accès à un certificat encodé en PEM que vous souhaitez approuver explicitement. Si vous n'utilisez pas de certificats ajoutés à la liste d'autorisation, omettez ce flag.

      Pour en savoir plus sur la gestion des configurations de confiance, consultez Créer et gérer des configurations de confiance.

4. Déployer Agent Gateway

   1. Créez le fichier de configuration du modèle de connectivité :

      Créez un fichier YAML nommé agw-connectivity-template.yaml :

      name: projects/AGENT_GATEWAY_PROJECT_NUMBER/locations/LOCATION/agentConnectivityTemplates/CONNECTIVITY_TEMPLATE_NAME
      accessPath: AGENT_TO_ANYWHERE
      deploymentModel: CENTRALIZED
      egressNetworkConfig:
        networkAttachment: PSC_NETWORK_ATTACHMENT_URI
        dnsPeeringConfig:
          domains:
            - DOMAIN_NAME
          targetNetwork: TARGET_VPC_NETWORK_URI
        vpcEgress: VPC_EGRESS_MODE
        tlsConfig:
          trustConfig: projects/AGENT_GATEWAY_PROJECT_NUMBER/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
          additionalRoots: ADDITIONAL_ROOTS_OPTION
      

      Remplacez les éléments suivants :

      • AGENT_GATEWAY_PROJECT_NUMBER : numéro du projet Cloud de Confiance dans lequel la passerelle est déployée. Pour récupérer le numéro de votre projet, exécutez la commande suivante : gcloud projects describe PROJECT_ID --format="value(projectNumber)".

      • LOCATION : région du modèle de connectivité (par exemple, europe-west1).

      • CONNECTIVITY_TEMPLATE_NAME : nom de la ressource de modèle de connectivité.

      • accessPath : chemin d'accès contrôlé pour le modèle de connectivité. Définissez la valeur sur AGENT_TO_ANYWHERE (les modèles de connectivité ne sont compatibles qu'avec les passerelles de sortie).

      • deploymentModel : modèle de déploiement de la passerelle. Défini sur CENTRALIZED.

      • PSC_NETWORK_ATTACHMENT_URI : rattachement de réseau de l'interface PSC pour la connectivité aux VPC. Si le rattachement de réseau est créé dans un projet différent de celui dans lequel vous avez déployé la passerelle (par exemple, le projet hôte de VPC partagé), transmettez le chemin d'accès complet de votre rattachement de réseau : projects/TARGET_VPC_PROJECT_ID/regions/REGION/networkAttachments/ATTACHMENT_NAME.

      • DOMAIN_NAME : (Facultatif) Un ou plusieurs suffixes de domaine pour l'appairage DNS (par exemple, corp.internal., googleapis.com. ou .). Ajoutez un élément de liste sous domains pour chaque suffixe de domaine que vous souhaitez appairer. Chaque valeur doit se terminer par un point (.) et être associée à une zone gérée Cloud DNS privée autorisée pour le réseau cible.

        Pour obtenir des conseils supplémentaires sur la configuration du champ domains, consultez Modèles de domaines pour le peering DNS.

      • TARGET_VPC_NETWORK_URI : réseau VPC cible dans lequel vous avez créé le rattachement de réseau. Elle doit se présenter au format suivant : projects/TARGET_VPC_PROJECT_ID/global/networks/TARGET_VPC_NETWORK_NAME. Spécifiez toujours targetNetwork à l'aide de l'ID du projet (TARGET_VPC_PROJECT_ID) plutôt que du numéro du projet.

      • VPC_EGRESS_MODE : définissez le mode de routage de sortie. Définissez cette valeur sur PRIVATE_RANGES_ONLY ou ALL_TRAFFIC.

      • tlsConfig : (facultatif) configuration TLS pour la validation du certificat de serveur lors de la connexion à des points de terminaison privés via HTTPS :

        • TRUST_CONFIG_NAME : nom de la ressource TrustConfig du Certificate Manager contenant vos certificats d'autorité de certification privée ou vos ancres de confiance.
        • ADDITIONAL_ROOTS_OPTION : spécifie s'il faut faire confiance aux racines d'AC publiques en plus de votre configuration de confiance personnalisée. Définissez la valeur sur PUBLICLY_TRUSTED_ROOTS (par défaut) pour approuver à la fois les certificats validés par le paramètre trustConfig et toutes les autorités de certification publiques approuvées. Définissez sur NO_ADDITIONAL_ROOTS pour n'approuver que les certificats validés par le paramètre trustConfig.

   2. Créez le modèle de connectivité :

      Exécutez la commande suivante pour créer le modèle de connectivité :

      gcloud network-services agent-connectivity-templates import CONNECTIVITY_TEMPLATE_NAME \
          --source="agw-connectivity-template.yaml" \
          --location=LOCATION
      

      Remplacez les éléments suivants :

      • CONNECTIVITY_TEMPLATE_NAME : nom de la ressource de modèle de connectivité.
      • LOCATION : emplacement où vous souhaitez créer la ressource de modèle de connectivité. Exemple :europe-west1

   3. Définissez la ressource Agent Gateway :

      Définissez une nouvelle ressource Agent Gateway en mode AGENT_TO_ANYWHERE en créant un fichier de configuration YAML de passerelle (par exemple, my-agent-gateway-vpc-egress.yaml) qui fait référence au modèle de connectivité :

      name: AGENT_GATEWAY_NAME
      protocols:
        - MCP
      googleManaged:
        governedAccessPath: AGENT_TO_ANYWHERE
      agentConnectivityTemplate: projects/AGENT_GATEWAY_PROJECT_NUMBER/locations/LOCATION/agentConnectivityTemplates/CONNECTIVITY_TEMPLATE_NAME
      registries:
        - AGENT_REGISTRY_PATH
      

      Remplacez les éléments suivants :

      • AGENT_GATEWAY_NAME : nom de la ressource Agent Gateway.

      • AGENT_GATEWAY_PROJECT_NUMBER : numéro du projet Cloud de Confiance dans lequel vous avez créé la passerelle et le modèle de connectivité. Pour récupérer le numéro de votre projet, exécutez la commande suivante : gcloud projects describe PROJECT_ID --format="value(projectNumber)".

      • LOCATION : emplacement du modèle de connectivité (par exemple, europe-west1).

      • CONNECTIVITY_TEMPLATE_NAME : nom de la ressource de modèle de connectivité.

      • AGENT_REGISTRY_PATH : chemin d'accès à l'Agent Registry. Vous pouvez configurer jusqu'à deux registres pour une passerelle d'agent. Lorsque vous configurez deux registres, l'un doit être un registre mondial et l'autre peut être un registre régional ou multirégional. Les chemins d'accès au registre doivent être mis en forme comme suit :

        • Registres régionaux : //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION
        • Registres mondiaux : //agentregistry.googleapis.com/projects/PROJECT_ID/locations/global
        • Registres multirégionaux : //agentregistry.googleapis.com/projects/PROJECT_ID/locations/MULTI_REGION

   4. Importer et déployer Agent Gateway :

      Exécutez la commande suivante pour créer la ressource Agent Gateway en fonction de la spécification YAML :

      gcloud network-services agent-gateways import AGENT_GATEWAY_NAME \
          --source="my-agent-gateway-vpc-egress.yaml" \
          --location=LOCATION
      

      Remplacez LOCATION par l'emplacement où vous souhaitez créer la ressource Agent Gateway. Exemple : europe-west1.

Considérations sur l'architecture et la mise en réseau

Cette section fournit des conseils sur l'architecture et des modèles de mise en réseau avancés pour déployer Agent Gateway avec la connectivité VPC.

Mettre à jour les paramètres de sortie VPC

Il est impossible de modifier un modèle de connectivité lorsqu'il est référencé par une passerelle d'agent.

• Pour mettre à jour les paramètres de sortie VPC modifiables (tels que la configuration d'appairage DNS, le mode de sortie VPC ou la configuration TLS), vous devez créer un modèle de connectivité qui utilise le même networkAttachment et mettre à jour l'Agent Gateway pour qu'elle référence le nouveau modèle.

• Le networkAttachment lui-même est immuable une fois configuré sur une passerelle d'agent. Pour passer à un autre rattachement de réseau (ou à un autre réseau VPC cible), vous devez créer un nouveau modèle de connectivité et un nouvel Agent Gateway.

Topologies de déploiement du VPC partagé

Dans une architecture de VPC partagé, vous pouvez créer le rattachement de réseau dans le projet de service (recommandé) ou dans le projet hôte :

• Recommandé : rattachement de réseau dans le projet de service :
  1. Créez le sous-réseau dans le projet hôte.
  2. Créez le rattachement de réseau dans le projet de service, en faisant référence au sous-réseau du projet hôte.
• Rattachement de réseau dans le projet hôte :
  1. Créez le sous-réseau dans le projet hôte.
  2. Créez le rattachement de réseau dans le projet hôte.

Conformité avec VPC Service Controls

Pour appliquer les périmètres VPC Service Controls aux communications des agents, assurez-vous des points suivants :

• Définissez vpcEgress sur ALL_TRAFFIC dans votre modèle de connectivité.

• Dirigez les requêtes d'API Google directement vers la plage d'adresses IP restricted.googleapis.com (199.36.153.4/30) ou vers un point de terminaison Private Service Connect interne pour les API Google.

• Configurez la résolution DNS pour googleapis.com. Créez une zone Cloud DNS privée dans votre réseau VPC en mappant *.googleapis.com sur restricted.googleapis.com, puis incluez googleapis.com. dans le champ domains de votre modèle de connectivité.

  Pour en savoir plus sur la configuration DNS, consultez Configurer le DNS pour googleapis.com dans la documentation sur l'accès privé à Google.

• Pour les déploiements de VPC partagé, le projet hôte propriétaire du sous-réseau et de l'dnsPeeringConfig.targetNetwork de l'association réseau doit se trouver dans le même périmètre de service que le projet dans lequel vous déployez l'Agent Gateway. Cela s'applique même lorsque vous créez le rattachement de réseau dans le projet de service, car le sous-réseau et le réseau VPC appartiennent toujours au projet hôte. Si vos zones DNS privées sont hébergées dans un projet DNS distinct, incluez également ce projet dans le périmètre.

Schémas de domaine d'appairage DNS

Cette section décrit les modèles de résolution de domaine et les options de configuration du champ domains dans un modèle de connectivité.

Configuration du nom de domaine : configurez le champ domains dans le modèle de connectivité en fonction des considérations suivantes :

• Domaines internes privés : pour résoudre les services internes privés hébergés dans votre réseau VPC (par exemple, service.corp.internal), spécifiez votre suffixe de domaine interne (par exemple, corp.internal.). Une zone gérée Cloud DNS privée correspondant exactement à ce domaine doit être autorisée pour le réseau VPC cible.

• DNS split-horizon (domaine public avec adresse IP RFC 1918) : si vous utilisez une zone DNS publique pour héberger des enregistrements pointant vers des adresses IP privées internes (par exemple, mcp.example.com résolvant une adresse RFC 1918 pour les certificats publics Certificate Manager), la passerelle résout automatiquement ces enregistrements à l'aide du DNS récursif public sans nécessiter d'appairage DNS.

• APICloud de Confiance avec VPC Service Controls : lorsque ALL_TRAFFIC est configuré pour appliquer VPC Service Controls, les requêtes d'API Google doivent être résolues dans la plage d'adresses IP restricted.googleapis.com (199.36.153.4/30) ou dans les points de terminaison PSC internes. Créez une zone Cloud DNS privée dans votre réseau VPC en mappant *.googleapis.com sur restricted.googleapis.com, puis incluez googleapis.com. dans le champ domains de votre modèle de connectivité.

• Schémas de résolution multidomaine : si votre déploiement nécessite la résolution de plusieurs suffixes de domaine privé, choisissez l'un des schémas suivants :

  • Appairer plusieurs domaines individuels : spécifiez une liste de suffixes de domaine dans le champ domains de dnsPeeringConfig (par exemple, corp.internal., prod.internal. et googleapis.com.). Chaque domaine de la liste doit se terminer par un point (.) et disposer d'une zone gérée Cloud DNS privée correspondante autorisée pour le réseau VPC cible.
  • Suffixe parent consolidé (recommandé) : consolidez les services internes sous un suffixe de domaine parent partagé (tel que *.internal. ou *.corp.internal.), puis incluez ce domaine parent dans la liste domains.

  • Appairage racine générique avec une zone de transfert privée : incluez "." dans le champ domains du modèle de connectivité, puis configurez une zone de transfert privée Cloud DNS pour le domaine racine (.) dans votre réseau VPC pointant vers un résolveur récursif en amont (tel que 8.8.8.8 ou un résolveur d'entreprise interne). Les zones privées les plus spécifiques de votre VPC sont d'abord mises en correspondance par la correspondance du suffixe le plus long, tandis que les requêtes publiques non mises en correspondance sont résolues par le redirecteur en amont.

Exigences concernant les zones DNS et l'appairage multiprojets

Le paramètre dnsPeeringConfig du modèle de connectivité n'est pas compatible avec l'appairage Cloud DNS interprojets direct. Lorsque vous importez le modèle de connectivité, la validation échoue si le targetNetwork se trouve dans un projet différent de celui du networkAttachment, ou si vous vous appuyez sur la liaison de zone DNS inter-projets à partir d'un service ou d'un projet externe.

La zone gérée pour le domaine doit être créée dans le projet hôte qui possède targetNetwork. La zone gérée peut être l'un des types de zones suivants :

• Zone privée faisant autorité
• Zone de transfert
• Zone d'appairage Cloud DNS : doit être associée au réseau VPC du projet hôte et cibler un réseau VPC de destination. Le VPC de destination doit résoudre la requête directement à l'aide d'une zone privée faisant autorité. Le transfert de la requête vers une autre zone d'appairage DNS (chaînage) n'est pas pris en charge et génère une erreur NXDOMAIN.

Étapes suivantes