Firewallrichtlinien-Regeln

Beim Erstellen einer Firewallrichtlinienregel geben Sie eine Reihe von Komponenten an, die die Funktionsweise der Regel definieren. Diese Komponenten geben Merkmale für Trafficrichtung, Quelle, Ziel und Ebene 4 an, z. B. Protokoll und Zielport (wenn das Protokoll Ports verwendet).

Jede Firewall-Richtlinien-regel gilt entweder für eingehende (ingress) oder für ausgehende Verbindungen (egress), jedoch nicht für beide Verbindungen.

Regeln für eingehenden Traffic

Die Richtung „Eingehender Traffic“ bezieht sich auf die eingehenden Verbindungen, die von bestimmten Quellen an Trusted Cloud by S3NS Ziele gesendet werden. Eingangsregeln gelten für eingehende Pakete, wo das Ziel der Pakete das Ziel ist.

Eine Regel für eingehenden Traffic mit einer deny-Aktion schützt alle Instanzen, indem eingehende Verbindungen an diese blockiert werden. Der eingehende Zugriff kann über eine Regel mit höherer Priorität zugelassen werden. Ein automatisch erstelltes Standardnetzwerk enthält einige vorausgefüllte VPC-Firewallregeln, die eingehenden Traffic für bestimmte Arten von Traffic zulassen.

Regeln für ausgehenden Traffic

Die Richtung "Ausgehender Traffic" bezieht sich auf den ausgehenden Traffic, der von einem Ziel an ein Ziel gesendet wird. Ausgangsregeln gelten für Pakete für neue Verbindungen, bei denen die Quelle des Pakets das Ziel ist.

Bei einer Regel für ausgehenden Traffic mit einer allow-Aktion kann eine Instanz Traffic an die in der Regel angegebenen Ziele senden. Ausgehender Traffic kann durch deny-Firewallregeln mit höherer Priorität abgelehnt werden. Trusted Cloud Außerdem blockiert oder begrenzt Google Cloud bestimmte Arten von Traffic.

Komponenten von Firewallrichtlinienregeln

Regeln in hierarchischen Firewallrichtlinien, globalen Netzwerk-Firewallrichtlinien und regionalen Netzwerk-Firewallrichtlinien verwenden die in diesem Abschnitt beschriebenen Komponenten. Der Begriff Firewallrichtlinie bezieht sich auf alle dieser drei Richtlinientypen. Weitere Informationen zu den Arten von Firewallrichtlinien finden Sie unter Firewallrichtlinien.

Firewallrichtlinienregeln funktionieren im Allgemeinen wie VPC-Firewallregeln. Es gibt jedoch einige Unterschiede, die in den folgenden Abschnitten beschrieben werden.

Priorität

Die Priorität einer Regel in einer Firewallrichtlinie ist eine Ganzzahl von 0 bis einschließlich 2.147.483.647. Niedrigere Werte bedeuten eine höhere Priorität. Die Priorität einer Regel in einer Firewallrichtlinie ähnelt der Priorität einer VPC-Firewall-Regel, mit den folgenden Unterschieden:

  • Jede Regel in einer Firewallrichtlinie muss eine eindeutige Priorität haben.
  • Die Priorität einer Regel in einer Firewallrichtlinie dient als eindeutige Kennung der Regel. Regeln in Firewallrichtlinien verwenden keine Namen zur Identifizierung.
  • Die Priorität einer Regel in einer Firewallrichtlinie definiert die Auswertungsreihenfolge innerhalb der Firewallrichtlinie selbst. VPC-Firewallregeln und -Regeln in hierarchischen Firewallrichtlinien, globalen Netzwerk-Firewallrichtlinien und regionalen Netzwerk-Firewallrichtlinien werden wie unter Richtlinien- und Regelauswertungsreihenfolge beschrieben ausgewertet.

Aktion bei Übereinstimmung

Eine Regel in einer Firewallrichtlinie kann eine der folgenden Aktionen haben:

  • allow lässt Traffic zu und beendet die weitere Regelauswertung.
  • deny lässt keinen Traffic zu und die weitere Regelauswertung wird beendet.

Erzwingung

Sie können auswählen, ob eine Firewallrichtlinienregel für erzwungen werden soll. Dazu legen Sie deren Status auf "Aktiviert" oder "Deaktiviert" fest. Sie können den Erzwingungszustand festlegen, wenn Sie eine Regel erstellen oder eine Regel aktualisieren.

Wenn Sie beim Erstellen einer neuen Firewallregel keinen Erzwingungsstatus festlegen, wird die Firewallregel automatisch aktiviert.

Protokolle und Ports

Ähnlich wie bei Regeln von VPC-Firewallregeln müssen Sie beim Erstellen einer Regel eine oder mehrere Protokoll- und Porteinschränkungen angeben. Beim Angeben von TCP oder UDP in einer Regel können Sie das Protokoll, das Protokoll und einen Zielport oder das Protokoll und einen Zielportbereich angeben. Sie können nicht nur einen Port oder Portbereich angeben. Außerdem können Sie nur Zielports angeben. Regeln für Quellports werden nicht unterstützt.

Sie können die folgenden Protokollnamen in Firewallregeln verwenden: tcp, udp, icmp (für IPv4 ICMP), esp, ah, sctp und ipip. Verwenden Sie für alle anderen Protokolle die IANA-Protokollnummern.

Viele Protokolle verwenden bei IPv4 und IPv6 denselben Namen und dieselbe Nummer, einige Protokolle wie ICMP jedoch nicht. Verwenden Sie icmp oder die Protokollnummer 1, um IPv4 ICMP anzugeben. Verwenden Sie die Protokollnummer 58, um IPv6 ICMP anzugeben.

Firewallregeln unterstützen nicht die Angabe von ICMP-Typen und -Codes, sondern nur das Protokoll.

Das IPv6-Hop-by-Hop-Protokoll wird in Firewallregeln nicht unterstützt.

Wenn Sie keine Protokoll- und Portparameter angeben, gilt die Regel für alle Protokolle und Zielports.

Logging

Das Logging für Regeln von Firewallrichtlinien funktioniert genauso wie das Logging von Regeln in VPC-Firewalls, mit folgenden Ausnahmen:

  • Das Referenzfeld enthält die Firewallrichtlinien-ID und eine Zahl, die die Ebene der Ressource angibt, mit dem die Richtlinie verknüpft ist. 0 bedeutet beispielsweise, dass die Richtlinie auf eine Organisation angewendet wird, und 1, dass die Richtlinie auf einen Ordner auf oberster Ebene unter der Organisation angewendet wird.

  • Logs für Regeln Firewallrichtlinien enthalten ein target_resource-Feld, das die VPC-Netzwerke angibt, auf die die Regel angewendet wird.

  • Logging kann nur für allow- und deny-Regeln aktiviert werden, nicht jedoch für goto_next-Regeln.

