Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
I bilanciatori del caricoGoogle Cloud in genere richiedono una o più regole firewall per garantire che il traffico dai client raggiunga i backend.
La maggior parte dei bilanciatori del carico è tenuta a specificare un controllo di integrità per le istanze di backend. Affinché i probe del controllo di integrità raggiungano i backend, devi creare
una regola firewall di autorizzazione in entrata che consenta ai probe del controllo di integrità di raggiungere le istanze di backend.
I bilanciatori del carico basati su Google Front End (GFE) richiedono una regola firewall di autorizzazione in entrata che consenta al traffico dal proxy GFE di raggiungere le istanze di backend. Nella maggior parte dei casi, i proxy GFE utilizzano gli stessi intervalli IP di origine dei probe di controllo dell'integrità e, pertanto, non richiedono una regola firewall separata.
Le eccezioni sono indicate nella tabella seguente.
I bilanciatori del carico basati sul proxy Envoy open source richiedono una regola firewall di autorizzazione in entrata che consenta al traffico dalla subnet solo proxy di raggiungere le istanze di backend. Questi bilanciatori del carico terminano le connessioni in entrata e il traffico dal bilanciatore del carico ai backend viene inviato dagli indirizzi IP nella subnet solo proxy.
La tabella seguente riassume le regole del firewall minime richieste per ogni
tipo di bilanciatore del carico.
Tipo di bilanciatore del carico
Regole firewall di autorizzazione in entrata minime richieste
Panoramica
Esempio
Bilanciatore del carico delle applicazioni esterno globale
Intervalli del controllo di integrità:
35.191.0.0/16
130.211.0.0/22
Per il traffico IPv6 verso i backend:
2600:2d00:1:b029::/64
2600:2d00:1:1::/64
Intervalli proxy GFE:
Gli stessi intervalli di controllo dell'integrità se i backend sono gruppi di istanze, NEG a livello di zona (GCE_VM_IP_PORT) o NEG con connettività ibrida (NON_GCP_PRIVATE_IP_PORT)
Intervalli di indirizzi IP elencati nel _cloud-eoips.googleusercontent.com
record TXT DNS. Puoi estrarre gli indirizzi IP di origine per i backend NEG internet globali utilizzando il seguente comando di esempio su un sistema Linux:
dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
Bilanciatore del carico delle applicazioni classico
Intervalli del controllo di integrità:
35.191.0.0/16
130.211.0.0/22
Intervalli proxy GFE:
Gli stessi intervalli di controllo dell'integrità se i backend sono gruppi di istanze, NEG a livello di zona (GCE_VM_IP_PORT) o NEG con connettività ibrida (NON_GCP_PRIVATE_IP_PORT)
Intervalli di indirizzi IP elencati nel _cloud-eoips.googleusercontent.com
record TXT DNS. Puoi estrarre gli indirizzi IP di origine per i backend NEG internet globali utilizzando il seguente comando di esempio su un sistema Linux:
dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
Bilanciatore del carico di rete passthrough esterno
Intervalli di controllo di integrità
Per il traffico IPv4 verso i backend:
35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
Per il traffico IPv6 verso i backend:
2600:1901:8001::/48
Indirizzi IP di origine esterni dei client su internet.
Ad esempio, 0.0.0.0/0 (tutti i client IPv4) o
::/0 (tutti i client IPv6) o un
insieme specifico di intervalli di indirizzi IP.
I bilanciatori del carico basati su pool di destinazione potrebbero eseguire il proxy dei controlli di integrità tramite il server dei metadati. In questo caso, le origini dei probe del controllo di integrità
corrispondono all'indirizzo IP del server di metadati:
169.254.169.254. Tuttavia, il traffico dal
server dei metadati è sempre consentito per raggiungere le VM. Non è obbligatoria alcuna regola firewall.
1
Per i NEG ibridi non è necessario consentire il traffico proveniente dagli intervalli di controllo di integrità di Google. Tuttavia, se utilizzi una combinazione di NEG ibridi e zonali in un singolo servizio di backend, devi consentire il traffico dagli intervalli di sonde di controllo di integrità di Google per i NEG zonali.
2
Per i NEG internet a livello di regione, i controlli di integrità sono facoltativi. Il traffico proveniente dai bilanciatori del carico che utilizzano NEG internet a livello di regione ha origine dalla subnet solo proxy e viene poi sottoposto a traduzione NAT (utilizzando Cloud NAT) in indirizzi IP NAT allocati manualmente o automaticamente. Questo traffico include sia i probe del controllo di integrità sia le richieste degli utenti dal bilanciatore del carico ai backend. Per informazioni dettagliate, consulta NEG regionali:
utilizzare un gateway Cloud NAT.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 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)."]]
