Menyiapkan Agent Gateway dengan konektivitas VPC

Dokumen ini memandu Anda melalui proses mengonfigurasi konektivitas VPC saat men-deploy Agent Gateway sehingga dapat berkomunikasi secara pribadi dengan jaringan VPC di organisasi Anda.

Dengan menyiapkan konektivitas VPC, Anda dapat melakukan hal berikut:

• Menerapkan traffic keluar VPC untuk traffic: Merutekan traffic yang berasal dari agen Anda melalui lampiran jaringan Private Service Connect ke jaringan VPC Anda menggunakan mode PRIVATE_RANGES_ONLY atau ALL_TRAFFIC.
• Rentang alamat IP sumber statis: Traffic keluar menggunakan rentang alamat IP pribadi subnet lampiran jaringan Private Service Connect Anda sebagai alamat IP sumbernya. Rentang IP sumber statis ini memungkinkan Anda mengonfigurasi kebijakan firewall untuk jaringan VPC guna mengatur traffic yang berasal dari gateway.
• Resolusi DNS kustom: Me-resolve nama domain pribadi internal dan nama domain eksternal langsung dari agen Anda menggunakan peering Cloud DNS.
• Keamanan perimeter: Lindungi komunikasi agen menggunakan perimeter layanan Kontrol Layanan VPC.
• Validasi sertifikat pribadi atau yang ditandatangani sendiri: Terhubung ke tujuan yang menggunakan CA pribadi atau sertifikat yang ditandatangani sendiri.

Untuk mengonfigurasi konektivitas VPC, Anda membuat template konektivitas Agent Gateway (AgentConnectivityTemplate) tempat Anda menentukan dan mengelola setelan jaringan keluar untuk instance Agent Gateway.

Cara kerja konektivitas VPC

Saat Anda men-deploy Agent Gateway dengan template konektivitas, gateway menggunakan antarmuka Private Service Connect untuk merutekan traffic agen keluar ke jaringan VPC yang Anda tetapkan.

Mode traffic keluar VPC

Anda mengonfigurasi cara gateway merutekan traffic melalui network attachment menggunakan setelan vpcEgress di template konektivitas.

• Traffic ke rentang alamat IP pribadi (PRIVATE_RANGES_ONLY): Merutekan traffic yang ditujukan hanya untuk rentang alamat IP pribadi ke dalam jaringan VPC Anda. Traffic keluar dirutekan ke jaringan VPC Anda hanya jika alamat IP tujuan berada dalam salah satu rentang berikut:

  • RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
  • RFC 6598: 100.64.0.0/10
  • Kelas E: 240.0.0.0/4
  • private.googleapis.com: 199.36.153.8/30
  • restricted.googleapis.com: 199.36.153.4/30
  • Endpoint PSC untuk Google API: Jika Anda men-deploy endpoint Private Service Connect kustom untuk Google API menggunakan alamat IP pribadi internal di jaringan VPC Anda, traffic ke endpoint ini akan dirutekan melalui jaringan VPC Anda. Pastikan peering Cloud DNS dikonfigurasi dalam template konektivitas sehingga Agent Gateway dapat menyelesaikan domain Google API dengan benar ke alamat IP endpoint PSC internal Anda.

  Permintaan ke Google API publik standar ditangani secara otomatis menggunakan Akses Google Pribadi, dan traffic yang terikat ke internet dirutekan langsung melalui Agent Gateway, bukan melalui jaringan VPC Anda.

• Traffic ke semua rentang alamat IP (ALL_TRAFFIC): Merutekan semua traffic keluar yang berasal dari agen Anda melalui jaringan VPC Anda, termasuk internet publik, API SaaS eksternal, dan alamat non-RFC 1918.

  • Perutean dan keamanan: Karena setelan ini merutekan semua traffic keluar ke VPC Anda, Anda bertanggung jawab untuk mengelola perutean dan keamanannya. Pastikan jaringan VPC Anda memiliki rute default (0.0.0.0/0) untuk meneruskan traffic ini ke gateway keluar atau peralatan keamanan (seperti firewall next hop atau antarmuka Cloud Interconnect).
  • Traffic keluar internet publik: Agent Gateway mengirim traffic keluar ke jaringan VPC Anda, yang keluar ke internet publik melalui gateway Cloud NAT di subnet lampiran jaringan Private Service Connect. Jika Anda menetapkan alamat IP eksternal statis ke gateway Cloud NAT, layanan jarak jauh dapat memasukkan traffic keluar agen Anda ke daftar yang diizinkan berdasarkan alamat IP sumber ini.
  • Kontrol Layanan VPC: Mode traffic keluar harus disetel ke ALL_TRAFFIC untuk mendukung perimeter layanan Kontrol Layanan VPC.