Ziel, Quelle, Bestimmungsort

Zielparameter identifizieren die Netzwerkschnittstellen von Instanzen, für die eine Firewallregel gilt.

Sie können sowohl Quellparameter als auch Zielparameter angeben, die für die Paketquellen oder Ziele für Firewallregeln für eingehenden und ausgehenden Traffic gelten. Die Richtung der Firewallregel bestimmt die möglichen Werte für die Quell- und Zielparameter.

Die Ziel- und Quellparameter arbeiten zusammen.

Ziele

Alle Firewallregeln für eingehenden und ausgehenden Traffic haben ein Ziel. Das Ziel identifiziert die Netzwerkschnittstellen der Compute Engine-Instanzen, einschließlich Google Kubernetes Engine-Knoten und Instanzen der flexiblen App Engine-Umgebung, für die die Firewallregel gilt.

Jede Firewallregel hat ein breitestes Ziel, das Sie eingrenzen können, indem Sie einen Zielparameter oder eine Zielparameterkombination angeben. Wenn Sie weder einen Zielparameter noch eine Zielparameterkombination angeben, gilt die Firewallregel für das breiteste Ziel.

  • Breitestes Ziel für Regeln in hierarchischen Firewallrichtlinien: alle VM-Netzwerkschnittstellen in einem Subnetz in einer beliebigen Region eines beliebigen VPC-Netzwerks, das sich in einem Projekt unter dem Resource Manager-Knoten (Ordner oder Organisation) befindet, der mit der hierarchischen Firewallrichtlinie verknüpft ist.

  • Breitestes Ziel für Regeln in globalen Netzwerk-Firewallrichtlinien: alle VM-Netzwerkschnittstellen in einem Subnetzwerk in einer beliebigen Region des VPC-Netzwerks, das mit der globalen Netzwerk-Firewallrichtlinie verknüpft ist.

  • Breitestes Ziel für Regeln in regionalen Netzwerk-Firewallrichtlinien: alle VM-Netzwerkschnittstellen in einem Subnetzwerk innerhalb der Region und des VPC-Netzwerks, das der regionalen Netzwerk-Firewallrichtlinie zugeordnet ist.

In der folgenden Tabelle sind gültige Zielparameter und Kombinationen aufgeführt, mit denen Sie das Ziel einer Firewallregel eingrenzen können:

Zielparameter Unterstützung in hierarchischen Firewallrichtlinien Unterstützung in globalen und regionalen Netzwerk-Firewallrichtlinien
VPC-VPC-Netzwerk als Ziel festlegen

Eine Liste mit einem oder mehreren VPC-Netzwerken, die mit dem Parameter target-resources angegeben werden. Diese Liste schränkt das breiteste Ziel der Firewallregel auf die VM-Netzwerkschnittstellen ein, die sich in mindestens einem der angegebenen VPC-Netzwerke befinden.
Zieldienstkonten

Eine Liste mit einem oder mehreren Dienstkonten, die mit dem Parameter target-service-accounts angegeben werden. Diese Liste schränkt das breiteste Ziel der Firewallregel auf die VM-Netzwerkschnittstellen ein, die zu VM-Instanzen gehören, die mindestens einem der angegebenen Dienstkonten zugeordnet sind.
Kombination aus Ziel-Dienstkonten und Ziel-VPC-Netzwerkressourcen

Eine Kombination, bei der sowohl der Parameter target-service-accounts als auch der Parameter target-resources in derselben Regel verwendet werden. Durch diese Kombination wird das breiteste Ziel der Firewallregel auf die VM-Netzwerkschnittstellen beschränkt, die beide der folgenden Kriterien erfüllen:

  • Schnittstellen, die sich in mindestens einem der angegebenen VPC-Netzwerke befinden
  • Schnittstellen, die zu VM-Instanzen gehören, die mindestens einem der angegebenen Dienstkonten zugeordnet sind
Sichere Tag-Werte aus einem Tag-Schlüssel mit Daten zum Netzwerkzweck ausrichten

Eine Liste mit mindestens einem Tag-Wert aus einem Tag-Schlüssel, dessen Zweckdaten ein einzelnes VPC-Netzwerk angeben. Diese Liste schränkt das breiteste Ziel der Firewallregel auf die VM-Netzwerkschnittstellen ein, die sich im VPC-Netzwerk befinden, das in den Zweckdaten angegeben ist. Weitere Informationen finden Sie unter Sichere Tags für Firewalls.
Sichere Tag-Werte aus einem Tag-Schlüssel mit Daten zum Organisationszweck ausrichten

Eine Liste mit mindestens einem Tag-Wert aus einem Tag-Schlüssel, dessen Zweckdaten organization=auto sind. Dadurch wird das breiteste Ziel der Firewallregel auf die VM-Netzwerkschnittstellen in einem beliebigen VPC-Netzwerk der Organisation eingegrenzt. Weitere Informationen finden Sie unter Sichere Tags für Firewalls.

Ziele und IP-Adressen für Regeln für eingehenden Traffic

Die an die Netzwerkschnittstelle einer Ziel-VM weitergeleiteten Pakete werden gemäß den folgenden Bedingungen verarbeitet:

  • Wenn die Firewallregel für eingehenden Traffic einen Ziel-IP-Adressbereich enthält, muss das Ziel des Pakets in einen der explizit definierten Ziel-IP-Adressbereiche passen (Funktion in der Vorabversion).

  • Wenn die Firewallregel für eingehenden Traffic keinen Ziel-IP-Adressbereich enthält, muss das Ziel des Pakets mit einer der folgenden IP-Adressen übereinstimmen:

    • Die primäre interne IPv4-Adresse, die der NIC der Instanz zugewiesen ist.

    • Alle konfigurierten Alias-IP-Adressbereiche auf der NIC der Instanz.

    • Die externe IPv4-Adresse, die der NIC der Instanz zugeordnet ist.

    • Beliebige IPv6-Adresse, die der NIC zugewiesenen ist, wenn IPv6 im Subnetz konfiguriert ist.

    • Eine interne oder externe IP-Adresse, die mit einer Weiterleitungsregel verbunden ist, die für das Passthrough Load-Balancing verwendet wird, wobei die Instanz ein Backend für einen internen Passthrough Network Load Balancer oder einen externen Passthrough Network Load Balancer ist.

    • Eine interne oder externe IP-Adresse, die einer Weiterleitungsregel für die Protokollweiterleitung zugeordnet ist, wobei auf die Instanz von einer Zielinstanz verwiesen wird.

    • Eine IP-Adresse im Zielbereich einer benutzerdefinierten statischen Route, die die Instanz (next-hop-instance oder next-hop-address) als VM des nächsten Hops verwendet.

    • Eine IP-Adresse innerhalb des Zielbereichs einer benutzerdefinierten statischen Route, die einen internen Passthrough Network Load Balancer (next-hop-ilb) als nächsten Hop verwendet, wenn die VM ein Backend für diesen Load-Balancer ist.

