Rute statis

Halaman ini memberikan ringkasan cara kerja rute statis di Google Cloud.

Untuk ringkasan umum rute di Google Cloud, lihat Ringkasan rute.

Pertimbangan untuk membuat rute statis

Anda dapat membuat rute statis dengan salah satu dari dua cara berikut:

• Anda dapat membuat rute statis secara manual menggunakan konsol Google Cloud, gcloud compute routes create, atau routes.insert API.

• Jika Anda menggunakan konsol Google Cloud untuk membuat tunnel VPN Klasik yang tidak menggunakan pemilihan rute dinamis, Cloud VPN dapat membuat rute statis yang sesuai secara otomatis. Untuk mengetahui informasi selengkapnya, lihat pemilihan rute jaringan dan tunnel Cloud VPN.

Anda dapat menukar rute statis dengan jaringan VPC yang di-peering seperti yang dijelaskan dalam Opsi untuk pertukaran rute statis kustom dalam dokumentasi Peering Jaringan VPC.

Catatan: Di jaringan VPC mode otomatis, jangan buat rute statis kustom yang tujuannya sesuai dalam rentang 10.128.0.0/9. Rentang tersebut berisi subnet yang dibuat secara otomatis. Rute statis dengan tujuan di dalam 10.128.0.0/9 yang ada dalam jaringan VPC mode otomatis mungkin dinonaktifkan secara tiba-tiba saat region Google Cloud baru tersedia. Hal ini terjadi karena rute subnet baru dibuat untuk rentang alamat IPv4 utama dari subnet yang dibuat secara otomatis di region baru. Untuk mengetahui informasi selengkapnya, lihat rentang IP mode otomatis dan pertimbangan untuk jaringan VPC mode otomatis.

Parameter rute

Rute statis mendukung atribut berikut:

• Nama dan Deskripsi. Kolom ini mengidentifikasi rute. Nama wajib diisi, tetapi deskripsi bersifat opsional. Setiap rute dalam project Anda harus memiliki nama yang unik.

• Jaringan. Setiap rute harus dikaitkan dengan hanya satu jaringan VPC.

• Next hop. Next hop mengidentifikasi resource jaringan yang menjadi tujuan pengiriman paket. Semua jenis next hop mendukung tujuan IPv4, dan beberapa jenis next hop mendukung tujuan IPv6. Untuk informasi selengkapnya, lihat Next hop dan fitur-fitur.

• Rentang tujuan. Rentang tujuan adalah notasi CIDR IPv4 atau IPv6 tunggal.

  Tujuan untuk rute statis harus mengikuti aturan yang dijelaskan dalam Interaksi dengan rute statis dan Interaksi rute statis dan subnet. Tujuan terluas yang memungkinkan untuk rute statis IPv4 adalah 0.0.0.0/0. Tujuan terluas yang memungkinkan untuk rute statis IPv6 adalah ::/0.

• Prioritas. Angka yang lebih kecil menunjukkan prioritas yang lebih tinggi. Prioritas tertinggi adalah 0, dan prioritas terendah adalah 65,535.

• Tag jaringan. Anda dapat menerapkan rute statis hanya ke instance VM tertentu di jaringan VPC, yang diidentifikasi dengan tag jaringan. Jika Anda tidak menentukan tag jaringan, Google Cloud akan membuat rute statis berlaku untuk semua instance dalam jaringan. Rute statis dengan tag tidak pernah dipertukarkan saat menggunakan Peering Jaringan VPC.

Next hop dan fitur-fitur

Tabel berikut merangkum dukungan fitur rute statis berdasarkan jenis next hop:

