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 dengan organisasi yang sama, atau project berbeda dengan organisasi yang berbeda.

Spesifikasi

Peering Jaringan VPC memungkinkan Anda melakukan hal berikut:

Konektivitas

  • Peering Jaringan VPC mendukung koneksi jaringan VPC, bukan jaringan lama.
  • Peering Jaringan VPC menyediakan konektivitas IPv4 dan IPv6 internal antara pasangan jaringan VPC. Traffic peering (traffic yang mengalir di antara jaringan yang di-peering) memiliki latensi, throughput, dan ketersediaan yang sama dengan traffic dalam jaringan VPC yang sama.
    • Peering Jaringan VPC tidak menyediakan perutean 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 menukar 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 dengan 10.128.0.0/9.
  • VPC Network Peering juga menyediakan konektivitas IPv6 eksternal tertentu ke rentang alamat IPv6 eksternal tujuan dari resource berikut saat rute ke alamat IPv6 eksternal tujuan tersebut dipertukarkan oleh VPC Network Peering:
    • 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 salah satu 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

Jaringan VPC yang terhubung menggunakan Peering Jaringan VPC hanya menukar rute, berdasarkan opsi pertukaran rute yang dikonfigurasi oleh administrator jaringan dari setiap jaringan VPC.

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 dalam 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 di-resolve ke instance di jaringan VPC aturan firewall.

  • Aturan firewall yang targetnya ditentukan menggunakan akun layanan hanya di-resolve ke instance di jaringan VPC aturan firewall. Bergantung pada izin IAM, administrator keamanan jaringan VPC yang tertaut mungkin dapat menggunakan akun layanan yang sama untuk menentukan target aturan firewall di jaringan VPC yang tertaut, tetapi target aturan firewall di jaringan VPC yang tertaut tidak menyertakan instance di 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 di jaringan VPC yang dicakup oleh Tag.

  • Saat digunakan untuk menentukan sumber aturan masuk dalam kebijakan firewall jaringan, Tag dapat mengidentifikasi sumber di jaringan VPC yang dicakup Tag dan jaringan VPC peering apa pun yang terhubung ke jaringan VPC yang dicakup Tag. Untuk mengetahui informasi selengkapnya, lihat Tag untuk firewall.

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

Karena aturan izinkan firewall traffic keluar yang tersirat, Anda tidak perlu membuat aturan izinkan firewall traffic keluar atau aturan dalam kebijakan firewall untuk mengizinkan paket ke tujuan di jaringan VPC yang di-peering, kecuali jika jaringan Anda menyertakan aturan penolakan traffic 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 pembanding. Untuk mengetahui informasi selengkapnya, lihat bagian Menggunakan Peering Jaringan VPC dalam dokumentasi load balancer berikut:

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

Grup peering & kuota

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:

Batasan

Peering Jaringan VPC memiliki batasan berikut.

Rentang IP subnet tidak boleh tumpang-tindih di seluruh jaringan VPC yang di-peering

Tidak ada rentang IP subnet yang dapat sama persis, berisi, atau sesuai dengan rentang IP subnet lain dalam jaringan VPC yang di-peering. Pada saat peering, Google Cloud memeriksa apakah ada subnet dengan rentang IP yang tumpang-tindih; jika ada, peering akan gagal. Untuk jaringan yang sudah di-peering, jika Anda melakukan tindakan yang menghasilkan pembuatan rute subnet baru, Google Cloud mewajibkan rute subnet baru memiliki rentang alamat IP tujuan yang unik.

Sebelum membuat subnet baru, Anda dapat mencantumkan rute dari koneksi peering untuk memastikan bahwa rentang alamat IPv4 subnet baru belum digunakan.

Batasan ini dan pemeriksaan terkait Google Cloud juga berlaku untuk skenario seperti berikut:

  • Jaringan VPC Anda, network-1, di-peering dengan jaringan VPC kedua, network-2.
  • network-2 juga di-peering dengan jaringan VPC ketiga, network-3.
  • network-3 tidak di-peering dengan network-1.

Dalam skenario ini, Anda harus berkoordinasi dengan administrator jaringan untuk network-2. Minta administrator jaringan network-2 untuk mencantumkan rute peering di jaringan VPC mereka.