Ziele und IP-Adressen für Regeln für ausgehenden Traffic

Die Verarbeitung von Paketen, die von der Netzwerkschnittstelle eines Ziels ausgegeben werden, hängt von der Konfiguration der IP-Weiterleitung auf der Ziel-VM ab. Die IP-Weiterleitung ist standardmäßig deaktiviert.

  • Wenn für die Ziel-VM die IP-Weiterleitung deaktiviert ist, kann die VM Pakete mit den folgenden Quellen ausgeben:

    • Die primäre interne IPv4-Adresse der NIC einer Instanz.

    • Jeder konfigurierte Alias-IP-Adressbereich auf der NIC einer Instanz.

    • Beliebige IPv6-Adresse, die der NIC zugewiesenen ist, wenn IPv6 im Subnetz konfiguriert ist.

    • Eine interne oder externe IP-Adresse, die mit einer Weiterleitungsregel verbunden ist, für Passthrough Load-Balancing oder Protokollweiterleitung. Dies gilt, wenn die Instanz ein Backend für einen internen Passthrough Network Load Balancer oder einen externen Passthrough Network Load Balancer ist oder von einer Zielinstanz referenziert wird.

    Wenn die Firewallregel für ausgehenden Traffic Quell-IP-Adressbereiche enthält, sind die Ziel-VMs weiterhin auf die zuvor erwähnten Quell-IP-Adressen beschränkt. Sie können diesen Satz jedoch mit dem Quellparameter verfeinern. Wenn Sie einen Quellparameter verwenden, ohne die IP-Weiterleitung zu aktivieren, wird der Satz möglicher Paketquelladressen nicht erweitert.

    Wenn die Firewallregel für ausgehenden Traffic keinen Quell-IP-Adressbereich enthält, sind alle zuvor genannten Quell-IP-Adressen zulässig.

  • Wenn für die Ziel-VM die IP-Weiterleitung aktiviert ist, kann die VM Pakete mit beliebigen Quelladressen ausgeben. Mit dem Quellparameter können Sie den Satz zulässiger Paketquellen genauer definieren.

Quellen

Die Werte der Quellparameter hängen von folgenden Faktoren ab:

  • Dem Typ der Firewallrichtlinie, die die Firewallregel enthält
  • Der Richtung der Firewallregel

Quellen für Regeln für eingehenden Traffic

In der folgenden Tabelle sind die Quellparameter aufgeführt, die einzeln oder in Kombination miteinander in einer einzelnen Regel für die Firewallrichtlinie für eingehenden Traffic verwendet werden können. Für Cloud NGFW müssen Sie mindestens einen Quellparameter angeben.

Quellparameter für Regeln für eingehenden Traffic Unterstützung in hierarchischen Firewallrichtlinien Unterstützung in globalen und regionalen Netzwerk-Firewallrichtlinien
Quell-IP-Adressbereiche

Eine einfache Liste mit IPv4-Adressen im CIDR-Format oder IPv6-Adressen im CIDR-Format. Die Liste wird in der Firewallrichtlinienregel selbst gespeichert.
Quelladressgruppen

Wiederverwendbare Sammlungen von IPv4-Adressen im CIDR-Format oder IPv6-Adressen im CIDR-Format. Die Firewallregel verweist auf die Sammlung. Weitere Informationen finden Sie unter Adressgruppen für Firewallrichtlinien.
Quelldomainnamen

Eine Liste mit einem oder mehreren Quelldomainnamen. Weitere Informationen, einschließlich der Konvertierung von Domainnamen in IP-Adressen, finden Sie unter FQDN-Objekte.
Sichere Tag-Werte aus einem Tag-Schlüssel mit Daten zum Netzwerkzweck abrufen

Eine Liste mit mindestens einem Tag-Wert aus einem Tag-Schlüssel, dessen Zweckdaten ein einzelnes VPC-Netzwerk angeben. Weitere Informationen finden Sie unter Sichere Tags für Firewalls und Wie sichere Quell-Tags Paketquellen implizieren.
Sichere Tag-Werte aus einem Tag-Schlüssel mit Daten zum Organisationszweck abrufen

Eine Liste mit mindestens einem Tag-Wert aus einem Tag-Schlüssel, dessen Zweckdaten organization=auto sind. Weitere Informationen finden Sie unter Sichere Tags für Firewalls und Wie sichere Quell-Tags Paketquellen implizieren.
Quellstandorte

Eine Liste mit einem oder mehreren geografischen Standorten, die als Ländercodes mit zwei Buchstaben oder Regionscodes angegeben sind. Weitere Informationen finden Sie unter Standortobjekte.
Quellnetzwerktyp

Eine Einschränkung, die eine Sicherheitsgrenze definiert. Weitere Informationen finden Sie unter Netzwerktypen.

In einer einzelnen Regel für eingehenden Traffic können Sie zwei oder mehr Quellparameter verwenden, um eine Quellkombination zu erstellen. Cloud NGFW erzwingt die folgenden Einschränkungen für Quellkombinationen jeder Ingress-Regel:

  • Quell-IP-Adressbereiche müssen entweder IPv4- oder IPv6-CIDRs enthalten, aber nicht beides.
  • Eine Quelladressgruppe, die IPv4-CIDRs enthält, kann nicht mit einer Quelladressgruppe verwendet werden, die IPv6-CIDRs enthält.
  • Ein Quell-IP-Adressbereich, der IPv4-CIDRs enthält, kann nicht mit einer Quelladressgruppe verwendet werden, die IPv6-CIDRs enthält.
  • Ein Quell-IP-Adressbereich, der IPv6-CIDRs enthält, kann nicht mit einer Quelladressgruppe verwendet werden, die IPv4-CIDRs enthält.
  • Der Internet-Netzwerktyp kann nicht mit den sicheren Quell-Tags verwendet werden.
  • Die Typen „Ohne Internet“, „VPC-Netzwerke“ und „VPC-übergreifend“ können nicht mit oder mit Geolocation als Quelle verwendet werden.

