Configurar o gateway de agente com conectividade VPC

Este documento orienta você no processo de configuração da conectividade da VPC ao implantar um gateway de agente para que ele possa se comunicar de forma particular com uma rede VPC na sua organização.

Ao configurar a conectividade da VPC, é possível fazer o seguinte:

• Aplicar saída de VPC para tráfego: roteie o tráfego originado dos seus agentes pelo anexo de rede do Private Service Connect para sua rede VPC usando o modo PRIVATE_RANGES_ONLY ou ALL_TRAFFIC.
• Intervalo de endereços IP de origem estático: o tráfego de saída usa o intervalo de endereços IP particulares da sub-rede de anexo de rede do Private Service Connect como endereço IP de origem. Esse intervalo de IP de origem estático permite configurar políticas de firewall para sua rede VPC e controlar o tráfego proveniente do gateway.
• Resolução de DNS personalizada: resolva nomes de domínio privados internos e externos diretamente dos seus agentes usando o peering de DNS do Cloud DNS.
• Segurança de perímetro: proteja as comunicações do agente usando perímetros de serviço do VPC Service Controls.
• Validação de certificado particular ou autoassinado: conecte-se a destinos que usam ACs particulares ou certificados autoassinados.

Para configurar a conectividade da VPC, crie um modelo de conectividade do Gateway de Agente (AgentConnectivityTemplate) em que você define e gerencia as configurações de rede de saída para as instâncias do Gateway de Agente.

Como funciona a conectividade VPC

Ao implantar um Gateway de Agente com um modelo de conectividade, o gateway usa uma interface do Private Service Connect para encaminhar o tráfego do agente de saída para a rede VPC designada.

Modos de saída da VPC

Você configura como o gateway roteia o tráfego pelo anexo de rede usando a configuração vpcEgress no modelo de conectividade.

• Tráfego para intervalos de endereços IP particulares (PRIVATE_RANGES_ONLY): roteia o tráfego destinado apenas a intervalos de endereços IP particulares para sua rede VPC. O tráfego de saída é roteado para sua rede VPC somente se o endereço IP de destino estiver em um dos seguintes intervalos:

  • 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
  • Endpoints do PSC para APIs do Google: se você implantar um endpoint personalizado do Private Service Connect para APIs do Google usando um endereço IP particular interno na sua rede VPC, o tráfego para esse endpoint será encaminhado pela rede VPC. Verifique se o peering do Cloud DNS está configurado no modelo de conectividade para que o gateway do agente resolva corretamente os domínios da API do Google para o endereço IP do endpoint PSC interno.

  As solicitações para APIs públicas padrão do Google são processadas automaticamente usando o Acesso Privado do Google, e o tráfego vinculado à internet é roteado diretamente pelo Gateway de Agente, em vez de pela rede VPC.

• Tráfego para todos os intervalos de endereços IP (ALL_TRAFFIC): encaminha todo o tráfego de saída originado dos seus agentes pela rede VPC, incluindo Internet pública, APIs SaaS externas e endereços não RFC 1918.

  • Roteamento e segurança: como essa configuração encaminha todo o tráfego de saída para sua VPC, você é responsável por gerenciar o roteamento e a segurança dela. Verifique se a rede VPC tem uma rota padrão (0.0.0.0/0) para encaminhar esse tráfego aos gateways de saída ou dispositivos de segurança (como firewalls de próximo salto ou interfaces do Cloud Interconnect).
  • Saída da Internet pública: o Gateway de Agente envia tráfego de saída para sua rede VPC, que sai para a Internet pública por um gateway do Cloud NAT na sub-rede de anexo de rede do Private Service Connect. Se você atribuir endereços IP externo estáticos ao gateway do Cloud NAT, os serviços remotos poderão usar uma lista de permissões para o tráfego de saída dos seus agentes com base nesses endereços IP de origem.
  • VPC Service Controls: o modo de saída precisa ser definido como ALL_TRAFFIC para compatibilidade com perímetros de serviço do VPC Service Controls.

