Urutan rute

Halaman ini menjelaskan cara kerja rute kustom dengan next hop tunnel Cloud VPN di Google Cloud.

Untuk mengetahui informasi latar belakang tentang rute Google Cloud, termasuk penerapan dan urutan rute, serta parameter rute statis, lihat ringkasan rute Virtual Private Cloud (VPC).

Jenis rute

Tunnel Cloud VPN dapat menjadi next hop untuk rute kustom di jaringan VPC Anda. Setiap rute kustom dengan tunnel Cloud VPN next hop menentukan jalur keluar untuk paket yang keluar dari jaringan VPC Anda:

Cloud Router selalu mengelola tunnel VPN Klasik yang menggunakan perutean dinamis atau tunnel VPN dengan ketersediaan tinggi (HA). Cloud Router menerima pemberitahuan BGP dari dan mengirim pesan BGP ke gateway VPN peer. Cloud Router membuat dan menghapus rute dinamis kustom di jaringan VPC secara otomatis, yaitu rute dengan tujuan di jaringan peer. VPC juga memberitahukan rute ke jaringan peer, yaitu rute ke rentang IP subnet di jaringan VPC atau ke tujuan khusus yang Anda tentukan dalam konfigurasi Cloud Router. Mode perutean dinamis pada jaringan VPC mengontrol kumpulan rute yang diimpor dan diekspor Cloud Router.
Tunnel VPN Klasik berbasis kebijakan atau berbasis rute menggunakan perutean statis. Jika Anda menggunakan konsol Google Cloud untuk membuat salah satu tunnel, Google Cloud akan secara otomatis membuat rute statis kustom berdasarkan rentang IP jarak jauh yang Anda tentukan di konfigurasi Cloud VPN. Jika Anda menggunakan Google Cloud CLI untuk membuat salah satu tunnel, Anda harus secara manual membuat rute statis yang menggunakan tunnel tersebut sebagai next hop.

Contoh skenario

Google Cloud mengikuti penerapan dan urutan yang ditentukan saat memilih next hop yang menjadi tujuan pengiriman paket. Contoh berikut menunjukkan interaksi umum antara rute dan Cloud VPN.

Interaksi dengan rute subnet

Tabel berikut menunjukkan cara rute subnet dan rute kustom berinteraksi. Setiap baris mewakili kemungkinan rentang IP subnet dalam jaringan VPC. Rentang lokal adalah 10.2.0.0/16 untuk IPv4 dan fd20:a:b:c::/64 untuk IPv6.

Traffic IPv6 hanya didukung oleh gateway VPN dengan ketersediaan tinggi (HA) yang dikonfigurasi dengan jenis stack ganda IPv4 dan IPv6.

Jaringan VPC	Perutean tunnel Cloud VPN
Rentang IP subnet Google Cloud	Statis (berbasis kebijakan, berbasis rute) Khusus VPN klasik	Dinamis (BGP) VPN Klasik atau VPN dengan ketersediaan tinggi (HA)
`10.2.0.0/16` Sama seperti rentang IP lokal	Google Cloud tidak mengizinkan Anda membuat rute statis kustom yang tujuannya adalah `10.2.0.0/16` dan next hop-nya adalah tunnel Cloud VPN.	Cloud Router yang terkait dengan tunnel mengabaikan semua pemberitahuan rute dengan tujuan `10.2.0.0/16`. Traffic yang ditujukan untuk `10.2.0.0/16` tetap ada di jaringan VPC Anda.
`fd20:a:b:c::/64` Sama seperti rentang IP lokal	VPN klasik tidak mendukung IPv6.	Cloud Router yang terkait dengan tunnel mengabaikan pemberitahuan semua rute dengan tujuan `fd20:a:b:c::/64`. Traffic yang ditujukan untuk `fd20:a:b:c::/64` tetap ada di jaringan VPC Anda.
`10.0.0.0/8` Lebih luas daripada rentang IP lokal (subnet mask yang lebih kecil)	Google Cloud tidak mengizinkan Anda membuat rute statis kustom yang tujuannya adalah `10.2.0.0/16` dan next hop-nya adalah tunnel Cloud VPN.	Cloud Router yang terkait dengan tunnel mengabaikan semua pemberitahuan rute yang tujuannya sesuai dengan `10.0.0.0/8`, termasuk `10.2.0.0/16`. Traffic yang ditujukan untuk `10.0.0.0/8` tetap ada di jaringan VPC Anda.
`fd20:a:b::/48` Lebih luas daripada rentang IP lokal (subnet mask yang lebih kecil)	VPN klasik tidak mendukung IPv6.	Cloud Router yang terkait dengan tunnel mengabaikan semua pemberitahuan rute yang tujuannya sesuai dengan `fd20:a:b::/48`, termasuk `fd20:a:b:c::/64`. Traffic yang ditujukan untuk `fd20:a:b::/48` tetap ada di jaringan VPC Anda.
`10.2.99.0/24` Lebih sempit daripada rentang IP lokal (subnet mask lebih panjang)	Google Cloud memungkinkan Anda membuat rute statis kustom dengan tujuan `10.2.0.0/16` dan tunnel Cloud VPN next hop; namun, traffic ke alamat IP di `10.2.99.0/24` tetap berada di dalam jaringan VPC Anda.	Cloud Router yang terkait dengan tunnel menerima pemberitahuan rute yang tujuannya adalah `10.2.0.0/16`; namun, traffic ke alamat IP di `10.2.99.0/24` tetap berada di dalam jaringan VPC Anda.
`fd20:a:b:c::/80` Lebih sempit daripada rentang IP lokal (subnet mask lebih panjang)	VPN klasik tidak mendukung IPv6.	Cloud Router yang terkait dengan tunnel menerima pemberitahuan rute yang tujuannya adalah `fd20:a:b:c::/64`; namun, traffic ke alamat IP di `fd20:a:b:c::/80` tetap berada di dalam jaringan VPC Anda.

