Peering Jaringan VPC

Peering Jaringan VPC Google Cloud menghubungkan dua jaringan Virtual Private Cloud (VPC) sehingga resource di setiap jaringan dapat saling berkomunikasi. Jaringan VPC yang di-peering dapat berada dalam project yang sama, project berbeda pada organisasi yang sama, atau project berbeda dari organisasi yang berbeda.

Spesifikasi

Peering Jaringan VPC memungkinkan Anda melakukan hal berikut:

Konektivitas

  • Peering Jaringan VPC mendukung penghubungan jaringan VPC, bukan jaringan lama.
  • Peering Jaringan VPC memberikan konektivitas IPv4 dan IPv6 internal berlatensi rendah di antara pasangan jaringan VPC.
    • Peering Jaringan VPC tidak menyediakan pemilihan rute transitif. Misalnya, jika jaringan VPC net-a dan net-b terhubung menggunakan Peering Jaringan VPC, dan jaringan VPC net-a dan net-c juga terhubung menggunakan Peering Jaringan VPC, Peering Jaringan VPC tidak menyediakan konektivitas antara net-b dan net-c.
    • Anda tidak dapat menghubungkan dua jaringan VPC mode otomatis menggunakan Peering Jaringan VPC. Hal ini karena jaringan VPC yang di-peering selalu bertukar rute subnet yang menggunakan alamat IPv4 internal pribadi, dan setiap subnet dalam jaringan VPC mode otomatis menggunakan rentang alamat IP subnet yang sesuai dengan blok CIDR 10.128.0.0/9.
    • Anda dapat menghubungkan jaringan VPC mode kustom ke jaringan VPC mode otomatis selama jaringan VPC mode kustom tidak memiliki rentang alamat IP subnet yang sesuai dalam 10.128.0.0/9.
  • Peering Jaringan VPC juga menyediakan konektivitas IPv6 eksternal tertentu ke rentang alamat IPv6 eksternal tujuan pada resource berikut saat rute ke alamat IPv6 eksternal tujuan tersebut dipertukarkan oleh Peering Jaringan VPC:
    • Antarmuka jaringan instance virtual machine (VM) dual-stack
    • Aturan penerusan untuk penerusan protokol eksternal
    • Aturan penerusan untuk Load Balancer Jaringan passthrough eksternal
  • Peering Jaringan VPC mendukung konektivitas IPv4 dan IPv6. Anda dapat mengonfigurasi Peering Jaringan VPC pada jaringan VPC yang berisi subnet stack ganda.

Administrasi

  • Jaringan VPC yang di-peering tetap terpisah secara administratif. Hanya rute yang dipertukarkan, sesuai dengan konfigurasi peering.
  • Untuk membuat konektivitas peering, Administrator Jaringan untuk setiap jaringan VPC harus membuat koneksi peering ke jaringan VPC lainnya. Administrator Jaringan untuk kedua jaringan VPC dapat memutuskan koneksi peering.
  • Setiap sisi pengaitan peering disiapkan secara mandiri. Peering hanya akan aktif jika konfigurasi dari kedua sisi cocok. Kedua sisi dapat memilih untuk menghapus pengaitan peering kapan saja.
  • Pembuatan koneksi peering tidak memberi Anda peran Identity and Access Management (IAM) apa pun di jaringan VPC lain. Misalnya, jika memiliki peran Compute Network Admin atau peran Compute Security Admin untuk satu jaringan, Anda tidak menjadi Network Administrator atau Security Administrator untuk jaringan lain.

Izin IAM

  • Izin IAM untuk membuat dan menghapus Peering Jaringan VPC disertakan sebagai bagian dari peran Compute Network Admin (roles/compute.networkAdmin).
  • Anda dapat menggunakan peran khusus jika menyertakan izin berikut:
    • compute.networks.addPeering
    • compute.networks.updatePeering
    • compute.networks.removePeering
    • compute.networks.listPeeringRoutes

Keamanan jaringan