Resolução de DNS e roteamento de tráfego

Por padrão, o Gateway de Agente resolve nomes de domínio usando DNS recursivo público. Se os agentes precisarem acessar cargas de trabalho internas, ferramentas particulares ou APIs do Google hospedadas em nomes de domínio particulares na sua rede rede VPC (como corp.internal. ou endpoints do PSC), você poderá configurar o peering de DNS do Cloud DNS para encaminhar consultas de DNS às zonas gerenciadas particulares do Cloud DNS da sua rede.

A tabela a seguir resume os requisitos de peering de DNS do Cloud DNS e o comportamento de roteamento de tráfego para diferentes destinos quando a conectividade da VPC é configurada no modo ALL_TRAFFIC:

Requisitos para certificados TLS

Ao rotear o tráfego de saída por HTTPS, o Gateway de Agente valida a cadeia de certificados TLS do servidor de destino durante o handshake de TLS. Os requisitos de certificado para conexões HTTPS dependem de os endpoints de destino usarem autoridades de certificação (CAs) publicamente confiáveis ou CAs particulares/autoassinadas.

• ACs públicas: por padrão, o Gateway de Agente confia em certificados emitidos por autoridades de certificação (ACs) confiáveis publicamente que atendem aos requisitos padrão de certificado do servidor, incluindo um nome alternativo do assunto (SAN) que corresponda ao nome do host de destino.

• CAs particulares e certificados autoassinados: se o destino (agentes, ferramentas ou servidores MCP na sua rede VPC) usar uma CA particular ou uma PKI interna, configure âncoras de confiança personalizadas usando a configuração tlsConfig no modelo de conectividade. Ao fazer referência a um recurso TrustConfig do Certificate Manager, é possível configurar o Gateway de Agente para confiar apenas em ACs particulares específicas ou combinar ACs raiz particulares com ACs confiáveis publicamente para estabelecer confiança em endpoints públicos e particulares.

  Ao usar trustConfigs para rotear o tráfego para destinos que usam CAs particulares, é necessário fazer a rotação manual dos arquivos PEM. A rotação automatizada de arquivos PEM usando gerenciadores de secrets, como o Secret Manager doCloud de Confiance, não é compatível.

Se o Gateway de Agente não conseguir validar a cadeia de certificados, a conexão vai falhar.

Papéis e permissões necessárias

Para configurar a conectividade da VPC para o Gateway de Agente, verifique se a identidade usada para provisionamento e o agente de serviço do gateway têm os papéis necessários.

Implantações de projetos independentes

Em um projeto independente em que o gateway, o anexo de rede e a rede VPC residem no mesmo projeto, as permissões padrão do Gateway de Agente são aplicadas. Para mais detalhes, consulte Permissões necessárias.

Implantações de VPC compartilhada ou entre projetos

Se você estiver usando uma VPC compartilhada ou uma configuração entre projetos em que a rede VPC de destino, o anexo de rede ou as zonas DNS particulares residem em um projeto host central (TARGET_VPC_PROJECT_ID), as seguintes funções serão necessárias além das permissões padrão do Gateway de Agente:

Configurar a conectividade da VPC

Para implantar um Gateway de Agente com um modelo de conectividade, siga estas etapas:

1. Crie um anexo de rede do Private Service Connect na rede VPC de destino.

   Verifique se a conexão de rede atende aos seguintes requisitos:

   • Preferência de conexão: configure a conexão de rede para aceitar conexões automaticamente (--connection-preference=ACCEPT_AUTOMATIC).
   • Requisito da mesma rede VPC: a sub-rede de anexo de rede e a rede de destino configurada para peering de DNS (targetNetwork) precisam estar na mesma rede VPC. Se a sub-rede do anexo de rede pertencer a uma rede diferente da rede de destino do peering de DNS, a validação da configuração vai falhar.
   • Requisitos de sub-rede: observe os seguintes requisitos para a sub-rede de anexação de rede:
     • Intervalo de sub-rede: a sub-rede de anexo de rede é compatível com todos os intervalos válidos.
     • Tamanho da sub-rede: o Gateway de Agente requer uma sub-rede /28 mínima para o anexo de rede. Uma sub-rede /28 fornece 12 endereços IP utilizáveis, o que é suficiente para uma única instância do Gateway de Agente. Se você planeja conectar vários gateways ao mesmo anexo de rede ou sub-rede, use uma sub-rede maior (como /26 ou /24) para evitar o esgotamento de endereços IP.
     • Requisito do Acesso privado do Google: é necessário ativar o Acesso privado do Google (private_ip_google_access = true) na sub-rede que hospeda a conexão de rede.
   • Implantações de VPC compartilhada: para implantações de VPC compartilhada, consulte Topologias de implantação de VPC compartilhada.

   Anote o URI do anexo de rede. Você vai precisar dele ao atualizar o atributo PSC_NETWORK_ATTACHMENT_URI do recurso de modelo de conectividade em uma etapa posterior.

2. Configurar o peering de DNS (opcional): o peering de DNS permite que o Gateway de Agente resolva nomes DNS usando registros de uma zona gerenciada particular do Cloud DNS na sua rede VPC. O peering de DNS é necessário apenas quando os agentes precisam resolver nomes de domínio internos particulares (como corp.internal.) ou aplicar o VPC Service Controls para APIs do Google (googleapis.com.). Ele não é necessário para domínios públicos da Internet ou APIs padrão do Google sem o VPC Service Controls.

   O Gateway de Agente oferece suporte ao peering de DNS transitivo apenas até um único salto transitivo, o que significa um máximo de três redes VPC. Por exemplo, vpc-net-a (a rede de locatário do gateway do agente) pode fazer peering com vpc-net-b (rede anexada), que, por sua vez, faz peering com vpc-net-c (rede remota) para resolver consultas de DNS em toda a cadeia.

   Para configurar o peering de DNS, siga estas etapas:

   1. Configure sua zona de DNS particular na rede VPC de destino. Para adicionar registros DNS à sua zona de DNS particular, consulte Adicionar um conjunto de registros de recursos.

   2. Reúna as seguintes informações para configurar o modelo de conectividade e ativar o peering:

      • URI da rede de destino (targetNetwork): o URI completo do recurso da rede VPC de destino. Ela precisa ser a mesma rede VPC que contém o anexo de rede.

      • Nomes de domínio: um ou mais sufixos de domínio para peering de DNS. Cada domínio precisa terminar com um ponto final (.), por exemplo, corp.internal. ou googleapis.com..

        Para mais orientações sobre como configurar o campo domains, consulte Padrões de domínio de peering de DNS. Para implantações entre projetos, como a VPC compartilhada, consulte Requisitos de peering e zona de DNS entre projetos.

3. Configurar a confiança do TLS (somente para destinos com CAs particulares e certificados autoassinados):

   Se o destino usar uma CA particular ou um certificado autoassinado, crie um recurso TrustConfig no Certificate Manager. O recurso TrustConfig define as âncoras de confiança e os certificados que o Gateway de Agente usa para validar conexões TLS.

   1. Prepare os arquivos de certificado no formato PEM:

      • Repositório de confiança: certificados de CA raiz ou intermediários no formato PEM. O Gateway de Agente confia em qualquer certificado de servidor cuja cadeia de confiança leve a um desses certificados de CA. O repositório de confiança precisa conter pelo menos um certificado de CA raiz ou intermediário.
      • Certificados na lista de permissões (opcional) : certificados de servidor no formato PEM em que você quer confiar explicitamente, como um certificado autassinado.

   2. Execute o comando a seguir para criar o recurso TrustConfig. O TrustConfig precisa ser criado no mesmo projeto e região que o Gateway de Agente e o modelo de conectividade.

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

      Substitua:

      • TRUST_CONFIG_NAME: um nome para o recurso TrustConfig.
      • LOCATION: a região da configuração de confiança (por exemplo, europe-west1). Ela precisa ser a mesma região do gateway do agente e do modelo de conectividade.
      • ROOT_CERT_FILE: o caminho para o certificado de CA raiz ou intermediário codificado em PEM.
      • ALLOWLISTED_CERT_FILE: (opcional) o caminho para um certificado codificado em PEM em que você quer confiar explicitamente. Se você não estiver usando certificados na lista de permissões, omita essa flag.

      Para mais informações sobre como gerenciar configurações de confiança, consulte Criar e gerenciar configurações de confiança.

