Rute statis

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

Untuk ringkasan umum tentang 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 perutean dinamis, Cloud VPN mungkin membuat rute statis yang sesuai secara otomatis. Untuk informasi selengkapnya, lihat Jaringan dan tunnel Cloud VPN pemilihan rute.

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: Dalam jaringan VPC mode otomatis, jangan membuat statis kustom rute yang tujuannya cocok dalam rentang 10.128.0.0/9. Rentang itu berisi subnet yang dibuat secara otomatis. Rute statis dengan tujuan di dalamnya 10.128.0.0/9 yang ada di jaringan VPC mode otomatis mungkin dinonaktifkan secara tiba-tiba saat region Google Cloud baru tersedia. Hal ini terjadi karena rute subnet baru dibuat untuk alamat IPv4 utama rentang subnet region baru yang otomatis dibuat. Untuk informasi selengkapnya, lihat rentang IP mode otomatis dan pertimbangan untuk mode otomatis Jaringan VPC.

Parameter rute

Rute statis mendukung atribut berikut:

• Name dan Description. 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 satu rute Jaringan VPC.

• Hop berikutnya. {i>Next hop<i} mengidentifikasi sumber daya jaringan yang menjadi tujuan paket akan dikirimkan. Semua jenis next hop mendukung tujuan IPv4, dan beberapa next hop yang mendukung tujuan IPv6. Untuk informasi selengkapnya, lihat Next hop dan fitur-fitur.

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

  Tujuan untuk rute statis harus mengikuti aturan yang dijelaskan di Interaksi dengan rute statis dan Subnet dan rute statis interaksi. Yang paling luas tujuan yang mungkin untuk rute statis IPv4 adalah 0.0.0.0/0. Yang paling luas tujuan yang mungkin untuk rute statis IPv6 adalah ::/0.

• Prioritas. Angka yang lebih kecil menunjukkan prioritas yang lebih tinggi. Tertinggi prioritas yang memungkinkan adalah 0, dan prioritas terendah yang memungkinkan 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) Kirim paket ke VM hop berikutnya yang diidentifikasi oleh IPv4 internal utama alamat IPv6 internal atau eksternal dari antarmuka jaringannya. Sebagai informasi selengkapnya, lihat Pertimbangan untuk next hop instance baru.		(Pratinjau)
Load Balancer Jaringan passthrough internal next hop dengan 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 project secara opsional. Sebagai informasi selengkapnya, lihat Pertimbangan untuk hop berikutnya Load Balancer Jaringan passthrough internal.
Load Balancer Jaringan passthrough internal next hop menurut alamat (next-hop-ilb) Mengirim paket ke backend Load Balancer Jaringan passthrough internal yang diidentifikasi oleh IP ke alamat aturan penerusan load balancer. Untuk mengetahui informasi selengkapnya, baca bagian Pertimbangan untuk next hop Load Balancer Jaringan passthrough internal.
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 proyek:

• 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 perutean berbasis instance atau Load Balancer Jaringan passthrough internal sebagai hop berikutnya, pertimbangkan pedoman berikut:

• Anda harus mengonfigurasi VM backend atau instance hop berikutnya 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 dalam grup instance terkelola, aktifkan penerusan IP di template instance yang digunakan oleh grup instance. Anda harus membuat perubahan konfigurasi ini di tambahan untuk konfigurasi sistem operasi apa pun yang diperlukan untuk merutekan paket.

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

• Backend VM atau instance next hop harus memiliki firewall yang sesuai aturan. 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. Tujuan aturan tolak masuk tersirat memblokir semua paket masuk, jadi Anda harus membuat aturan firewall izinkan traffic masuk kustom.
  • Aturan firewall traffic keluar yang berlaku untuk instance yang menjalankan fungsi perutean harus menyertakan alamat IP tujuan paket yang dirutekan. Aturan izinkan keluar tersirat mengizinkan hal ini kecuali Anda telah membuat aturan penolakan traffic keluar untuk menggantinya.
  • Pertimbangkan apakah VM backend atau Instance Next Hop menjalankan Penafsiran Alamat Jaringan (NAT) saat membuat aturan firewall.

  Untuk informasi selengkapnya, lihat Firewall tersirat aturan.