Peering Jaringan VPC tidak menukar aturan firewall VPC atau kebijakan firewall.

Untuk aturan firewall VPC:

  • Aturan firewall yang targetnya ditentukan menggunakan tag jaringan hanya di-resolve ke instance di jaringan VPC aturan firewall. Meskipun administrator keamanan jaringan VPC yang di-peering dapat menggunakan tag jaringan yang sama untuk menentukan target aturan firewall di jaringan VPC yang di-peering, target aturan firewall di jaringan VPC yang di-peering tidak menyertakan instance di jaringan VPC Anda. Demikian pula, aturan firewall masuk yang sumbernya ditentukan menggunakan tag jaringan hanya akan di-resolve ke instance di jaringan VPC aturan firewall.

  • Aturan firewall yang targetnya ditentukan menggunakan akun layanan hanya akan diselesaikan ke instance di jaringan VPC aturan firewall. Sesuai dengan izin IAM, administrator keamanan jaringan VPC yang di-peering mungkin dapat menggunakan akun layanan yang sama untuk menentukan target aturan firewall dalam jaringan VPC yang di-peering, tetapi target aturan firewall di jaringan VPC yang di-peering tidak menyertakan instance dalam jaringan VPC Anda. Demikian pula, aturan firewall masuk yang sumbernya ditentukan menggunakan akun layanan hanya di-resolve ke instance di jaringan VPC aturan firewall.

Aturan dalam kebijakan firewall jaringan dapat menggunakan Tag aman, yang berbeda dengan tag jaringan, untuk mengidentifikasi target dan sumber:

  • Saat digunakan untuk menentukan target untuk aturan masuk atau keluar dalam kebijakan firewall jaringan, Tag hanya dapat mengidentifikasi target dalam jaringan VPC yang cakupan Tag tersebut.

  • Saat digunakan untuk menentukan sumber aturan masuk dalam kebijakan firewall jaringan, Tag dapat mengidentifikasi sumber di kedua jaringan VPC yang mencakup Tag dan semua jaringan VPC yang di-peering yang terhubung ke jaringan VPC tempat Tag tercakup. Untuk informasi selengkapnya, lihat Tag untuk firewall.

Setiap jaringan VPC berisi aturan firewall tersirat. Karena aturan firewall penolakan masuk yang tersirat, administrator keamanan untuk setiap jaringan VPC harus membuat aturan firewall atau aturan masuk yang diizinkan dalam kebijakan firewall. Sumber aturan tersebut dapat mencakup rentang alamat IP dari jaringan VPC yang di-peering.

Karena aturan firewall izinkan keluar yang tersirat, Anda tidak perlu membuat aturan keluar mengizinkan firewall atau aturan dalam kebijakan firewall untuk mengizinkan paket ke tujuan dalam jaringan VPC yang di-peering, kecuali jika jaringan Anda menyertakan aturan penolakan keluar.

Dukungan DNS

Resource dalam jaringan VPC yang di-peering tidak dapat menggunakan nama DNS internal Compute Engine yang dibuat oleh jaringan VPC lokal.

Jaringan VPC yang di-peering tidak dapat menggunakan zona pribadi yang dikelola Cloud DNS yang hanya diizinkan untuk jaringan VPC lokal. Agar nama DNS tersedia untuk resource dalam jaringan VPC yang di-peering, gunakan salah satu teknik berikut:

Dukungan load balancer internal

Klien di jaringan VPC lokal dapat mengakses load balancer internal dalam jaringan VPC peer. Untuk informasi selengkapnya, lihat bagian Menggunakan Peering Jaringan VPC dari dokumentasi load balancer berikut:

Jaringan yang di-peering dapat menukar rute statis yang menggunakan Load Balancer Jaringan passthrough internal sebagai hop berikutnya. Untuk mengetahui informasi selengkapnya, lihat Opsi pertukaran rute.

Kuota & grup peering