Saat tunnel tidak aktif

Perutean dinamis (BGP)

Saat tunnel VPN Klasik yang menggunakan perutean dinamis atau tunnel VPN dengan ketersediaan tinggi (HA) mati, Cloud Router yang mengelolanya akan menghapus rute yang dipelajari secara otomatis. Durasi waktu yang diperlukan untuk mendeteksi kerusakan bervariasi. Bergantung pada apakah Deteksi Penerusan Dua Arah (BFD) diaktifkan. Jika BFD diaktifkan, deteksi akan terjadi saat timer penangguhan BGP berakhir. Jika tidak, deteksi akan terjadi dalam waktu kurang dari 60 detik. Rute yang dipelajari dapat ditambahkan kembali saat tunnel dibuat kembali.

Proses ini sepenuhnya otomatis, tetapi masih dapat mengakibatkan hilangnya beberapa paket pada saat Cloud Router membutuhkan waktu untuk menghapus rute yang terpengaruh.

Pemilihan rute statis

Google Cloud tidak pernah menganggap tunnel Cloud VPN sebagai next hop valid yang belum membentuk pengaitan keamanan IKE (SA). Jika tunnel Cloud VPN telah membuat IKE SA, Google Cloud akan menganggapnya operasional. Tunnel Cloud VPN operasional hanya meneruskan traffic jika dipilih sebagai next hop berdasarkan urutan perutean. Next hop untuk rute yang berbeda, dengan tujuan yang lebih spesifik atau dengan prioritas yang lebih tinggi, dapat digunakan sebagai gantinya.

Skenario berikut menunjukkan perilaku yang diharapkan:

Jika Anda memiliki beberapa rute statis kustom untuk tujuan yang sama, yang masing-masing memiliki tunnel Cloud VPN next hop yang berbeda, Google Cloud hanya mempertimbangkan tunnel yang telah menetapkan SA IKE (Fase 1). Tunnel yang tidak aktif—yaitu, yang tidak memiliki SA IKE yang valid—diabaikan sebelum mempertimbangkan prioritas rute.

Misalnya, Anda memiliki tiga rute statis kustom untuk tujuan 192.168.168.0/24: yang pertama dengan prioritas 10 yang tunnel Cloud VPN next hop-nya tidak aktif, yang kedua dengan prioritas 20 yang tunnel next hop-nya aktif, dan yang ketiga dengan prioritas 30 yang tunnel next hop-nya juga aktif. Google Cloud mengirimkan traffic ke next hop kedua, meskipun rutenya memiliki prioritas lebih rendah daripada rute yang next hop-nya tidak aktif. Jika tunnel pertama dibuat kembali, Google Cloud akan menganggapnya sebagai next hop yang valid dan yang menggunakan rute tersebut sebagai gantinya.
Traffic akan menurun jika semua tunnel Cloud VPN yang berfungsi sebagai next hop untuk rute statis kustom dengan tujuan yang sama tidak aktif. Traffic akan menurun meskipun ada rute statis kustom untuk tujuan yang lebih luas dengan tunnel next hop yang beroperasi.

Misalnya, Anda memiliki rute statis kustom untuk 192.168.168.0/24 yang tunnel Cloud VPN next hop-nya sedang mengalami masalah (tidak ada IKE SA yang valid). Meskipun Anda memiliki rute untuk 192.168.0.0/16 yang next hop-nya adalah tunnel Cloud VPN operasional, traffic ke 192.168.168.0/24 akan menurun. Hal ini karena Google Cloud selalu memilih rute dengan tujuan yang paling spesifik.

Saat traffic beralih dari satu tunnel Cloud VPN next hop ke tunnel yang lain, Anda tetap akan mengalami kehilangan paket. Paket yang sedang dikirimkan mungkin akan dibuang dan perlu dikirim ulang.

ECMP melalui tunnel

Pada perutean dinamis dan statis, jika ada lebih dari satu rute kustom untuk tujuan yang sama dan memiliki prioritas yang sama serta tunnel next hop yang aktif (IKE SA telah ditetapkan), Google Cloud akan menggunakan multipath dengan biaya perutean yang sama (ECMP) untuk mendistribusikan paket di antara tunnel.

Metode penyeimbangan ini didasarkan pada hash, sehingga semua paket dari alur yang sama akan menggunakan tunnel yang sama selama tunnel tersebut aktif.

Untuk menguji perilaku ECMP, gunakan iperf3 untuk mengirim beberapa streaming TCP simultan, biasanya dari beberapa instance mesin virtual (VM) Google Cloud, melalui tunnel Cloud VPN. Jika Anda perlu memvalidasi perilaku ECMP, jangan gunakan ICMP (ping) untuk melakukan pengujian. Pengujian ping dari satu instance VM tidak cukup untuk menguji traffic keluar berbasis ECMP melalui tunnel Cloud VPN karena hanya terdapat satu tunnel yang dipilih saat Anda memiliki sumber dan tujuan tetap. ICMP merupakan protokol tetap dan tidak memiliki konsep port sehingga hash hanya dihitung dari dua informasi: alamat sumber dan tujuan (hash dua tuple).

Langkah selanjutnya

Untuk mempelajari konsep dasar Cloud VPN, lihat ringkasan Cloud VPN.
Untuk membantu memecahkan masalah umum yang mungkin Anda temui saat menggunakan Cloud VPN, lihat Pemecahan masalah.