Configura Agent Gateway con la connettività VPC

Questo documento ti guida nella procedura di configurazione della connettività VPC durante il deployment di un Agent Gateway in modo che possa comunicare privatamente con una rete VPC nella tua organizzazione.

La configurazione della connettività VPC ti consente di:

• Forza l'uscita VPC per il traffico: instrada il traffico proveniente dai tuoi agenti tramite l'allegato di rete Private Service Connect nella tua rete VPC utilizzando la modalità PRIVATE_RANGES_ONLY o ALL_TRAFFIC.
• Intervallo di indirizzi IP di origine statici: il traffico in uscita utilizza l'intervallo di indirizzi IP privati della subnet di collegamento di rete Private Service Connect come indirizzo IP di origine. Questo intervallo di indirizzi IP di origine statici ti consente di configurare le policy firewall per la tua rete VPC in modo da controllare il traffico proveniente dal gateway.
• Risoluzione DNS personalizzata: risolvi i nomi di dominio privati interni e i nomi di dominio esterni direttamente dagli agenti utilizzando il peering Cloud DNS.
• Sicurezza del perimetro: proteggi le comunicazioni degli agenti utilizzando i perimetri di servizio dei Controlli di servizio VPC.
• Convalida di certificati privati o autofirmati: connettiti alle destinazioni che utilizzano CA private o certificati autofirmati.

Per configurare la connettività VPC, crea un modello di connettività di Agent Gateway (AgentConnectivityTemplate) in cui definisci e gestisci le impostazioni di rete in uscita per le istanze di Agent Gateway.

Come funziona la connettività VPC

Quando fai il deployment di un Agent Gateway con un modello di connettività, il gateway utilizza un'interfaccia Private Service Connect per instradare il traffico in uscita dell'agente nella rete VPC designata.

Modalità di uscita VPC

Configura il modo in cui il gateway instrada il traffico tramite il collegamento di rete utilizzando l'impostazione vpcEgress nel modello di connettività.

• Traffico verso intervalli di indirizzi IP privati (PRIVATE_RANGES_ONLY): indirizza il traffico destinato solo a intervalli di indirizzi IP privati nella tua rete VPC. Il traffico in uscita viene instradato nella tua rete VPC solo se l'indirizzo IP di destinazione rientra in uno dei seguenti intervalli:

  • 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
  • Endpoint PSC per le API di Google: se implementi un endpoint Private Service Connect personalizzato per le API di Google utilizzando un indirizzo IP privato interno nella tua rete VPC, il traffico verso questo endpoint viene instradato tramite la tua rete VPC. Assicurati che il peering Cloud DNS sia configurato nel modello di connettività in modo che Agent Gateway risolva correttamente i domini delle API di Google nell'indirizzo IP dell'endpoint PSC interno.

  Le richieste alle API di Google pubbliche standard vengono gestite automaticamente utilizzando l'accesso privato Google e il traffico diretto a internet viene instradato direttamente tramite Agent Gateway anziché tramite la rete VPC.

• Traffico verso tutti gli intervalli di indirizzi IP (ALL_TRAFFIC): instrada tutto il traffico in uscita proveniente dai tuoi agenti attraverso la tua rete VPC, inclusi internet pubblico, API SaaS esterne e indirizzi non RFC 1918.

  • Routing e sicurezza: poiché questa impostazione instrada tutto il traffico in uscita nel tuo VPC, sei responsabile della gestione del routing e della sicurezza. Assicurati che la tua rete VPC abbia una route predefinita (0.0.0.0/0) per inoltrare questo traffico ai tuoi gateway in uscita o alle tue appliance di sicurezza (come firewall next-hop o interfacce Cloud Interconnect).
  • Egress da internet pubblico: Agent Gateway invia il traffico in uscita nella tua rete VPC, da cui esce verso internet pubblico tramite un gateway Cloud NAT nella subnet di collegamento di rete Private Service Connect. Se assegni indirizzi IP esterni statici al gateway Cloud NAT, i servizi remoti possono inserire nella lista consentita il traffico in uscita degli agenti in base a questi indirizzi IP di origine.
  • Controlli di servizio VPC: la modalità di uscita deve essere impostata su ALL_TRAFFIC per supportare i perimetri di servizio dei Controlli di servizio VPC.