Kuota peering VPC bergantung pada konsep yang disebut grup peering. Setiap jaringan VPC memiliki grup peering sendiri yang terdiri dari jaringan itu sendiri dan semua jaringan VPC lain yang terhubung dengannya menggunakan Peering Jaringan VPC. Dalam skenario yang paling simpel, jika dua jaringan VPC, net-a dan net-b, di-peering satu sama lain, ada dua grup peering: satu dari perspektif net-a dan yang lainnya dari perspektif net-b.

Untuk mengetahui informasi selengkapnya tentang kuota Peering Jaringan VPC, lihat:

Opsi pertukaran rute

Saat berbagi rute lokal dengan jaringan VPC yang di-peering, jaringan VPC akan mengekspor rute. Lalu, jaringan VPC yang di-peering dapat import rute tersebut. Rute subnet, kecuali untuk rute subnet IPv4 yang menggunakan alamat IPv4 publik yang digunakan secara pribadi, akan selalu ditukar.

Konfigurasi Peering Jaringan VPC memungkinkan Anda mengontrol hal berikut:

  • Jika rute IPv6 ditukar.
  • Jika rute untuk subnet yang menggunakan alamat IPv4 publik yang digunakan secara pribadi diekspor atau diimpor.
  • Apakah rute statis dan dinamis diekspor atau diimpor.

Anda dapat mengubah konfigurasi sebelum peering dibuat atau saat konektivitas peering aktif.

Peering Jaringan VPC tidak menyediakan:

  • Metode terperinci untuk mengontrol pertukaran rute subnet tertentu, rute statis, dan rute dinamis.
  • Dukungan untuk pertukaran rute berbasis kebijakan.

Opsi untuk bertukar rute subnet

Tabel berikut menjelaskan opsi pertukaran rute untuk rute subnet:

Jenis rute Kondisi ekspor rute Kondisi impor rute
Rute subnet IPv4 (rentang subnet IPv4 utama dan sekunder) menggunakan rentang alamat IPv4 pribadi Selalu diekspor

Tidak dapat dinonaktifkan		 Selalu diimpor

Tidak dapat dinonaktifkan
Rute subnet IPv4 (rentang subnet IPv4 utama dan sekunder) menggunakan rentang alamat IPv4 publik yang digunakan secara pribadi Diekspor secara default

Ekspor dikontrol menggunakan flag --export-subnet-routes-with-public-ip 		Tidak diimpor secara default

Impor dikontrol menggunakan flag --import-subnet-routes-with-public-ip
Rentang subnet IPv6 internal
(ipv6-access-type=INTERNAL) 		Tidak diekspor secara default

Ekspor diaktifkan dengan menyetel --stack-type=IPV4_IPV6 		Tidak diimpor secara default

Impor diaktifkan dengan menetapkan --stack-type=IPV4_IPV6
Rentang subnet IPv6 eksternal
(ipv6-access-type=EXTERNAL) 		Tidak diekspor secara default

Ekspor diaktifkan dengan menyetel --stack-type=IPV4_IPV6 		Tidak diimpor secara default

Impor diaktifkan dengan menetapkan --stack-type=IPV4_IPV6

Opsi untuk bertukar rute statis

Tabel berikut menjelaskan opsi pertukaran rute untuk rute statis.

Jenis rute Kondisi ekspor rute Kondisi impor rute
Rute statis dengan tag jaringan (semua jenis next hop) Tidak dapat diekspor Tidak dapat diimpor
Rute statis yang menggunakan next hop gateway internet default Tidak dapat diekspor Tidak dapat diimpor
Rute statis IPv4—tanpa tag jaringan—yang menggunakan next hop yang berbeda dari gateway internet default Tidak diekspor secara default

Ekspor dikontrol dengan menggunakan flag --export-custom-routes 		Tidak diimpor secara default

Impor dikontrol dengan menggunakan flag --import-custom-routes
Rute statis IPv6—tanpa tag jaringan—yang menggunakan instance VM sebagai next hop Tidak diekspor secara default

Ekspor dikontrol menggunakan flag --export-custom-routes saat jenis stack peering ditetapkan ke --stack-type=IPV4_IPV6 		Tidak diimpor secara default

