Cloud VPN ke VM GCP: gunakan IP internal, bukan IP NAT

Saat jaringan lokal mencapai VPC melalui Cloud VPN, tujuan untuk layanan Compute Engine biasanya adalah alamat internal VM. Alamat IPv4 eksternal bukan alamat kedua yang bisa Anda masukkan ke rute privat yang sama. Sebagian besar kebingungan di area ini berasal dari memperlakukan tiga alamat dengan tiga tugas sebagai hal yang bisa saling menggantikan, jadi mulailah dengan menyebut mana yang dipakai oleh paket tertentu.

Tiga alamat, tiga tugas

Sebutkan ketiganya sebelum melakukan debug pada salah satunya, karena jawabannya mengubah objek yang akan Anda periksa berikutnya.

Yang pertama milik terowongan. Yang kedua milik desain rute dan firewall Anda. Yang ketiga milik akses internet masuk dan dipetakan, bukan dilampirkan. Desain yang berfungsi untuk salah satunya tidak menjelaskan apa pun tentang dua lainnya.

Mengapa alamat eksternal bukan antarmuka kedua

Panduan pengalamatan adalah otoritas tentang bagaimana keterjangkauan internal dan eksternal berbeda di Compute Engine. IPv4 eksternal Compute Engine adalah pemetaan satu-ke-satu ke satu-satunya NIC internal instans, sehingga tamu tidak pernah melihat antarmuka kedua atau alamat kedua pada NIC tersebut. Yang dilaporkan VM dari dalam tetap satu alamat internal utama.

Itulah sebabnya klien privat yang merutekan melalui terowongan ke 10.24.1.7 dan klien yang menargetkan alamat eksternal VM berada di jalur berbeda. Membuka aturan firewall untuk alamat publik tidak mengubah apa pun pada rute VPC yang harus membawa lalu lintas terowongan, dan menyunting rute di tamu tidak menggeser pemetaan platform. Pilih alamat yang dinamai rute Anda, lalu periksa hanya objek yang mengaturnya. Disiplin itu menghilangkan sebagian besar dugaan dari jalur pemecahan masalah ini.

Telusuri jalur dengan gcloud

Mulailah dari instans dan baca kedua alamat dari objek yang sama, agar Anda tahu mana yang dibicarakan dokumentasi Anda:

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

Lalu pastikan perutean dan izin yang benar-benar menjadi sandaran jalur:

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

Baca rentang yang diumumkan dan dipelajari terowongan, rute VPC untuk subnet beban kerja, dan aturan firewall yang mengizinkan sumber lokal. Ketiganya harus sepakat sebelum pendengar di tamu menjadi relevan sama sekali.

Lalu periksa tamu: apakah layanan mendengarkan di alamat internal, dan apakah jalur kembalinya melewati VPC lagi? Pendengar yang hanya terikat ke alamat publik akan gagal dalam uji ini bahkan ketika setiap objek di sisi cloud sudah benar.

Prefiks publik adalah pertanyaan lain

Tidak satu pun di atas berarti setiap alamat yang dibawa di dalam VPN harus RFC1918. Jaringan jarak jauh dapat diberi nomor secara sah dari ruang publik, asalkan platform mendukung perutean dan operator memegang otoritas alamat. Itu pilihan desain yang normal.

Ini tidak sama dengan memperlakukan alamat NAT eksternal biasa seolah-olah itu alamat subnet internal lain. Yang satu adalah prefiks yang Anda rutekan; yang lain adalah pemetaan yang diterapkan platform pada akses masuk.

IPv6 eksternal dan penataan alamat yang dirancang khusus punya semantiknya sendiri. Jika rencana Anda bergantung pada salah satunya, baca dokumentasi platform untuk fitur itu alih-alih menggeneralisasi dari kasus IPv4. Pemetaan IPv4 adalah kasus umum, bukan satu-satunya, dan setiap pengecualian punya aturannya sendiri.

Rentang yang tumpang tindih adalah masalah lain

Rentang privat yang tumpang tindih adalah alasan nyata orang meraih alamat publik, dan itu tuas yang salah. Mengubah tujuan ke alamat NAT VM tidak menyelesaikan tumpang tindih; itu mengubah alamat tujuan yang diklaim paket, tanpa menentukan bagaimana jalur kembali bekerja.

Selesaikan tumpang tindih dengan sengaja: lakukan penomoran ulang, gunakan desain penerjemahan yang didukung, atau rutekan melalui jaringan tempat prefiks tidak bertabrakan. Masing-masing adalah desain dengan pemilik. Alamat NAT bukanlah desain.

Dokumentasikan kedua bidang secara terpisah

Catat peer terowongan dan tujuan beban kerja sebagai dua bidang runbook terpisah, masing-masing dengan rute dan aturan firewall yang mendukungnya. Terowongan IPsec yang naik hanya memberi tahu Anda bahwa kedua sisi sepakat; itu tidak menjelaskan pada alamat mana beban kerja dapat dijangkau, dan tidak juga apakah rute privatnya lengkap.

Verifikasi dengan klien sungguhan di sisi lain: selesaikan nama, pastikan ia mengembalikan alamat internal, sambungkan, dan periksa lalu lintas kembali. Dokumentasi alamat IP Compute Engine adalah rujukan untuk pembedaan internal versus eksternal yang digunakan di atas.