KI-Agenten-Gateway mit VPC-Verbindung einrichten

In diesem Dokument wird beschrieben, wie Sie die VPC-Konnektivität konfigurieren, wenn Sie ein Agent Gateway bereitstellen, damit es privat mit einem VPC-Netzwerk in Ihrer Organisation kommunizieren kann.

Wenn Sie eine VPC-Verbindung einrichten, haben Sie folgende Möglichkeiten:

• VPC-Ausgang für Traffic erzwingen: Leiten Sie Traffic, der von Ihren Agents stammt, über die Private Service Connect-Netzwerkverbindung in Ihr VPC-Netzwerk weiter. Verwenden Sie dazu den Modus PRIVATE_RANGES_ONLY oder ALL_TRAFFIC.
• Statischer Quell-IP-Adressbereich: Für ausgehenden Traffic wird der private IP-Adressbereich Ihres Private Service Connect-Netzwerk-Anhangssubnetzes als Quell-IP-Adresse verwendet. Mit diesem statischen Quell-IP-Bereich können Sie Firewallrichtlinien für Ihr VPC-Netzwerk konfigurieren, um den Traffic vom Gateway zu steuern.
• Benutzerdefinierte DNS-Auflösung: Interne private Domainnamen und externe Domainnamen direkt von Ihren Agents auflösen lassen, indem Sie Cloud DNS-Peering verwenden.
• Perimetersicherheit: Schützen Sie die Agent-Kommunikation mit VPC Service Controls-Dienstperimetern.
• Validierung privater oder selbst signierter Zertifikate: Stellen Sie eine Verbindung zu Zielen her, die private Zertifizierungsstellen oder selbst signierte Zertifikate verwenden.

Um die VPC-Verbindung zu konfigurieren, erstellen Sie eine Agent Gateway-Verbindungsvorlage (AgentConnectivityTemplate), in der Sie die Einstellungen für das Egress-Netzwerk für Ihre Agent Gateway-Instanzen definieren und verwalten.

So funktioniert die VPC-Konnektivität

Wenn Sie ein Agent Gateway mit einer Konnektivitätsvorlage bereitstellen, verwendet das Gateway eine Private Service Connect-Schnittstelle, um ausgehenden Agent-Traffic in Ihr angegebenes VPC-Netzwerk weiterzuleiten.

Modi für ausgehenden VPC-Traffic

Sie konfigurieren, wie das Gateway Traffic über Ihre Netzwerkverbindung weiterleitet, indem Sie die Einstellung vpcEgress in Ihrer Verbindungsvorlage verwenden.

• Traffic zu privaten IP-Adressbereichen (PRIVATE_RANGES_ONLY): Leitet Traffic, der nur für private IP-Adressbereiche bestimmt ist, in Ihr VPC-Netzwerk weiter. Ausgehender Traffic wird nur dann in Ihr VPC-Netzwerk weitergeleitet, wenn die Ziel-IP-Adresse in einen der folgenden Bereiche fällt:

  • RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
  • RFC 6598: 100.64.0.0/10
  • Klasse E: 240.0.0.0/4
  • private.googleapis.com: 199.36.153.8/30
  • restricted.googleapis.com: 199.36.153.4/30
  • PSC-Endpunkte für Google APIs: Wenn Sie einen benutzerdefinierten Private Service Connect-Endpunkt für Google APIs mit einer internen privaten IP-Adresse in Ihrem VPC-Netzwerk bereitstellen, wird der Traffic zu diesem Endpunkt über Ihr VPC-Netzwerk weitergeleitet. Achten Sie darauf, dass Cloud DNS-Peering in der Vorlage für die Verbindung konfiguriert ist, damit Agent Gateway Google API-Domains korrekt in die IP-Adresse Ihres internen PSC-Endpunkts auflöst.

  Anfragen an öffentliche Google-Standard-APIs werden automatisch über den privater Google-Zugriff verarbeitet. Internetgebundener Traffic wird direkt über das Agent Gateway und nicht über Ihr VPC-Netzwerk weitergeleitet.