Impor dikontrol menggunakan flag --import-custom-routes saat jenis stack peering ditetapkan ke --stack-type=IPV4_IPV6

Opsi untuk bertukar rute dinamis

Tabel berikut menjelaskan opsi pertukaran rute untuk rute dinamis.

Jenis rute Kondisi ekspor rute Kondisi impor rute
Rute IPv4 dinamis Tidak diekspor secara default

Ekspor dikontrol dengan menggunakan flag --export-custom-routes 		Tidak diimpor secara default

Impor dikontrol dengan menggunakan flag --import-custom-routes
Rute IPv6 dinamis Tidak diekspor secara default

Ekspor dikontrol menggunakan flag --export-custom-routes saat jenis stack peering ditetapkan ke --stack-type=IPV4_IPV6 		Tidak diimpor secara default

Impor dikontrol menggunakan flag --import-custom-routes saat jenis stack peering ditetapkan ke --stack-type=IPV4_IPV6

Manfaat pertukaran rute statis dan dinamis

Saat satu jaringan VPC mengekspor rute statis dan dinamis, sedangkan jaringan VPC lainnya mengimpor rute tersebut, jaringan pengimpor dapat mengirimkan paket langsung ke hop berikutnya untuk setiap rute statis atau dinamis yang diimpor, yang mana hop berikutnya berada di jaringan VPC peer.

Administrator jaringan dari jaringan VPC lokal mengontrol ekspor rute statis dan dinamis jaringan tersebut—bersama-sama—menggunakan flag --export-custom-routes. Administrator jaringan dari jaringan VPC yang di-peering terkait mengontrol impor rute statis dan dinamis menggunakan flag --import-custom-routes. Untuk mengetahui informasi selengkapnya, lihat Rute yang diabaikan, Interaksi rute subnet dan peering, serta Interaksi subnet dan rute statis.

Mengimpor rute statis dan dinamis dari jaringan VPC yang di-peering dapat berguna dalam skenario berikut:

  • Jika jaringan VPC yang di-peering berisi cluster GKE berbasis rute, dan Anda perlu mengirim paket ke Pod dalam cluster tersebut. Alamat IP pod diterapkan sebagai rentang tujuan untuk rute statis yang terletak di jaringan VPC yang di-peering.
  • Jika Anda perlu menyediakan konektivitas antara jaringan lokal dan jaringan VPC yang di-peering. Misalkan jaringan VPC lokal berisi rute dinamis dengan tunnel Cloud VPN next hop, lampiran Cloud Interconnect (VLAN), atau perangkat Router yang terhubung ke jaringan lokal. Untuk menyediakan jalur dari jaringan VPC yang di-peering ke jaringan lokal, administrator jaringan untuk jaringan VPC lokal dapat mengaktifkan ekspor rute kustom, dan administrator jaringan untuk jaringan VPC yang di-peering dapat mengaktifkan impor rute kustom. Untuk menyediakan jalur dari jaringan lokal ke jaringan VPC yang di-peering, administrator jaringan untuk jaringan VPC lokal harus menggunakan iklan rute kustom Cloud Router di Cloud Router yang mengelola sesi BGP untuk tunnel Cloud VPN, lampiran Cloud Interconnect (VLAN), atau perangkat Router yang terhubung ke jaringan lokal. Konten iklan rute kustom tersebut harus menyertakan rentang alamat IP subnet jaringan VPC yang di-peering.

Rute yang diabaikan