4. Implantar o Gateway de Agente

   1. Crie o arquivo de configuração do modelo de conectividade:

      Crie um arquivo YAML chamado 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
      

      Substitua:

      • AGENT_GATEWAY_PROJECT_NUMBER: o número do projeto numérico do projeto Cloud de Confiance em que o gateway está implantado. Para recuperar o número do projeto, execute: gcloud projects describe PROJECT_ID --format="value(projectNumber)".

      • LOCATION: a região do modelo de conectividade (por exemplo, europe-west1).

      • CONNECTIVITY_TEMPLATE_NAME: o nome do recurso de modelo de conectividade.

      • accessPath: o caminho de acesso controlado para o modelo de conectividade. Defina como AGENT_TO_ANYWHERE. Os modelos de conectividade são compatíveis apenas com gateways de saída.

      • deploymentModel: o modelo de implantação do gateway. Defina como CENTRALIZED.

      • PSC_NETWORK_ATTACHMENT_URI: o anexo de rede da interface do PSC para conectividade com VPCs. Se o anexo de rede for criado em um projeto diferente de onde você implantou o gateway (como o projeto host da VPC compartilhada), transmita o caminho completo do anexo de rede: projects/TARGET_VPC_PROJECT_ID/regions/REGION/networkAttachments/ATTACHMENT_NAME.

      • DOMAIN_NAME: (opcional) um ou mais sufixos de domínio para peering de DNS (por exemplo, corp.internal., googleapis.com. ou .). Adicione um item de lista em domains para cada sufixo de domínio que você quer parear. Cada valor precisa terminar com um ponto final (.) e ter uma zona gerenciada privada do Cloud DNS correspondente autorizada para a rede de destino.

        Para mais orientações sobre como configurar o campo domains, consulte Padrões de domínio de peering de DNS.

      • TARGET_VPC_NETWORK_URI: a rede VPC de destino em que você criou o anexo de rede. Ele precisa estar neste formato: projects/TARGET_VPC_PROJECT_ID/global/networks/TARGET_VPC_NETWORK_NAME. Sempre especifique targetNetwork usando o ID do projeto (TARGET_VPC_PROJECT_ID) em vez do número do projeto.

      • VPC_EGRESS_MODE: defina o modo de roteamento de saída. Defina como PRIVATE_RANGES_ONLY ou ALL_TRAFFIC.

      • tlsConfig: (opcional) a configuração TLS para validação do certificado do servidor ao se conectar a endpoints particulares por HTTPS:

        • TRUST_CONFIG_NAME: o nome do recurso TrustConfig do Certificate Manager que contém seus certificados de CA particular ou âncoras de confiança.
        • ADDITIONAL_ROOTS_OPTION: especifica se as raízes de CA confiáveis publicamente devem ser consideradas confiáveis além da configuração de confiança personalizada. Defina como PUBLICLY_TRUSTED_ROOTS (padrão) para confiar em ambos: certificados validados pelo parâmetro trustConfig e todas as CAs publicamente confiáveis. Defina como NO_ADDITIONAL_ROOTS para confiar apenas nos certificados validados pelo parâmetro trustConfig.

   2. Crie o modelo de conectividade:

      Execute o comando a seguir para criar o modelo de conectividade:

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

      Substitua:

      • CONNECTIVITY_TEMPLATE_NAME: o nome do recurso de modelo de conectividade.
      • LOCATION: o local em que você quer criar o recurso de modelo de conectividade. Por exemplo, europe-west1.

   3. Defina o recurso do gateway de agente:

      Defina um novo recurso do Gateway de Agente no modo AGENT_TO_ANYWHERE criando um arquivo de configuração YAML do gateway (por exemplo, my-agent-gateway-vpc-egress.yaml) que faça referência ao modelo de conectividade:

      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
      

      Substitua:

      • AGENT_GATEWAY_NAME: o nome do recurso Gateway de Agente.

      • AGENT_GATEWAY_PROJECT_NUMBER: o número numérico do projeto Cloud de Confiance em que você criou o gateway e o modelo de conectividade. Para recuperar o número do projeto, execute: gcloud projects describe PROJECT_ID --format="value(projectNumber)".

      • LOCATION: o local do modelo de conectividade (por exemplo, europe-west1).

      • CONNECTIVITY_TEMPLATE_NAME: o nome do recurso de modelo de conectividade.

      • AGENT_REGISTRY_PATH: o caminho para o Agent Registry. É possível configurar até dois registros para um gateway de agente. Ao configurar dois registros, um precisa ser global e o outro pode ser regional ou multirregional. Os caminhos do registro precisam ser formatados da seguinte maneira:

        • Registros regionais: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION
        • Registros globais: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/global
        • Registros multirregionais: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/MULTI_REGION

   4. Importe e implante o Gateway de Agente:

      Execute o comando a seguir para criar o recurso do Gateway de Agente com base na especificação YAML:

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

      Substitua LOCATION pelo local em que você quer criar o recurso do Gateway de Agente. Por exemplo, europe-west1.