• Traffic zu allen IP-Adressbereichen (ALL_TRAFFIC): Leitet den gesamten ausgehenden Traffic, der von Ihren Agents stammt, über Ihr VPC-Netzwerk weiter, einschließlich des öffentlichen Internets, externer SaaS-APIs und Adressen, die nicht RFC 1918 entsprechen.

  • Routing und Sicherheit: Da mit dieser Einstellung der gesamte ausgehende Traffic in Ihre VPC geleitet wird, sind Sie für das Routing und die Sicherheit verantwortlich. Achten Sie darauf, dass Ihr VPC-Netzwerk eine Standardroute (0.0.0.0/0) hat, um diesen Traffic an Ihre ausgehenden Gateways oder Sicherheits-Appliances (z. B. Next-Hop-Firewalls oder Cloud Interconnect-Schnittstellen) weiterzuleiten.
  • Ausgehender Traffic über das öffentliche Internet: Das Agent Gateway sendet ausgehenden Traffic in Ihr VPC-Netzwerk, wo er über ein Cloud NAT-Gateway im Subnetz des Private Service Connect-Netzwerkanhangs ins öffentliche Internet gelangt. Wenn Sie dem Cloud NAT-Gateway statische externe IP-Adressen zuweisen, können Remote-Dienste den Egress-Traffic Ihrer Agents anhand dieser Quell-IP-Adressen auf die Zulassungsliste setzen.
  • VPC Service Controls: Der Egress-Modus muss auf ALL_TRAFFIC festgelegt sein, um VPC Service Controls-Dienstperimeter zu unterstützen.

DNS-Auflösung und Traffic-Routing

Standardmäßig löst Agent Gateway Domainnamen mithilfe von öffentlichen rekursiven DNS auf. Wenn Ihre Agents auf interne Arbeitslasten, private Tools oder Google APIs zugreifen müssen, die in Ihrem VPC-Netzwerk unter privaten Domainnamen gehostet werden (z. B. corp.internal. oder PSC-Endpunkte), können Sie Cloud DNS-Peering konfigurieren, um DNS-Abfragen an die privaten von Cloud DNS verwalteten Zonen Ihres Netzwerks weiterzuleiten.

In der folgenden Tabelle sind die Cloud DNS-Peering-Anforderungen und das Traffic-Routing-Verhalten für verschiedene Ziele zusammengefasst, wenn die VPC-Verbindung im ALL_TRAFFIC-Modus konfiguriert ist:

Anforderungen an TLS-Zertifikate

Wenn der ausgehende Traffic über HTTPS weitergeleitet wird, validiert das Agent Gateway die TLS-Zertifikatkette des Zielservers während des TLS-Handshake. Die Zertifikatsanforderungen für HTTPS-Verbindungen hängen davon ab, ob für Ihre Zielendpunkte öffentlich vertrauenswürdige Zertifizierungsstellen (CAs) oder private/selbst signierte CAs verwendet werden.

• Öffentliche Zertifizierungsstellen: Standardmäßig vertraut Agent Gateway Zertifikaten, die von öffentlich vertrauenswürdigen Zertifizierungsstellen ausgestellt wurden und die standardmäßigen Anforderungen an Serverzertifikate erfüllen (einschließlich eines alternativen Antragstellernamens (Subject Alternative Name, SAN), der mit dem Zielhostname übereinstimmt).