Risoluzione DNS e routing del traffico

Per impostazione predefinita, Agent Gateway risolve i nomi di dominio utilizzando il DNS ricorsivo pubblico. Se i tuoi agenti devono accedere a carichi di lavoro interni, strumenti privati o API di Google ospitate su nomi di dominio privati nella tua rete VPC (come corp.internal. o endpoint PSC), puoi configurare il peering Cloud DNS per inoltrare le query DNS alle zone gestite Cloud DNS private della tua rete.

La tabella seguente riepiloga i requisiti di peering Cloud DNS e il comportamento di routing del traffico per diverse destinazioni quando la connettività VPC è configurata in modalità ALL_TRAFFIC:

Requisiti per i certificati TLS

Quando esegue il routing del traffico in uscita su HTTPS, Agent Gateway convalida la catena di certificati TLS del server di destinazione durante l'handshake TLS. I requisiti dei certificati per le connessioni HTTPS dipendono dal fatto che gli endpoint di destinazione utilizzino autorità di certificazione (CA) attendibili pubblicamente o CA private/autofirmate.

• CA pubbliche: per impostazione predefinita, Agent Gateway considera attendibili i certificati emessi da autorità di certificazione (CA) attendibili pubblicamente che soddisfano i requisiti standard per i certificati del server (incluso un nome alternativo del soggetto (SAN) corrispondente al nome host di destinazione).

• CA private e certificati autofirmati: se la destinazione di destinazione (agenti, strumenti o server MCP nella rete VPC) utilizza una CA privata o una PKI interna, puoi configurare trust anchor personalizzati utilizzando l'impostazione tlsConfig nel modello di connettività. Se fai riferimento a una risorsa di Certificate Manager TrustConfig, puoi configurare Agent Gateway in modo che consideri attendibili solo CA private specifiche oppure combinare CA radice private con CA attendibili pubblicamente per stabilire l'attendibilità sia per gli endpoint pubblici che per quelli privati.

  Quando utilizzi trustConfig per indirizzare il traffico verso destinazioni che utilizzano CA private, devi ruotare manualmente i file PEM. La rotazione automatica dei file PEM utilizzando i gestori dei secret, come Secret Manager di Cloud de Confiance, non è supportata.

Se Agent Gateway non è in grado di convalidare la catena di certificati, la connessione non va a buon fine.

Ruoli e autorizzazioni richiesti

Per configurare la connettività VPC per Agent Gateway, assicurati che l'identità utilizzata per il provisioning e l'agente di servizio gateway dispongano dei ruoli richiesti.

Deployment di progetti autonomi

In un progetto autonomo in cui il gateway, il collegamento di rete e la rete VPC si trovano nello stesso progetto, si applicano le autorizzazioni standard dell'Agent Gateway. Per maggiori dettagli, vedi Autorizzazioni richieste.

Deployment VPC condiviso o tra progetti

Se utilizzi un VPC condiviso o una configurazione tra progetti in cui la rete VPC di destinazione, il collegamento di rete o le zone DNS private si trovano in un progetto host centrale (TARGET_VPC_PROJECT_ID), sono necessari i seguenti ruoli oltre alle autorizzazioni standard di Agent Gateway:

Configura la connettività VPC

Per eseguire il deployment di un Agent Gateway con un modello di connettività, segui questi passaggi:

1. Crea un collegamento di rete Private Service Connect nella tua rete VPC di destinazione.

   Assicurati che il collegamento di rete soddisfi i seguenti requisiti:

   • Preferenza di connessione: configura il collegamento di rete in modo da accettare automaticamente le connessioni (--connection-preference=ACCEPT_AUTOMATIC).
   • Requisito della stessa rete VPC: la subnet del collegamento di rete e la rete di destinazione configurata per il peering DNS (targetNetwork) devono trovarsi esattamente nella stessa rete VPC. Se la subnet dell'allegato di rete appartiene a una rete diversa da quella di destinazione del peering DNS, la convalida della configurazione non va a buon fine.
   • Requisiti della subnet: tieni presente i seguenti requisiti per la subnet dell'allegato di rete:
     • Intervallo di subnet: la subnet di collegamento di rete supporta tutti gli intervalli validi.
     • Dimensioni della subnet: Agent Gateway richiede una subnet minima /28 per il collegamento di rete. Una subnet /28 fornisce 12 indirizzi IP utilizzabili, sufficienti per una singola istanza di Agent Gateway. Se prevedi di connettere più gateway allo stesso collegamento di rete o alla stessa subnet, utilizza una subnet più grande (ad esempio /26 o /24) per evitare l'esaurimento degli indirizzi IP.
     • Requisito di accesso privato Google: devi abilitare l'accesso privato Google (private_ip_google_access = true) sulla subnet che ospita il collegamento di rete.
   • Deployment VPC condiviso: per i deployment VPC condiviso, consulta Topologie di deployment VPC condiviso.

   Prendi nota dell'URI del collegamento di rete. Ti servirà quando aggiornerai l'attributo PSC_NETWORK_ATTACHMENT_URI della risorsa modello di connettività in un passaggio successivo.

2. Configura il peering DNS (facoltativo): il peering DNS consente ad Agent Gateway di risolvere i nomi DNS utilizzando i record di una zona privata gestita di Cloud DNS nella tua rete VPC. Il peering DNS è necessario solo quando gli agenti devono risolvere nomi di dominio interni privati (ad esempio corp.internal.) o applicare i Controlli di servizio VPC per le API di Google (googleapis.com.). Non è necessario per i domini internet pubblici o le API di Google standard senza Controlli di servizio VPC.

   Agent Gateway supporta il peering DNS transitivo solo fino a un singolo hop transitivo, ovvero un massimo di tre reti VPC. Ad esempio, vpc-net-a (la rete tenant di Agent Gateway) può eseguire il peering con vpc-net-b (rete collegata), che a sua volta esegue il peering con vpc-net-c (rete remota) per risolvere le query DNS nella catena.

   Per configurare il peering DNS, segui questi passaggi:

   1. Configura la zona DNS privata nella rete VPC di destinazione. Per aggiungere record DNS alla tua zona DNS privata, consulta Aggiungere un insieme di record di risorse.

   2. Raccogli le seguenti informazioni per configurare il modello di connettività per abilitare il peering:

      • URI di rete di destinazione (targetNetwork): l'URI completo della risorsa della rete VPC di destinazione. Questa deve essere la stessa rete VPC che contiene il collegamento di rete.

      • Nomi di dominio: uno o più suffissi di dominio per il peering DNS. Ogni dominio deve terminare con un punto finale (.), ad esempio corp.internal. o googleapis.com..

        Per ulteriori indicazioni su come configurare il campo domains, consulta Pattern di dominio di peering DNS. Per i deployment tra progetti come VPC condiviso, consulta Requisiti per il peering e le zone DNS tra progetti.

3. Configura l'attendibilità TLS (solo per le destinazioni con CA private e certificati autofirmati):

   Se la destinazione di destinazione utilizza un certificato autofirmato o una CA privata, devi creare una risorsa TrustConfig in Certificate Manager. La risorsa TrustConfig definisce le ancore di attendibilità e i certificati utilizzati da Agent Gateway per convalidare le connessioni TLS.

   1. Prepara i file dei certificati in formato PEM:

      • Archivio di attendibilità: certificati CA radice o intermedi in formato PEM. Agent Gateway considera attendibile qualsiasi certificato del server la cui catena di attendibilità porta a uno di questi certificati CA. L'archivio di attendibilità deve contenere almeno un certificato CA radice o intermedio.
      • Certificati inclusi nella lista consentita (facoltativo) : certificati server in formato PEM di cui vuoi considerare attendibile in modo esplicito, ad esempio un certificato autofirmato.

   2. Esegui il comando seguente per creare la risorsa TrustConfig. Il TrustConfig deve essere creato nello stesso progetto e nella stessa regione di Agent Gateway e del modello di connettività.

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

      Sostituisci quanto segue:

      • TRUST_CONFIG_NAME: un nome per la risorsa TrustConfig.
      • LOCATION: la regione per la configurazione del trust (ad esempio europe-west1). Deve essere la stessa regione dell'Agent Gateway e del modello di connettività.
      • ROOT_CERT_FILE: il percorso del certificato CA radice o intermedio con codifica PEM.
      • ALLOWLISTED_CERT_FILE: (facoltativo) il percorso di un certificato con codifica PEM di cui vuoi considerare attendibile in modo esplicito. Se non utilizzi certificati consentiti, ometti questo flag.

      Per saperne di più sulla gestione delle configurazioni di attendibilità, consulta Creare e gestire le configurazioni di attendibilità.

