Netzwerkkontexte

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

In der folgenden Tabelle wird gezeigt, 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)
Nicht-Internet (NON_INTERNET)
VPC-Netzwerke (VPC_NETWORKS)
VPC-intern (INTRA_VPC)

Die Netzwerkkontexte „Internet“ und „Nicht-Internet“ schließen sich gegenseitig aus. Die Netzwerkkontexte „Virtual Private Cloud-Netzwerke“ und „VPC-intern“ sind Teilmengen des Netzwerkkontexts „Nicht-Internet“.

Netzwerkkontext „Internet“

Der Netzwerkkontext Internet (INTERNET) kann als Teil einer Quellkombination einer Regel für eingehenden Traffic oder als Teil einer Zielkombination einer Regel für ausgehenden Traffic verwendet werden, wobei der Zieltyp entweder auf INSTANCES festgelegt oder nicht angegeben ist:

Kriterien für den Netzwerkkontext „Internet“

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

Netzwerkkontext „Internet“ für eingehende Pakete

Eingehende Pakete, die von einem Google Maglev an eine Netzwerkschnittstelle einer VM weitergeleitet werden, gehören zum Netzwerkkontext „Internet“. Pakete werden von einem Maglev an eine Netzwerkschnittstelle einer VM weitergeleitet, wenn das Ziel des Pakets mit einer der folgenden Optionen übereinstimmt:

  • Eine regionale externe IPv4-Adresse einer Netzwerkschnittstelle einer VM, eine Weiterleitungsregel eines regionalen externen Passthrough-Network Load Balancers oder eine Weiterleitungsregel für die externe Protokollweiterleitung.
  • Eine regionale externe IPv6-Adresse einer Netzwerkschnittstelle einer VM, eine Weiterleitungsregel eines regionalen externen Passthrough-Network Load Balancers oder eine Weiterleitungsregel für die externe Protokollweiterleitung und das Paket wurde nicht über eine lokale Subnetzroute oder eine Subnetzroute weitergeleitet, die über VPC-Netzwerk-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 externe Protokollweiterleitung.

Netzwerkkontext „Internet“ für ausgehende Pakete

Wenn eine statische Route mit dem Standard-Internetgateway als nächstem Hop ausgehende Pakete von einer Netzwerkschnittstelle einer VM weiterleitet, bestimmt die Ziel-IP-Adresse den Netzwerkkontext, wie in der folgenden Tabelle aufgeführt:

Ziel-IP-Adresse des ausgehenden Pakets Netzwerkkontexte
Externe IP-Adressen außerhalb des Google-Netzwerks Netzwerkkontext „Internet“
Externe IP-Adresse globaler Google APIs und -Dienste, einschließlich Anfragenpaketen, die an Cloud Run- oder App Engine Dienste gesendet werden Netzwerkkontext „Nicht-Internet“
Regionale externe IPv4-Adresse einer Netzwerkschnittstelle einer VM, Weiterleitungsregel eines regionalen externen Application Load Balancers, regionalen externen Proxy-Network Load Balancers, regionalen externen Passthrough-Network Load Balancers oder einer externen Protokollweiterleitung Netzwerkkontext „Internet“
Regionale externe IPv6-Adresse einer Netzwerkschnittstelle einer VM, Weiterleitungsregel eines regionalen externen Application Load Balancers, regionalen externen Proxy-Network Load Balancers, regionalen externen Passthrough-Network Load Balancers oder einer externen Protokollweiterleitung Netzwerkkontext „Internet“, außer wenn Subnetz routen ausgehende Pakete an externe IPv6-Ziele weiterleiten
Globale externe IPv4- oder IPv6-Adresse einer Weiterleitungsregel eines globalen externen Application Load Balancers, globalen externen Proxy-Network Load Balancers oder globalen externen Passthrough-Network Load Balancers Netzwerkkontext „Internet“
Regionale externe IPv4-Adresse eines Cloud VPN-Gateways Netzwerkkontext „Internet“
Regionale externe IPv4-Adresse eines Cloud NAT-Gateways Netzwerkkontext „Internet“
Ausgehende Pakete an externe IPv6-Ziele, die über Subnetzrouten weitergeleitet werden

Wenn VPC-Netzwerke über VPC-Netzwerk-Peering verbunden sind oder als VPC-Spokes im selben NCC-Hub verwendet werden, können IPv6-Subnetzrouten eine Verbindung zu regionalen externen IPv6-Adresszielen von Netzwerkschnittstellen von VMs, regionalen externen Weiterleitungsregeln für Load Balancer und externen Weiterleitungsregeln für Protokolle herstellen. Wenn eine IPv6-Subnetzroute den Pfad für ausgehenden Traffic von einer Netzwerkschnittstelle einer VM zu diesen regionalen externen IPv6-Adresszielen bereitstellt, gehört der Traffic stattdessen zum Netzwerkkontext „Nicht-Internet“.

Netzwerkkontext „Nicht-Internet“

Sie können den Netzwerkkontext Nicht-Internet (NON-INTERNET) als Teil einer Quellkombination einer Regel für eingehenden Traffic oder als Teil einer Zielkombination einer Regel für ausgehenden Traffic verwenden, wobei der Zieltyp entweder auf INSTANCES festgelegt oder nicht angegeben ist:

Kriterien für den Netzwerkkontext „Nicht-Internet“

In diesem Abschnitt werden die Kriterien beschrieben, anhand derer Cloud NGFW ermittelt, ob ein Paket zum Netzwerkkontext „Nicht-Internet“ gehört.

Netzwerkkontext „Nicht-Internet“ für eingehende Pakete

Eingehende Pakete gehören zum Netzwerkkontext „Nicht-Internet“, wenn sie auf eine der folgenden Arten an die Netzwerkschnittstelle einer VM-Instanz weitergeleitet werden:

  • Die Pakete werden über eine Subnetzroute weitergeleitet, und die Ziele der Pakete stimmen mit einer der folgenden Optionen überein:
    • Ein regionales internes IPv4- oder IPv6-Adressziel einer Netzwerkschnittstelle einer VM, eine Weiterleitungsregel eines internen Passthrough-Network Load Balancers oder eine Weiterleitungsregel für die interne Protokollweiterleitung.
    • Ein regionales externes IPv6-Adressziel einer Netzwerkschnittstelle einer VM, eine Weiterleitungsregel eines externen Passthrough-Network Load Balancers oder eine Weiterleitungsregel für die externe Protokollweiterleitung.
  • Die Pakete werden über eine statische Route an eine VM-Instanz als nächsten Hop 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 Routing pfade weitergeleitet:

Eingehende Antwortpakete von globalen Google APIs und -Diensten gehören ebenfalls zum Netzwerkkontext „Nicht-Internet“. Antwortpakete von globalen Google APIs und -Diensten können eine der folgenden Quellen haben:

Netzwerkkontext „Nicht-Internet“ für ausgehende Pakete

Ausgehende Pakete, die von Netzwerkschnittstellen von VMs gesendet werden, gehören zum Netzwerkkontext „Nicht-Internet“, wenn sie auf eine der folgenden Arten weitergeleitet werden:

Netzwerkkontext „VPC-Netzwerke“

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

  1. Sie müssen eine Liste der VPC-Quellnetzwerke angeben:

    • Die Liste der Quellnetzwerke muss mindestens ein VPC-Netzwerk enthalten. Sie können der Liste der Quellnetzwerke 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 seiner teilweisen oder vollständigen URL-Kennung hinzufügen.
    • VPC-Netzwerke, die Sie der Liste der Quellnetzwerke 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 Liste der Quellnetzwerke hinzugefügt wurde, bleibt der Verweis auf das gelöschte Netzwerk in der Liste. Cloud NGFW ignoriert gelöschte VPC-Netzwerke, wenn eine Regel für eingehenden Traffic erzwungen wird. Wenn alle VPC-Netzwerke in der Liste der Quellnetzwerke gelöscht werden, sind Regeln für eingehenden Traffic, die auf der Liste basieren, unwirksam, da sie mit keinen Paketen übereinstimmen.

  2. Sie müssen mindestens einen weiteren Quellparameter angeben, mit Ausnahme einer einer Quelle für die geografische Position.

Pakete stimmen mit der Regel für eingehenden Traffic überein, wenn sie mindestens einem der anderen Quell parameter und den Kriterien für den Netzwerkkontext „VPC-Netzwerke“ entsprechen.

Kriterien für den Netzwerkkontext „VPC-Netzwerke“

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

Ein Paket stimmt mit einer Regel für eingehenden Traffic überein, die den Netzwerkkontext „VPC-Netzwerke“ 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 in einem der VPC-Quellnetzwerke gesendet.

  • Das VPC-Quellnetzwerk und das VPC-Netzwerk, auf das die Firewallrichtlinie mit der Regel für eingehenden Traffic angewendet wird, 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 und der Traffic zwischen ihnen gehört zum Netzwerkkontext „VPC-Netzwerke“:

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

Außerdem gehören Pakete, die über ausgehenden Direct VPC-Traffic in ein VPC-Netzwerk gelangen, zum Netzwerkkontext „VPC-Netzwerke“.

Netzwerkkontext „VPC-intern“

Der Netzwerkkontext VPC-intern (INTRA_VPC) kann nur als Teil einer Quellkombination einer Regel für eingehenden Traffic verwendet werden. Wenn Sie den Netzwerkkontext „VPC-intern“ als Teil einer Quellkombination einer Regel für eingehenden Traffic verwenden möchten, müssen Sie mindestens einen weiteren Quellparameter angeben, mit Ausnahme einer Quelle für die geografische Position.

Pakete stimmen mit der Regel für eingehenden Traffic überein, wenn sie mindestens einem der anderen Quell parameter und den Kriterien für den Netzwerkkontext „VPC-intern“ entsprechen.

Kriterien für den Netzwerkkontext „VPC-intern“

In diesem Abschnitt werden die Kriterien beschrieben, anhand derer Cloud NGFW ermittelt, ob ein Paket zum Netzwerkkontext „VPC-intern“ gehört.

Ein Paket stimmt mit einer Regel für eingehenden Traffic überein, die den Netzwerkkontext „VPC-intern“ 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 und der Traffic zwischen ihnen gehört zum Netzwerkkontext „VPC-intern“:

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

Außerdem gehören Pakete, die über ausgehenden Direct VPC-Traffic in ein VPC-Netzwerk gelangen, zum Netzwerkkontext „VPC-intern“.