• Private Zertifizierungsstellen und selbstsignierte Zertifikate: Wenn für Ihr Ziel (Agents, Tools oder MCP-Server in Ihrem VPC-Netzwerk) eine private Zertifizierungsstelle oder eine interne PKI verwendet wird, können Sie benutzerdefinierte Vertrauensanker mit der Einstellung tlsConfig in Ihrer Konnektivitätsvorlage konfigurieren. Durch den Verweis auf eine TrustConfig-Ressource in Zertifikatmanager können Sie Agent Gateway so konfigurieren, dass nur bestimmten privaten Zertifizierungsstellen vertraut wird. Alternativ können Sie private Stamm-CAs mit öffentlich vertrauenswürdigen CAs kombinieren, um sowohl öffentliche als auch private Endpunkte zu schützen.

  Wenn Sie trustConfig verwenden, um Traffic an Ziele weiterzuleiten, die private CAs verwenden, müssen Sie die PEM-Dateien manuell rotieren. Die automatische Rotation von PEM-Dateien mit Secret-Managern wie dem Cloud de Confiance-Secret Manager wird nicht unterstützt.

Wenn das Agent Gateway die Zertifikatskette nicht validieren kann, schlägt die Verbindung fehl.

Erforderliche Rollen und Berechtigungen

Wenn Sie die VPC-Verbindung für Agent Gateway konfigurieren möchten, müssen Sie darauf achten, dass die für die Bereitstellung verwendete Identität und der Gateway-Dienst-Agent die erforderlichen Rollen haben.

Bereitstellungen in eigenständigen Projekten

In einem eigenständigen Projekt, in dem sich das Gateway, die Netzwerkverbindung und das VPC-Netzwerk im selben Projekt befinden, gelten die Standardberechtigungen für das Agent Gateway. Weitere Informationen finden Sie unter Erforderliche Berechtigungen.

Bereitstellungen mit freigegebene VPC oder projektübergreifende Bereitstellungen

Wenn Sie eine gemeinsam genutzte VPC oder eine projektübergreifende Einrichtung verwenden, bei der sich das Ziel-VPC-Netzwerk, die Netzwerkverbindung oder die privaten DNS-Zonen in einem zentralen Hostprojekt (TARGET_VPC_PROJECT_ID) befinden, sind zusätzlich zu den Standardberechtigungen für Agent Gateway die folgenden Rollen erforderlich:

VPC-Verbindung konfigurieren

So stellen Sie ein Agent Gateway mit einer Konnektivitätsvorlage bereit:

1. Erstellen Sie einen Private Service Connect-Netzwerkanhang in Ihrem Ziel-VPC-Netzwerk.

   Ihre Netzwerkverbindung muss die folgenden Anforderungen erfüllen:

   • Verbindungseinstellung: Konfiguriere die Netzwerkverbindung so, dass Verbindungen automatisch akzeptiert werden (--connection-preference=ACCEPT_AUTOMATIC).
   • Anforderung für dasselbe VPC-Netzwerk: Das Subnetz für die Netzwerkverbindung und das für das DNS-Peering konfigurierte Zielnetzwerk (targetNetwork) müssen sich im selben VPC-Netzwerk befinden. Wenn das Subnetz der Netzwerkverbindung zu einem anderen Netzwerk als dem DNS-Peering-Zielnetzwerk gehört, schlägt die Konfigurationsvalidierung fehl.
   • Anforderungen an Subnetze: Beachten Sie die folgenden Anforderungen an das Subnetz für die Netzwerkverbindung:
     • Subnetzbereich: Das Subnetz für den Netzwerkanhang unterstützt alle gültigen Bereiche.
     • Subnetzgröße: Für Agent Gateway ist für den Netzwerkanhang ein Subnetz mit mindestens /28 erforderlich. Ein /28-Subnetz bietet 12 nutzbare IP-Adressen, was für eine einzelne Agent Gateway-Instanz ausreicht. Wenn Sie mehrere Gateways mit demselben Netzwerk-Anhang oder Subnetz verbinden möchten, verwenden Sie ein größeres Subnetz (z. B. /26 oder /24), um eine Erschöpfung der IP-Adressen zu vermeiden.
     • Anforderung für privaten Google-Zugriff: Sie müssen privaten Google-Zugriff (private_ip_google_access = true) für das Subnetz aktivieren, in dem die Netzwerkverbindung gehostet wird.
   • Bereitstellungen gemeinsam genutzter VPCs: Informationen zu Bereitstellungen gemeinsam genutzter VPCs finden Sie unter Bereitstellungstopologien für gemeinsam genutzte VPCs.

   Notieren Sie sich den URI des Netzwerkanhangs. Sie benötigen ihn, wenn Sie das Attribut PSC_NETWORK_ATTACHMENT_URI der Verbindungsressource in einem späteren Schritt aktualisieren.