Cloud NGFW wendet die folgende Logik an, um die Pakete einer Ingress-Regel zuzuordnen, die eine Quellkombination verwendet:

  • Wenn die Quellkombination keinen Quellnetzwerktyp enthält, stimmen Pakete mit der Regel für eingehenden Traffic überein, wenn sie mindestens einem Quellparameter in der Quellkombination entsprechen.

  • Wenn die Quellkombination einen Quellnetzwerktyp enthält, stimmen Pakete mit der Regel für eingehenden Traffic überein, wenn sie mit dem Quellnetzwerktyp und mindestens einem der anderen Quellparameter in der Quellkombination übereinstimmen.

Wie sichere Quell-Tags Paketquellen implizieren

Regeln für eingehenden Traffic in Firewallrichtlinien können Quellen mithilfe von sicheren Quell-Tags (Tag-Werten) angeben. Sichere Tag-Werte identifizieren Netzwerkschnittstellen, nicht Paketmerkmale wie IP-Adressen.

Pakete, die von einer Netzwerkschnittstelle einer VM-Instanz gesendet werden, entsprechen einer Regel für eingehenden Traffic, die einen sicheren Quell-Tag-Wert verwendet, gemäß den folgenden Regeln:

  • Wenn sich die Regel für eingehenden Traffic in einer regionalen Netzwerkrichtlinie befindet, muss sich die VM-Instanz in einer Zone derselben Region wie die regionale Netzwerk-Firewallrichtlinie befinden. Andernfalls kann sich die VM-Instanz in einer beliebigen Zone befinden.

  • Die VM-Instanz muss demselben sicheren Tag-Wert zugeordnet sein, der in einer Firewallregel für eingehenden Traffic als sicheres Quell-Tag verwendet wird.

  • Der sichere Tag-Wert, der der VM-Instanz zugeordnet und von der Firewallregel für eingehenden Traffic verwendet wird, muss von einem Tag-Schlüssel stammen, dessen Attribut purpose-data mindestens ein VPC-Netzwerk identifiziert, das eine Netzwerkschnittstelle der VM-Instanz enthält:

    • Wenn die Zweckdaten des Tag-Schlüssels ein einzelnes VPC-Netzwerk angeben, gelten Firewallregeln für eingehenden Traffic, die den sicheren Quell-Tag-Wert verwenden, für die Netzwerkschnittstellen der VM-Instanz, die sich in diesem VPC-Netzwerk befinden.

    • Wenn die Zweckdaten des Tag-Schlüssels die Organisation angeben, gelten Firewallregeln für eingehenden Traffic, die den sicheren Quell-Tag-Wert verwenden, für die Netzwerkschnittstellen der VM-Instanz, die sich in einem beliebigen VPC-Netzwerk der Organisation befinden.

  • Die identifizierte VM-Netzwerkschnittstelle muss eines der folgenden Kriterien erfüllen:

    • Die VM-Netzwerkschnittstelle befindet sich im selben VPC-Netzwerk wie das VPC-Netzwerk, für das die Firewallrichtlinie gilt.
    • Die VM-Netzwerkschnittstelle befindet sich in einem VPC-Netzwerk, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk verbunden ist, für das die Firewallrichtlinie gilt.

Weitere Informationen zu sicheren Tags für Firewalls finden Sie unter Spezifikationen.

Quellen für Regeln für ausgehenden Traffic

Sie können die folgenden Quellen für Regeln für ausgehenden Traffic sowohl in hierarchischen Firewallrichtlinien als auch in Netzwerk-Firewallrichtlinien verwenden:

  • Standard – durch Ziel impliziert: Wenn Sie den Quellparameter in einer Regel für ausgehenden Traffic weglassen, werden die Paketquellen implizit wie in Ziele und IP-Adressen für Regeln für ausgehenden Traffic beschrieben definiert.

  • IPv4-Quelladressbereiche: Eine Liste von IPv4-Adressen im CIDR-Format.

  • IPv6-Quelladressbereiche: Eine Liste von IPv6-Adressen im CIDR-Format.

Befolgen Sie diese Richtlinien, um Quell-IP-Adressbereiche für Regeln für ausgehenden Traffic hinzuzufügen:

  • Wenn einer VM-Schnittstelle sowohl interne als auch externe IPv4-Adressen zugewiesen sind, wird nur die interne IPv4-Adresse während der Regelauswertung verwendet.

  • Wenn Sie in der Regel für ausgehenden Traffic einen Quell-IP-Adressbereich und Zielparameter haben, werden die Zielparameter in dieselbe IP-Version aufgelöst wie die Quell-IP-Version.

    Beispiel: In einer Regel für ausgehenden Traffic haben Sie im Quellparameter einen IPv4-Adressbereich und im Zielparameter ein FQDN-Objekt. Wenn der FQDN sowohl in IPv4- als auch in IPv6-Adressen aufgelöst wird, wird während der Regelerzwingung nur die aufgelöste IPv4-Adresse verwendet.

Reiseziele

Ziele können mithilfe von IP-Adressbereichen angegeben werden, die sowohl von Regeln für eingehenden als auch von Regeln für ausgehenden Traffic in hierarchischen und Netzwerk-Firewallrichtlinien unterstützt werden. Das Standardverhalten des Ziels hängt von der Richtung der Regel ab.

Ziele für Regeln für eingehenden Traffic

Sie können die folgenden Ziele für Firewallregeln für eingehenden Traffic sowohl in hierarchischen als auch in Netzwerk-Firewallrichtlinien verwenden:

  • Standard – durch Ziel impliziert: Wenn Sie den Zielparameter in einer Regel für eingehenden Traffic weglassen, werden die Paketziele implizit definiert, wie unter Ziele und IP-Adressen für Regeln für eingehenden Traffic beschrieben.

  • IPv4-Zieladressbereiche: Eine Liste von IPv4-Adressen im CIDR-Format.

  • IPv6-Zieladressbereiche: Eine Liste von IPv6-Adressen im CIDR-Format.

Befolgen Sie diese Richtlinien, um Ziel-IP-Adressbereiche für Regeln für eingehenden Traffic hinzuzufügen:

Ziele für Regeln für ausgehenden Traffic

In der folgenden Tabelle sind die Zielparameter aufgeführt, die einzeln oder in Kombination miteinander in einer einzelnen Regel für ausgehenden Traffic in einer Firewallrichtlinie verwendet werden können. Für Cloud NGFW müssen Sie mindestens einen Zielparameter angeben.

