Netzwerkkontexte

Netzwerkkontexte helfen Ihnen, Ihre Sicherheitsziele mit weniger Firewallrichtlinienregeln effizienter zu erreichen. Cloud NGFW unterstützt vier Netzwerkkontexte, die verwendet werden können, um eine Quell- oder Zielkombination in einer Regel einer hierarchischen Firewallrichtlinie, einer globalen Netzwerk-Firewallrichtlinie oder einer regionalen Netzwerk-Firewallrichtlinie zu erstellen.

In der folgenden Tabelle sehen Sie, wie die vier Netzwerkkontexte in Firewallregeln verwendet werden können.

Netzwerkkontexte Unterstützter Zieltyp Unterstützte Richtung, Quellkombination oder Zielkombination
INSTANCES INTERNAL_MANAGED_LB Quellkombination einer Regel für eingehenden Traffic Zielkombination einer Regel für ausgehenden Traffic
Internet (INTERNET)
Kein Internet (NON_INTERNET)
VPC-Netzwerke (VPC_NETWORKS)
VPC-intern (INTRA_VPC)

Die Netzwerkkontexte „Internet“ und „Ohne Internet“ schließen sich gegenseitig aus. Die VPC-Netzwerke und die VPC-internen Netzwerkkontexte sind Teilmengen des Netzwerkkontexts „Ohne Internet“.

Internetnetzwerkkontext

Der Netzwerkkontext internet (INTERNET) kann als Teil einer Quellkombination einer Ingress-Regel oder als Teil einer Zielkombination einer Egress-Regel verwendet werden:

  • Geben Sie für eine Regel für eingehenden Traffic die Quelle des Internetkontexts und mindestens einen anderen Quellparameter an, mit Ausnahme einer sicheren Tag-Quelle. Pakete entsprechen der Regel für eingehenden Traffic, wenn sie mindestens einem der anderen Quellparameter und Kriterien für den Internetnetzwerkkontext für eingehende Pakete entsprechen.

  • Geben Sie für eine Ausgangsregel das Ziel des Internetkontexts und mindestens einen weiteren Zielparameter an. Pakete entsprechen der Regel für ausgehenden Traffic, wenn sie mindestens einem der anderen Zielparameter und Kriterien für den Internetnetzwerkkontext für ausgehende Pakete entsprechen.

Kriterien für den Internetnetzwerkkontext

In diesem Abschnitt werden die Kriterien beschrieben, anhand derer Cloud Next Generation Firewall bestimmt, ob ein Paket zum Internet-Netzwerkkontext gehört.

Internetnetzwerkkontext für eingehende Pakete

Eingehende Pakete, die von einem Google Maglev an eine VM-Netzwerkschnittstelle weitergeleitet werden, gehören zum Internet-Netzwerkkontext. Pakete werden von einem Maglev an eine VM-Netzwerkschnittstelle weitergeleitet, wenn das Paketziel mit einem der folgenden Elemente übereinstimmt:

  • Eine regionale externe IPv4-Adresse einer VM-Netzwerkschnittstelle, einer Weiterleitungsregel eines externen Passthrough-Network Load Balancers oder einer Weiterleitungsregel für die externe Protokollweiterleitung.
  • Eine regionale externe IPv6-Adresse einer VM-Netzwerkschnittstelle, einer Weiterleitungsregel eines externen Passthrough-Network Load Balancers oder einer Weiterleitungsregel für die externe Protokollweiterleitung und das Paket nicht über eine lokale Subnetzroute oder eine Subnetzroute weitergeleitet wurde, die über VPC Network Peering oder von einem VPC-Spoke in einem NCC-Hub importiert wurde.

Weitere Informationen zu Paketen, die von Maglev an Backend-VMs für einen externen Passthrough-Network Load Balancer oder die externe Protokollweiterleitung weitergeleitet werden, finden Sie unter Pfade für externe Passthrough-Network Load Balancer und die externe Protokollweiterleitung.

Internetnetzwerkkontext für ausgehende Pakete

Die meisten Pakete für ausgehenden Traffic, die von VM-Netzwerkschnittstellen gesendet und über eine statische Route weitergeleitet werden, deren nächster Hop das Standard-Internetgateway ist, gehören zum Internet-Netzwerkkontext. Wenn die Ziel-IP-Adressen dieser ausgehenden Pakete jedoch für globale Google APIs und ‑Dienste bestimmt sind, gehören diese Pakete zum Netzwerkkontext ohne Internet. Weitere Informationen zur Verbindung mit globalen Google APIs und ‑Diensten finden Sie unter Netzwerkkontext ohne Internetverbindung.