Resolusi DNS dan pemilihan rute traffic

Secara default, Agent Gateway menyelesaikan nama domain menggunakan DNS rekursif publik. Jika agen Anda perlu mengakses beban kerja internal, alat pribadi, atau Google API yang dihosting di nama domain pribadi di jaringan VPC Anda (seperti corp.internal. atau endpoint PSC), Anda dapat mengonfigurasi peering Cloud DNS untuk meneruskan kueri DNS ke zona pribadi terkelola Cloud DNS jaringan Anda.

Tabel berikut merangkum persyaratan peering Cloud DNS dan perilaku perutean traffic untuk tujuan yang berbeda saat konektivitas VPC dikonfigurasi dalam mode ALL_TRAFFIC:

Persyaratan sertifikat TLS

Saat merutekan traffic keluar melalui HTTPS, Agent Gateway memvalidasi rantai sertifikat TLS server tujuan selama TLS handshake. Persyaratan sertifikat untuk koneksi HTTPS bergantung pada apakah endpoint target Anda menggunakan Certificate Authority (CA) yang dipercaya secara publik atau CA pribadi/yang ditandatangani sendiri.

• CA Publik: Secara default, Agent Gateway memercayai sertifikat yang dikeluarkan oleh Certificate Authority (CA) yang dipercaya secara publik yang memenuhi persyaratan sertifikat server standar (termasuk Nama Alternatif Subjek (SAN) yang cocok dengan nama host target).

• CA pribadi dan sertifikat yang ditandatangani sendiri: Jika tujuan target Anda (agen, alat, atau server MCP di jaringan VPC Anda) menggunakan CA pribadi atau PKI internal, Anda dapat mengonfigurasi anchor kepercayaan kustom menggunakan setelan tlsConfig dalam template konektivitas Anda. Dengan mereferensikan resource TrustConfig Certificate Manager, Anda dapat mengonfigurasi Agent Gateway agar hanya memercayai CA pribadi tertentu, atau menggabungkan CA root pribadi dengan CA yang dipercaya secara publik untuk membuat kepercayaan bagi endpoint publik dan pribadi.

  Saat menggunakan trustConfig untuk merutekan traffic ke tujuan yang menggunakan CA pribadi, Anda harus mengganti file PEM secara manual. Rotasi otomatis file PEM menggunakan pengelola secret, seperti Secret Manager Cloud de Confiance, tidak didukung.

Jika Agent Gateway tidak dapat memvalidasi rantai sertifikat, koneksi akan gagal.

Peran dan izin yang diperlukan

Untuk mengonfigurasi konektivitas VPC untuk Agent Gateway, pastikan identitas yang digunakan untuk penyediaan dan agen layanan gateway memiliki peran yang diperlukan.

Deployment project mandiri

Dalam project mandiri tempat gateway, network attachment, dan jaringan VPC berada di project yang sama, izin Agent Gateway standar berlaku. Untuk mengetahui detailnya, lihat Izin yang diperlukan.

Deployment VPC Bersama atau lintas project

Jika Anda menggunakan VPC Bersama atau penyiapan lintas project dengan jaringan VPC target, network attachment, atau zona DNS pribadi berada di project host pusat (TARGET_VPC_PROJECT_ID), peran berikut diperlukan selain izin standar Agent Gateway:

Mengonfigurasi konektivitas VPC

Untuk men-deploy Agent Gateway dengan template konektivitas, lakukan langkah-langkah berikut:

