Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Les équilibreurs de charge Google Cloud nécessitent généralement une ou plusieurs règles de pare-feu pour garantir que le trafic des clients atteint les backends.
La plupart des équilibreurs de charge sont nécessaires pour spécifier une vérification d'état pour les instances backend. Pour que les vérifications d'état puissent atteindre vos backends, vous devez créer une règle de pare-feu autorisant le trafic entrant qui permet aux vérifications d'état d'atteindre vos instances backend.
Les équilibreurs de charge basés sur Google Front End (GFE) nécessitent une règle de pare-feu autorisant le trafic entrant et permettant au trafic provenant du proxy GFE d'accéder aux instances backend. Dans la plupart des cas, les proxys GFE utilisent les mêmes plages d'adresses IP sources que les vérifications d'état et ne nécessitent donc pas de règle de pare-feu distincte.
Les exceptions sont indiquées dans le tableau suivant.
Les équilibreurs de charge basés sur le proxy Envoy Open Source requièrent une règle de pare-feu autorisant les entrées qui autorise le trafic provenant du sous-réseau proxy réservé à accéder aux instances backend. Ces équilibreurs de charge interrompent les connexions entrantes, et le trafic de l'équilibreur de charge vers les backends est ensuite envoyé depuis les adresses IP du sous-réseau proxy réservé.
Le tableau suivant récapitule les règles de pare-feu minimales requises pour chaque type d'équilibreur de charge.
Type d'équilibreur de charge
Règles de pare-feu autorisant les entrées minimales requises
Aperçu
Exemple
Équilibreur de charge d'application externe global
Plages de vérification d'état :
35.191.0.0/16
130.211.0.0/22
Pour le trafic IPv6 vers les backends :
2600:2d00:1:b029::/64
2600:2d00:1:1::/64
Plages de proxy GFE :
Identiques aux plages de vérifications d'état si les backends sont des groupes d'instances, des NEG zonaux (GCE_VM_IP_PORT) ou des NEG de connectivité hybride (NON_GCP_PRIVATE_IP_PORT).
Plages d'adresses IP répertoriées dans l'enregistrement TXT DNS _cloud-eoips.googleusercontent.com. Vous pouvez extraire les adresses IP sources des backends NEG Internet à l'aide de l'exemple de commande suivant sur un système Linux : dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
Identiques aux plages de vérifications d'état si les backends sont des groupes d'instances, des NEG zonaux (GCE_VM_IP_PORT) ou des NEG de connectivité hybride (NON_GCP_PRIVATE_IP_PORT).
Plages d'adresses IP répertoriées dans l'enregistrement TXT DNS _cloud-eoips.googleusercontent.com. Vous pouvez extraire les adresses IP sources des backends NEG Internet à l'aide de l'exemple de commande suivant sur un système Linux : dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
Adresses IP sources externes des clients sur Internet.
Par exemple, 0.0.0.0/0 (tous les clients IPv4) ou ::/0 (tous les clients IPv6) ou un ensemble spécifique de plages d'adresses IP.
Les équilibreurs de charge basés sur un pool cible peuvent relayer les vérifications d'état via le serveur de métadonnées. Dans ce cas, les sources des requêtes de vérification d'état correspondent à l'adresse IP du serveur de métadonnées : 169.254.169.254. Toutefois, le trafic en provenance du serveur de métadonnées est toujours autorisé à atteindre les VM. Aucune règle de pare-feu n'est requise.
1
L'ajout de plages de vérification de l'état à la liste d'autorisation de Google n'est pas nécessaire pour les NEG hybrides. Toutefois, si vous utilisez à la fois des NEG hybrides et zonaux dans un service de backend, vous devez ajouter les plages de vérification d'état Google à la liste d'autorisation pour les NEG zonaux.
2
Pour les NEG Internet régionaux, les vérifications d'état sont facultatives. Le trafic provenant des équilibreurs de charge qui utilisent des NEG Internet régionaux provient du sous-réseau proxy réservé, puis est traduit par la NAT (à l'aide de Cloud NAT) en adresses IP NAT allouées manuellement ou automatiquement. Ce trafic inclut à la fois les vérifications d'état et les requêtes des utilisateurs depuis l'équilibreur de charge vers les backends. Pour en savoir plus, consultez la page NEG régionaux : utiliser Cloud NAT pour la sortie.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2024/12/22 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2024/12/22 (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)."]]