Meskipun jaringan VPC mengimpor rute, jaringan tersebut dapat mengabaikan rute yang diimpor dalam situasi seperti berikut:

  • Jika jaringan VPC lokal memiliki rute dengan tujuan yang mirip atau lebih spesifik (subnet mask yang lebih panjang), jaringan VPC lokal selalu menggunakan rute lokalnya.

  • Jika jaringan VPC lokal tidak berisi rute paling spesifik untuk tujuan paket, tetapi dua atau beberapa jaringan VPC yang di-peering berisi tujuan yang sama dan paling spesifik untuk paket tersebut, Google Cloud menggunakan algoritma internal untuk memilih next hop hanya dari salah satu jaringan VPC yang di-peering. Pemilihan ini dilakukan sebelum prioritas rute dipertimbangkan, dan Anda tidak dapat mengonfigurasi perilaku tersebut. Sebagai praktik terbaik, hindari konfigurasi ini karena menambahkan atau menghapus jaringan VPC yang di-peering dapat menimbulkan perubahan yang tidak diinginkan pada urutan pemilihan rute.

Untuk mengetahui detail selengkapnya tentang situasi sebelumnya, lihat Urutan pemilihan rute.

Untuk peering stack ganda, jika jaringan VPC lokal yang mengimpor rute IPv6 tidak memiliki subnet stack ganda, rute IPv6 yang diterima dari jaringan VPC yang di-peering tidak dapat digunakan. Selanjutnya, jika batasan kebijakan organisasi constraints/compute.disableAllIpv6 telah ditetapkan, Administrator Jaringan mungkin tidak dapat membuat subnet stack ganda.

Subnet dan interaksi rute subnet peering

Rute subnet IPv4 di jaringan VPC yang di-peering tidak boleh tumpang tindih:

  • Proses peering akan melarang rute subnet IPv4 yang identik. Misalnya, dua jaringan VPC yang di-peering tidak boleh memiliki rute subnet IPv4 yang tujuannya 100.64.0.0/10.
  • Proses peering akan melarang rute subnet yang dimuat dalam rute subnet peering. Misalnya, jika jaringan VPC lokal memiliki rute subnet yang tujuannya 100.64.0.0/24, tidak ada jaringan VPC yang di-peering yang boleh memiliki rute subnet yang tujuannya 100.64.0.0/10.

Google Cloud memberlakukan persyaratan sebelumnya untuk rute subnet IPv4 dalam kasus berikut:

  • Saat Anda menghubungkan jaringan VPC untuk pertama kalinya menggunakan Peering Jaringan VPC.
  • Saat jaringan di-peering.
  • Saat Anda membuat perubahan konfigurasi peering—misalnya, mengaktifkan impor rute IPv4 subnet dengan alamat IP publik yang digunakan secara pribadi.

Saat Anda melakukan peering jaringan, Google Cloud akan menampilkan error jika terjadi tumpang-tindih pada salah satu operasi berikut:

Rute subnet IPv6 (internal dan eksternal) bersifat unik menurut definisi. Tidak ada dua jaringan VPC yang dapat menggunakan rentang subnet IPv6 internal atau eksternal yang sama. Misalnya, jika satu jaringan VPC menggunakan fc:1000:1000:1000::/64 sebagai rentang subnet IPv6, tidak ada jaringan VPC lain di Google Cloud yang dapat menggunakan fc:1000:1000:1000::/64, terlepas dari apakah jaringan VPC tersebut terhubung dengan menggunakan Peering Jaringan VPC.

Interaksi subnet dan rute statis

Google Cloud mengharuskan rute subnet dan rute subnet peering memiliki rentang IPv4 atau IPv6 tujuan yang paling spesifik. Dalam jaringan VPC apa pun, rute statis lokal tidak boleh memiliki tujuan yang sama persis atau sesuai dengan rute subnet lokal. Untuk pembahasan lebih mendetail tentang skenario ini, lihat Interaksi dengan rute statis.