1. Buat lampiran jaringan Private Service Connect di jaringan VPC target Anda.

   Pastikan lampiran jaringan Anda memenuhi persyaratan berikut:

   • Preferensi koneksi: Konfigurasi lampiran jaringan untuk menerima koneksi secara otomatis (--connection-preference=ACCEPT_AUTOMATIC).
   • Persyaratan jaringan VPC yang sama: Subnet lampiran jaringan dan jaringan target yang dikonfigurasi untuk peering DNS (targetNetwork) harus berada di jaringan VPC yang sama persis. Jika subnet lampiran jaringan termasuk dalam jaringan yang berbeda dengan jaringan target peering DNS, validasi konfigurasi akan gagal.
   • Persyaratan subnet: Perhatikan persyaratan berikut untuk subnet lampiran jaringan:
     • Rentang subnet: Subnet lampiran jaringan mendukung semua rentang yang valid.
     • Ukuran subnet: Agent Gateway memerlukan subnet /28 minimum untuk lampiran jaringan. Subnet /28 menyediakan 12 alamat IP yang dapat digunakan, yang cukup untuk satu instance Agent Gateway. Jika Anda berencana menghubungkan beberapa gateway ke lampiran jaringan atau subnet yang sama, gunakan subnet yang lebih besar (seperti /26 atau /24) untuk menghindari kekurangan alamat IP.
     • Persyaratan Akses Google Pribadi: Anda harus mengaktifkan Akses Google Pribadi (private_ip_google_access = true) di subnet yang menghosting network attachment.
   • Deployment VPC Bersama: Untuk deployment VPC Bersama, lihat Topologi deployment VPC Bersama.

   Catat URI lampiran jaringan. Anda akan memerlukannya saat mengupdate atribut PSC_NETWORK_ATTACHMENT_URI dari resource template konektivitas pada langkah berikutnya.

2. Siapkan peering DNS (Opsional): Peering DNS memungkinkan Agent Gateway me-resolve nama DNS menggunakan data dari zona terkelola pribadi Cloud DNS di jaringan VPC Anda. Peering DNS hanya diperlukan saat agen Anda perlu menyelesaikan nama domain internal pribadi (seperti corp.internal.) atau menerapkan Kontrol Layanan VPC untuk Google API (googleapis.com.). Peering DNS tidak diperlukan untuk domain internet publik atau Google API standar tanpa Kontrol Layanan VPC.

   Agent Gateway mendukung peering DNS transitif hanya hingga satu hop transitif, yang berarti maksimum tiga jaringan VPC. Misalnya, vpc-net-a (jaringan tenant Agent Gateway) dapat melakukan peering ke vpc-net-b (jaringan terlampir), yang pada gilirannya melakukan peering ke vpc-net-c (jaringan jarak jauh) untuk menyelesaikan kueri DNS di seluruh rantai.

   Untuk menyiapkan peering DNS, lakukan langkah-langkah berikut:

   1. Siapkan zona DNS pribadi di jaringan VPC target Anda. Untuk menambahkan data DNS ke zona DNS pribadi, lihat bagian Menambahkan set data resource.

   2. Kumpulkan informasi berikut untuk mengonfigurasi template konektivitas guna mengaktifkan peering:

      • URI jaringan target (targetNetwork): URI resource lengkap dari jaringan VPC target. Harus berupa jaringan VPC yang sama dengan yang berisi network attachment.

      • Nama domain: Satu atau beberapa akhiran domain untuk peering DNS. Setiap domain harus diakhiri dengan titik di akhir (.) (misalnya, corp.internal. atau googleapis.com.).

        Untuk panduan tambahan tentang cara mengonfigurasi kolom domains, lihat Pola domain peering DNS. Untuk deployment lintas project seperti VPC Bersama, lihat Persyaratan peering dan zona DNS lintas project.

3. Siapkan konfigurasi kepercayaan TLS (hanya untuk tujuan dengan CA pribadi dan sertifikat yang ditandatangani sendiri):

   Jika tujuan target Anda menggunakan CA pribadi atau sertifikat yang ditandatangani sendiri, Anda harus membuat resource TrustConfig di Certificate Manager. Resource TrustConfig menentukan anchor kepercayaan dan sertifikat yang digunakan Agent Gateway untuk memvalidasi koneksi TLS.

   1. Siapkan file sertifikat Anda dalam format PEM:

      • Penyimpanan tepercaya: Sertifikat CA root atau perantara dalam format PEM. Agent Gateway memercayai sertifikat server apa pun yang rantai kepercayaannya mengarah ke salah satu sertifikat CA ini. Trust store harus berisi setidaknya satu sertifikat CA root atau perantara.
      • Sertifikat yang diizinkan (Opsional) : Sertifikat server dalam format PEM yang ingin Anda percayai secara eksplisit, seperti sertifikat yang ditandatangani sendiri.

   2. Jalankan perintah berikut untuk membuat resource TrustConfig. TrustConfig harus dibuat di project dan region yang sama dengan Agent Gateway dan template konektivitas.

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

      Ganti kode berikut:

      • TRUST_CONFIG_NAME: Nama untuk resource TrustConfig.
      • LOCATION: Region untuk konfigurasi kepercayaan (misalnya, europe-west1). Region ini harus sama dengan region Agent Gateway dan template konektivitas.
      • ROOT_CERT_FILE: Jalur ke sertifikat CA root atau perantara yang dienkode PEM.
      • ALLOWLISTED_CERT_FILE: (Opsional) Jalur ke sertifikat berenkode PEM yang ingin Anda percayai secara eksplisit. Jika Anda tidak menggunakan sertifikat yang masuk daftar yang diizinkan, hapus tanda ini.

      Untuk mengetahui informasi selengkapnya tentang cara mengelola konfigurasi kepercayaan, lihat Membuat dan mengelola konfigurasi kepercayaan.

