Firewallregeln

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 Überblick Beispiel
Globaler externer Application Load Balancer
  • Bereiche der Systemdiagnose:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • 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
 Überblick Beispiel
Klassischer Application Load Balancer
  • Bereiche der Systemdiagnose:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • 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
 Überblick Beispiel
Regionaler externer Application Load Balancer
  • Bereiche der Systemdiagnose 1, 2:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • Nur-Proxy-Subnetz: 2
 Überblick Beispiel
Regionsübergreifender interner Application Load Balancer
  • Bereiche der Systemdiagnose 1, 2:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • Nur-Proxy-Subnetz: 2
 Überblick Beispiel
Regionaler interner Application Load Balancer
  • Bereiche der Systemdiagnose 1, 2:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • Nur-Proxy-Subnetz: 2
 Überblick Beispiel
Globaler externer Proxy-Network Load Balancer
  • Bereiche der Systemdiagnose:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • GFE-Proxybereiche: Wie Systemdiagnosebereiche
 Überblick Beispiel
Klassischer Proxy-Network Load Balancer
  • Bereiche der Systemdiagnose:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • GFE-Proxybereiche: Wie Systemdiagnosebereiche
 Überblick Beispiel
Regionaler externer Proxy-Network Load Balancer
  • Bereiche der Systemdiagnose 1, 2:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • Nur-Proxy-Subnetz: 2
 Überblick Beispiel
Regionaler interner Proxy-Network Load Balancer
  • Bereiche der Systemdiagnose 1, 2:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • Nur-Proxy-Subnetz: 2
 Überblick Beispiel
Regionsübergreifender interner Proxy-Network Load Balancer
  • Bereiche der Systemdiagnose 1, 2:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • Nur-Proxy-Subnetz: 2
 Überblick Beispiel
Externer Passthrough-Network-Load-Balancer
  • Bereiche der Systemdiagnose

    Bei IPv4-Traffic zu den Back-Ends:

    • 35.191.0.0/16
    • 209.85.152.0/22
    • 209.85.204.0/22

    Bei IPv6-Traffic zu den Back-Ends:

    • 2600:1901:8001::/48

  • 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.

 Übersicht
 Beispiele
Interner Passthrough-Network Load Balancer
  • Bereiche der Systemdiagnose 1, 2:

    Bei IPv4-Traffic zu den Back-Ends:

    • 35.191.0.0/16
    • 130.211.0.0/22

    Bei IPv6-Traffic zu den Back-Ends:

    • 2600:2d00:1:b029::/64
  • Interne Quell-IP-Adressen von Clients
 Überblick Single-Stack Dual-Stack

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.