Zielparameter für Regeln für ausgehenden Traffic Unterstützung in hierarchischen Firewallrichtlinien Unterstützung in globalen und regionalen Netzwerk-Firewallrichtlinien
Ziel-IP-Adressbereiche

Eine einfache Liste mit IPv4-Adressen im CIDR-Format oder IPv6-Adressen im CIDR-Format. Die Liste wird in der Firewallrichtlinienregel selbst gespeichert.
Zieladressgruppen

Wiederverwendbare Sammlungen von IPv4-Adressen im CIDR-Format oder IPv6-Adressen im CIDR-Format. Die Firewallrichtlinien-Regel verweist auf die Sammlung. Weitere Informationen finden Sie unter Adressgruppen für Firewallrichtlinien.
Zieldomainnamen

Eine Liste mit einem oder mehreren Quelldomainnamen. Weitere Informationen, einschließlich der Konvertierung von Domainnamen in IP-Adressen, finden Sie unter FQDN-Objekte.
Geografische Standorte von Zielen

Eine Liste mit einem oder mehreren geografischen Standorten, die als Ländercodes mit zwei Buchstaben oder Regionscodes angegeben sind. Weitere Informationen finden Sie unter Standortobjekte.
Zielnetzwerktyp

Eine Einschränkung, die eine Sicherheitsgrenze definiert. Weitere Informationen finden Sie unter Netzwerktypen.

In einer einzelnen Regel für ausgehenden Traffic können Sie zwei oder mehr Zielparameter verwenden, um eine Zielkombination zu erstellen. Cloud NGFW erzwingt die folgenden Einschränkungen für Zielkombinationen jeder Ausgangsregel:

  • Ziel-IP-Adressbereiche müssen entweder IPv4- oder IPv6-CIDRs enthalten, aber nicht beides.
  • Eine Zieladressgruppe, die IPv4-CIDRs enthält, kann nicht mit einer Zieladressgruppe verwendet werden, die IPv6-CIDRs enthält.
  • Ein Ziel-IP-Adressbereich, der IPv4-CIDRs enthält, kann nicht mit einer Zieladressgruppe verwendet werden, die IPv6-CIDRs enthält.
  • Ein Ziel-IP-Adressbereich, der IPv6-CIDRs enthält, kann nicht mit einer Zieladressgruppe verwendet werden, die IPv4-CIDRs enthält.
  • Ziel- Geolokationen können nicht mit dem Zielnetzwerktyp „Nicht-Internet“ verwendet werden.

Cloud NGFW wendet die folgende Logik an, um die Pakete einer Egress-Regel zuzuordnen, die eine Zielkombination verwendet:

  • Wenn die Zielkombination keinen Zielnetzwerktyp enthält, stimmen Pakete mit der Regel für ausgehenden Traffic überein, wenn sie mindestens einem Zielparameter in der Zielkombination entsprechen.

  • Wenn die Zielkombination einen Zielnetzwerktyp enthält, entsprechen Pakete der Regel für ausgehenden Traffic, wenn sie dem Zielnetzwerktyp und mindestens einem der anderen Zielparameter in der Zielkombination entsprechen.

Netzwerktypen

Mit Netzwerktypen können Sie Ihre Sicherheitsziele mit weniger Firewallrichtlinienregeln effizienter erreichen. Cloud NGFW unterstützt vier Netzwerktypen, die zum Erstellen einer Quellkombination oder Zielkombination in einer Regel einer hierarchischen Firewallrichtlinie, einer globalen Netzwerk-Firewallrichtlinie oder einer regionalen Netzwerk-Firewallrichtlinie verwendet werden können.

In der folgenden Tabelle sind die vier Netzwerktypen aufgeführt und es wird angegeben, ob ein Netzwerktyp in einer Quellkombination einer Ingress-Regel, in einer Zielkombination einer Egress-Regel oder in beiden verwendet werden kann.

Netzwerktyp Quellen für Regeln für eingehenden Traffic Ziele für Regeln für ausgehenden Traffic
Internet (INTERNET)
Nicht internetbasiert (NON_INTERNET)
VPC-Netzwerke (VPC_NETWORKS)
VPC-intern (INTRA_VPC)

Die Netzwerktypen „Internet“ und „Ohne Internet“ schließen sich gegenseitig aus. Die VPC-Netzwerke und Intra-VPC-Netzwerktypen sind Teilmengen des Netzwerktyps „Ohne Internet“.

Typ des Internetnetzwerks

Der Netzwerktyp 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 Internetyps und mindestens einen anderen Quellparameter an, mit Ausnahme einer Quelle mit sicherem Tag. Pakete entsprechen der Regel für eingehenden Traffic, wenn sie mindestens einem der anderen Quellparameter entsprechen und dem Quellparameter für den Internettyp entsprechen.

  • Geben Sie für eine Ausgangsregel das Ziel vom Typ „Internet“ und mindestens einen weiteren Zielparameter an. Pakete entsprechen der Regel für ausgehenden Traffic, wenn sie mindestens einem der anderen Zielparameter und dem Zielparameter für den Internettyp entsprechen.

Im restlichen Teil dieses Abschnitts werden die Kriterien beschrieben, anhand derer Cloud NGFW ermittelt, ob ein Paket zum Internet-Netzwerktyp gehört.

Typ des Internetnetzwerks für eingehende Pakete

Eingehende Pakete, die von einem Google Maglev an eine VM-Netzwerkschnittstelle weitergeleitet werden, gehören zum Netzwerktyp „Internet“. 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 Subnetzroute weitergeleitet wurde, die durch VPC-Netzwerk-Peering oder von einem VPC-Spoke in einem Network Connectivity Center-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.

Typ des Internetnetzwerks für ausgehende Pakete

Ausgehende Pakete, die von den Netzwerkschnittstellen der VM gesendet und über statische Routen mit dem nächsten Hop des Standard-Internetgateways weitergeleitet werden, gehören zum Netzwerktyp „Internet“. Wenn die Ziel-IP-Adresse dieser Egress-Pakete jedoch für Google APIs und Dienste bestimmt ist, gehören diese Pakete zum Netzwerktyp „Nicht-Internet“. Weitere Informationen zur Verbindung mit Google APIs und ‑Diensten finden Sie unter Nicht internetbasierter Netzwerktyp.