4. Men-deploy Agent Gateway

   1. Buat file konfigurasi template konektivitas:

      Buat file YAML bernama 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
      

      Ganti kode berikut:

      • AGENT_GATEWAY_PROJECT_NUMBER: Nomor project numerik dari project Cloud de Confiance tempat gateway di-deploy. Untuk mengambil nomor project Anda, jalankan: gcloud projects describe PROJECT_ID --format="value(projectNumber)".

      • LOCATION: Region untuk template konektivitas (misalnya, europe-west1).

      • CONNECTIVITY_TEMPLATE_NAME: Nama resource template konektivitas.

      • accessPath: Jalur akses yang diatur untuk template konektivitas. Setel ke AGENT_TO_ANYWHERE (template konektivitas hanya didukung untuk gateway keluar).

      • deploymentModel: Model deployment untuk gateway. Tetapkan ke CENTRALIZED.

      • PSC_NETWORK_ATTACHMENT_URI: Lampiran jaringan antarmuka PSC untuk konektivitas ke VPC. Jika lampiran jaringan dibuat di project yang berbeda dengan tempat Anda men-deploy gateway (seperti project host VPC Bersama), teruskan jalur lengkap lampiran jaringan Anda: projects/TARGET_VPC_PROJECT_ID/regions/REGION/networkAttachments/ATTACHMENT_NAME.

      • DOMAIN_NAME: (Opsional) Satu atau beberapa akhiran domain untuk peering DNS (misalnya, corp.internal., googleapis.com., atau .). Tambahkan item daftar di bagian domains untuk setiap akhiran domain yang ingin Anda peering. Setiap nilai harus diakhiri dengan titik di akhir (.) dan memiliki zona pribadi terkelola Cloud DNS yang sesuai yang diberi otorisasi untuk jaringan target.

        Untuk panduan tambahan tentang cara mengonfigurasi kolom domains, lihat Pola domain peering DNS.

      • TARGET_VPC_NETWORK_URI: Jaringan VPC target tempat Anda membuat network attachment. Nilai ini harus dalam bentuk: projects/TARGET_VPC_PROJECT_ID/global/networks/TARGET_VPC_NETWORK_NAME. Selalu tentukan targetNetwork menggunakan project ID (TARGET_VPC_PROJECT_ID), bukan nomor project.

      • VPC_EGRESS_MODE: Tetapkan mode pemilihan rute egress. Tetapkan ke PRIVATE_RANGES_ONLY atau ALL_TRAFFIC.

      • tlsConfig: (Opsional) Konfigurasi TLS untuk validasi sertifikat server saat terhubung ke endpoint pribadi melalui HTTPS:

        • TRUST_CONFIG_NAME: Nama resource Certificate Manager TrustConfig yang berisi sertifikat CA pribadi atau anchor tepercaya Anda.
        • ADDITIONAL_ROOTS_OPTION: Menentukan apakah mempercayai root CA yang tepercaya secara publik selain konfigurasi kepercayaan kustom Anda. Disetel ke PUBLICLY_TRUSTED_ROOTS (default) untuk memercayai keduanya, sertifikat yang divalidasi oleh parameter trustConfig, dan semua CA yang dipercaya publik. Tetapkan ke NO_ADDITIONAL_ROOTS untuk memercayai hanya sertifikat yang divalidasi oleh parameter trustConfig.

   2. Buat template konektivitas:

      Jalankan perintah berikut untuk membuat template konektivitas:

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

      Ganti kode berikut:

      • CONNECTIVITY_TEMPLATE_NAME: Nama resource template konektivitas.
      • LOCATION: Lokasi tempat Anda ingin membuat resource template konektivitas. Contoh, europe-west1.

   3. Tentukan resource Agent Gateway:

      Tentukan resource Agent Gateway baru dalam mode AGENT_TO_ANYWHERE dengan membuat file konfigurasi YAML gateway (misalnya, my-agent-gateway-vpc-egress.yaml) yang mereferensikan template konektivitas:

      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
      

      Ganti kode berikut:

      • AGENT_GATEWAY_NAME: Nama resource Agent Gateway.

      • AGENT_GATEWAY_PROJECT_NUMBER: Nomor project numerik dari Cloud de Confiance project tempat Anda membuat gateway dan template konektivitas. Untuk mengambil nomor project Anda, jalankan: gcloud projects describe PROJECT_ID --format="value(projectNumber)".

      • LOCATION: Lokasi template konektivitas (misalnya, europe-west1).

      • CONNECTIVITY_TEMPLATE_NAME: Nama resource template konektivitas.

      • AGENT_REGISTRY_PATH: Jalur ke Agent Registry. Anda dapat mengonfigurasi hingga dua registri untuk Agent Gateway. Saat mengonfigurasi dua registry, salah satunya harus berupa registry global dan yang lainnya dapat berupa registry regional atau multi-regional. Jalur registri harus diformat sebagai berikut:

        • Registri regional: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION
        • Registri global: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/global
        • Registry multi-region: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/MULTI_REGION

   4. Mengimpor dan men-deploy Agent Gateway:

      Jalankan perintah berikut untuk membuat resource Agent Gateway berdasarkan spesifikasi YAML:

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

      Ganti LOCATION dengan lokasi tempat Anda ingin membuat resource Agent Gateway. Contoh, europe-west1.