Untuk mengetahui informasi selengkapnya tentang pemeriksaan tumpang-tindih, lihat Interaksi rute subnet dan subnet peering.

Nama DNS internal tidak di-resolve di jaringan yang di-peering

Nama DNS internal Compute Engine yang dibuat dalam jaringan tidak dapat diakses oleh jaringan yang di-peering. Untuk menjangkau instance VM dalam jaringan yang di-peering, gunakan alamat IP VM.

Tag dan akun layanan tidak dapat digunakan di seluruh jaringan yang di-peering

Anda tidak dapat merujuk pada tag atau akun layanan yang terkait dengan VM dari satu jaringan yang di-peering dalam aturan firewall di jaringan yang di-peering lainnya. Misalnya, jika aturan masuk dalam satu jaringan yang di-peering memfilter sumbernya berdasarkan tag, aturan tersebut hanya akan mengizinkan penerapan ke traffic VM yang berasal dari dalam jaringan tersebut, bukan peer-nya, bahkan jika VM di jaringan yang di-peering memiliki tag tersebut. Situasi ini juga berlaku untuk akun layanan dengan cara yang serupa.

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 mengimpor 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.
  • Jika 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, rute statis, dan rute dinamis tertentu.
  • Dukungan untuk bertukar 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 menyetel --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 menyetel --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 dan jaringan VPC lainnya mengimpor rute tersebut, jaringan pengimpor dapat mengirim paket langsung ke next hop untuk setiap rute statis atau dinamis yang diimpor yang next hop-nya berada di jaringan VPC pembanding.

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

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 di 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 tertaut. 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 akan mengaktifkan ekspor rute kustom, dan administrator jaringan untuk jaringan VPC yang di-peering akan mengaktifkan impor rute kustom. Untuk menyediakan jalur dari jaringan lokal ke jaringan VPC yang di-peering, administrator jaringan untuk jaringan VPC lokal harus mengonfigurasi mode iklan 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 rute kustom yang diiklankan 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 mengetahui pembahasan yang 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 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 atau sesuai dengan tujuan rute subnet jaringan VPC lokal, jika konfigurasi peering menyebabkan pengimporan rute statis dari pembanding. 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 pemilihan rute dinamis jaringan VPC akan menentukan region tempat imbuhan yang dipelajari dari Cloud Router dalam jaringan tersebut diterapkan sebagai rute dinamis lokal. Untuk mengetahui detail tentang perilaku ini, lihat Efek mode pemilihan rute dinamis.

Konsep ini diperluas ke Peering Jaringan VPC. Mode pemilihan rute dinamis pada jaringan VPC yang mengekspor—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 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 dikonfigurasi dengan flag --export-custom-routes, dan koneksi peering untuk network-a dikonfigurasi dengan flag --import-custom-routes.
Jaringan yang di-peering dengan pemilihan rute dinamis global.
Jaringan yang di-peering dengan akses ke jaringan lokal melalui pemilihan rute dinamis global (klik untuk memperbesar).

Untuk menyediakan konektivitas dari lokal ke subnet di network-a dan network-b, Cloud Router di network-b harus dikonfigurasi agar dapat menggunakan mode iklan kustom. Misalnya, Cloud Router hanya memberitahukan imbuhan 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 dengan beberapa peering

Pertimbangkan skenario saat network-b terhubung ke jaringan lokal dan bertindak sebagai jaringan transportasi umum untuk dua jaringan lainnya, network-a dan network-c. Agar VM di kedua jaringan ini dapat mengakses network-b dan jaringan lokal yang terhubung hanya menggunakan alamat IP internal, konfigurasi berikut diperlukan:

  • 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 pemilihan rute dinamis. Prinsip yang sama berlaku jika tunnel 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 mode iklan kustom. Misalnya, Cloud Router memberitahukan rute subnet dari network-b plus imbuhan kustom yang mencakup rute subnet di network-a dan network-c.
    • Tunduk kepada interaksi rute dinamis dan subnet, Cloud Router di network-b akan mempelajari imbuhan 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.
Jaringan VPC transit, berisi tunnel VPN, yang di-peering dengan dua jaringan VPC lainnya.
Jaringan transit VPC (klik untuk memperbesar).

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