Firewallregeln

Google Cloud Für Load Balancer sind in der Regel eine oder mehrere Firewallregeln erforderlich, damit 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 Systemdiagnose-Prü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
 Übersicht 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
 Übersicht 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
 Übersicht 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
 Übersicht 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
 Übersicht Beispiel
Globaler externer Proxy-Network 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: Wie Systemdiagnosebereiche
 Übersicht Beispiel
Klassischer Proxy-Network Load Balancer
  • Bereiche der Systemdiagnose:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • GFE-Proxybereiche: Wie Systemdiagnosebereiche
 Übersicht 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
 Übersicht 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
 Übersicht 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
 Übersicht 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. Traffic vom Metadatenserver darf jedoch immer VMs 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
 Übersicht Single-Stack Dual-Stack

1 Bei Hybrid-NEGs ist es nicht erforderlich, Traffic aus den Prüfbereichen der Systemdiagnose von Google zuzulassen. Wenn Sie jedoch eine Kombination aus hybriden und zonalen NEGs in einem einzelnen Backend-Dienst verwenden, müssen Sie den Traffic aus den Prüfbereichen der Systemdiagnose von Google für die zonalen NEGs zulassen.

2 Bei regionalen Internet-NEGs sind Systemdiagnosen optional. Der Traffic von Load Balancern, die regionale Internet-NEGs verwenden, stammt aus dem Nur-Proxy-Subnetz und wird dann (mithilfe von Cloud NAT) entweder auf manuell oder automatisch zugewiesene NAT-IP-Adressen ü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-Gateway verwenden.