Considerações sobre arquitetura e rede

Esta seção fornece orientações de arquitetura e padrões de rede avançados para implantar o Gateway de Agente com conectividade VPC.

Atualizar as configurações de saída da VPC

Não é possível modificar um modelo de conectividade enquanto ele é referenciado por um gateway de agente.

• Para atualizar as configurações mutáveis de saída da VPC (como a configuração de peering de DNS, o modo de saída da VPC ou a configuração de TLS), crie um modelo de conectividade que use o mesmo networkAttachment e atualize o Gateway de Agente para referenciar o novo modelo.

• O próprio networkAttachment é imutável depois de configurado em um Gateway de Agente. Para mudar para um anexo de rede diferente (ou rede VPC de destino), crie um novo modelo de conectividade e um novo Gateway de Agente.

Topologias de implantação da VPC compartilhada

Em uma arquitetura de VPC compartilhada, é possível criar o anexo de rede no projeto de serviço (recomendado) ou no projeto host:

• Recomendado: anexo de rede no projeto de serviço:
  1. Crie a sub-rede no projeto host.
  2. Crie o anexo de rede no projeto de serviço, referenciando a sub-rede do projeto host.
• Anexo de rede no projeto host:
  1. Crie a sub-rede no projeto host.
  2. Crie o anexo de rede no projeto host.

Conformidade com o VPC Service Controls

Para aplicar perímetros do VPC Service Controls às comunicações do agente, verifique o seguinte:

• Defina vpcEgress como ALL_TRAFFIC no modelo de conectividade.

• Direcione as solicitações de API do Google para o intervalo de IP restricted.googleapis.com (199.36.153.4/30) ou para um endpoint interno do Private Service Connect para APIs do Google.

• Configure a resolução de DNS para googleapis.com. Crie uma zona de DNS privada do Cloud DNS no mapeamento da rede VPC *.googleapis.com para restricted.googleapis.com e inclua googleapis.com. no campo domains do modelo de conectividade.

  Para mais detalhes sobre a configuração de DNS, consulte Configurar DNS para googleapis.com na documentação do Acesso privado do Google.

