Sebagian atau seluruh informasi di halaman ini mungkin tidak berlaku untuk Cloud de Confiance dari S3NS. Lihat Perbedaan dengan Google Cloud untuk mengetahui detail selengkapnya.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Interaksi produk Cloud NAT

Halaman ini menjelaskan interaksi penting antara Cloud NAT dan produk Cloud de Confiance by S3NS lainnya.

Interaksi rute

Gateway Cloud NAT hanya dapat menggunakan rute yang next hop berikutnya adalah gateway internet default. Setiap jaringan Virtual Private Cloud (VPC) dimulai dengan rute default yang tujuannya adalah 0.0.0.0/0 dan hop berikutnya adalah gateway internet default. Untuk mengetahui informasi selengkapnya, lihat ringkasan rute.

Contoh berikut menggambarkan situasi yang dapat menyebabkan gateway Cloud NAT menjadi tidak dapat dioperasikan:

Jika Anda membuat rute statis dengan next hop yang ditetapkan ke jenis next hop rute statis lainnya, maka paket dengan alamat IP tujuan yang cocok dengan tujuan rute akan dikirim ke next hop tersebut, bukan ke gateway internet default. Misalnya, jika Anda menggunakan instance virtual machine (VM) yang menjalankan software gateway NAT, firewall, atau proxy, Anda membuat rute statis untuk mengarahkan traffic ke VM tersebut sebagai hop berikutnya. VM next-hop memerlukan alamat IP eksternal. Oleh karena itu, traffic dari VM yang mengandalkan VM next hop atau VM next hop itu sendiri tidak dapat menggunakan gateway Cloud NAT .
Jika Anda membuat rute statis kustom yang next hop-nya adalah tunnel Cloud VPN, Cloud NAT tidak menggunakan rute tersebut. Misalnya, rute statis dengan tujuan 0.0.0.0/0 dan tunnel Cloud VPN next hop mengarahkan traffic ke tunnel tersebut, bukan ke gateway internet default. Oleh karena itu, gateway Cloud NAT tidak dapat menggunakan rute tersebut. Demikian pula, gateway Cloud NAT tidak dapat menggunakan rute statis dengan tujuan yang lebih spesifik, termasuk 0.0.0.0/1 dan 128.0.0.0/1.
Jika router lokal mengiklankan rute dinamis ke Cloud Router yang mengelola tunnel Cloud VPN atau lampiran VLAN, gateway Cloud NAT tidak dapat menggunakan rute tersebut. Misalnya, jika router lokal Anda mengiklankan rute dinamis dengan tujuan 0.0.0.0/0, 0.0.0.0/0 akan diarahkan ke tunnel Cloud VPN atau lampiran VLAN. Perilaku ini tetap berlaku bahkan untuk tujuan yang lebih spesifik, termasuk 0.0.0.0/1 dan 128.0.0.0/1.

Interaksi Akses Google Pribadi

Gateway Cloud NAT tidak pernah melakukan NAT untuk traffic yang dikirim ke alamat IP eksternal untuk Google API dan layanan yang dipilih. Sebagai gantinya, gateway Cloud de Confiance akan otomatis mengaktifkan Akses Google Pribadi untuk rentang alamat IP subnet saat Anda mengonfigurasi Cloud NAT agar diterapkan ke rentang subnet tersebut, baik primer maupun sekunder. Selama gateway menyediakan NAT untuk rentang subnet, Akses Google Pribadi berlaku untuk rentang tersebut dan tidak dapat dinonaktifkan secara manual.

Gateway Cloud NAT tidak mengubah cara kerja Akses Google Pribadi. Untuk mengetahui informasi selengkapnya, lihat Akses Google Pribadi.

Interaksi VPC Bersama

VPC Bersama memungkinkan beberapa project layanan dalam satu organisasi menggunakan jaringan VPC Bersama yang umum dalam project host. Untuk menyediakan NAT bagi VM di project layanan yang menggunakan jaringan VPC Bersama, Anda harus membuat gateway Cloud NAT di project host.

Interaksi Peering Jaringan VPC

Gateway Cloud NAT dikaitkan dengan rentang alamat IP subnet dalam satu region dan satu jaringan VPC. Gateway Cloud NAT yang dibuat di satu jaringan VPC tidak dapat menyediakan NAT untuk VM di jaringan VPC lain yang terhubung dengan menggunakan Peering Jaringan VPC, meskipun VM di jaringan yang di-peering berada di region yang sama dengan gateway.

