Configura Agent Gateway con conectividad de VPC

En este documento, se explica el proceso para configurar la conectividad de la VPC cuando implementas una Agent Gateway, de modo que pueda comunicarse de forma privada con una red de VPC en tu organización.

Configurar la conectividad de VPC te permite hacer lo siguiente:

• Aplicar la salida de VPC para el tráfico: Enruta el tráfico que se origina en tus agentes a través de la vinculación de red de Private Service Connect a tu red de VPC con el modo PRIVATE_RANGES_ONLY o ALL_TRAFFIC.
• Rango de direcciones IP de origen estáticas: El tráfico de salida usa el rango de direcciones IP privadas de la subred de la vinculación de red de Private Service Connect como su dirección IP de origen. Este rango de IP de origen estático te permite configurar políticas de firewall para tu red de VPC y controlar el tráfico que proviene de la puerta de enlace.
• Resolución de DNS personalizada: Resuelve nombres de dominio privados internos y nombres de dominio externos directamente desde tus agentes con la interconexión de Cloud DNS.
• Seguridad del perímetro: Protege las comunicaciones del agente con los perímetros de servicio de los Controles del servicio de VPC.
• Validación de certificados privados o autofirmados: Conéctate a destinos que usan AC privadas o certificados autofirmados.

Para configurar la conectividad de la VPC, crea una plantilla de conectividad de Agent Gateway (AgentConnectivityTemplate) en la que defines y administras la configuración de redes de salida para tus instancias de Agent Gateway.

Cómo funciona la conectividad de VPC

Cuando implementas un Agent Gateway con una plantilla de conectividad, la puerta de enlace usa una interfaz de Private Service Connect para enrutar el tráfico saliente del agente a tu red de VPC designada.

Modos de salida de VPC

Configuras cómo la puerta de enlace enruta el tráfico a través de tu adjunto de red con el parámetro de configuración vpcEgress en tu plantilla de conectividad.

• Tráfico a rangos de direcciones IP privadas (PRIVATE_RANGES_ONLY): Enruta el tráfico destinado solo a rangos de direcciones IP privadas a tu red de VPC. El tráfico saliente se enruta a tu red de VPC solo si la dirección IP de destino se encuentra dentro de uno de los siguientes rangos:

  • RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
  • RFC 6598: 100.64.0.0/10
  • Clase E: 240.0.0.0/4
  • private.googleapis.com: 199.36.153.8/30
  • restricted.googleapis.com: 199.36.153.4/30
  • Extremos de PSC para las APIs de Google: Si implementas un extremo de Private Service Connect personalizado para las APIs de Google con una dirección IP privada interna en tu red de VPC, el tráfico a este extremo se enruta a través de tu red de VPC. Asegúrate de que el peering de Cloud DNS esté configurado en la plantilla de conectividad para que Agent Gateway resuelva correctamente los dominios de la API de Google en la dirección IP de tu extremo de PSC interno.

  Las solicitudes a las APIs públicas estándar de Google se controlan automáticamente con el Acceso privado a Google, y el tráfico vinculado a Internet se enruta directamente a través de Agent Gateway en lugar de a través de tu red de VPC.

• Tráfico a todos los rangos de direcciones IP (ALL_TRAFFIC): Enruta todo el tráfico saliente que se origina en tus agentes a través de tu red de VPC, lo que incluye Internet pública, APIs de SaaS externas y direcciones que no son RFC 1918.

  • Enrutamiento y seguridad: Debido a que este parámetro de configuración enruta todo el tráfico saliente a tu VPC, eres responsable de administrar su enrutamiento y seguridad. Asegúrate de que tu red de VPC tenga una ruta predeterminada (0.0.0.0/0) para reenviar este tráfico a tus puertas de enlace salientes o dispositivos de seguridad (como firewalls de próximo salto o interfaces de Cloud Interconnect).
  • Salida a Internet pública: La puerta de enlace del agente envía tráfico saliente a tu red de VPC, donde sale a Internet pública a través de una puerta de enlace de Cloud NAT en la subred del adjunto de red de Private Service Connect. Si asignas direcciones IP externas estáticas a la puerta de enlace de Cloud NAT, los servicios remotos pueden incluir en la lista de entidades permitidas el tráfico de salida de tus agentes en función de estas direcciones IP de origen.
  • Controles del servicio de VPC: El modo de salida debe establecerse en ALL_TRAFFIC para admitir perímetros de servicio de los Controles del servicio de VPC.