Wenn die Pakete über eine statische Route weitergeleitet werden, die den nächsten Hop des Standard-Internetgateways verwendet, gehören alle Pakete, die von den VM-Netzwerkschnittstellen an die folgenden Ziele gesendet werden, zum Internettraffic:

  • 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 Typ „Internet“:

  • Ausgehende Pakete, die von einer Netzwerkschnittstelle einer VM mit VPN-Software an die regionale externe IPv4-Adresse eines Cloud VPN-Gateways gesendet werden, gehören zum Internettraffic.
  • Ausgehende Pakete, die von einem Cloud VPN-Gateway an ein anderes Cloud VPN-Gateway gesendet werden, gehören zu keinem Netzwerktyp, da Firewallregeln nur für VMs gelten.
  • Bei Public NAT werden Antwortpakete, die von einer VM-Netzwerkschnittstelle an die regionale externe IPv4-Adresse eines Cloud NAT-Gateways gesendet werden, als zum Internettyp gehörig betrachtet.

Wenn VPC-Netzwerke über VPC Network Peering verbunden sind oder VPC-Netzwerke als VPC-Spokes am selben Network Connectivity Center-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-Zieladressen über eine Subnetzroute erfolgt, gehören die Ziele stattdessen zum Netzwerktyp „Nicht-Internet“.

Nicht internetbasierter Netzwerktyp