Interaksi GKE

Gateway Cloud NAT dapat melakukan NAT untuk node dan Pod di cluster pribadi, yang merupakan jenis cluster VPC native. Gateway Cloud NAT harus dikonfigurasi agar diterapkan ke setidaknya rentang alamat IP subnet berikut untuk subnet yang digunakan cluster Anda:

Rentang alamat IP primer subnet (digunakan oleh node)
Rentang alamat IP sekunder subnet yang digunakan untuk Pod di cluster
Rentang alamat IP sekunder subnet yang digunakan untuk Service di cluster

Cara termudah untuk menyediakan NAT bagi seluruh cluster pribadi adalah dengan mengonfigurasi gateway Cloud NAT agar diterapkan ke semua rentang alamat IP subnet dari subnet cluster.

Untuk mengetahui informasi latar belakang tentang cara cluster VPC native menggunakan rentang alamat IP subnet, lihat Rentang IP untuk cluster VPC native.

Jika gateway Cloud NAT dikonfigurasi untuk menyediakan NAT bagi cluster pribadi, gateway tersebut akan mencadangkan alamat IP sumber NAT dan port sumber untuk setiap VM node. Alamat IP sumber dan port sumber NAT tersebut dapat digunakan oleh Pod karena alamat IP Pod diterapkan sebagai rentang IP alias yang ditetapkan ke setiap VM node.

Cluster native VPC Google Kubernetes Engine (GKE) selalu menetapkan rentang IP alias yang berisi lebih dari satu alamat IP (masker jaringan lebih kecil dari /32) ke setiap node.

Jika alokasi port statis dikonfigurasi, prosedur reservasi port Public NAT akan mencadangkan minimal 1.024 port sumber per node. Jika nilai yang ditentukan untuk port minimum per VM lebih besar dari 1.024, nilai tersebut akan digunakan.
Jika alokasi port dinamis dikonfigurasi, nilai yang ditentukan untuk port minimum per VM awalnya dialokasikan per node. Jumlah port yang dialokasikan selanjutnya bervariasi antara nilai yang ditentukan untuk port minimum dan maksimum per VM, berdasarkan permintaan.

Untuk mengetahui informasi tentang rentang alamat IP Pod dan cluster VPC native, lihat Rentang alamat IP sekunder subnet untuk Pod.

Terlepas dari Cloud NAT , Google Kubernetes Engine melakukan penafsiran alamat jaringan sumber (NAT sumber atau SNAT) dengan menggunakan software yang berjalan di setiap node saat Pod mengirim paket ke internet, kecuali jika Anda telah mengubah konfigurasi penyamaran IP cluster. Jika Anda memerlukan kontrol terperinci atas traffic keluar dari Pod, Anda dapat menggunakan kebijakan jaringan.

Dalam keadaan tertentu, Cloud NAT juga dapat berguna untuk cluster native VPC non-pribadi. Karena node dalam cluster nonpribadi memiliki alamat IP eksternal, paket yang dikirim dari alamat IP internal utama node tidak pernah diproses oleh Cloud NAT. Namun, jika kedua hal berikut benar, paket yang dikirim dari Pod dalam cluster nonpribadi dapat diproses oleh gateway Cloud NAT :

Untuk cluster native VPC, gateway Cloud NAT dikonfigurasi untuk diterapkan ke rentang alamat IP sekunder untuk Pod cluster.
Konfigurasi penyamaran IP cluster tidak dikonfigurasi untuk melakukan SNAT dalam cluster untuk paket yang dikirim dari Pod ke internet.

Contoh berikut menunjukkan interaksi Cloud NAT dengan GKE:

Public NAT dengan GKE. — Cloud NAT dengan GKE (klik untuk memperbesar).

Dalam contoh ini, Anda ingin container Anda diterjemahkan NAT. Untuk mengaktifkan NAT bagi semua penampung dan node GKE, Anda harus memilih semua rentang alamat IP Subnet 1 sebagai kandidat NAT:

Rentang alamat IP primer subnet: 10.240.0.0/24
Rentang alamat IP sekunder subnet yang digunakan untuk Pod: 10.0.0.0/16

Anda tidak dapat mengaktifkan NAT hanya untuk Pod1 atau Pod2.

Interaksi traffic keluar VPC Langsung