4. Esegui il deployment di Agent Gateway

   1. Crea il file di configurazione del modello di connettività:

      Crea un file YAML denominato 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
      

      Sostituisci quanto segue:

      • AGENT_GATEWAY_PROJECT_NUMBER: il numero di progetto numerico del progetto Cloud de Confiance in cui viene eseguito il deployment del gateway. Per recuperare il numero di progetto, esegui: gcloud projects describe PROJECT_ID --format="value(projectNumber)".

      • LOCATION: la regione per il modello di connettività (ad esempio europe-west1).

      • CONNECTIVITY_TEMPLATE_NAME: il nome della risorsa del modello di connettività.

      • accessPath: il percorso di accesso controllato per il modello di connettività. Imposta su AGENT_TO_ANYWHERE (i modelli di connettività sono supportati solo per i gateway di uscita).

      • deploymentModel: il modello di deployment per il gateway. Impostalo su CENTRALIZED.

      • PSC_NETWORK_ATTACHMENT_URI: il collegamento di rete dell'interfaccia PSC per la connettività ai VPC. Se il collegamento di rete viene creato in un progetto diverso da quello in cui hai eseguito il deployment del gateway (ad esempio il progetto host VPC condiviso), passa il percorso completo del collegamento di rete: projects/TARGET_VPC_PROJECT_ID/regions/REGION/networkAttachments/ATTACHMENT_NAME.

      • DOMAIN_NAME: (facoltativo) Uno o più suffissi di dominio per il peering DNS (ad esempio corp.internal., googleapis.com. o .). Aggiungi un elemento di elenco in domains per ogni suffisso di dominio di cui vuoi eseguire il peering. Ogni valore deve terminare con un punto finale (.) e avere una zona gestita privata Cloud DNS corrispondente autorizzata per la rete di destinazione.

        Per ulteriori indicazioni su come configurare il campo domains, consulta Pattern di dominio di peering DNS.

      • TARGET_VPC_NETWORK_URI: la rete VPC di destinazione in cui hai creato il collegamento di rete. Deve essere nel formato: projects/TARGET_VPC_PROJECT_ID/global/networks/TARGET_VPC_NETWORK_NAME. Specifica sempre targetNetwork utilizzando l'ID progetto (TARGET_VPC_PROJECT_ID) anziché il numero di progetto.

      • VPC_EGRESS_MODE: imposta la modalità di routing in uscita. Imposta su PRIVATE_RANGES_ONLY o ALL_TRAFFIC.

      • tlsConfig: (facoltativo) la configurazione TLS per la convalida del certificato del server durante la connessione a endpoint privati tramite HTTPS:

        • TRUST_CONFIG_NAME: il nome della risorsa TrustConfig di Certificate Manager contenente i certificati CA privati o gli ancoraggi attendibili.
        • ADDITIONAL_ROOTS_OPTION: specifica se considerare attendibili le radici delle CA attendibili pubblicamente oltre alla configurazione di attendibilità personalizzata. Imposta PUBLICLY_TRUSTED_ROOTS (impostazione predefinita) per considerare attendibili sia i certificati convalidati dal parametro trustConfig sia tutte le CA pubblicamente attendibili. Imposta NO_ADDITIONAL_ROOTS per considerare attendibili solo i certificati convalidati dal parametro trustConfig.

   2. Crea il modello di connettività:

      Esegui questo comando per creare il modello di connettività:

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

      Sostituisci quanto segue:

      • CONNECTIVITY_TEMPLATE_NAME: il nome della risorsa del modello di connettività.
      • LOCATION: la località in cui vuoi creare la risorsa modello di connettività. Ad esempio, europe-west1.

   3. Definisci la risorsa Agent Gateway:

      Definisci una nuova risorsa Agent Gateway in modalità AGENT_TO_ANYWHERE creando un file di configurazione YAML del gateway (ad esempio, my-agent-gateway-vpc-egress.yaml) che faccia riferimento al modello di connettività:

      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
      

      Sostituisci quanto segue:

      • AGENT_GATEWAY_NAME: il nome della risorsa Agent Gateway.

      • AGENT_GATEWAY_PROJECT_NUMBER: il numero di progetto numerico del progetto Cloud de Confiance in cui hai creato il gateway e il modello di connettività. Per recuperare il numero di progetto, esegui: gcloud projects describe PROJECT_ID --format="value(projectNumber)".

      • LOCATION: la posizione del modello di connettività (ad esempio europe-west1).

      • CONNECTIVITY_TEMPLATE_NAME: il nome della risorsa del modello di connettività.

      • AGENT_REGISTRY_PATH: il percorso dell'Agent Registry. Puoi configurare fino a due registry per un Agent Gateway. Quando configuri due registri, uno deve essere un registro globale e l'altro può essere un registro regionale o multiregionale. I percorsi del registro devono essere formattati come segue:

        • Registri regionali: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION
        • Registri globali: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/global
        • Registri multiregionali: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/MULTI_REGION

   4. Importa ed esegui il deployment di Agent Gateway:

      Esegui questo comando per creare la risorsa Agent Gateway in base alla specifica YAML:

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

      Sostituisci LOCATION con la località in cui vuoi creare la risorsa Agent Gateway. Ad esempio, europe-west1.