Konsep ini diperluas ke Peering Jaringan VPC dengan dua aturan berikut:

  • Rute statis lokal tidak boleh memiliki tujuan yang sama persis atau sesuai dengan rute subnet yang di-peering. Jika ada rute statis lokal, Google Cloud akan menerapkan hal berikut:

    • Anda tidak dapat membuat koneksi peering baru ke jaringan VPC yang sudah berisi rute subnet yang sama persis atau berisi tujuan rute statis lokal jika konfigurasi peering mengakibatkan pengimporan rute subnet yang bertentangan. Contoh:

      • Jika ada rute statis lokal dengan tujuan 10.0.0.0/24, Anda tidak dapat membuat koneksi peering baru ke jaringan VPC yang berisi rute subnet IPv4 yang tujuannya sama persis dengan 10.0.0.0/24 atau berisi 10.0.0.0/24 (misalnya, 10.0.0.0/8).

      • Apabila jenis stack peering yang diinginkan adalah IPV4_IPV6, jika rute statis lokal dengan tujuan 2001:0db8:0a0b:0c0d::/96 tersedia, Anda tidak dapat membuat koneksi peering baru ke jaringan VPC yang berisi rute subnet IPv6 yang tujuannya sama persis atau berisi2001:0db8:0a0b:0c0d::/96. Dalam situasi ini, satu-satunya rentang alamat IPv6 subnet yang memungkinkan adalah 2001:0db8:0a0b:0c0d::/64 karena rentang alamat IPv6 subnet di Google Cloud harus menggunakan panjang subnet mask 64 bit.

    • Anda tidak dapat mengubah koneksi peering yang sudah ada jika konfigurasi peering yang diubah menyebabkan pengimporan rute subnet yang bertentangan. Contoh:

      • Misalkan dua jaringan VPC sudah di-peering, tetapi keduanya saat ini tidak mengekspor dan mengimpor rute subnet IPv4 menggunakan rentang alamat IPv4 publik yang digunakan secara pribadi. Rute statis lokal dengan tujuan 11.0.0.0/24 ada di jaringan VPC pertama, dan rute subnet dengan tujuan 11.0.0.0/8 ada di jaringan VPC yang di-peering. Anda tidak dapat mengonfigurasi jaringan VPC yang di-peering secara bersamaan untuk mengekspor rute subnet menggunakan alamat IPv4 publik yang digunakan secara pribadi dan mengonfigurasi jaringan VPC pertama untuk mengimpor rute subnet dengan menggunakan alamat IPv4 publik yang digunakan secara pribadi.

      • Misalkan dua jaringan VPC sudah di-peering, dan jenis stack peering adalah khusus IPv4. Rute statis lokal dengan tujuan 2001:0db8:0a0b:0c0d::/96 ada di jaringan VPC pertama, dan rute subnet IPv6 dengan tujuan 2001:0db8:0a0b:0c0d::/64 ada di jaringan VPC yang di-peering. Anda tidak dapat mengubah jenis stack peering ke IPV4_IPV6.

    • Sebaliknya, jika jaringan VPC sudah terhubung menggunakan Peering Jaringan VPC, Anda tidak dapat melakukan operasi berikut:

      • Buat rute statis lokal baru yang tujuannya akan sama persis atau sesuai dengan rute subnet peering yang diimpor.

      • Buat rentang alamat subnet baru di jaringan VPC yang di-peering jika rentang tersebut akan sama persis atau berisi rute statis lokal yang sudah ada.

  • Rute statis peering tidak boleh memiliki tujuan yang sama persis atau sesuai dengan rute subnet lokal. Jika ada rute subnet lokal, Google Cloud akan melarang hal berikut:

    • Anda tidak dapat membuat koneksi peering baru ke jaringan VPC yang sudah berisi rute statis yang sama persis dengan atau pas dengan tujuan rute subnet jaringan VPC lokal, jika konfigurasi peering mengakibatkan pengimporan rute statis dari peer. Sebagai contoh:

      • Jika rute subnet lokal untuk10.0.0.0/8 Anda tidak dapat membuat koneksi peering ke jaringan VPC dengan rute statis yang tujuannya sama persis10.0.0.0/8 atau sesuai dengan10.0.0.0/8 (misalnya, 10.0.0.0/24).

      • Apabila jenis stack peering yang diinginkan adalah IPV4_IPV6, jika rute subnet lokal untuk 2001:0db8:0a0b:0c0d::/64 Anda tidak dapat membuat koneksi peering ke jaringan VPC dengan rute statis yang tujuannya sama persis 2001:0db8:0a0b:0c0d::/64 atau sesuai dengan 2001:0db8:0a0b:0c0d::/64 (misalnya, 2001:0db8:0a0b:0c0d::/96).

    • Anda tidak dapat mengubah koneksi peering yang ada jika konfigurasi peering yang diubah menyebabkan pengimporan rute statis yang bertentangan.

    • Sebaliknya, jika jaringan VPC sudah terhubung menggunakan Peering Jaringan VPC, Anda tidak dapat melakukan operasi berikut:

      • Buat rute subnet lokal baru yang tujuannya akan sama persis atau berisi rute statis peering yang diimpor.
      • Buat rute statis baru di jaringan VPC yang di-peering yang tujuannya akan sama persis atau sesuai dengan rute subnet lokal yang ada.