Gateway Cloud NAT dapat menyediakan NAT untuk resource Cloud Run yang dikonfigurasi dengan traffic keluar VPC Langsung. Untuk mengizinkan Cloud Run menggunakan gateway Cloud NAT untuk Public NAT atau Private NAT, konfigurasikan hal berikut:

Saat Anda men-deploy resource Cloud Run, tetapkan flag --vpc-egress. Jika Anda ingin menggunakan NAT Publik, nilai harus ditetapkan ke all-traffic.
Konfigurasi gateway Cloud NAT dengan setelan berikut:
- Tentukan rentang subnet sumber yang dapat menggunakan gateway dengan menetapkan flag --nat-custom-subnet-ip-ranges. Tetapkan nilai ke nama subnet tempat Anda men-deploy resource Cloud Run.
- Tetapkan nilai flag --endpoint-types ke ENDPOINT_TYPE_VM.
- Untuk NAT Publik, pastikan nilai flag --min-ports-per-vm ditetapkan menjadi dua kali lipat jumlah port yang dibutuhkan oleh satu instance Cloud Run. Untuk Private NAT, flag ini harus ditetapkan ke empat kali jumlah port yang diperlukan per instance Cloud Run.
- Jika Anda ingin mengonfigurasi alokasi alamat IP NAT manual (Khusus Public NAT), tetapkan sejumlah alamat IP ke gateway Anda yang cukup untuk mencakup jumlah instance VM dan instance Cloud Run yang dilayani oleh gateway.

Log Cloud NAT untuk egress Direct VPC tidak menampilkan nama resource Cloud Run.

Interaksi Uji Konektivitas

Anda dapat menggunakan Uji Konektivitas untuk memeriksa konektivitas antara endpoint jaringan yang menggunakan konfigurasi Cloud NAT.

Anda dapat menjalankan Uji Konektivitas di jaringan yang menggunakan gateway Cloud NAT .

Lihat detail konfigurasi NAT di panel Trace analisis konfigurasi di halaman Detail uji konektivitas.

Interaksi Cloud Load Balancing

Cloud de Confiance Load Balancer Aplikasi internal regional dan Load Balancer Aplikasi eksternal regional berkomunikasi dengan beberapa backend grup endpoint jaringan (NEG) internet regional. Dengan mengonfigurasi gateway Cloud NAT untuk NEG internet regional, Anda dapat mengalokasikan rangkaian alamat IP eksternal Anda sendiri dari tempat traffic harus berasal. Cloud de Confiance Health check dan traffic bidang data berasal dari alamat IP NAT yang Anda alokasikan.

Load balancer eksternal dan sistem health check lainnya berkomunikasi dengan VM menggunakan jalur perutean khusus. Cloud de Confiance VM backend tidak memerlukan alamat IP eksternal dan gateway Cloud NAT tidak mengelola komunikasi untuk load balancer dan health check. Untuk mengetahui informasi selengkapnya, lihat Ringkasan Cloud Load Balancing dan Ringkasan health check.

Interaksi koneksi yang dipropagasi Private Service Connect

Saat menggunakan Private NAT for NCC dan koneksi yang dipropagasi Private Service Connect di spoke VPC yang sama, hal berikut berlaku:

Jika subnet dikonfigurasi dengan NAT Pribadi, traffic dari subnet ke koneksi yang di-propagate Private Service Connect akan dihentikan.
Untuk menghindari penurunan traffic dari subnet yang tidak tumpang-tindih, pertimbangkan hal berikut saat Anda mengonfigurasi Private NAT:
- Tentukan subnet yang tumpang-tindih menggunakan flag --nat-custom-subnet-ip-ranges.
- Jangan tentukan subnet yang tidak tumpang-tindih yang perlu mengakses koneksi yang di-propagate.
- Jangan gunakan flag --nat-all-subnet-ip-ranges.

Interaksi Hybrid Subnets

Hybrid NAT tidak didukung dengan Hybrid Subnets.

Jika traffic berasal dari subnet tempat Hybrid NAT dikonfigurasi dan alamat IP tujuan cocok dengan rute subnet hybrid, SNAT tidak dilakukan. Konfigurasi ini menghasilkan perilaku pemilihan rute yang tidak dapat diprediksi karena traffic dapat mencapai jaringan non-VPC menggunakan alamat IP sumber asli yang tidak diterjemahkan.

Jangan gunakan Subnet Hybrid di jaringan tempat Hybrid NAT dikonfigurasi.