Considerazioni su architettura e networking

Questa sezione fornisce indicazioni sull'architettura e modelli di networking avanzati per il deployment di Agent Gateway con connettività VPC.

Aggiornamento delle impostazioni di traffico in uscita VPC

Un modello di connettività non può essere modificato se viene fatto riferimento a un Agent Gateway.

• Per aggiornare le impostazioni di uscita VPC modificabili (ad esempio la configurazione del peering DNS, la modalità di uscita VPC o la configurazione TLS), devi creare un nuovo modello di connettività che utilizzi lo stesso networkAttachment e aggiornare Agent Gateway in modo che faccia riferimento al nuovo modello.

• L'networkAttachment stesso è immutabile una volta configurato su un gateway dell'agente. Per passare a un diverso collegamento di rete (o rete VPC di destinazione), devi creare un nuovo modello di connettività e un nuovo Agent Gateway.

Topologie di deployment VPC condiviso

In un'architettura VPC condiviso, puoi creare il collegamento di rete nel progetto di servizio (consigliato) o nel progetto host:

• Consigliato: collegamento di rete nel progetto di servizio:
  1. Crea la subnet nel progetto host.
  2. Crea il collegamento di rete nel progetto di servizio, facendo riferimento alla subnet del progetto host.
• Collegamento di rete nel progetto host:
  1. Crea la subnet nel progetto host.
  2. Crea il collegamento di rete nel progetto host.

Conformità ai Controlli di servizio VPC

Per applicare i perimetri dei Controlli di servizio VPC per le comunicazioni dell'agente, assicurati che:

• Imposta vpcEgress su ALL_TRAFFIC nel modello di connettività.

• Invia richieste API di Google direttamente all'intervallo IP restricted.googleapis.com (199.36.153.4/30) o a un endpoint Private Service Connect interno per le API di Google.

• Configura la risoluzione DNS per googleapis.com. Crea una zona Cloud DNS privata nel mapping della rete VPC *.googleapis.com a restricted.googleapis.com e includi googleapis.com. nel campo domains del modello di connettività.

  Per ulteriori dettagli sulla configurazione DNS, consulta Configura il DNS per googleapis.com nella documentazione sull'accesso privato Google.