Der Netzwerktyp non-internet (NON-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 vom Typ „Nicht-Internet“ und mindestens einen weiteren Quellparameter an, mit Ausnahme einer Threat Intelligence-Listenquelle oder einer Geolocation-Quelle. Pakete entsprechen der Regel für eingehenden Traffic, wenn sie mindestens einem der anderen Quellparameter entsprechen und dem Quellparameter vom Typ „Nicht-Internet“.

  • Geben Sie für eine Ausgangsregel das Ziel vom Typ „Nicht-Internet“ und mindestens einen weiteren Zielparameter an. Pakete entsprechen der Regel für ausgehenden Traffic, wenn sie mindestens einem der anderen Zielparameter entsprechen und dem Zielparameter vom Typ „Nicht-Internet“.

Im weiteren Verlauf dieses Abschnitts werden die Kriterien beschrieben, anhand derer Cloud NGFW ermittelt, ob ein Paket zum Netzwerktyp „Nicht-Internet“ gehört.

Nicht internetbasierter Netzwerktyp für eingehende Pakete

Pakete für eingehenden Traffic, die über nächste Hops innerhalb eines VPC-Netzwerk oder von Google APIs und ‑Diensten an eine VM-Netzwerkschnittstelle weitergeleitet werden, gehören zum Netzwerktyp „Nicht-Internet“.

Pakete werden in den folgenden Szenarien über nächste Hops innerhalb eines VPC-Netzwerk oder von Google APIs und Google-Diensten weitergeleitet:

  • Das Paketziel entspricht einem der folgenden:

    • Eine regionale interne IPv4- oder IPv6-Adresse einer VM-Netzwerkschnittstelle, einer Weiterleitungsregel eines internen Passthrough-Network Load Balancers oder einer Weiterleitungsregel für die interne 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 wurde über eine lokale Subnetzroute, eine Peering-Subnetzroute oder eine Network Connectivity Center-Subnetzroute weitergeleitet.
    • Eine beliebige Adresse im Zielbereich einer statischen Route, bei der die empfangende VM entweder eine Next-Hop-VM oder eine Backend-VM eines internen Passthrough Network Load Balancers als nächsten Hop ist.

  • Die Paketquelle entspricht einer der folgenden:

Nicht internetbasierter Netzwerktyp für ausgehende Pakete

Ausgehende Pakete, die entweder von den VM-Netzwerkschnittstellen gesendet und in einem VPC-Netzwerk weitergeleitet oder an Google APIs und Google-Dienste gesendet werden, gehören zum Netzwerktyp „Nicht-Internet“.

Pakete werden in den folgenden Szenarien über nächste Hops innerhalb eines VPC-Netzwerk oder an Google APIs und Google-Dienste weitergeleitet:

VPC-Netzwerktyp

Der Typ VPC-Netzwerke (VPC_NETWORKS) kann nur als Teil einer Quellkombination einer Ingress-Regel verwendet werden. Sie können den VPC-Netzwerktyp nicht als Teil einer Zielkombination einer Egress-Regel verwenden.

Wenn Sie den Typ „VPC-Netzwerke“ als Teil einer Quellkombination einer Ingress-Regel verwenden möchten, gehen Sie so vor:

  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 eingehende Regeln, die auf der Liste basieren, ineffektiv, da sie mit keinen Paketen übereinstimmen.

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

Ein Paket entspricht einer Regel für eingehenden Traffic, die den VPC-Netzwerktyp in der 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 Quell-VPC-Netzwerke gesendet.

  • Das Quell-VPC-Netzwerk und das VPC-Netzwerk, auf das die Firewallrichtlinie mit der Ingress-Regel 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:

  • 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

Intra-VPC-Netzwerktyp

Der Netzwerktyp intra-VPC (INTRA_VPC) kann nur als Teil einer Quellkombination einer Regel für eingehenden Traffic verwendet werden. Sie können den VPC-internen Netzwerktyp nicht als Teil einer Zielkombination einer Egress-Regel verwenden.

Wenn Sie den Typ „Intra-VPC“ als Teil einer Quellkombination einer Regel für eingehenden Traffic verwenden möchten, müssen Sie mindestens einen anderen Quellparameter angeben, mit Ausnahme einer oder einer geografischen Quelle.

Ein Paket entspricht einer Regel für eingehenden Traffic, die den Typ „intra-VPC“ 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

Standortobjekte

Verwenden Sie Standortobjekte in Firewallrichtlinien-Regeln, um externen IPv4- und externen IPv6-Traffic anhand bestimmter geografischer Standorte oder Regionen zu filtern.

Sie können Regeln mit Standortobjekten auf eingehenden und ausgehenden Traffic anwenden. Basierend auf der Richtung des Traffics werden die mit den Ländercodes verknüpften IP-Adressen mit der Quelle oder dem Ziel des Traffics abgeglichen.

  • Sie können Standortobjekte für hierarchische Firewallrichtlinien, globale Netzwerk-Firewallrichtlinien und regionale Netzwerk-Firewallrichtlinien konfigurieren.

  • Verwenden Sie zum Hinzufügen von Standorten zu den Firewallrichtlinien-Regeln Ländercodes mit zwei Buchstaben oder Regionscodes, wie in den ISO 3166-Alpha-2-Ländercodes definiert.

    Wenn Sie beispielsweise eingehenden Traffic nur aus den USA in das Netzwerk zulassen möchten, erstellen Sie eine Firewallregel für eingehenden Traffic und setzen Sie den Quellcode des Quelllandes auf US und die Aktion aufallow. Wenn Sie ausgehenden Traffic nur in die USA zulassen möchten, konfigurieren Sie eine Firewallrichtlinien-Regel und setzen Sie den Ziellländercode auf US und die Aktion auf allow.

  • Mit Cloud NGFW können Sie Firewallregeln für die folgenden Gebiete konfigurieren, die umfassenden US-Sanktionen unterliegen:

    Gebiete Zugewiesener Code
    Krim XC
    Sogenannte Volksrepublik Donezk und sogenannte Volksrepublik Luhansk XD

  • Wenn in einer einzelnen Firewallregel doppelte Ländercodes enthalten sind, wird nur ein Eintrag für diesen Ländercode beibehalten. Der doppelte Eintrag wird entfernt. In der Ländercodeliste ca,us,us wird beispielsweise nur ca,us beibehalten.

  • Google verwaltet eine Datenbank mit IP-Adressen und Ländercodezuordnungen. Trusted Cloud -Firewalls verwenden diese Datenbank, um die IP-Adressen des Quell- und Zieltraffics dem Ländercode zuzuordnen. Anschließend wird die übereinstimmende Firewallrichtlinien-Regel mit Standortobjekten angewendet.

  • Manchmal ändern sich IP-Adresszuweisungen und Ländercodes aufgrund der folgenden Bedingungen:

    Da es einige Zeit dauern kann, bis diese Änderungen in der Google-Datenbank widergespiegelt werden, kommt es unter Umständen zu Trafficunterbrechungen und Verhaltensänderungen bei bestimmtem Traffic, der blockiert oder zugelassen wird.

Standortobjekte mit anderen Filtern für Firewallrichtlinien-Regeln verwenden

Sie können Standortobjekte zusammen mit anderen Quell- oder Zielfiltern verwenden. Abhängig von der Regelrichtung wird die Firewallrichtlinien-Regel auf den eingehenden oder ausgehenden Traffic angewendet, der der Vereinigung aller angegebenen Filter entspricht.

Informationen zur Funktionsweise von Standortobjekten mit anderen Quellfiltern in den Regeln für eingehenden Traffic finden Sie unter Quellen für Regeln für eingehenden Traffic in hierarchischen Firewallrichtlinien und Quellen für Regeln für eingehenden Traffic in Netzwerk-Firewallrichtlinien.

Informationen zur Funktionsweise von Standortobjekten mit anderen Zielfiltern in den Regeln für ausgehenden Traffic finden Sie unter Ziele für Regeln für ausgehenden Traffic.

Adressgruppen für Firewallrichtlinien

Adressbereiche sind eine logische Sammlung von IPv4-Adressbereichen oder IPv6-Adressbereichen im CIDR-Format. Mit Adressgruppen können Sie konsistente Quellen oder Ziele definieren, auf die viele Firewallregeln verweisen. Adressgruppen können ohne Änderung der Firewallregeln aktualisiert werden, von denen sie verwendet werden. Weitere Informationen zu Adressgruppen finden Sie unter Adressgruppen für Firewallrichtlinien.

Sie können Quell- und Zieladressgruppen für Firewallregeln für eingehenden und ausgehenden Traffic definieren.

Informationen zur Funktionsweise von Quelladressgruppen mit anderen Quellfiltern in den Regeln für eingehenden Traffic finden Sie unter Quellen für Regeln für eingehenden Traffic in hierarchischen Firewallrichtlinien und Quellen für Regeln für eingehenden Traffic in Netzwerk-Firewallrichtlinien.

Informationen zur Funktionsweise von Zieladressgruppen mit anderen Zielfiltern in den Regeln für ausgehenden Traffic finden Sie unter Ziele für Regeln für ausgehenden Traffic.

FQDN-Objekte

Verwenden Sie Objekte für voll qualifizierte Domainnamen (FQDN) in den Firewallrichtlinienregeln, um eingehenden oder ausgehenden Traffic von oder zu bestimmten Domains zu filtern.

Sie können Firewallregeln mit FQDN-Objekten sowohl auf eingehenden als auch auf ausgehenden Traffic anwenden. Abhängig von der Richtung des Traffics werden die mit den Domainnamen verknüpften IP-Adressen mit der Quelle oder dem Ziel des Traffics abgeglichen.

  • Sie können FQDN-Objekte in Firewallregeln für hierarchische Firewallrichtlinien, globale Netzwerk-Firewallrichtlinien und regionale Netzwerk-Firewallrichtlinien konfigurieren.

  • FQDN-Objekte müssen in der Standard-FQDN-Syntax angegeben werden.

    Weitere Informationen zu Domainnamenformaten finden Sie unter Domainnamenformat.

  • Cloud NGFW aktualisiert in regelmäßigen Abständen die Richtlinien für Firewallrichtlinien, die FQDN-Objekte mit den neuesten Ergebnissen der Domainnamenauflösung enthalten.

  • Die in den Firewallrichtlinien-Regeln angegebenen Domainnamen werden entsprechend der Reihenfolge der VPC-Namensauflösung von Cloud DNS in IP-Adressen aufgelöst. Cloud DNS benachrichtigt die Cloud NGFW, wenn sich die Ergebnisse der Auflösung von Domainnamen ändern. Diese werden auch als DNS-Einträge (Domain Name System) bezeichnet.

  • Wenn zwei Domainnamen in dieselbe IP-Adresse aufgelöst werden, gilt die Firewallregel für diese IP-Adresse, nicht nur für eine Domain. Die FQDN-Objekte sind also Layer-3-Entitäten.

  • Wenn das FQDN-Objekt in der Firewallregel für ausgehenden Traffic eine Domain enthält, die CNAMEs im DNS-Eintrag enthält, müssen Sie die Firewallregel für ausgehenden Traffic mit allen Domainnamen konfigurieren, die Ihre VMs abfragen können, einschließlich aller potenziellen Aliase, um das zuverlässige Verhalten der Firewallregel zu gewährleisten. Wenn Ihre VMs CNAMEs abfragen, die nicht in der Firewallregel für ausgehenden Traffic konfiguriert sind, funktioniert die Richtlinie möglicherweise während der Änderung der DNS-Einträge nicht.

  • Sie können in Ihren Regeln für Netzwerk-Firewallrichtlinien auch interne Compute Engine-DNS-Namen verwenden. Achten Sie jedoch darauf, dass Ihr Netzwerk nicht für die Verwendung eines alternativen Nameservers in der Serverrichtlinie für ausgehenden Traffic konfiguriert ist.

  • Wenn Sie in den Firewallrichtlinien-Regeln für Ihr Netzwerk benutzerdefinierte Domainnamen hinzufügen möchten, können Sie verwaltete Cloud DNS-Zonen für die Auflösung von Domainnamen verwenden. Achten Sie jedoch darauf, dass Ihr Netzwerk nicht für die Verwendung eines alternativen Nameservers in der Serverrichtlinie für ausgehenden Traffic konfiguriert ist. Weitere Informationen zur Zonenverwaltung finden Sie unter Zonen erstellen, ändern und löschen.

Beschränkungen

Die folgenden Einschränkungen gelten sowohl für eingehende als auch für ausgehende Firewallregeln, die FQDN-Objekte verwenden:

  • FQDN-Objekte unterstützen weder Platzhalter (*) noch Stammdomainnamen der obersten Ebene. Beispielsweise werden *.example.com. und .org nicht unterstützt.

  • FQDN-Objekte sind nicht mit Cloud DNS DNS64 kompatibel. Wenn Sie DNS64 mit FQDN aktivieren, erhalten die VMs keine NAT-übersetzten IPv6-Adressen.

Sie können FQDN-Objekte in Firewallregeln für eingehenden Traffic verwenden. Beim Definieren von FQDN-Objekten für Regeln für eingehenden Traffic müssen Sie die folgenden Einschränkungen berücksichtigen:

  • Ein Domainname kann maximal 32 IPv4-Adressen und 32 IPv6-Adressen auflösen. DNS-Abfragen, die in mehr als 32 IPv4- und 32 IPv6-Adressen aufgelöst werden, werden gekürzt, um nur 32 IPv4- oder IPv6-Adressen dieser aufgelösten IP-Adressen aufzunehmen. Geben Sie daher keine Domainnamen an, die in mehr als 32 IPv4- und IPv6-Adressen in die Firewallregeln für eingehenden Traffic aufgelöst werden.

  • Einige Abfragen von Domainnamen haben je nach Standort des anfragenden Clients eindeutige Antworten. Der Standort, von dem aus die DNS-Auflösung der Firewallrichtlinien-Regel ausgeführt wird, ist die Trusted Cloud Region mit der VM, für die die Firewallrichtlinien-Regel gilt.

  • Verwenden Sie keine Regeln für eingehenden Traffic mit FQDN-Objekten, wenn die Ergebnisse der Domainauflösung sehr variabel sind oder die Auflösung der Domainnamen eine Form des DNS-basierten Load-Balancings verwendet. Viele Google-Domainnamen verwenden beispielsweise ein DNS-basiertes Load-Balancing-Schema.

Sie können FQDN-Objekte in Firewallregeln für ausgehenden Traffic verwenden. Wir empfehlen jedoch, keine FQDN-Objekte mit DNS-A-Einträgen mit einer TTL (Time-to-Live) von weniger als 90 Sekunden zu verwenden.

FQDN-Objekte mit anderen Filtern für Firewallrichtlinien-Regeln verwenden

In einer Firewallrichtlinien-Regel können Sie FQDN-Objekte zusammen mit anderen Quell- oder Zielfiltern definieren.

Informationen zur Funktionsweise von FQDN-Objekten mit anderen Quellfiltern in den Regeln für eingehenden Traffic finden Sie unter Quellen für Regeln für eingehenden Traffic in hierarchischen Firewallrichtlinien und Quellen für Regeln für eingehenden Traffic in Netzwerk-Firewallrichtlinien.

Weitere Informationen zur Funktionsweise von FQDN-Objekten mit anderen Zielfiltern in den Regeln für ausgehenden Traffic finden Sie unter Ziele für Regeln für ausgehenden Traffic.

Domainnamenformat

VPC-Firewalls unterstützen das Domainnamenformat wie in RFC 1035, RFC 1123 und RFC 4343 definiert.

Beachten Sie diese Formatierungsrichtlinien, um Domainnamen zu Firewallrichtlinien-Regeln hinzuzufügen.

  • Der Domainname muss mindestens zwei Labels enthalten, die so beschrieben werden:

    • Jedes Label passt zu regulären Ausdrücken, die nur diese Zeichen enthalten: [a-z]([-a-z0-9][a-z0-9])?..
    • Jedes Label umfasst 1 bis 63 Zeichen.
    • Labels sind mit einem Punkt (.) verkettet.

  • Die maximale codierte Länge des Domainnamens darf 255 Byte (Oktett) nicht überschreiten.

  • Sie können den Firewallrichtlinien-Regeln auch einen internationalisierten Domainnamen (IDN) hinzufügen.

  • Domainnamen müssen im Unicode- oder Punycode-Format vorliegen.

  • Wenn Sie einen IDN im Unicode-Format angeben, wird dieser von der Trusted Cloud Firewall vor der Verarbeitung in das Punycode-Format formatiert. Alternativ können Sie das IDN Converter Tool verwenden, um die Punycode-Darstellung eines IDN abzurufen.

  • Die Trusted Cloud Firewall unterstützt keine entsprechenden Domainnamen in derselben Firewallrichtlinien-Regel. Wenn die Domainnamen in das Punycode-Format konvertiert wurden und sich beide Domainnamen höchstens durch einen abschließenden Punkt unterscheiden, werden sie als äquivalent betrachtet.

FQDN-Ausnahmeszenarien

Wenn Sie FQDN-Objekte in den Firewallrichtlinien-Regeln verwenden, können bei der DNS-Namensauflösung die folgenden Ausnahmen auftreten:

  • Fehlerhafter Domainname: Wenn Sie beim Erstellen einer Firewallrichtlinien-Regel einen oder mehrere Domainnamen mit einem ungültigen Format angeben, erhalten Sie eine Fehlermeldung. Die Firewallrichtlinien-Regel kann nur erstellt werden, wenn alle Domainnamen richtig formatiert sind.

  • Domainname nicht vorhanden (NXDOMAIN): Wenn der Domainname nicht vorhanden ist,ignoriert Trusted Cloud das FQDN-Objekt von der Firewallrichtlinien-Regel.

  • Keine IP-Adressauflösung: Wenn der Domainname nicht in eine IP-Adresse aufgelöst wird, wird das FQDN-Objekt ignoriert.

  • Cloud DNS-Server nicht erreichbar: Wenn kein DNS-Server erreichbar ist, gelten die Firewallrichtlinien-Regeln, die FQDN-Objekte verwenden, nur dann, wenn die zuvor im Cache gespeicherten Ergebnisse der DNS-Auflösung verfügbar sind. Die FQDN-Objekte der Regel werden ignoriert, wenn keine im Cache gespeicherten DNS-Auflösungsergebnisse vorhanden oder die im Cache gespeicherten DNS-Ergebnisse nicht mehr gültig sind.

Nächste Schritte