Jenis next hop	IPv4	IPv6	ECMP^1
Gateway next hop (next-hop-gateway) Menentukan gateway internet default untuk menentukan jalur ke alamat IP eksternal.
Instance next hop berdasarkan nama dan zona (next-hop-instance) Mengirim paket ke VM next hop yang diidentifikasi berdasarkan nama dan zona, serta berada dalam project yang sama dengan rute. Untuk informasi selengkapnya, lihat Pertimbangan untuk instance next hop.
Instance next hop menurut alamat (next-hop-address) Mengirim paket ke VM next hop yang diidentifikasi oleh alamat IPv4 internal utama, atau alamat IPv6 internal atau eksternal, dari antarmuka jaringannya. Untuk mengetahui informasi selengkapnya, lihat Pertimbangan untuk instance next hop.		(Pratinjau)
Load Balancer Jaringan passthrough internal next hop berdasarkan nama aturan penerusan (next-hop-ilb) dan region (next-hop-ilb-region) Mengirim paket ke backend Load Balancer Jaringan passthrough internal yang diidentifikasi oleh nama, region, dan, secara opsional, project aturan penerusan. Untuk mengetahui informasi selengkapnya, lihat Pertimbangan untuk next hop Load Balancer Jaringan passthrough internal.		(Pratinjau)
Load Balancer Jaringan passthrough internal next hop berdasarkan alamat (next-hop-ilb) Mengirim paket ke backend Load Balancer Jaringan passthrough internal yang diidentifikasi dengan alamat IP aturan penerusan load balancer. Untuk mengetahui informasi selengkapnya, baca bagian Pertimbangan untuk next hop Load Balancer Jaringan passthrough internal.		(Pratinjau)
Tunnel VPN klasik next hop (next-hop-vpn-tunnel) Mengirim paket ke tunnel VPN Klasik next hop menggunakan pemilihan rute berbasis kebijakan atau VPN berbasis rute. Untuk informasi selengkapnya, lihat Pertimbangan untuk next hop tunnel VPN Klasik.

¹Equal-cost multipath (ECMP) berarti dua rute statis atau lebih dapat memiliki rentang tujuan dan prioritas yang sama. Meskipun Anda dapat membuat dua atau beberapa rute statis dalam jaringan VPC dengan tujuan yang sama, prioritas yang sama, dan next hop gateway internet default, efeknya sama seperti memiliki satu rute statis yang menggunakan next hop gateway internet default untuk tujuan dan prioritas tersebut.

Jaringan dan project next hop

Next hop rute statis dikaitkan dengan jaringan VPC dan project:

• Jaringan: Kecuali seperti yang ditunjukkan pada tabel di bawah, jaringan VPC next hop harus cocok dengan jaringan VPC rute.

• Project: Kecuali seperti yang ditunjukkan pada tabel di bawah, next hop harus berada dalam project yang berisi jaringan VPC next hop (project mandiri atau project host VPC Bersama). Beberapa next hop dapat ditemukan di project layanan VPC Bersama.

Jenis next hop	Dapat berada dalam jaringan VPC yang di-peering	Dapat berada dalam project layanan VPC Bersama
Gateway next hop (next-hop-gateway)
Instance next hop berdasarkan nama (next-hop-instance)
Instance next hop berdasarkan alamat (next-hop-address)
Load Balancer Jaringan passthrough internal next hop berdasarkan aturan penerusan nama dan region (next-hop-ilb)
Load Balancer Jaringan passthrough internal next hop berdasarkan alamat (next-hop-ilb)
Tunnel VPN Klasik next hop (next-hop-vpn-tunnel)

Pertimbangan umum untuk next hop Load Balancer Jaringan passthrough internal dan instance

Pemilihan rute berbasis instance mengacu pada rute statis dengan next hop yang merupakan instance VM (next-hop-instance atau next-hop-address).

Load Balancer Jaringan passthrough internal sebagai next hop mengacu pada rute statis dengan next hop yang merupakan Load Balancer Jaringan passthrough internal (next-hop-ilb).

Saat Anda mengonfigurasi pemilihan rute berbasis instance atau Load Balancer Jaringan passthrough internal sebagai next hop, pertimbangkan pedoman berikut:

• Anda harus mengonfigurasi VM backend atau instance next hop untuk meneruskan paket dari alamat IP sumber mana pun. Untuk mengonfigurasi penerusan, aktifkan penerusan IP (can-ip-forward) berbasis per VM saat Anda membuat VM. Untuk VM yang dibuat secara otomatis sebagai bagian dari grup instance terkelola, aktifkan penerusan IP di template instance yang digunakan oleh grup instance. Anda harus membuat perubahan konfigurasi ini sebagai tambahan pada konfigurasi sistem operasi yang diperlukan untuk merutekan paket.