Pertimbangan arsitektur dan jaringan

Bagian ini memberikan panduan arsitektur dan pola jaringan lanjutan untuk men-deploy Agent Gateway dengan konektivitas VPC.

Memperbarui setelan traffic keluar VPC

Template konektivitas tidak dapat diubah saat dirujuk oleh Agent Gateway.

• Untuk memperbarui setelan keluar VPC yang dapat diubah (seperti konfigurasi peering DNS, mode keluar VPC, atau konfigurasi TLS), Anda harus membuat template konektivitas baru yang menggunakan networkAttachment yang sama dan memperbarui Agent Gateway untuk mereferensikan template baru.

• networkAttachment itu sendiri tidak dapat diubah setelah dikonfigurasi di Agent Gateway. Untuk beralih ke network attachment lain (atau Jaringan VPC target), Anda harus membuat template konektivitas baru dan Agent Gateway baru.

Topologi deployment VPC Bersama

Dalam arsitektur VPC Bersama, Anda dapat membuat lampiran jaringan di project layanan (direkomendasikan) atau project host:

• Direkomendasikan: Lampiran jaringan di project layanan:
  1. Buat subnet di project host.
  2. Buat network attachment di project layanan, dengan mereferensikan subnet project host.
• Network attachment di project host:
  1. Buat subnet di project host.
  2. Buat network attachment di project host.

Kepatuhan Kontrol Layanan VPC

Untuk menerapkan perimeter Kontrol Layanan VPC untuk komunikasi agen, pastikan hal berikut:

• Tetapkan vpcEgress ke ALL_TRAFFIC di template konektivitas Anda.

• Mengarahkan permintaan Google API ke rentang IP restricted.googleapis.com (199.36.153.4/30) atau ke endpoint Private Service Connect internal untuk Google API.

• Konfigurasi resolusi DNS untuk googleapis.com. Buat zona Cloud DNS pribadi di jaringan VPC Anda yang memetakan *.googleapis.com ke restricted.googleapis.com, dan sertakan googleapis.com. di kolom domains template konektivitas Anda.

  Untuk mengetahui detail selengkapnya tentang konfigurasi DNS, lihat Mengonfigurasi DNS untuk googleapis.com dalam dokumentasi Akses Google Pribadi.