Resolución de DNS y enrutamiento del tráfico

De forma predeterminada, Agent Gateway resuelve los nombres de dominio con DNS recursivo público. Si tus agentes necesitan acceder a cargas de trabajo internas, herramientas privadas o APIs de Google alojadas en nombres de dominio privados en tu red de VPC (como corp.internal. o extremos de PSC), puedes configurar el intercambio de tráfico de Cloud DNS para reenviar consultas de DNS a las zonas privadas administradas de Cloud DNS de tu red.

En la siguiente tabla, se resumen los requisitos de intercambio de tráfico de Cloud DNS y el comportamiento del enrutamiento del tráfico para diferentes destinos cuando la conectividad de VPC está configurada en el modo ALL_TRAFFIC:

Requisitos de los certificados TLS

Cuando enruta el tráfico de salida a través de HTTPS, Agent Gateway valida la cadena de certificados TLS del servidor de destino durante el protocolo de enlace TLS. Los requisitos de los certificados para las conexiones HTTPS dependen de si tus extremos de destino usan autoridades certificadoras (CA) de confianza pública o CA privadas o autofirmadas.

• AC públicas: De forma predeterminada, Agent Gateway confía en los certificados emitidos por autoridades certificadoras (AC) de confianza pública que cumplen con los requisitos estándar de los certificados de servidor (incluido un nombre alternativo del sujeto [SAN] que coincida con el nombre de host de destino).

• CA privadas y certificados autofirmados: Si tu destino objetivo (agentes, herramientas o servidores de MCP en tu red de VPC) usa una CA privada o una PKI interna, puedes configurar anclajes de confianza personalizados con el parámetro de configuración tlsConfig en tu plantilla de conectividad. Si haces referencia a un recurso TrustConfig de Administrador de certificados, puedes configurar Agent Gateway para que confíe solo en AC privadas específicas o combinar AC raíz privadas con AC de confianza pública para establecer la confianza en los extremos públicos y privados.

  Cuando usas trustConfigs para enrutar el tráfico a destinos que usan CAs privadas, debes rotar los archivos PEM de forma manual. No se admite la rotación automática de archivos PEM con administradores de secretos, como Secret Manager deCloud de Confiance.

Si Agent Gateway no puede validar la cadena de certificados, la conexión falla.

Roles y permisos requeridos

Para configurar la conectividad de VPC para Agent Gateway, asegúrate de que la identidad que se usa para el aprovisionamiento y el agente de servicio de la puerta de enlace tengan los roles necesarios.

Implementaciones de proyectos independientes

En un proyecto independiente en el que la puerta de enlace, el adjunto de red y la red de VPC residen en el mismo proyecto, se aplican los permisos estándar de Agent Gateway. Para obtener más información, consulta Permisos necesarios.

Implementaciones de VPC compartida o entre proyectos

Si usas una VPC compartida o una configuración entre proyectos en la que la red de VPC, el adjunto de red o las zonas de DNS privadas de destino residen en un proyecto host central (TARGET_VPC_PROJECT_ID), se requieren los siguientes roles además de los permisos estándar de Agent Gateway:

Configura la conectividad de la VPC

Para implementar un Agent Gateway con una plantilla de conectividad, sigue estos pasos:

1. Crea un adjunto de red de Private Service Connect en tu red de VPC de destino.

   Asegúrate de que el adjunto de red cumpla con los siguientes requisitos:

   • Preferencia de conexión: Configura el adjunto de red para aceptar automáticamente las conexiones (--connection-preference=ACCEPT_AUTOMATIC).
   • Requisito de la misma red de VPC: La subred del adjunto de red y la red de destino configurada para el intercambio de tráfico de DNS (targetNetwork) deben estar en la misma red de VPC. Si la subred del adjunto de red pertenece a una red diferente de la red de destino del intercambio de tráfico de DNS, falla la validación de la configuración.
   • Requisitos de la subred: Ten en cuenta los siguientes requisitos para la subred de la conexión de red:
     • Rango de subred: El adjunto de red admite todos los rangos válidos.
     • Tamaño de la subred: Agent Gateway requiere una subred /28 como mínimo para la conexión de red. Una subred /28 proporciona 12 direcciones IP utilizables, lo que es suficiente para una sola instancia de Agent Gateway. Si planeas conectar varias puertas de enlace al mismo adjunto de red o subred, usa una subred más grande (como /26 o /24) para evitar el agotamiento de las direcciones IP.
     • Requisito de Acceso privado a Google: Debes habilitar el Acceso privado a Google (private_ip_google_access = true) en la subred que aloja el adjunto de red.
   • Implementaciones de VPC compartida: Para las implementaciones de VPC compartida, consulta Topologías de implementación de VPC compartida.

   Toma nota del URI del adjunto de red. La necesitarás cuando actualices el atributo PSC_NETWORK_ATTACHMENT_URI del recurso de plantilla de conectividad en un paso posterior.

2. Configura el intercambio de tráfico de DNS (opcional): El intercambio de tráfico de DNS permite que Agent Gateway resuelva nombres de DNS con registros de una zona administrada privada de Cloud DNS en tu red de VPC. El intercambio de tráfico de DNS solo es necesario cuando tus agentes necesitan resolver nombres de dominio internos privados (como corp.internal.) o aplicar Controles del servicio de VPC para las APIs de Google (googleapis.com.). No es necesario para los dominios de Internet públicos ni para las APIs de Google estándar sin Controles del servicio de VPC.

   Agent Gateway admite el intercambio de tráfico de DNS transitivo solo hasta un salto transitivo, lo que significa un máximo de tres redes de VPC. Por ejemplo, vpc-net-a (la red de inquilinos de la puerta de enlace del agente) puede intercambiar tráfico con vpc-net-b (red adjunta), que, a su vez, intercambia tráfico con vpc-net-c (red remota) para resolver consultas de DNS en toda la cadena.

   Para configurar la interconexión de DNS, sigue estos pasos:

   1. Configura tu zona de DNS privada en tu red de VPC de destino. Para agregar registros DNS a tu zona del DNS privada, consulta Agrega un conjunto de registros de recursos.

   2. Recopila la siguiente información para configurar la plantilla de conectividad y habilitar el intercambio de tráfico:

      • URI de la red de destino (targetNetwork): Es el URI completo del recurso de la red de VPC de destino. Esta debe ser la misma red de VPC que contiene el adjunto de red.

      • Nombres de dominio: Uno o más sufijos de dominio para el intercambio de tráfico de DNS. Cada dominio debe terminar con un punto final (.) (por ejemplo, corp.internal. o googleapis.com.).

        Para obtener orientación adicional sobre cómo configurar el campo domains, consulta Patrones de dominios de intercambio de tráfico de DNS. Para las implementaciones entre proyectos, como la VPC compartida, consulta Requisitos de intercambio de tráfico y zonas de DNS entre proyectos.

3. Configura la confianza de TLS (solo para destinos con CAs privadas y certificados autofirmados):

   Si el destino de destino usa una CA privada o un certificado autofirmado, debes crear un recurso TrustConfig en Administrador de certificados. El recurso TrustConfig define las entidades de certificación raíz y los certificados que usa Agent Gateway para validar las conexiones TLS.

   1. Prepara tus archivos de certificado en formato PEM:

      • Almacén de confianza: Certificados de CA raíz o intermedios en formato PEM. Agent Gateway confía en cualquier certificado de servidor cuya cadena de confianza conduzca a uno de estos certificados de la AC. El almacén de certificados de confianza debe contener al menos un certificado de CA raíz o intermedio.
      • Certificados incluidos en la lista de entidades permitidas (opcional) : Son los certificados de servidor en formato PEM en los que deseas confiar de forma explícita, como un certificado autofirmado.

   2. Ejecuta el siguiente comando para crear el recurso TrustConfig. El TrustConfig debe crearse en el mismo proyecto y región que el Agent Gateway y la plantilla de conectividad.

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

      Reemplaza lo siguiente:

      • TRUST_CONFIG_NAME: Es un nombre para el recurso TrustConfig.
      • LOCATION: Es la región de la configuración de confianza (por ejemplo, europe-west1). Debe ser la misma región que la puerta de enlace del agente y la plantilla de conectividad.
      • ROOT_CERT_FILE: Es la ruta de acceso a tu certificado de la AC raíz o intermedio codificado en PEM.
      • ALLOWLISTED_CERT_FILE: (Opcional) Es la ruta de acceso a un certificado con codificación PEM en el que deseas confiar de forma explícita. Si no usas certificados incluidos en la lista de entidades permitidas, omite esta marca.

      Para obtener más información sobre cómo administrar las configuraciones de confianza, consulta Crea y administra configuraciones de confianza.