• Software yang berjalan di VM backend atau instance next hop harus dikonfigurasi dengan benar. Misalnya, VM perangkat pihak ketiga yang bertindak sebagai router atau firewall harus dikonfigurasi sesuai dengan petunjuk produsen.

• VM backend atau instance next hop harus memiliki aturan firewall yang sesuai. Anda harus mengonfigurasi aturan firewall yang berlaku untuk paket yang dirutekan. Perhatikan hal-hal berikut:

  • Aturan firewall traffic masuk yang berlaku untuk instance yang menjalankan fungsi perutean harus menyertakan alamat IP sumber paket yang dirutekan. Aturan traffic masuk deny tersirat akan memblokir semua paket masuk, sehingga Anda setidaknya harus membuat aturan firewall allow traffic masuk kustom.
  • Aturan firewall traffic keluar yang berlaku untuk instance yang menjalankan fungsi perutean harus menyertakan alamat IP tujuan paket yang dirutekan. Aturan traffic keluar allow tersirat memberikan izin atas hal ini kecuali jika Anda telah menentukan aturan deny traffic keluar khusus untuk menggantikannya.
  • Pertimbangkan apakah VM backend atau Instance Next Hop menjalankan Penafsiran Alamat Jaringan (NAT) saat membuat aturan firewall.

  Untuk mengetahui informasi selengkapnya, lihat Aturan firewall tersirat.

• Region sumber paket yang dikirim oleh VM backend atau instance next hop adalah region tempat VM backend atau instance next hop berada. Misalnya, paket yang diproses oleh VM backend atau instance next hop di us-west1 dapat dikirim ke tujuan yang hanya dapat diakses di us-west1 meskipun VM backend atau instance next hop awalnya menerima paket dari resource di region yang berbeda dengan us-west1. Contoh resource yang hanya dapat diakses di region yang sama dengan VM yang mengirim paket meliputi hal berikut:

  • Load Balancer Jaringan passthrough internal, Load Balancer Aplikasi internal, dan Load Balancer Jaringan proxy internal regional dengan akses global dinonaktifkan
  • Tunnel Cloud VPN, lampiran VLAN Cloud Interconnect, dan VM perangkat Router Network Connectivity jika jaringan VPC menggunakan pemilihan rute dinamis regional

Pertimbangan untuk instance next hop

• Next hop berdasarkan nama dan zona instance (next-hop-instance): Saat Anda membuat rute statis yang memiliki instance next hop yang ditentukan oleh nama dan zona instance, Google Cloud mengharuskan instance dengan nama tersebut berada di zona yang ditentukan, dan memenuhi kriteria berikut:

  • Instance tersebut berada dalam project yang sama dengan rute.
  • Instance memiliki antarmuka jaringan (NIC) di jaringan VPC rute (bukan jaringan VPC yang di-peering).

  Selama rute statis ada, hal berikut akan berlaku:

  • Google Cloud akan otomatis memperbarui pemrograman untuk next hop dalam salah satu kasus berikut:

    • Alamat IPv4 internal utama dari instance next hop berubah, atau
    • Anda mengganti instance next hop, dan instance pengganti memiliki nama yang sama, berada di zona dan project yang sama, serta memiliki antarmuka jaringan di jaringan VPC rute.

  • Google Cloud tidak memperbarui pemrograman untuk next hop dalam kasus berikut:

    • Saat instance dihapus.
    • Rentang alamat IPv6 yang ditetapkan ke NIC instance berubah.
    • Jika alamat IPv4 atau IPv6 instance tidak ditetapkan.