2. DNS-Peering einrichten (optional): Mit DNS-Peering kann Agent Gateway DNS-Namen mithilfe von Einträgen aus einer privaten verwalteten Cloud DNS-Zone in Ihrem VPC-Netzwerk auflösen. DNS-Peering ist nur erforderlich, wenn Ihre Agents private interne Domainnamen (z. B. corp.internal.) auflösen oder VPC Service Controls für Google APIs (googleapis.com.) erzwingen müssen. Es ist nicht für öffentliche Internetdomains oder Standard-Google APIs ohne VPC Service Controls erforderlich.

   Agent Gateway unterstützt transitives DNS-Peering nur bis zu einem einzigen transitiven Hop, was einem Maximum von drei VPC-Netzwerken entspricht. Beispiel: vpc-net-a (das Agent Gateway-Mandantennetzwerk) kann mit vpc-net-b (angehängtes Netzwerk) und wiederum mit vpc-net-c (Remote-Netzwerk) ein Peering durchführen, um DNS-Abfragen in der gesamten Kette aufzulösen.

   So richten Sie DNS-Peering ein:

   1. Richten Sie Ihre private DNS-Zone in Ihrem Ziel-VPC-Netzwerk ein. Informationen zum Hinzufügen von DNS-Einträgen zu Ihrer privaten DNS-Zone finden Sie unter Ressourceneintragsgruppe hinzufügen.

   2. Erfassen Sie die folgenden Informationen, um die Konnektivitätsvorlage für das Peering zu konfigurieren:

      • Zielnetzwerk-URI (targetNetwork): Der vollständige Ressourcen-URI des Ziel-VPC-Netzwerk. Dies muss dasselbe VPC-Netzwerk sein, das den Netzwerk-Anhang enthält.

      • Domainnamen: Ein oder mehrere Domain-Suffixe für DNS-Peering. Jede Domain muss mit einem nachgestellten Punkt (.) enden, z. B. corp.internal. oder googleapis.com..

        Weitere Informationen zum Konfigurieren des Felds domains finden Sie unter Domainmuster für DNS-Peering. Informationen zu projektübergreifenden Bereitstellungen wie freigegebene VPC finden Sie unter Anforderungen an projektübergreifende DNS-Zonen und Peering.

3. TLS-Vertrauenskonfiguration einrichten (nur für Ziele mit privaten CAs und selbstsignierten Zertifikaten):

   Wenn für Ihr Ziel eine private Zertifizierungsstelle oder ein selbst signiertes Zertifikat verwendet wird, müssen Sie im Zertifikatmanager eine TrustConfig-Ressource erstellen. Die TrustConfig-Ressource definiert die Vertrauensanker und Zertifikate, die Agent Gateway zum Validieren von TLS-Verbindungen verwendet.

   1. Bereiten Sie Ihre Zertifikatsdateien im PEM-Format vor:

      • Vertrauensspeicher: Root- oder Zwischen-CA-Zertifikate im PEM-Format. Agent Gateway vertraut jedem Serverzertifikat, dessen Vertrauenskette zu einem dieser CA-Zertifikate führt. Der Trust Store muss mindestens ein Root- oder Zwischen-CA-Zertifikat enthalten.
      • Zulässige Zertifikate (optional) : Serverzertifikate im PEM-Format, denen Sie explizit vertrauen möchten, z. B. ein selbstsigniertes Zertifikat.

   2. Führen Sie den folgenden Befehl aus, um die TrustConfig-Ressource zu erstellen. Die TrustConfig muss im selben Projekt und in derselben Region wie das Agent Gateway und die Konnektivitätsvorlage erstellt werden.

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

      Ersetzen Sie Folgendes:

      • TRUST_CONFIG_NAME: Ein Name für die TrustConfig-Ressource.
      • LOCATION: Die Region für die Vertrauenskonfiguration (z. B. europe-west1). Dies muss dieselbe Region wie das Agent Gateway und die Konnektivitätsvorlage sein.
      • ROOT_CERT_FILE: Der Pfad zu Ihrem PEM-codierten Stamm- oder Zwischen-CA-Zertifikat.
      • ALLOWLISTED_CERT_FILE: (Optional) Der Pfad zu einem PEM-codierten Zertifikat, dem Sie explizit vertrauen möchten. Wenn Sie keine Zertifikate auf der Zulassungsliste verwenden, lassen Sie dieses Flag weg.

      Weitere Informationen zum Verwalten von Vertrauenskonfigurationen finden Sie unter Vertrauenskonfigurationen erstellen und verwalten.