4. Implementa Agent Gateway

   1. Crea el archivo de configuración de la plantilla de conectividad:

      Crea un archivo YAML llamado 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
      

      Reemplaza lo siguiente:

      • AGENT_GATEWAY_PROJECT_NUMBER: Es el número de proyecto numérico del proyecto Cloud de Confiance en el que se implementa la puerta de enlace. Para recuperar el número de tu proyecto, ejecuta gcloud projects describe PROJECT_ID --format="value(projectNumber)".

      • LOCATION: Es la región de la plantilla de conectividad (por ejemplo, europe-west1).

      • CONNECTIVITY_TEMPLATE_NAME: Es el nombre del recurso de plantilla de conectividad.

      • accessPath: Es la ruta de acceso controlada para la plantilla de conectividad. Se establece en AGENT_TO_ANYWHERE (las plantillas de conectividad solo se admiten para las puertas de enlace de salida).

      • deploymentModel: Es el modelo de implementación de la puerta de enlace. Se establece en CENTRALIZED.

      • PSC_NETWORK_ATTACHMENT_URI: Es la vinculación de red de la interfaz de PSC para la conectividad a las VPC. Si el adjunto de red se crea en un proyecto diferente de aquel en el que implementaste la puerta de enlace (como el proyecto host de la VPC compartida), pasa la ruta de acceso completa de tu adjunto de red: projects/TARGET_VPC_PROJECT_ID/regions/REGION/networkAttachments/ATTACHMENT_NAME.

      • DOMAIN_NAME: (Opcional) Uno o más sufijos de dominio para la interconexión de DNS (por ejemplo, corp.internal., googleapis.com. o .). Agrega un elemento de lista en domains para cada sufijo de dominio con el que desees establecer una interconexión. Cada valor debe terminar con un punto final (.) y tener una zona privada administrada de Cloud DNS correspondiente autorizada para la red de destino.

        Para obtener orientación adicional sobre cómo configurar el campo domains, consulta Patrones de dominios de vinculación de DNS.

      • TARGET_VPC_NETWORK_URI: Es la red de VPC de destino en la que creaste el adjunto de red. Debe tener el siguiente formato: projects/TARGET_VPC_PROJECT_ID/global/networks/TARGET_VPC_NETWORK_NAME. Siempre especifica targetNetwork con el ID del proyecto (TARGET_VPC_PROJECT_ID) en lugar del número del proyecto.

      • VPC_EGRESS_MODE: Establece el modo de enrutamiento de salida. Se establece en PRIVATE_RANGES_ONLY o ALL_TRAFFIC.

      • tlsConfig: (Opcional) Es la configuración de TLS para la validación del certificado del servidor cuando se conecta a extremos privados a través de HTTPS:

        • TRUST_CONFIG_NAME: Es el nombre del recurso TrustConfig de Administrador de certificados que contiene tus certificados de CA privada o anclajes de confianza.
        • ADDITIONAL_ROOTS_OPTION: Especifica si se debe confiar en las raíces de CA de confianza pública además de la configuración de confianza personalizada. Establece el valor en PUBLICLY_TRUSTED_ROOTS (predeterminado) para confiar en ambos: los certificados validados por el parámetro trustConfig y todas las AC de confianza pública. Establece el valor en NO_ADDITIONAL_ROOTS para confiar solo en los certificados validados por el parámetro trustConfig.

   2. Crea la plantilla de conectividad:

      Ejecuta el siguiente comando para crear la plantilla de conectividad:

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

      Reemplaza lo siguiente:

      • CONNECTIVITY_TEMPLATE_NAME: Es el nombre del recurso de plantilla de conectividad.
      • LOCATION: Es la ubicación en la que deseas crear el recurso de plantilla de conectividad. Por ejemplo, europe-west1

   3. Define el recurso de Agent Gateway:

      Define un nuevo recurso de Agent Gateway en modo AGENT_TO_ANYWHERE creando un archivo de configuración de puerta de enlace en formato YAML (por ejemplo, my-agent-gateway-vpc-egress.yaml) que haga referencia a la plantilla de conectividad:

      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
      

      Reemplaza lo siguiente:

      • AGENT_GATEWAY_NAME: Es el nombre del recurso de Agent Gateway.

      • AGENT_GATEWAY_PROJECT_NUMBER: Es el número de proyecto numérico del proyecto Cloud de Confiance en el que creaste la puerta de enlace y la plantilla de conectividad. Para recuperar el número de tu proyecto, ejecuta gcloud projects describe PROJECT_ID --format="value(projectNumber)".

      • LOCATION: Es la ubicación de la plantilla de conectividad (por ejemplo, europe-west1).

      • CONNECTIVITY_TEMPLATE_NAME: Es el nombre del recurso de plantilla de conectividad.

      • AGENT_REGISTRY_PATH: Es la ruta de acceso al registro de agentes. Puedes configurar hasta dos registros para una Agent Gateway. Cuando configures dos registros, uno debe ser global y el otro puede ser regional o multirregional. Las rutas de acceso del registro deben tener el siguiente formato:

        • Registros regionales: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION
        • Registros globales: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/global
        • Registros multirregionales: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/MULTI_REGION

   4. Importa e implementa Agent Gateway:

      Ejecuta el siguiente comando para crear el recurso de Agent Gateway basado en la especificación YAML:

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

      Reemplaza LOCATION por la ubicación en la que deseas crear el recurso de Agent Gateway. Por ejemplo, europe-west1.