• Region sumber paket yang dikirim oleh VM backend atau instance hop berikutnya adalah region tempat VM backend atau instance hop berikutnya 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 mengirimkan paket mencakup berikut ini:

  • Load Balancer Jaringan passthrough internal, Load Balancer Aplikasi internal, dan Load Balancer Jaringan proxy internal regional dengan akses global dinonaktifkan
  • Tunnel Cloud VPN, VLAN Cloud Interconnect lampiran, dan VM peralatan {i> Router<i} Konektivitas Jaringan, jika Jaringan VPC menggunakan perutean 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 hop berikutnya yang ditentukan oleh instance nama dan zona Anda, Google Cloud mengharuskan instance dengan nama tersebut berada di zona yang ditentukan dan memenuhi persyaratan berikut:

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

  Selama rute statis ada, hal berikut akan berlaku:

  • Google Cloud secara otomatis mengupdate pemrograman untuk next hop in salah satu kasus berikut:

    • Alamat IPv4 internal utama dari instance next hop berubah, atau
    • Anda mengganti instance hop berikutnya, 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 mengupdate pemrograman untuk next hop di kasus berikut:

    • Saat instance dihapus.
    • Rentang alamat IPv6 yang ditetapkan untuk perubahan NIC instance.
    • 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.
  • Alamat IPv6 internal atau eksternal apa pun di rentang alamat IPv6 /96 yang ditetapkan ke antarmuka jaringan VM.

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

  Google Cloud secara otomatis memperbarui pemrograman untuk next hop jika alamat IP hop berikutnya dipindahkan ke VM lain, jika alamat IP tetap akan menggunakan alamat IP VM next hop yang valid.

  Ketika Anda menentukan {i>instance <i}berikutnya berdasarkan alamat IP, paket akan dirutekan ke antarmuka jaringan instance, bukan alamat IP spesifik.

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

• Biaya dan latensi region-ke-region: Saat Anda menggunakan VM sebagai hop berikutnya, next hop terletak di zona suatu region. Rute yang menggunakan hop berikutnya tersedia untuk semua instance di jaringan VPC yang sama atau instance tertentu dengan tag jaringan yang cocok. Google Cloud tidak pertimbangkan jarak regional untuk rute yang menggunakan instance sebagai next hop, jadi dimungkinkan untuk membuat rute yang mengirimkan lalu lintas ke VM {i>next hop<i} dalam wilayah yang berbeda. Mengirim paket dari satu {i>region<i} ke {i>region<i} lain menambahkan keluar biaya transfer data dan menyebabkan latensi jaringan.

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

• Tidak ada hashing simetris saat menghubungkan dua jaringan VPC: Google Cloud tidak menawarkan hashing simetris saat menggunakan dua atau lebih VM next hop 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 terhubung jaringan VPC, dan Anda perlu meminta agar VM yang sama diproses paket untuk koneksi yang diberikan di kedua arah, Anda membutuhkan {i>hashing<i}, yang hanya didukung oleh Load Balancer Jaringan passthrough internal {i> next hop<i}. Untuk selengkapnya informasi selengkapnya, lihat Symmetric hashing.