• Para implantações de VPC compartilhada, o projeto host que possui a sub-rede do anexo de rede e o dnsPeeringConfig.targetNetwork precisam estar no mesmo perímetro de serviço que o projeto em que você implanta o Gateway de Agente. Isso se aplica mesmo quando você cria o anexo de rede no projeto de serviço, porque a sub-rede e a rede VPC ainda pertencem ao projeto host. Se as zonas de DNS particulares estiverem hospedadas em um projeto de DNS separado, inclua esse projeto no perímetro também.

Padrões de domínio de peering de DNS

Esta seção descreve padrões de resolução de domínio e opções para configurar o campo domains em um modelo de conectividade.

Configuração do nome de domínio: configure o campo domains no modelo de conectividade com base nas seguintes considerações:

• Domínios internos particulares: para resolver serviços internos particulares hospedados na rede VPC (por exemplo, service.corp.internal), especifique o sufixo do domínio interno (como corp.internal.). Uma zona gerenciada particular do Cloud DNS de correspondência exata para esse domínio precisa ser autorizada para a rede VPC de destino.

• DNS de horizonte dividido (domínio público com IP RFC 1918): se você usa uma zona de DNS pública para hospedar registros que apontam para IPs privados internos (como mcp.example.com resolvendo para um endereço RFC 1918 para certificados públicos do Certificate Manager), o gateway resolve esses registros automaticamente usando o DNS público recursivo sem exigir peering de DNS.

• APIsCloud de Confiance com o VPC Service Controls: quando o ALL_TRAFFIC é configurado para aplicar o VPC Service Controls, as solicitações de API do Google precisam ser resolvidas para o intervalo de IP restricted.googleapis.com (199.36.153.4/30) ou para endpoints internos do PSC. Crie uma zona de DNS privada do Cloud DNS na sua rede VPC, mapeando *.googleapis.com para restricted.googleapis.com e inclua googleapis.com. no campo domains do modelo de conectividade.

• Padrões de resolução de vários domínios: se a implantação exigir a resolução de vários sufixos de domínio particular, escolha um dos seguintes padrões:

  • Fazer peering com vários domínios individuais: especifique uma lista de sufixos de domínio no campo domains de dnsPeeringConfig (por exemplo, corp.internal., prod.internal. e googleapis.com.). Cada domínio na lista precisa terminar com um ponto final (.) e ter uma zona gerenciada particular do Cloud DNS autorizada para a rede VPC de destino.
  • Sufixo de domínio principal consolidado (recomendado): consolide os serviços internos em um sufixo de domínio principal compartilhado (como *.internal. ou *.corp.internal.) e inclua esse domínio principal na lista domains.

  • Peering de raiz catch-all com uma zona de encaminhamento particular: inclua "." no campo domains do modelo de conectividade e configure uma zona de encaminhamento particular do Cloud DNS para o domínio raiz (.) na sua rede VPC apontando para um resolvedor recursivo upstream (como 8.8.8.8 ou um resolvedor interno da empresa). Zonas particulares mais específicas na sua VPC correspondem primeiro pela correspondência de sufixo mais longa, enquanto consultas públicas sem correspondência são resolvidas pelo encaminhador upstream.

Requisitos de peering e zona de DNS entre projetos

A configuração dnsPeeringConfig do modelo de conectividade não aceita peering de DNS direto do Cloud DNS entre projetos. Ao importar o modelo de conectividade, a validação falha se o targetNetwork estiver em um projeto diferente do networkAttachment ou se você depender da vinculação entre projetos de uma zona de DNS de um serviço ou projeto externo.

A zona gerenciada do domínio precisa ser criada no projeto host que é proprietário de targetNetwork. A zona gerenciada pode ser de qualquer um dos seguintes tipos:

• Zona particular confiável
• Zona de encaminhamento
• Zona de peering de DNS do Cloud DNS: precisa estar associada à rede VPC do projeto host e ter como destino uma rede VPC. A VPC de destino precisa resolver a consulta diretamente usando uma zona privada autoritativa. O encaminhamento da consulta para outra zona de peering de DNS (encadeamento) não é compatível e resulta em um erro NXDOMAIN.

A seguir