Consideraciones sobre la arquitectura y las redes

En esta sección, se proporciona orientación sobre la arquitectura y patrones de redes avanzados para implementar Agent Gateway con conectividad de VPC.

Actualiza la configuración de salida de VPC

No se puede modificar una plantilla de conectividad mientras un Agent Gateway haga referencia a ella.

• Para actualizar la configuración de salida de la VPC mutable (como la configuración del intercambio de tráfico de DNS, el modo de salida de la VPC o la configuración de TLS), debes crear una nueva plantilla de conectividad que use el mismo networkAttachment y actualizar el Agent Gateway para que haga referencia a la nueva plantilla.

• El objeto networkAttachment en sí es inmutable una vez que se configura en una puerta de enlace de Agent. Para cambiar a un adjunto de red diferente (o a una red de VPC de destino), debes crear una nueva plantilla de conectividad y un nuevo Agent Gateway.

Topologías de implementación de VPC compartida

En una arquitectura de VPC compartida, puedes crear el adjunto de red en el proyecto de servicio (recomendado) o en el proyecto host:

• Recomendado: Adjunto de red en el proyecto de servicio:
  1. Crea la subred en el proyecto host.
  2. Crea el adjunto de red en el proyecto de servicio, haciendo referencia a la subred del proyecto host.
• Adjunto de red en el proyecto host:
  1. Crea la subred en el proyecto host.
  2. Crea el adjunto de red en el proyecto host.

Cumplimiento de los Controles del servicio de VPC

Para aplicar perímetros de Controles del servicio de VPC a las comunicaciones del agente, asegúrate de lo siguiente:

• Establece vpcEgress en ALL_TRAFFIC en tu plantilla de conectividad.

• Dirige las solicitudes de la API de Google al rango de IP restricted.googleapis.com (199.36.153.4/30) o a un extremo interno de Private Service Connect para las APIs de Google.

• Configura la resolución de DNS para googleapis.com. Crea una zona privada de Cloud DNS en tu red de VPC que asigne *.googleapis.com a restricted.googleapis.com y, luego, incluye googleapis.com. en el campo domains de tu plantilla de conectividad.

  Para obtener más detalles sobre la configuración del DNS, consulta Configura el DNS para googleapis.com en la documentación del Acceso privado a Google.