• Per i deployment VPC condiviso, il progetto host proprietario della subnet dell'allegato di rete e dnsPeeringConfig.targetNetwork devono trovarsi nello stesso perimetro di servizio del progetto in cui viene eseguito il deployment di Agent Gateway. Ciò vale anche quando crei il collegamento di rete nel progetto di servizio, perché la subnet e la rete VPC appartengono ancora al progetto host. Se le tue zone DNS private sono ospitate in un progetto DNS separato, includi anche questo progetto nel perimetro.

Pattern di dominio di peering DNS

Questa sezione descrive i pattern di risoluzione dei domini e le opzioni per configurare il campo domains in un modello di connettività.

Configurazione del nome di dominio: configura il campo domains nel modello di connettività in base alle seguenti considerazioni:

• Domini interni privati: per risolvere i servizi interni privati ospitati nella tua rete VPC (ad esempio service.corp.internal), specifica il suffisso del dominio interno (ad esempio corp.internal.). Una zona gestita Cloud DNS privata con corrispondenza esatta per questo dominio deve essere autorizzata per la rete VPC di destinazione.

• DNS split-horizon (dominio pubblico con IP RFC 1918): se utilizzi una zona DNS pubblica per ospitare record che puntano a IP privati interni (ad esempio mcp.example.com che si risolve in un indirizzo RFC 1918 per i certificati pubblici di Certificate Manager), il gateway risolve automaticamente questi record utilizzando il DNS ricorsivo pubblico senza richiedere il peering DNS.

• Cloud de Confiance API con Controlli di servizio VPC: quando ALL_TRAFFIC è configurato per applicare i Controlli di servizio VPC, le richieste API di Google devono essere risolte nell'intervallo IP restricted.googleapis.com (199.36.153.4/30) o negli endpoint PSC interni. Crea una zona Cloud DNS privata nel mapping della rete VPC *.googleapis.com a restricted.googleapis.com e includi googleapis.com. nel campo domains del modello di connettività.

• Pattern di risoluzione multi-dominio: se il tuo deployment richiede la risoluzione di più suffissi di dominio privato, scegli uno dei seguenti pattern:

  • Peering di più singoli domini: specifica un elenco di suffissi di dominio nel campo domains di dnsPeeringConfig (ad esempio, corp.internal., prod.internal. e googleapis.com.). Ogni dominio nell'elenco deve terminare con un punto finale (.) e avere una zona gestita privata Cloud DNS corrispondente autorizzata per la rete VPC di destinazione.
  • Suffisso principale consolidato (consigliato): consolida i servizi interni in un suffisso di dominio principale condiviso (ad esempio *.internal. o *.corp.internal.) e includi il dominio principale nell'elenco domains.

  • Peering della radice catch-all con una zona di forwarding privato: includi "." nel campo domains del modello di connettività e configura una zona di forwarding privato Cloud DNS per il dominio principale (.) nella tua rete VPC che punta a un resolver ricorsivo upstream (ad esempio 8.8.8.8 o un resolver aziendale interno). Le zone private più specifiche nel tuo VPC corrispondono innanzitutto alla corrispondenza del suffisso più lungo, mentre le query pubbliche senza corrispondenza vengono risolte tramite il forwarder upstream.

Requisiti per il peering e la zona DNS tra progetti

L'impostazione dnsPeeringConfig del modello di connettività non supporta il peering Cloud DNS diretto tra progetti. Quando importi il modello di connettività, la convalida non va a buon fine se targetNetwork si trova in un progetto diverso da networkAttachment o se ti affidi al binding della zona DNS tra progetti da un servizio o un progetto esterno.

La zona gestita per il dominio deve essere creata nel progetto host proprietario di targetNetwork. La zona gestita può essere uno dei seguenti tipi di zona:

• Zona privata autorevole
• Zona di forwarding
• Zona di peering Cloud DNS: deve essere associata alla rete VPC del progetto host e avere come target una rete VPC di destinazione. Il VPC di destinazione deve risolvere la query direttamente utilizzando una zona privata autorevole. L'inoltro della query a un'altra zona di peering DNS (concatenamento) non è supportato e genera un errore NXDOMAIN.

Passaggi successivi