• Perilaku saat instance dihentikan atau dihapus: Google Cloud tidak mencegah untuk menghentikan atau menghapus VM next hop rute statis (ditentukan oleh nama dan zona atau alamat internal). Ketika VM next hop tidak berjalan, perutean untuk tujuan tergantung pada apakah rute lain untuk tujuan yang sama persis dan apakah rute lain tersebut memiliki hop yang berjalan. Untuk menggambarkan perilaku ini, pertimbangkan hal berikut contoh:
  • Paket yang tujuannya sesuai dengan 192.168.168.0/24 akan dikirim ke hop berikutnya dari route-vm-b dalam situasi berikut di mana hop berikutnya karena rute prioritas tertinggi tidak berjalan. Perutean ini terjadi karena Google Cloud mengabaikan hop berikutnya yang tidak berjalan sebelum mempertimbangkan langkah mengabaikan rute prioritas rendah urutan perutean:
  • route-vm-a, tujuan 192.168.168.0/24, prioritas 10, VM next hop dihentikan
  • route-vm-b, tujuan 192.168.168.0/24, prioritas 20, VM next hop sedang berjalan

  • route-vm-c, tujuan 192.168.168.0/24, prioritas 30, VM next hop sedang berjalan

  • Paket yang tujuannya sesuai dengan 192.168.168.0/24 akan dimasukkan ke dalam paket ini contoh berikutnya saat semua VM next hop untuk rute 192.168.168.0/24 tidak berjalan, meskipun rute untuk 192.168.0.0/16 yang lebih luas memiliki VM next hop yang sedang berjalan. Paket-paket dihapus karena Google Cloud mengabaikan rute dengan subnet mask yang lebih luas (subnet mask lebih pendek) panjang) rentang tujuan pada langkah tujuan paling spesifik, yang terjadi sebelum mengabaikan rute statis kustom yang hop berikutnya tidak berjalan dari urutan perutean):

  • route-vm-x, tujuan 192.168.168.0/24, prioritas 10, VM next hop dihentikan

  • route-vm-y, tujuan 192.168.168.0/24, prioritas 20, VM next hop dihentikan

  • route-vm-z, tujuan 192.168.0.0/16, prioritas 0, VM next hop sedang berjalan

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 metode jaringan aturan harus cocok dengan jaringan rute dan dalam proyek apa aturan penerusan dapat ditemukan:

  • 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 IPv4 aturan penerusan: Saat Anda menentukan aturan penerusan next hop berdasarkan alamat IPv4-nya, jaringan aturan penerusannya dapat berupa salah satu dari jaringan VPC rute atau jaringan VPC yang di-peering. Aturan penerusan bisa juga ditempatkan di 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 berbeda Load Balancer Jaringan passthrough internal next hop. Google Cloud tidak pernah mendistribusikan traffic di antara dua atau lebih Load Balancer Jaringan passthrough internal hop yang menggunakan ECMP. Sebagai gantinya, Google Cloud hanya memilih satu Load Balancer Jaringan passthrough internal hop berikutnya menggunakan determenistik, algoritme internal. 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 next hop yang sama Load Balancer Jaringan passthrough internal. Tanpa tag jaringan, Google Cloud tidak memungkinkan Anda membuat beberapa rute statis yang memiliki kombinasi tujuan, prioritas, dan Load Balancer Jaringan passthrough internal. Dengan tag jaringan, Anda dapat membuat beberapa rute statis yang memiliki kombinasi tujuan yang sama, prioritas, dan Load Balancer Jaringan passthrough internal.

Pertimbangan untuk next hop tunnel VPN Klasik

• Biaya dan latensi region-ke-region: Google Cloud tidak mempertimbangkan jarak regional untuk rute yang menggunakan VPN Klasik hop berikutnya . Mengirim traffic ke tunnel VPN Klasik hop berikutnya dalam region lain menambahkan biaya transfer data keluar dan memperkenalkan latensi yang rendah. Sebagai praktik terbaik, gunakan VPN dengan ketersediaan tinggi (HA) tunnel dengan dinamis pemilihan rute karena konfigurasi itu mempertimbangkan jarak regional.

• Perilaku saat tunnel VPN Klasik tidak berjalan: Kustom rute statis yang hop berikutnya adalah tunnel VPN Klasik tidak otomatis dihapus saat tunnel VPN Klasik tidak sedang berjalan. Untuk mengetahui detail tentang apa yang terjadi saat tunnel tidak berjalan, lihat Kapan tunnel turun dalam dokumentasi VPN Klasik.

Langkah selanjutnya

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