Halaman ini menunjukkan contoh konfigurasi resource Google Cloud yang tidak valid atau tidak konsisten yang mungkin Anda temui saat memecahkan masalah jaringan dengan Uji Konektivitas.
Untuk mengetahui petunjuk tentang cara menjalankan pengujian, lihat Membuat dan menjalankan Uji Konektivitas.
Untuk deskripsi pengujian ke dan dari jenis sumber dan tujuan jaringan umum, lihat Kasus penggunaan umum.
Mendeteksi konfigurasi yang tidak valid
Ada banyak jenis konfigurasi yang tidak valid; yaitu, konfigurasi yang salah atau telah diperbarui dan tidak lagi valid.
Salah satu contohnya adalah instance virtual machine (VM) yang telah dikonfigurasi sebagai gateway NAT, tetapi telah dihapus atau dimigrasikan. Dalam hal ini, rute ke instance VM masih ada.
Pada diagram berikut, VM1 di Network 1 harus dapat mengakses data di
VM2, VM3, dan VM4 di Network 2 melalui instance VM bernama nat_vm_1.
Namun, nat_vm_1 tidak ada lagi karena telah dimigrasikan ke VM baru,
nat_vm_2.
Rute yang dikonfigurasi dari VM1 ke tiga instance VM lainnya masih mengarah ke nat_vm_1 sebagai next hop. Namun, karena nat_vm_1 tidak ada lagi
dan tidak ada rute ke nat_vm_2, VM1 tidak dapat berkomunikasi dengan
instance VM lainnya.
Uji Konektivitas yang dijalankan dariVM1 ke VM2 mengungkapkan bahwa
traffic antara VM1 dan instance VM lainnya telah dihentikan karena
next hop yang tidak valid untuk rute ke VM lainnya.
Sebaliknya, dalam kasus penggunaan untuk
konfigurasi yang tidak konsisten,
VM3 tidak memiliki tag jaringan, sehingga konfigurasi load balancer
tidak konsisten
di seluruh backend load balancer. Namun, konfigurasi untuk VM3 itu sendiri
valid karena mengonfigurasi instance VM tidak memerlukan tag.
Mendeteksi konfigurasi yang tidak konsisten
Anda juga dapat menggunakan Uji Konektivitas untuk memvalidasi konfigurasi yang tidak konsisten secara rutin. Konfigurasi ini mungkin tidak menyebabkan masalah koneksi saat ini, tetapi mungkin secara tidak sengaja mengurangi redundansi jaringan atau menyebabkan masalah performa di masa mendatang.
Load balancer dikonfigurasi untuk mengirim traffic ke alamat IP eksternal
35.184.176.28. Traffic ke alamat tersebut didistribusikan di tiga
backend: VM1, VM2, dan VM3. Namun, karena tag jaringan tidak ada
di
VM3, aturan firewall Virtual Private Cloud (VPC) mengizinkan traffic dari
rentang IP eksternal ke VM1 dan VM2, tetapi menolak traffic tersebut ke VM3.
Pelacakan berikut dari rentang sumber yang diizinkan yang dikonfigurasi untuk load
balancer ke alamat IP eksternal tujuan load balancer menunjukkan
konfigurasi yang diinginkan dan inkonsistensi. VM1 dan VM2 dapat dijangkau,
tetapi
VM3 tidak dapat dijangkau. Hanya dua backend yang dapat dijangkau karena VM3 telah gagal dalam health check.