Efek mode pemilihan rute dinamis

Mode perutean dinamis jaringan VPC menentukan region tempat awalan yang dipelajari dari Cloud Router dalam jaringan tersebut diterapkan sebagai rute dinamis lokal. Untuk mengetahui detail tentang perilaku ini, lihat Efek mode perutean dinamis.

Konsep ini diperluas ke Peering Jaringan VPC. Mode pemilihan rute dinamis pada jaringan VPC yang exporting—jaringan yang berisi Cloud Router yang mempelajari imbuhan untuk rute dinamis tersebut—akan menentukan region tempat rute dinamis peering dapat diprogram dalam jaringan pembanding:

  • Jika mode pemilihan rute dinamis pada jaringan VPC yang diekspor bersifat regional, jaringan tersebut akan mengekspor rute dinamis hanya di region yang sama dengan Cloud Router-nya yang mempelajari imbuhan.

  • Jika mode pemilihan rute dinamis jaringan VPC yang diekspor bersifat global, jaringan tersebut akan mengekspor rute dinamis di semua region.

Dalam kedua kasus tersebut, mode pemilihan rute dinamis dari jaringan VPC pengimpor tidak relevan.

Untuk contoh yang menggambarkan perilaku ini, lihat Jaringan VPC lokal dan jaringan VPC Pembanding dengan konektivitas lokal.

Interaksi subnet dan rute dinamis

Konflik antara rute subnet lokal atau peering dan rute dinamis akan diselesaikan seperti yang dijelaskan dalam Interaksi dengan rute dinamis.

Contoh Peering Jaringan VPC

Contoh berikut menunjukkan dua skenario Peering Jaringan VPC umum.

Jaringan VPC lokal dan jaringan VPC pembanding dengan konektivitas lokal

Dalam contoh ini, peering jaringan berikut disiapkan:

  • network-a di-peering ke network-b, dan network-b di-peering ke network-a.
  • network-a berisi dua subnet, dan setiap subnet berada di region terpisah. network-b berisi satu subnet.
  • network-b terhubung ke jaringan lokal dengan tunnel Cloud VPN dengan menggunakan pemilihan rute dinamis. (Prinsip yang sama berlaku jika tunnel diganti dengan lampiran VLAN Cloud Interconnect.)
  • Koneksi peering untuk network-b dikonfigurasikan dengan tanda --export-custom-routes, dan koneksi peering untuk network-a dikonfigurasikan dengan tanda --import-custom-routes.

Untuk menyediakan konektivitas dari lokal ke subnet di network-a dan network-b, Cloud Router di network-b harus dikonfigurasi agar dapat menggunakan pemberitahuan rute kustom. Misalnya, Cloud Router hanya mengiklankan awalan kustom, custom-prefix-1, yang mencakup rentang subnet dari network-b dan rentang subnet dari network-a.

Cloud Router di us-west1 akan mempelajari on-premises-prefix dari router lokal. on-premises-prefix tidak menimbulkan konflik apa pun karena lebih luas dari rute subnet dan peering. Dengan kata lain, on-premises-prefix tidak sama persis dan tidak sesuai dalam rute subnet atau subnet peering apa pun.