4. Agent Gateway bereitstellen

   1. Konfigurationsdatei für die Konnektivitätsvorlage erstellen:

      Erstellen Sie eine YAML-Datei mit dem Namen 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
      

      Ersetzen Sie Folgendes:

      • AGENT_GATEWAY_PROJECT_NUMBER: Die numerische Projektnummer des Cloud de Confiance -Projekts, in dem das Gateway bereitgestellt wird. Führen Sie gcloud projects describe PROJECT_ID --format="value(projectNumber)" aus, um Ihre Projektnummer abzurufen.

      • LOCATION: Die Region für die Vorlage für die Verbindung (z. B. europe-west1).

      • CONNECTIVITY_TEMPLATE_NAME: Der Name der Konnektivitätsvorlagenressource.

      • accessPath: Der Pfad für den eingeschränkten Zugriff für die Konnektivitätsvorlage. Auf AGENT_TO_ANYWHERE festgelegt (Verbindungsvorlagen werden nur für Egress-Gateways unterstützt).

      • deploymentModel: Das Bereitstellungsmodell für das Gateway. Legen Sie CENTRALIZED fest.

      • PSC_NETWORK_ATTACHMENT_URI: Die Netzwerkverbindung der PSC-Schnittstelle für die Verbindung zu VPCs. Wenn die Netzwerkverbindung in einem anderen Projekt als dem Projekt erstellt wird, in dem Sie das Gateway bereitgestellt haben (z. B. im Hostprojekt der freigegebene VPC), geben Sie den vollständigen Pfad der Netzwerkverbindung an: projects/TARGET_VPC_PROJECT_ID/regions/REGION/networkAttachments/ATTACHMENT_NAME.

      • DOMAIN_NAME: (Optional) Ein oder mehrere Domain-Suffixe für DNS-Peering (z. B. corp.internal., googleapis.com. oder .). Fügen Sie für jedes Domain-Suffix, das Sie per Peering verbinden möchten, ein Listenelement unter domains hinzu. Jeder Wert muss mit einem nachgestellten Punkt (.) enden und eine entsprechende private verwaltete Cloud DNS-Zone haben, die für das Zielnetzwerk autorisiert ist.

        Weitere Informationen zum Konfigurieren des Felds domains finden Sie unter DNS-Peering-Domainmuster.

      • TARGET_VPC_NETWORK_URI: Das Ziel-VPC-Netzwerk, in dem Sie den Netzwerkanhang erstellt haben. Das Format muss projects/TARGET_VPC_PROJECT_ID/global/networks/TARGET_VPC_NETWORK_NAME sein. Geben Sie targetNetwork immer mit der Projekt-ID (TARGET_VPC_PROJECT_ID) an, nicht mit der Projektnummer.

      • VPC_EGRESS_MODE: Legen Sie den Modus für das Routing von ausgehendem Traffic fest. Legen Sie entweder PRIVATE_RANGES_ONLY oder ALL_TRAFFIC fest.

      • tlsConfig: (Optional) Die TLS-Konfiguration für die Validierung von Serverzertifikaten beim Herstellen einer Verbindung zu privaten Endpunkten über HTTPS:

        • TRUST_CONFIG_NAME: Der Name der Zertifikatmanager-Ressource TrustConfig, die Ihre privaten CA-Zertifikate oder Trust-Anchor enthält.
        • ADDITIONAL_ROOTS_OPTION: Gibt an, ob zusätzlich zu Ihrer benutzerdefinierten Vertrauenskonfiguration auch öffentlich vertrauenswürdige CA-Stammzertifikate verwendet werden sollen. Legen Sie PUBLICLY_TRUSTED_ROOTS (Standardeinstellung) fest, um sowohl Zertifikaten, die durch den Parameter trustConfig validiert werden, als auch allen öffentlich vertrauenswürdigen Zertifizierungsstellen zu vertrauen. Legen Sie NO_ADDITIONAL_ROOTS fest, um nur den vom Parameter trustConfig validierten Zertifikaten zu vertrauen.

   2. Verbindungsvorlage erstellen:

      Führen Sie den folgenden Befehl aus, um die Verbindungsvorlage zu erstellen:

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

      Ersetzen Sie Folgendes:

      • CONNECTIVITY_TEMPLATE_NAME: Der Name der Konnektivitätsvorlagenressource.
      • LOCATION: Der Ort, an dem Sie die Ressource für die Konnektivitätsvorlage erstellen möchten. Beispiel: europe-west1.

   3. KI-Agenten-Gateway-Ressource definieren:

      Definieren Sie eine neue Agent Gateway-Ressource im AGENT_TO_ANYWHERE-Modus, indem Sie eine Gateway-YAML-Konfigurationsdatei (z. B. my-agent-gateway-vpc-egress.yaml) erstellen, die auf die Konnektivitätsvorlage verweist:

      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
      

      Ersetzen Sie Folgendes:

      • AGENT_GATEWAY_NAME: Der Name der Agent Gateway-Ressource.

      • AGENT_GATEWAY_PROJECT_NUMBER: Die numerische Projektnummer des Cloud de Confiance Projekts, in dem Sie das Gateway und die Konnektivitätsvorlage erstellt haben. Führen Sie gcloud projects describe PROJECT_ID --format="value(projectNumber)" aus, um Ihre Projektnummer abzurufen.

      • LOCATION: Der Speicherort der Konnektivitätsvorlage (z. B. europe-west1).

      • CONNECTIVITY_TEMPLATE_NAME: Der Name der Konnektivitätsvorlagenressource.

      • AGENT_REGISTRY_PATH: Der Pfad zur Agent Registry. Sie können bis zu zwei Registries für ein Agent Gateway konfigurieren. Wenn Sie zwei Registries konfigurieren, muss eine davon eine globale Registry sein. Die andere kann entweder eine regionale oder eine multiregionale Registry sein. Die Registrierungspfade müssen so formatiert sein:

        • Regionale Registrierungsstellen: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION
        • Globale Registrierungen: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/global
        • Multiregionale Registrierungen: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/MULTI_REGION

   4. Agent Gateway importieren und bereitstellen:

      Führen Sie den folgenden Befehl aus, um die Agent Gateway-Ressource basierend auf der YAML-Spezifikation zu erstellen:

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

      Ersetzen Sie LOCATION durch den Ort, an dem Sie die Agent Gateway-Ressource erstellen möchten. Beispiel: europe-west1