Wenn die Pakete über eine statische Route weitergeleitet werden, deren nächster Hop das Standard-Internetgateway ist, gehören alle Pakete, die von den VM-Netzwerkschnittstellen an die folgenden Ziele gesendet werden, zum Internet-Netzwerkkontext:

  • Ein externes IP-Adressziel außerhalb des Google-Netzwerks.
  • Eine regionale externe IPv4-Zieladresse einer VM-Netzwerkschnittstelle, einer Weiterleitungsregel eines regionalen externen Load Balancers oder einer Weiterleitungsregel für die externe Protokollweiterleitung.
  • Eine regionale externe IPv6-Zieladresse einer VM-Netzwerkschnittstelle, einer Weiterleitungsregel eines regionalen externen Load Balancers oder einer Weiterleitungsregel für die externe Protokollweiterleitung.
  • Ein globales externes IPv4- und IPv6-Adressziel einer Weiterleitungsregel eines globalen externen Load-Balancers.

Pakete, die von den VM-Netzwerkschnittstellen an Cloud VPN- und Cloud NAT-Gateways gesendet werden, gehören zum Internet-Netzwerkkontext:

  • Pakete für ausgehenden Traffic, die von einer Netzwerkschnittstelle einer VM mit Cloud VPN-Software an die regionale externe IPv4-Adresse eines Cloud VPN-Gateways gesendet werden, gehören zum Internet-Netzwerkkontext.
  • Ausgangspakete, die von einem Cloud VPN-Gateway an ein anderes Cloud VPN-Gateway gesendet werden, gehören zu keinem Netzwerkkontext, da Firewallregeln nicht für Cloud VPN-Gateways gelten.
  • Bei Public NAT gehören Antwortpakete, die von einer VM-Netzwerkschnittstelle an die regionale externe IPv4-Adresse eines Cloud NAT-Gateways gesendet werden, zum Internet-Netzwerkkontext.

Wenn VPC-Netzwerke über VPC-Netzwerk-Peering verbunden sind oder VPC-Netzwerke als VPC-Spokes am selben NCC-Hub teilnehmen, können IPv6-Subnetzrouten die Verbindung zu regionalen externen IPv6-Adressenzielen von VM-Netzwerkschnittstellen, regionalen externen Load-Balancer-Weiterleitungsregeln und externen Protokollweiterleitungsregeln ermöglichen. Wenn die Verbindung zu diesen regionalen externen IPv6-Adresszielen über eine Subnetzroute erfolgt, befinden sich die Ziele stattdessen im Netzwerkkontext ohne Internet.

Netzwerkkontext ohne Internetverbindung

Der Netzwerkkontext non-internet (NON-INTERNET) kann als Teil einer Quellkombination einer Ingress-Regel oder als Teil einer Zielkombination einer Egress-Regel verwendet werden:

Kriterien für den Netzwerkkontext „Ohne Internet“

In diesem Abschnitt werden die Kriterien beschrieben, anhand derer Cloud NGFW bestimmt, ob ein Paket zum Netzwerkkontext ohne Internet gehört.

Nicht internetbezogener Netzwerkkontext für eingehende Pakete

Pakete für eingehenden Traffic gehören zum Netzwerkkontext ohne Internetzugang, wenn die Pakete auf eine der folgenden Arten an die Netzwerkschnittstelle einer VM-Instanz oder an eine Weiterleitungsregel für einen internen Load Balancer weitergeleitet werden:

  • Die Pakete werden über eine Subnetzroute weitergeleitet und die Paketziele stimmen mit einem der folgenden überein:
    • Eine regionale interne IPv4- oder IPv6-Zieladresse einer VM-Netzwerkschnittstelle, einer Weiterleitungsregel eines internen Load Balancers oder einer Weiterleitungsregel für die interne Protokollweiterleitung.
    • Eine regionale externe IPv6-Zieladresse einer VM-Netzwerkschnittstelle, einer Weiterleitungsregel eines regionalen externen Load Balancers oder einer Weiterleitungsregel für die externe Protokollweiterleitung.
  • Die Pakete werden über eine statische Route an eine VM-Instanz oder einen internen Passthrough-Network-Load-Balancer als nächsten Hop weitergeleitet.
  • Die Pakete werden über eine richtlinienbasierte Route an einen internen Passthrough Network Load Balancer als nächsten Hop weitergeleitet.
  • Die Pakete werden über einen der folgenden speziellen Routingpfade weitergeleitet:

Eingehende Antwortpakete von globalen Google APIs und ‑Diensten gehören ebenfalls zum Netzwerkkontext ohne Internet. Antwortpakete von globalen Google APIs und ‑Diensten können aus den folgenden Quellen stammen:

Nicht-Internet-Netzwerkkontext für ausgehende Pakete

Ausgehende Pakete, die von VM-Netzwerkschnittstellen gesendet werden, gehören zum Netzwerkkontext ohne Internet, wenn die Pakete auf eine der folgenden Arten weitergeleitet werden:

VPC-Netzwerke – Kontext