• Alamat IP instance next hop (next-hop-address): Alamat IP VM next hop yang valid adalah sebagai berikut:
  • Alamat IPv4 internal utama dari antarmuka jaringan VM.
  • Setiap alamat IPv6 internal atau eksternal dalam rentang alamat IPv6 /96 yang ditetapkan ke antarmuka jaringan VM.

  Saat Anda membuat rute statis dengan instance next hop yang ditentukan oleh alamat IP, Google Cloud akan menerima alamat IP yang ditetapkan VM yang sesuai dalam rentang subnet dari subnet di jaringan VPC yang sama dengan rute. Namun, Google Cloud hanya memprogram rute jika alamat next hop adalah alamat IP VM next hop yang valid. Misalnya, jika Anda membuat rute dan menentukan next hop sebagai alamat IP yang berasal dari rentang IP alias, rute akan dibuat. Namun, karena alamat IP alias bukan alamat IP VM next hop yang valid, rute tidak diprogram.

  Google Cloud akan otomatis memperbarui pemrograman untuk next hop jika alamat IP next hop dipindahkan ke VM yang berbeda, jika alamat IP tersebut tetap merupakan alamat IP VM next hop yang valid.

  Saat Anda menentukan instance next hop menurut alamat IP, paket akan dirutekan ke antarmuka jaringan instance, bukan alamat IP tertentu.

• Instance next hop di project layanan VPC Bersama: Saat Anda menentukan VM next hop berdasarkan alamat IP, VM tersebut dapat berada di salah satu project yang sama dengan rute (project mandiri atau project host VPC Bersama) atau VM dapat ditempatkan di project layanan VPC Bersama. Saat Anda menentukan VM next hop berdasarkan nama dan zona instance, VM next hop harus ditempatkan di project yang sama dengan rute dan jaringan VPC (project mandiri atau project host VPC Bersama).

• Biaya dan latensi region-ke-region: Saat Anda menggunakan VM sebagai next hop, next hop tersebut berada di zona suatu region. Rute yang menggunakan next hop tersedia untuk semua instance dalam jaringan VPC yang sama atau untuk memilih instance dengan tag jaringan yang cocok. Google Cloud tidak mempertimbangkan jarak regional untuk rute yang menggunakan instance sebagai next hop, sehingga Anda dapat membuat rute yang mengirimkan traffic ke VM next hop di region yang berbeda. Mengirim paket dari satu region ke region lain akan menambah biaya transfer data keluar dan menimbulkan latensi jaringan.

• Tidak dilakukan health check, tidak dilakukan validasi konfigurasi: Google Cloud tidak pernah memeriksa apakah instance next hop memenuhi semua persyaratan yang diuraikan dalam bagian Pertimbangan umum untuk next hop Load Balancer Jaringan passthrough internal dan instance. Menonaktifkan antarmuka jaringan VM dengan mengonfigurasi sistem operasi tamu instance tidak menyebabkan Google Cloud mengabaikan instance next hop.

• Tidak ada hashing simetris saat menghubungkan dua jaringan VPC: Google Cloud tidak menawarkan hashing simetris saat menggunakan dua VM next hop atau lebih yang memiliki beberapa antarmuka jaringan dalam konfigurasi yang memenuhi semua kriteria berikut:

  • VM memiliki satu antarmuka jaringan dalam satu jaringan VPC dan antarmuka lainnya dalam jaringan VPC kedua.
  • Di setiap jaringan VPC, ada set yang terdiri dari setidaknya dua rute statis kustom untuk tujuan yang sama, menggunakan prioritas yang sama, di mana setiap rute dalam set mereferensikan VM next hop yang unik.

  Jika Anda menggunakan dua VM atau lebih dengan beberapa antarmuka untuk menghubungkan jaringan VPC, dan Anda mengharuskan VM yang sama memproses paket untuk koneksi tertentu di kedua arah, Anda memerlukan hashing simetris, yang hanya didukung oleh Load Balancer Jaringan passthrough internal next hop. Untuk informasi selengkapnya, lihat Hashing simetris.