• Untuk deployment VPC Bersama, project host yang memiliki subnet lampiran jaringan dan dnsPeeringConfig.targetNetwork harus berada di perimeter layanan yang sama dengan project tempat Anda men-deploy Agent Gateway. Hal ini berlaku meskipun Anda membuat lampiran jaringan di project layanan, karena subnet dan jaringan VPC tetap menjadi milik project host. Jika zona DNS pribadi Anda dihosting di project DNS terpisah, sertakan project tersebut dalam perimeter juga.

Pola domain peering DNS

Bagian ini menjelaskan pola dan opsi penyelesaian domain untuk mengonfigurasi kolom domains dalam template konektivitas.

Konfigurasi nama domain: Konfigurasi kolom domains dalam template konektivitas berdasarkan pertimbangan berikut:

• Domain internal pribadi: Untuk menyelesaikan layanan internal pribadi yang dihosting di jaringan VPC Anda (misalnya, service.corp.internal), tentukan sufiks domain internal Anda (seperti corp.internal.). Zona terkelola Cloud DNS pribadi yang cocok persis untuk domain ini harus diberi otorisasi untuk jaringan VPC target.

• DNS split-horizon (Domain publik dengan IP RFC 1918): Jika Anda menggunakan zona DNS publik untuk menghosting data yang mengarah ke IP pribadi internal (seperti mcp.example.com yang di-resolve ke alamat RFC 1918 untuk sertifikat publik Certificate Manager), gateway akan otomatis me-resolve data ini menggunakan DNS rekursif publik tanpa memerlukan peering DNS.

• Cloud de Confiance API dengan Kontrol Layanan VPC: Jika ALL_TRAFFIC dikonfigurasi untuk menerapkan Kontrol Layanan VPC, permintaan Google API harus diselesaikan ke rentang IP restricted.googleapis.com (199.36.153.4/30) atau ke endpoint PSC internal. Buat zona Cloud DNS pribadi di jaringan VPC Anda yang memetakan *.googleapis.com ke restricted.googleapis.com, dan sertakan googleapis.com. di kolom domains template konektivitas Anda.

• Pola penyelesaian multi-domain: Jika deployment Anda memerlukan penyelesaian beberapa akhiran domain pribadi, pilih salah satu pola berikut:

  • Melakukan peering beberapa domain individual: Tentukan daftar akhiran domain di kolom domains dari dnsPeeringConfig (misalnya, corp.internal., prod.internal., dan googleapis.com.). Setiap domain dalam daftar harus diakhiri dengan titik (.) dan memiliki zona pribadi terkelola Cloud DNS yang sesuai dan diotorisasi untuk jaringan VPC target.
  • Sufiks induk gabungan (Direkomendasikan): Gabungkan layanan internal di bawah sufiks domain induk bersama (seperti *.internal. atau *.corp.internal.) dan sertakan domain induk tersebut dalam daftar domains.

  • Peering root catch-all dengan Zona Penerusan Pribadi: Sertakan "." di kolom domains template konektivitas, dan konfigurasi Zona Penerusan Pribadi Cloud DNS untuk domain root (.) di jaringan VPC Anda yang mengarah ke resolver rekursif upstream (seperti 8.8.8.8 atau resolver perusahaan internal). Zona pribadi yang lebih spesifik di VPC Anda akan dicocokkan terlebih dahulu berdasarkan kecocokan akhiran terpanjang, sementara kueri publik yang tidak cocok akan di-resolve melalui penerus upstream.

Persyaratan peering dan zona DNS lintas project

Setelan dnsPeeringConfig template konektivitas tidak mendukung peering Cloud DNS langsung antar-project. Saat Anda mengimpor template konektivitas, validasi akan gagal jika targetNetwork berada di project yang berbeda dengan networkAttachment, atau jika Anda mengandalkan pengikatan zona DNS lintas project dari project layanan atau eksternal.

Zona terkelola untuk domain harus dibuat di project host yang memiliki targetNetwork. Managed zone dapat berupa salah satu jenis zona berikut:

• Zona pribadi yang kredibel
• Zona penerusan
• Zona peering Cloud DNS: Harus dikaitkan dengan jaringan VPC project host dan menargetkan jaringan VPC tujuan. VPC tujuan harus menyelesaikan kueri secara langsung menggunakan zona pribadi yang tepercaya. Meneruskan kueri ke zona peering DNS lain (berantai) tidak didukung dan akan menghasilkan error NXDOMAIN.

Langkah berikutnya