Tabel berikut meringkas konfigurasi jaringan yang ditentukan dalam contoh sebelumnya:

Nama jaringan Komponen jaringan IPv4 range IPv6 range Region

network-a

subnet-a

10.0.0.0/24

fc:1000:1000:1000::/64

us-west1

network-a

subnet-b

10.0.1.0/24

fc:1000:1000:1001::/64

europe-north 1

network-b

subnet-c

10.0.2.0/23

fc:1000:1000:1002::/64

us-west1

network-b

Cloud Router

10.0.0.0/22

fc:1000:1000:1000::/64

us-west1

Jaringan lokal

Router lokal

10.0.0.0/8

fc:1000:1000:1000::/56

T/A

Terlepas dari mode pemilihan rute dinamis network-a, karakteristik pemilihan rute berikut berlaku:

  • Jika mode pemilihan rute dinamis network-b bersifat global, On-premises prefix yang dipelajari oleh Cloud Router di network-b akan ditambahkan sebagai rute dinamis di semua region network-b dan sebagai rute dinamis peering di semua region network-a. Jika aturan firewall dikonfigurasi dengan benar, vm-a1, vm-a2, danvm-b dapat berkomunikasi dengan resource lokal menggunakan alamat IPv410.5.6.7 (atau alamat IPv6 fc:1000:1000:10a0:29b::).

  • Jika mode pemilihan rute dinamis network-b diubah menjadi regional, On-premises prefix yang dipelajari oleh Cloud Router di network-b hanya ditambahkan sebagai rute dinamis di region us-west1 dari network-b dan sebagai rute dinamis peering di region us-west1 dari network-a. Jika aturan firewall sudah dikonfigurasi dengan benar, hanya vm-a1 dan vm-b yang dapat berkomunikasi dengan resource lokal dengan alamat IPv4 10.5.6.7 (atau fc:1000:1000:10a0:29b:: alamat IPv6) karena itu adalah satu-satunya VM di region yang sama dengan Cloud Router.

Jaringan transit

Pada contoh berikut, network-b bertindak sebagai jaringan transportasi umum.

  • network-a di-peering ke network-b, dan network-b di-peering ke network-a.
  • network-c di-peering ke network-b, dan network-b di-peering ke network-c.
  • network-b terhubung ke jaringan lokal dengan tunnel Cloud VPN menggunakan perutean dinamis. Prinsip yang sama berlaku jika tunnel{i> <i} diganti dengan lampiran VLAN Cloud Interconnect.
    • Untuk menyediakan konektivitas dari lokal ke subnet di network-a, network-b, dan network-c, Cloud Router di network-b dikonfigurasi untuk menggunakan iklan rute kustom. Misalnya, Cloud Router mengiklankan rute subnet dari network-b ditambah awalan kustom yang mencakup rute subnet di network-a dan network-c.
    • Sesuai dengan interaksi rute subnet dan dinamis, Cloud Router di network-b mempelajari awalan lokal dan membuat rute dinamis di network-b.
  • Koneksi peering dari network-b ke network-a dan dari network-b ke network-c dikonfigurasi dengan flag --export-custom-routes. Koneksi peering dari network-a ke network-b dan dari network-c ke network-b dikonfigurasi dengan flag --import-custom-routes.

Jika firewall dikonfigurasi dengan benar, skenario konektivitas berikut dapat terjadi:

  • Instance VM di network-a dapat menjangkau VM lain di network-b dan sistem lokal.
  • Instance VM di network-c dapat menjangkau VM lain di network-b dan sistem lokal.
  • Instance VM di network-b dapat menjangkau VM lain di network-a dan network-c, serta sistem di jaringan lokal.

Karena Peering Jaringan VPC tidak bersifat transitif, instance VM di network-a dan network-c tidak dapat saling berkomunikasi kecuali jika Anda juga menghubungkan jaringan network-a dan network-c menggunakan VPC Peering Jaringan.

Harga

Harga jaringan reguler berlaku untuk Peering Jaringan VPC.

Langkah selanjutnya