• Perilaku saat instance dihentikan atau dihapus: Google Cloud tidak mencegah Anda menghentikan atau menghapus VM next hop rute statis (yang ditentukan berdasarkan nama dan zona atau alamat internal). Saat VM next hop tidak berjalan, pemilihan rute bergantung pada apakah rute lain untuk tujuan yang sama persis ada dan apakah rute lain tersebut memiliki next hop yang sedang berjalan. Untuk mengilustrasikan perilaku ini, pertimbangkan contoh berikut:

  • Anda memiliki rute dan status VM berikut:

    • route-a, tujuan 192.168.168.0/24, prioritas 10, VM next hop vm-a dihentikan
    • route-b, tujuan 192.168.168.0/24, prioritas 20, VM next hop vm-b sedang berjalan
    • route-c, tujuan 192.168.168.0/24, prioritas 30, VM next hop vm-c sedang berjalan

    Dalam contoh ini, paket yang tujuannya sesuai dengan 192.168.168.0/24 akan dikirim ke next hop vm-b karena next hop vm-a dari route-a prioritas tertinggi tidak berjalan. Hal ini terjadi karena langkah mengabaikan rute statis dan dinamis dengan next hop yang tidak dapat digunakan mendahului langkah mengabaikan rute dengan prioritas rendah dalam urutan pemilihan rute Google Cloud.

  • Anda memiliki rute dan status VM berikut:

    • route-x, tujuan 192.168.168.0/24, prioritas 10, VM next hop vm-x dihentikan
    • route-y, tujuan 192.168.168.0/24, prioritas 20, VM next hop vm-y dihentikan
    • route-z, tujuan 192.168.0.0/16, prioritas 0, VM next hop vm-z sedang berjalan

    Dalam contoh ini, paket yang tujuannya sesuai dengan 192.168.168.0/24 akan dihentikan karena VM next hop untuk dua rute 192.168.168.0/24 (route-x dan route-y) tidak berjalan, meskipun rute untuk tujuan 192.168.0.0/16 yang lebih luas ada (route-z) dengan VM next hop yang berjalan. Hal ini terjadi karena langkah tujuan paling spesifik mendahului langkah mengabaikan rute statis dan dinamis dengan next hop yang tidak dapat digunakan dalam urutan pemilihan rute Google Cloud.

Pertimbangan untuk next hop Load Balancer Jaringan passthrough internal

• Aturan penerusan yang didukung. Google Cloud hanya mendukung aturan penerusan Load Balancer Jaringan passthrough internal next hop. Google Cloud tidak mendukung aturan penerusan next hop yang digunakan oleh load balancer lain, penerusan protokol, atau sebagai endpoint Private Service Connect.

• Metode spesifikasi serta jaringan dan project aturan penerusan. Anda dapat menentukan aturan penerusan next hop menggunakan salah satu dari tiga metode berikut. Metode spesifikasi yang Anda gunakan menentukan apakah jaringan aturan penerusan harus cocok dengan jaringan rute dan dalam project apa aturan penerusan tersebut dapat ditemukan.

  Pilih salah satu metode berikut dan pastikan versi IP aturan penerusan Anda cocok dengan versi IP rute statis yang Anda buat:

  • Berdasarkan nama aturan penerusan (--next-hop-ilb) dan region (--next-hop-ilb-region): Saat Anda menentukan aturan penerusan next hop berdasarkan nama dan region, jaringan aturan penerusan harus cocok dengan jaringan VPC rute. Aturan penerusan harus berada dalam project yang sama yang berisi jaringan aturan penerusan (project mandiri atau project host VPC Bersama).

  • Berdasarkan aturan penerusan link resource: Link resource aturan penerusan menggunakan format /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, dengan PROJECT_ID adalah project ID dari project yang berisi aturan penerusan, REGION adalah region aturan penerusan, dan FORWARDING_RULE_NAME adalah nama aturan penerusan. Saat Anda menentukan aturan penerusan next hop berdasarkan link resource-nya, jaringan aturan penerusan harus cocok dengan jaringan VPC rute. Aturan penerusan dapat berada di salah satu project yang berisi jaringan aturan penerusan (project mandiri atau project host VPC Bersama) atau di project layanan VPC Bersama.

  • Dengan alamat IP aturan penerusan: Saat Anda menentukan aturan penerusan next hop berdasarkan alamat IPv4 atau IPv6-nya (Pratinjau), jaringan aturan penerusan dapat berupa salah satu dari jaringan VPC rute atau jaringan VPC yang di-peering. Aturan penerusan dapat berada di salah satu project yang berisi jaringan aturan penerusan (project mandiri atau project host VPC Bersama) atau project layanan VPC Bersama.