Der Netzwerkkontext VPC-Netzwerke (VPC_NETWORKS) kann nur als Teil einer Quellkombination einer Regel für eingehenden Traffic verwendet werden. So verwenden Sie den Kontext von VPC-Netzwerken als Teil einer Quellkombination einer Ingress-Regel:

  1. Sie müssen eine Liste mit Quell-VPC-Netzwerken angeben:

    • Die Liste der Quellnetzwerke muss mindestens ein VPC-Netzwerk enthalten. Sie können der Quellnetzwerkliste maximal 250 VPC-Netzwerke hinzufügen.
    • Ein VPC-Netzwerk muss vorhanden sein, bevor Sie es der Liste der Quellnetzwerke hinzufügen können.
    • Sie können das Netzwerk entweder mit der teilweisen oder der vollständigen URL-Kennung hinzufügen.
    • VPC-Netzwerke, die Sie der Quellnetzwerkliste hinzufügen, müssen nicht miteinander verbunden sein. Jedes VPC-Netzwerk kann sich in einem beliebigen Projekt befinden.
    • Wenn ein VPC-Netzwerk gelöscht wird, nachdem es der Quellnetzwerkliste hinzugefügt wurde, bleibt der Verweis auf das gelöschte Netzwerk in der Liste. Cloud NGFW ignoriert gelöschte VPC-Netzwerke, wenn eine Ingress-Regel erzwungen wird. Wenn alle VPC-Netzwerke in der Quellnetzwerkliste gelöscht werden, sind die Ingress-Regeln, die auf der Liste basieren, wirkungslos, da sie mit keinen Paketen übereinstimmen.

  2. Sie müssen mindestens einen weiteren Quellparameter angeben, mit Ausnahme einer Google Threat Intelligence-Listenquelle oder einer Geolocation-Quelle.

Pakete entsprechen der Regel für eingehenden Traffic, wenn sie mindestens einem der anderen Quellparameter und den Kriterien für VPC-Netzwerke entsprechen.

Kriterien für den Kontext von VPC-Netzwerken

In diesem Abschnitt werden die Kriterien beschrieben, anhand derer Cloud NGFW ermittelt, ob ein Paket zum Kontext der VPC-Netzwerke gehört.

Ein Paket entspricht einer Ingress-Regel, die den Kontext von VPC-Netzwerken in ihrer Quellkombination verwendet, wenn alle der folgenden Bedingungen erfüllt sind:

  • Das Paket entspricht mindestens einem der anderen Quellparameter.

  • Das Paket wird von einer Ressource in einem der Quell-VPC-Netzwerke gesendet.

  • Das Quell-VPC-Netzwerk und das VPC-Netzwerk, für das die Firewallrichtlinie mit der Ingress-Regel gilt, sind dasselbe VPC-Netzwerk oder sind entweder über VPC-Netzwerk-Peering oder als VPC-Spokes in einem Network Connectivity Center-Hub verbunden.

Die folgenden Ressourcen befinden sich in einem VPC-Netzwerk:

  • VM-Netzwerkschnittstellen
  • Cloud VPN-Tunnel
  • Cloud Interconnect-VLAN-Anhänge
  • Router-Appliances
  • Envoy-Proxys in einem Nur-Proxy-Subnetz
  • Private Service Connect-Endpunkte
  • Connectors für serverlosen VPC-Zugriff

VPC-interner Netzwerkkontext

Der Netzwerkkontext intra-VPC networks (INTRA_VPC) kann nur als Teil einer Quellkombination einer Regel für eingehenden Traffic verwendet werden. Wenn Sie den Kontext für Intra-VPC-Netzwerke als Teil einer Quellkombination einer Regel für eingehenden Traffic verwenden möchten, müssen Sie mindestens einen weiteren Quellparameter angeben, mit Ausnahme einer Google Threat Intelligence-Liste oder einer geografischen Quelle.

Pakete entsprechen der Regel für eingehenden Traffic, wenn sie mindestens einem der anderen Quellparameter und Kriterien für den Kontext von Intra-VPC-Netzwerken entsprechen.

Kriterien für den Intra-VPC-Netzwerkkontext

In diesem Abschnitt werden die Kriterien beschrieben, anhand derer Cloud NGFW bestimmt, ob ein Paket zum Intra-VPC-Netzwerkkontext gehört.

Ein Paket entspricht einer Ingress-Regel, die den Intra-VPC-Kontext in ihrer Quellkombination verwendet, wenn alle folgenden Bedingungen erfüllt sind:

  • Das Paket entspricht mindestens einem der anderen Quellparameter.

  • Das Paket wird von einer Ressource im VPC-Netzwerk gesendet, auf das die Firewallrichtlinie mit der Regel für eingehenden Traffic angewendet wird.

Die folgenden Ressourcen befinden sich in einem VPC-Netzwerk:

  • VM-Netzwerkschnittstellen
  • Cloud VPN-Tunnel
  • Cloud Interconnect-VLAN-Anhänge
  • Router-Appliances
  • Envoy-Proxys in einem Nur-Proxy-Subnetz
  • Private Service Connect-Endpunkte
  • Connectors für serverlosen VPC-Zugriff