Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Google Cloud-Load-Balancer erfordern in der Regel eine oder mehrere Firewallregeln, um sicherzustellen, dass der Traffic von Clients die Back-Ends erreicht.
Die meisten Load-Balancer sind erforderlich, um eine Systemdiagnose für Backend-Instanzen festzulegen. Damit die Systemdiagnoseprüfungen Ihre Back-Ends erreichen können, müssen Sie eine entsprechende Firewallregel zum Zulassen von eingehendem Traffic erstellen.
Load-Balancer, die auf Google Front Ends (GFEs) basieren, erfordern eine Firewallregel zum Zulassen von eingehendem Traffic, die Traffic vom GFE-Proxy zu den Backend-Instanzen zulässt. In den meisten Fällen verwenden GFE-Proxys dieselben Quell-IP-Bereiche wie die Systemdiagnoseprüfungen und erfordern daher keine separate Firewallregel.
Ausnahmen sind in der folgenden Tabelle aufgeführt.
Load-Balancer, die auf dem Open-Source-Envoy-Proxy basieren, erfordern eine Firewallregel zum Zulassen von eingehendem Traffic, die Traffic vom Nur-Proxy-Subnetz zu den Backend-Instanzen zulässt. Diese Load-Balancer beenden eingehende Verbindungen und der Traffic vom Load-Balancer zu den Back-Ends wird dann über IP-Adressen im Nur-Proxy-Subnetz gesendet.
In der folgenden Tabelle sind die mindestens erforderlichen Firewallregeln für jeden Load-Balancer-Typ zusammengefasst.
Load-Balancer-Typ
Mindestens erforderliche Firewallregeln zum Zulassen von eingehendem Traffic
Übersicht
Beispiel
Globaler externer Application Load Balancer
Bereiche der Systemdiagnose:
35.191.0.0/16
130.211.0.0/22
Bei IPv6-Traffic zu den Back-Ends:
2600:2d00:1:b029::/64
2600:2d00:1:1::/64
GFE-Proxybereiche:
Entspricht identischen Systemdiagnosebereichen, wenn die Back-Ends Instanzgruppen, zonale NEGs (GCE_VM_IP_PORT) oder Hybridkonnektivitäts-NEGs (NON_GCP_PRIVATE_IP_PORT) sind
IP-Adressbereiche, die im DNS-TXT-Eintrag _cloud-eoips.googleusercontent.com aufgeführt sind. Sie können die Quell-IP-Adressen für globale Internet-NEG-Back-Ends mit dem folgenden Beispielbefehl auf einem Linux-System extrahieren: dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
Entspricht identischen Systemdiagnosebereichen, wenn die Back-Ends Instanzgruppen, zonale NEGs (GCE_VM_IP_PORT) oder Hybridkonnektivitäts-NEGs (NON_GCP_PRIVATE_IP_PORT) sind
IP-Adressbereiche, die im DNS-TXT-Eintrag _cloud-eoips.googleusercontent.com aufgeführt sind. Sie können die Quell-IP-Adressen für globale Internet-NEG-Back-Ends mit dem folgenden Beispielbefehl auf einem Linux-System extrahieren: dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
Externe Quell-IP-Adressen von Clients im Internet
Beispiel: 0.0.0.0/0 (alle IPv4-Clients) oder ::/0 (alle IPv6-Clients) oder eine bestimmte Gruppe von IP-Adressbereichen.
Zielpoolbasierte Load-Balancer können Systemdiagnosen über den Metadatenserver weiterleiten. In diesem Fall stimmen die Quellen des Systemdiagnoseprügungen mit der IP-Adresse des Metadatenservers überein: 169.254.169.254. Der Traffic vom Metadatenserver darf VMs jedoch immer erreichen. Es ist keine Firewallregel erforderlich.
1
Die Prüfbereiche der Systemdiagnose von Google müssen bei Hybrid-NEGs nicht auf die Zulassungsliste gesetzt werden. Wenn Sie jedoch eine Kombination aus hybriden und zonalen NEGs in einem einzelnen Backend-Dienst verwenden, müssen Sie die Prüfbereiche der Systemdiagnose von Google für die zonalen NEGs auf die Zulassungsliste setzen.
2
Bei regionalen Internet-NEGs sind Systemdiagnosen optional. Der Traffic von Load-Balancern mit regionalen Internet-NEGs stammt aus dem Nur-Proxy-Subnetz und wird dann (mithilfe von Cloud NAT) in die manuelle oder automatisch zugewiesene NAT-IP-Adressen NAT-übersetzt. Dieser Traffic umfasst sowohl Systemdiagnoseprüfungen als auch Nutzeranfragen vom Load Balancer an die Back-Ends. Weitere Informationen finden Sie unter Regionale NEGs: Cloud NAT für ausgehenden Traffic verwenden.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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)."]]