• Pengaruh akses global. Rute statis kustom yang menggunakan next hop Load Balancer Jaringan passthrough internal diprogram di semua region. Kemampuan next hop untuk dapat digunakan bergantung pada setelan akses global load balancer. Dengan mengaktifkan akses global, next hop load balancer dapat diakses di semua region jaringan VPC. Jika akses global dinonaktifkan, next hop load balancer hanya dapat diakses di region yang sama dengan load balancer. Dengan menonaktifkan akses global, paket yang dikirim dari region lain ke rute menggunakan next hop Load Balancer Jaringan passthrough internal akan dihentikan.

• Saat semua backend tidak responsif. Jika semua backend Load Balancer Jaringan passthrough internal gagal dalam health check, rute yang menggunakan next hop load balancer tersebut masih akan berpengaruh. Paket yang diproses oleh rute dikirim ke salah satu backend load balancer next hop sesuai dengan distribusi traffic.

• Aturan penerusan yang menggunakan alamat IP internal yang umum (--purpose=SHARED_LOADBALANCER_VIP) tidak didukung. Load Balancer Jaringan passthrough internal next hop dan aturan penerusan Load Balancer Jaringan passthrough internal dengan alamat IP umum adalah fitur yang sama-sama eksklusif. Load Balancer Jaringan passthrough internal next hop harus menggunakan alamat IP yang unik untuk aturan penerusan load balancer, sehingga hanya satu layanan backend (satu load balancer) yang direferensikan dengan jelas. Anda dapat meneruskan aturan penerusan yang menggunakan alamat IP internal umum untuk mereferensikan layanan backend yang berbeda (Load Balancer Jaringan passthrough internal yang berbeda).

• Beberapa rute dengan tujuan dan prioritas yang sama, tetapi Load Balancer Jaringan passthrough internal next hop yang berbeda. Google Cloud tidak pernah mendistribusikan traffic di antara dua atau beberapa Load Balancer Jaringan passthrough internal next hop menggunakan ECMP. Sebagai gantinya, Google Cloud hanya memilih satu Load Balancer Jaringan passthrough internal next hop menggunakan algoritma internal deterministik. Untuk menghindari ambiguitas ini, Anda dapat menggunakan tag jaringan yang unik untuk setiap rute.

  

  Google Cloud memilih satu next hop saat rute statis dengan berbagai next hop load Balancer Jaringan passthrough internal yang berbeda memiliki prioritas dan tujuan yang sama.

• Beberapa rute dengan tujuan, prioritas, dan Load Balancer Jaringan passthrough internal next hop yang sama. Tanpa tag jaringan, Google Cloud tidak mengizinkan Anda membuat beberapa rute statis yang memiliki kombinasi tujuan, prioritas, dan next hop Load Balancer Jaringan passthrough internal yang sama. Dengan tag jaringan, Anda dapat membuat beberapa rute statis yang memiliki kombinasi tujuan, prioritas, dan next hop Load Balancer Jaringan passthrough internal yang sama.

Pertimbangan untuk next hop tunnel VPN Klasik

• Biaya dan latensi region-ke-region: Google Cloud tidak mempertimbangkan jarak regional untuk rute yang menggunakan tunnel VPN Klasik next hop. Mengirim traffic ke tunnel VPN Klasik next hop di region lain akan menambahkan biaya transfer data keluar dan menimbulkan latensi jaringan. Sebagai praktik terbaik, gunakan tunnel VPN dengan ketersediaan tinggi (HA) bersama dengan pemilihan rute dinamis karena konfigurasi tersebut mempertimbangkan jarak regional.

• Perilaku saat tunnel VPN Klasik tidak berjalan: Rute statis kustom yang next hop-nya adalah tunnel VPN Klasik tidak otomatis dihapus saat tunnel VPN Klasik tidak berjalan. Untuk mengetahui detail tentang hal yang terjadi saat tunnel tidak berjalan, lihat Saat tunnel tidak aktif dalam dokumentasi VPN Klasik.

Langkah selanjutnya

• Untuk membuat dan mengelola rute, lihat Menggunakan rute.
• Untuk mendapatkan ringkasan umum tentang rute Google Cloud, lihat Rute.