Überlegungen zu Architektur und Netzwerk

In diesem Abschnitt finden Sie Architekturrichtlinien und erweiterte Netzwerk-Patterns für die Bereitstellung von Agent Gateway mit VPC-Verbindung.

Einstellungen für ausgehenden VPC-Traffic aktualisieren

Eine Konnektivitätsvorlage kann nicht geändert werden, wenn ein Agent Gateway darauf verweist.

• Wenn Sie veränderliche VPC-Ausgangseinstellungen aktualisieren möchten (z. B. die DNS-Peering-Konfiguration, den VPC-Ausgangsmodus oder die TLS-Konfiguration), müssen Sie eine neue Verbindungsvorlage erstellen, die dieselbe networkAttachment verwendet, und das Agent Gateway aktualisieren, damit es auf die neue Vorlage verweist.

• Die networkAttachment selbst ist unveränderlich, sobald sie auf einem Agent Gateway konfiguriert wurde. Wenn Sie zu einer anderen Netzwerkverbindung (oder einem anderen Ziel-VPC-Netzwerk) wechseln möchten, müssen Sie eine neue Verbindungsvorlage und ein neues Agent Gateway erstellen.

Bereitstellungstopologien für freigegebene VPC

In einer gemeinsam genutzten VPC können Sie den Netzwerk-Anhang entweder im Dienstprojekt (empfohlen) oder im Hostprojekt erstellen:

• Empfohlen: Netzwerkanhang im Dienstprojekt:
  1. Erstellen Sie das Subnetz im Hostprojekt.
  2. Netzwerkverbindung erstellen im Dienstprojekt, die auf das Subnetz des Hostprojekts verweist.
• Netzwerkanhang im Hostprojekt:
  1. Erstellen Sie das Subnetz im Hostprojekt.
  2. Netzwerkanhang im Hostprojekt erstellen

Compliance mit VPC Service Controls

Damit VPC Service Controls-Perimeter für die Agentenkommunikation erzwungen werden, müssen folgende Voraussetzungen erfüllt sein:

• Setzen Sie vpcEgress in Ihrer Konnektivitätsvorlage auf ALL_TRAFFIC.

• Leiten Sie Google API-Anfragen entweder an den restricted.googleapis.com-IP-Bereich (199.36.153.4/30) oder an einen internen Private Service Connect-Endpunkt für Google APIs weiter.

• DNS-Auflösung für googleapis.com konfigurieren Erstellen Sie in Ihrem VPC-Netzwerk eine private Cloud DNS-Zone, die *.googleapis.com restricted.googleapis.com zuordnet, und fügen Sie googleapis.com. in das Feld domains Ihrer Konnektivitätsvorlage ein.

  Weitere Informationen zur DNS-Konfiguration finden Sie in der Dokumentation zum privater Google-Zugriff unter DNS für googleapis.com konfigurieren.

• Bei Bereitstellungen mit gemeinsam genutzter VPC müssen sich das Hostprojekt, zu dem das Subnetz der Netzwerkverbindung gehört, und das dnsPeeringConfig.targetNetwork im selben Dienstperimeter wie das Projekt befinden, in dem Sie das Agent Gateway bereitstellen. Das gilt auch, wenn Sie den Netzwerk-Anhang im Dienstprojekt erstellen, da das Subnetz und das VPC-Netzwerk weiterhin zum Hostprojekt gehören. Wenn Ihre privaten DNS-Zonen in einem separaten DNS-Projekt gehostet werden, müssen Sie dieses Projekt ebenfalls in den Perimeter aufnehmen.

DNS-Peering-Domainmuster

In diesem Abschnitt werden Muster für die Domainauflösung und Optionen zum Konfigurieren des Felds domains in einer Konnektivitätsvorlage beschrieben.

Domainnamen konfigurieren: Konfigurieren Sie das Feld domains in der Konnektivitätsvorlage anhand der folgenden Überlegungen:

• Private interne Domains: Wenn Sie private interne Dienste auflösen möchten, die in Ihrem VPC-Netzwerk gehostet werden (z. B. service.corp.internal), geben Sie Ihr internes Domainsuffix an (z. B. corp.internal.). Eine private verwaltete Cloud DNS-Zone mit exakter Übereinstimmung für diese Domain muss für das Ziel-VPC-Netzwerk autorisiert sein.

