Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Load balancerGoogle Cloud biasanya memerlukan satu atau beberapa aturan firewall untuk memastikan traffic dari klien mencapai backend.
Sebagian besar load balancer diwajibkan untuk menentukan health check untuk instance
backend. Agar pemeriksaan health check dapat menjangkau backend, Anda harus membuat aturan firewall izinkan masuk yang memungkinkan pemeriksaan health check menjangkau instance backend.
Load balancer berdasarkan Google Front End (GFE) memerlukan aturan firewall izinkan masuk yang mengizinkan traffic dari proxy GFE untuk menjangkau instance backend. Pada umumnya, proxy GFE menggunakan rentang IP sumber yang sama dengan
probe pemeriksaan kesehatan sehingga tidak memerlukan aturan firewall terpisah.
Pengecualian dicatat dalam tabel berikut.
Load balancer berdasarkan proxy Envoy open source memerlukan aturan firewall izinkan masuk yang mengizinkan traffic dari subnet khusus proxy untuk menjangkau instance backend. Load balancer ini menghentikan koneksi masuk dan traffic dari load balancer ke backend kemudian dikirim dari alamat IP di subnet khusus proxy.
Tabel berikut merangkum aturan firewall minimum yang diperlukan untuk setiap
jenis load balancer.
Jenis load balancer
Aturan firewall izinkan masuk minimum yang diperlukan
Ringkasan
Contoh
Load Balancer Aplikasi eksternal global
Rentang health check:
35.191.0.0/16
130.211.0.0/22
Untuk traffic IPv6 ke backend:
2600:2d00:1:b029::/64
2600:2d00:1:1::/64
Rentang proxy GFE:
Sama dengan rentang pemeriksaan kesehatan jika backend adalah grup instance, NEG zona, atau NEG konektivitas hybridGCE_VM_IP_PORTNON_GCP_PRIVATE_IP_PORT
Rentang alamat IP yang tercantum dalam data TXT DNS _cloud-eoips.googleusercontent.com. Anda dapat mengekstrak alamat IP sumber untuk backend NEG internet global menggunakan contoh perintah berikut di sistem Linux:
dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
Sama dengan rentang pemeriksaan kesehatan jika backend adalah grup instance, NEG zona, atau NEG konektivitas hybridGCE_VM_IP_PORTNON_GCP_PRIVATE_IP_PORT
Rentang alamat IP yang tercantum dalam data TXT DNS _cloud-eoips.googleusercontent.com. Anda dapat mengekstrak alamat IP sumber untuk backend NEG internet global menggunakan contoh perintah berikut di sistem Linux:
dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
Alamat IP sumber eksternal klien di internet.
Misalnya, 0.0.0.0/0 (semua klien IPv4) atau
::/0 (semua klien IPv6) atau
kumpulan rentang alamat IP tertentu.
Load balancer berbasis kumpulan target dapat melakukan proxy health check
melalui server metadata. Dalam hal ini, sumber pemeriksaan health check cocok dengan alamat IP server metadata: 169.254.169.254. Namun, traffic dari server metadata selalu diizinkan untuk menjangkau VM. Tidak diperlukan aturan
firewall.
1
Mengizinkan traffic dari rentang probe health check Google tidak diperlukan untuk NEG
hibrida. Namun, jika Anda menggunakan kombinasi NEG hybrid dan zonal dalam satu layanan backend, Anda harus mengizinkan traffic dari rentang probe health check Google untuk NEG zona.
2
Untuk NEG internet regional, health check bersifat opsional. Traffic dari load
balancer yang menggunakan NEG internet regional berasal dari subnet khusus proxy, lalu
diterjemahkan NAT (dengan menggunakan Cloud NAT) ke alamat IP NAT yang dialokasikan secara manual atau otomatis. Traffic ini mencakup pemeriksaan health check dan permintaan pengguna dari load balancer ke backend. Untuk mengetahui detailnya, lihat NEG Regional:
Menggunakan gateway Cloud NAT.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-11 UTC."],[],[],null,["# Firewall rules\n\nGoogle Cloud load balancers typically require one or more firewall rules\nto ensure that traffic from clients reaches the backends.\n\n- Most load balancers are required to specify a health check for backend\n instances. For the health check probes to reach your backends, you must create\n an ingress allow [firewall rule](/firewall/docs/using-firewalls) that allows\n health check probes to reach your backend instances.\n\n- Load balancers based on Google Front Ends (GFEs) require an ingress allow\n firewall rule that permits traffic from the GFE proxy to reach the backend\n instances. In most cases, GFE proxies use the same source IP ranges as the\n health check probes and therefore don't require a separate firewall rule.\n Exceptions are noted in the following table.\n\n- Load balancers based on the open source Envoy proxy require an ingress allow\n firewall rule that permits traffic from the *proxy-only subnet* to reach the\n backend instances. These load balancers terminate incoming connections and\n traffic from the load balancer to the backends is then sent from IP addresses\n in the proxy-only subnet.\n\nThe following table summarizes the minimum required firewall rules for each\ntype of load balancer.\n\n^1^\nAllowing traffic from Google's health check probe ranges isn't required for hybrid\nNEGs. However, if you're using a combination of hybrid and zonal NEGs in\na single backend service, you need to allow traffic from the [Google\nhealth check probe ranges](/load-balancing/docs/health-check-concepts#ip-ranges) for the zonal NEGs.\n\n^2^\nFor regional internet NEGs, health checks are optional. Traffic from load\nbalancers using *regional* internet NEGs originates from the [proxy-only subnet](/load-balancing/docs/proxy-only-subnets) and is then\nNAT-translated (by using Cloud NAT) to either manually or automatically allocated\nNAT IP addresses. This traffic includes both health check probes and user\nrequests from the load balancer to the backends. For details, see [Regional NEGs:\nUse a Cloud NAT gateway](/load-balancing/docs/negs/internet-neg-concepts#nat-support)."]]