• Para las implementaciones de VPC compartida, el proyecto host que posee la subred de la conexión de red y el dnsPeeringConfig.targetNetwork deben estar en el mismo perímetro de servicio que el proyecto en el que implementas Agent Gateway. Esto se aplica incluso cuando creas el adjunto de red en el proyecto de servicio, ya que la subred y la red de VPC siguen perteneciendo al proyecto host. Si tus zonas DNS privadas están alojadas en un proyecto de DNS independiente, incluye ese proyecto en el perímetro también.

Patrones de dominios de intercambio de tráfico de DNS

En esta sección, se describen los patrones de resolución de dominios y las opciones para configurar el campo domains en una plantilla de conectividad.

Configuración del nombre de dominio: Configura el campo domains en la plantilla de conectividad según las siguientes consideraciones:

• Dominios internos privados: Para resolver servicios internos privados alojados en tu red de VPC (por ejemplo, service.corp.internal), especifica el sufijo de tu dominio interno (como corp.internal.). Se debe autorizar una zona administrada privada de Cloud DNS de coincidencia exacta para este dominio en la red de VPC de destino.

• DNS de horizonte dividido (dominio público con IP de RFC 1918): Si usas una zona DNS pública para alojar registros que apuntan a IPs privadas internas (como mcp.example.com que se resuelve en una dirección RFC 1918 para los certificados públicos de Administrador de certificados), la puerta de enlace resuelve estos registros automáticamente con el DNS recursivo público sin necesidad de intercambio de tráfico de DNS.

• APIs deCloud de Confiance con Controles del servicio de VPC: Cuando ALL_TRAFFIC está configurado para aplicar los Controles del servicio de VPC, las solicitudes a las APIs de Google deben resolverse en el rango de IP de restricted.googleapis.com (199.36.153.4/30) o en los extremos internos de PSC. Crea una zona del DNS privada de Cloud DNS en tu red de VPC que asigne *.googleapis.com a restricted.googleapis.com y, luego, incluye googleapis.com. en el campo domains de tu plantilla de conectividad.

• Patrones de resolución de varios dominios: Si tu implementación requiere resolver varios sufijos de dominio privado, elige uno de los siguientes patrones:

  • Intercambia tráfico con varios dominios individuales: Especifica una lista de sufijos de dominio en el campo domains de dnsPeeringConfig (por ejemplo, corp.internal., prod.internal. y googleapis.com.). Cada dominio de la lista debe terminar con un punto final (.) y tener una zona privada administrada por Cloud DNS correspondiente autorizada para la red de VPC de destino.
  • Sufijo principal consolidado (recomendado): Consolida los servicios internos en un sufijo de dominio principal compartido (como *.internal. o *.corp.internal.) y, luego, incluye ese dominio principal en la lista de domains.

  • Intercambio de tráfico raíz general con una zona de reenvío privada: Incluye "." en el campo domains de la plantilla de conectividad y configura una zona de reenvío privada de Cloud DNS para el dominio raíz (.) en tu red de VPC que apunte a un agente de resolución recursivo upstream (como 8.8.8.8 o un agente de resolución empresarial interno). Las zonas privadas más específicas de tu VPC coinciden primero por la coincidencia de sufijo más largo, mientras que las búsquedas públicas no coincidentes se resuelven a través del reenviador upstream.

Requisitos de intercambio de tráfico y zonas de DNS entre proyectos

El parámetro de configuración dnsPeeringConfig de la plantilla de conectividad no admite el intercambio de tráfico directo de Cloud DNS entre proyectos. Cuando importas la plantilla de conectividad, la validación falla si targetNetwork se encuentra en un proyecto diferente al de networkAttachment o si dependes de la vinculación de zonas del DNS entre proyectos desde un servicio o proyecto externo.

La zona administrada para el dominio se debe crear en el proyecto host que posee targetNetwork. La zona administrada puede ser cualquiera de los siguientes tipos de zonas:

• Zona privada autorizada
• Zona de reenvío
• Zona de intercambio de tráfico de Cloud DNS: Debe estar asociada a la red de VPC del proyecto host y tener como destino una red de VPC. La VPC de destino debe resolver la consulta directamente con una zona privada autorizada. No se admite el reenvío de la consulta a otra zona de intercambio de tráfico de DNS (encadenamiento), lo que genera un error NXDOMAIN.

¿Qué sigue?