• Split-Horizon-DNS (öffentliche Domain mit RFC 1918-IP): Wenn Sie eine öffentliche DNS-Zone zum Hosten von Einträgen verwenden, die auf interne private IP-Adressen verweisen (z. B. mcp.example.com, die in eine RFC 1918-Adresse für öffentliche Zertifikatmanager-Zertifikate aufgelöst wird), löst das Gateway diese Einträge automatisch mithilfe des öffentlichen rekursiven DNS auf, ohne dass DNS-Peering erforderlich ist.

• Cloud de Confiance APIs mit VPC Service Controls: Wenn ALL_TRAFFIC so konfiguriert ist, dass VPC Service Controls erzwungen werden, müssen Google API-Anfragen in den IP-Bereich restricted.googleapis.com (199.36.153.4/30) oder in interne PSC-Endpunkte aufgelöst werden. Erstellen Sie in Ihrem VPC-Netzwerk eine private Cloud DNS-Zone, die *.googleapis.com restricted.googleapis.com zuordnet, und fügen Sie googleapis.com. in das Feld domains Ihrer Konnektivitätsvorlage ein.

• Auflösungsmuster für mehrere Domains: Wenn für Ihre Bereitstellung mehrere private Domainsuffixe aufgelöst werden müssen, wählen Sie eines der folgenden Muster aus:

  • Mehrere einzelne Domains per Peering verbinden: Geben Sie eine Liste von Domainsuffixen im Feld domains von dnsPeeringConfig an (z. B. corp.internal., prod.internal. und googleapis.com.). Jede Domain in der Liste muss mit einem abschließenden Punkt (.) enden und eine entsprechende private verwaltete Cloud DNS-Zone haben, die für das Ziel-VPC-Netzwerk autorisiert ist.
  • Zusammengefasstes übergeordnetes Suffix (empfohlen): Fassen Sie interne Dienste unter einem gemeinsamen übergeordneten Domainsuffix zusammen (z. B. *.internal. oder *.corp.internal.) und fügen Sie diese übergeordnete Domain in die domains-Liste ein.

  • Catch-all-Root-Peering mit einer privaten Weiterleitungszone: Fügen Sie "." in das Feld domains der Konnektivitätsvorlage ein und konfigurieren Sie eine Cloud DNS private Weiterleitungszone für die Stammdomain (.) in Ihrem VPC-Netzwerk, die auf einen rekursiven Upstream-Resolver (z. B. 8.8.8.8 oder einen internen Unternehmensresolver) verweist. Spezifischere private Zonen in Ihrer VPC werden zuerst anhand der längsten Suffixübereinstimmung abgeglichen, während nicht übereinstimmende öffentliche Anfragen über den Upstream-Forwarder aufgelöst werden.

Projektübergreifende DNS-Zone und Peering-Anforderungen

Die Einstellung dnsPeeringConfig der Konnektivitätsvorlage unterstützt kein direktes projektübergreifendes Cloud DNS-Peering. Wenn Sie die Konnektivitätsvorlage importieren, schlägt die Validierung fehl, wenn sich targetNetwork in einem anderen Projekt als networkAttachment befindet oder wenn Sie auf die projektübergreifende DNS-Zonenbindung aus einem Dienst oder externen Projekt angewiesen sind.

Die verwaltete Zone für die Domain muss im Hostprojekt erstellt werden, zu dem targetNetwork gehört. Die verwaltete Zone kann einer der folgenden Zonentypen sein:

• Autoritative private Zone
• Weiterleitungszone
• Cloud DNS-Peering-Zone: Muss dem VPC-Netzwerk des Hostprojekts zugeordnet sein und auf ein Ziel-VPC-Netzwerk ausgerichtet sein. Die Ziel-VPC muss die Anfrage direkt mithilfe einer autoritativen privaten Zone auflösen. Das Weiterleiten der Anfrage an eine andere DNS-Peering-Zone (Verkettung) wird nicht unterstützt und führt zu einem NXDOMAIN-Fehler.

Nächste Schritte