Wenn eine NSX VPC erfolgreich realisiert wurde, erstellt das System vertikale und horizontale Standard-Firewallregeln, um das Standard-Firewallverhalten für die Arbeitslasten zu steuern, die in der NSX VPC ausgeführt werden.

Bei vertikalen Firewallregeln handelt es sich um zentralisierte Regeln, die für eingehenden und ausgehenden Datenverkehr der NSX VPC gelten.

Horizontale Firewallregeln sind verteilte Regeln, die für innerhalb der NSX VPC ausgeführte Arbeitslasten gelten.

Horizontale Standard-Firewallregeln in einer NSX VPC

Für jede im Projekt hinzugefügte NSX VPC erstellt das System eine horizontale Standard-Firewallrichtlinie in der NSX VPC. Die folgende Benennungskonvention wird verwendet, um die horizontale Standardrichtlinie in einer NSX VPC zu identifizieren:

ORG-default PROJECT-<Project_Name> VPC-<VPC_Name> default-layer3-section

Project_Name und VPC_Name werden durch tatsächliche Werte im System ersetzt.

Die folgende Bildschirmaufnahme zeigt beispielsweise die horizontalen Standard-Firewallregeln in einer NSX VPC.


Bildschirmaufnahme wird im umgebenden Text beschrieben.

Für alle drei horizontalen Standard-Firewallregeln in einer NSX VPC ist die Option Angewendet auf auf DFW festgelegt. Obwohl die Option Angewendet auf auf DFW festgelegt ist, werden die Firewallregeln nur auf den Arbeitslast-VMs erzwungen, die mit den Subnetzen in der NSX VPC verbunden sind. Arbeitslast-VMs, die sich außerhalb der NSX VPC befinden, sind von diesen Firewallregeln nicht betroffen. Bei Bedarf können VPC-Benutzer die Option Angewendet auf auf Gruppen festlegen und nur die Gruppen auswählen, die in der NSX VPC erstellt wurden.

Gehen wir auf die Bedeutung der drei horizontalen Standardregeln ein, wie in dieser Bildschirmaufnahme dargestellt:
  • Regel 1033 lässt den gesamten ausgehenden Datenverkehr aus den Subnetzen in der NSX VPC zu. Das Ziel des ausgehenden Datenverkehrs können Arbeitslasten innerhalb der NSX VPC oder außerhalb der VPC sein. Sie können diese Standardregel bei Bedarf ändern.
  • Regel 1034 lässt den gesamten DHCP-Datenverkehr zu. Sie können diese Standardregel bei Bedarf ändern.
  • Regel 1035 verwirft den gesamten Datenverkehr, der nicht mit den vorherigen beiden Regeln übereinstimmt. Diese Regel bedeutet implizit, dass der gesamte eingehende Datenverkehr zur NSX VPC standardmäßig verworfen wird. Sie können nur die Regelaktion dieser Standardregel ändern. Alle anderen Felder in dieser Regel können nicht bearbeitet werden.

Vertikale Standard-Firewallregel in einer NSX VPC

Für jede im Projekt hinzugefügte NSX VPC erstellt das System eine vertikale Standard-Firewallrichtlinie in der NSX VPC. Die folgende Bildschirmaufnahme zeigt beispielsweise die vertikale Standardrichtlinie in einer NSX VPC. Sie enthält nur eine einzige Firewallregel.


Bildschirmaufnahme wird im umgebenden Text beschrieben.

Die Firewallregel lässt standardmäßig den gesamten Datenverkehr über die VPC-N-S-Firewall zu. Sie können nur die Regelaktion dieser Standardregel ändern. Alle anderen Felder in dieser Regel können nicht bearbeitet werden. Sie können jedoch benutzerdefinierte vertikale Firewallregeln hinzufügen, um den eingehenden oder ausgehenden Datenverkehr je nach Ihren Sicherheitsanforderungen einzuschränken.

Kommunikation innerhalb einer NSX VPC

Standardmäßig ist der horizontale Datenverkehr zwischen Arbeitslasten innerhalb einer NSX VPC zulässig.

Das folgende Diagramm zeigt beispielsweise drei Arbeitslast-VMs in einer NSX VPC. Standardmäßig kann VM 1 im öffentlichen Subnetz in beide Richtungen mit VM 2 im privaten Subnetz kommunizieren.

Standardmäßig können VMs in isolierten Subnetzen nicht mit VMs in privaten oder öffentlichen Subnetzen kommunizieren. In diesem Diagramm ist VM 2 im privaten Subnetz jedoch auch mit dem isolierten Subnetz verbunden. Daher kann VM 2 im privaten Subnetz in beide Richtungen mit VM 3 im isolierten Subnetz kommunizieren.


Diagramm wird im umgebenden Text beschrieben.

Egress-Kommunikation von einer NSX VPC

Wie bereits in diesem Thema erläutert, ist der gesamte ausgehende Datenverkehr von einer NSX VPC standardmäßig zulässig.

Mit öffentlichen Subnetzen verbundene Arbeitslasten können Pakete außerhalb der NSX VPC senden. Dabei ist es unerheblich, ob die Option N-S-Dienste für die NSX VPC aktiviert oder deaktiviert ist. Den Arbeitslasten in öffentlichen Subnetzen werden IP-Adressen aus den externen IPv4-Blöcken der NSX VPC zugewiesen. Die externen IP-Adressen sind außerhalb der NSX VPC erreichbar.

Mit privaten Subnetzen verbundene Arbeitslasten können Pakete außerhalb der NSX VPC nur dann senden, wenn die folgenden Bedingungen erfüllt sind:

  • Die Option N-S-Dienste ist für die NSX VPC aktiviert.
  • Die Option Standard NAT ausgehende ist für die NSX VPC aktiviert.

Wenn die Option NSX VPCNSX VPC weitergeleitet wird. Wenn diese Option deaktiviert ist, wird die SNAT-Standardregel nicht erstellt und der Datenverkehr aus den privaten Subnetzen kann nicht außerhalb der NSX VPC weitergeleitet werden.

Das folgende Diagramm zeigt beispielsweise eine NSX VPC, auf der die OptionStandard NAT ausgehend deaktiviert ist. Der Datenverkehr von VM 1 im öffentlichen Subnetz kann direkt an Benutzer 1.1.1.1 gehen, der sich außerhalb der NSX VPC befindet. Der Egress-Datenverkehr von VM 2 im privaten Subnetz wird jedoch blockiert.


Diagramm wird im umgebenden Text beschrieben.

Das folgende Diagramm zeigt eine NSX VPC, auf der die Option Standard NAT ausgehend aktiviert ist. In diesem Fall konfiguriert das System automatisch eine Standard-SNAT-Regel für die N-S-Firewall der VPC. Die IP-Adresse von VM 2 im privaten Subnetz wird in eine externe IP übersetzt, die vom System aus dem externen IPv4-Block zugeteilt wird. VM 2 im privaten Subnetz kann jetzt Datenverkehr an Benutzer 1.1.1.1 senden, der sich außerhalb der NSX VPC befindet. VM 1 im öffentlichen Subnetz kann weiterhin Datenverkehr außerhalb der NSX VPC senden, ohne NAT in der VPC-N-S-Firewall zu durchlaufen.


Diagramm wird im umgebenden Text beschrieben.

Ingress-Kommunikation in eine NSX VPC

Wie bereits zuvor in diesem Thema erwähnt, verwirft die horizontale Standardregel (Regel 1035) den gesamten eingehenden Datenverkehr in die NSX VPC.

Eingehender Datenverkehr in die NSX VPC kann einer der folgenden Datenverkehrsarten sein:
  • Datenverkehr von Arbeitslasten, die in anderen NSX-VPCs ausgeführt werden, die sich entweder im selben oder in einem anderen Projekt befinden.
  • Datenverkehr von Arbeitslasten, die in einem beliebigen Netzwerk innerhalb des Datencenters ausgeführt werden.
  • Datenverkehr aus dem Internet.

Das folgende Diagramm zeigt beispielsweise, dass der Datenverkehr von Benutzer 1.1.1.1, der mit einem Tier-0-/VRF-Gateway verbunden ist, daran gehindert wird, VM 1 im öffentlichen Subnetz und VM 2 im privaten Subnetz zu erreichen.


Diagramm wird im umgebenden Text beschrieben.

Damit eingehender Datenverkehr von außerhalb der NSX VPC die Arbeitslasten in den öffentlichen Subnetzen erreichen kann, müssen Sie eine benutzerdefinierte horizontale Firewallrichtlinie hinzufügen oder die horizontale Regel in der Standard-Firewallrichtlinie der NSX VPC ändern. Beachten Sie, dass die vertikale Standardregel in der NSX VPC standardmäßig den gesamten Datenverkehr über die VPC-N-S-Firewall zulässt.

Hinweis: VPC-Benutzern wird empfohlen, benutzerdefinierte vertikale Firewallregeln in ihren NSX VPC hinzuzufügen, um eingehenden Datenverkehr je nach ihren Sicherheitsanforderungen nur auf bestimmte Ports zu beschränken.

Um zuzulassen, dass eingehender Datenverkehr von außerhalb der NSX VPC Arbeitslasten in den privaten Subnetzen erreicht, führen Sie die folgenden Schritte aus:

  1. Stellen Sie sicher, dass die Option N-S-Dienste für die NSX VPC aktiviert ist.
  2. Fügen Sie eine NAT-Regel mit reflexiver Aktion oder DNAT-Aktion in der NSX VPC hinzu.

    Teilen Sie in der NAT-Regel eine gültige IPv4-Adresse aus dem externen IPv4-Block zu, damit das System die IP-Adresse der VM im privaten Subnetz dieser externen IPv4-Adresse zuordnen kann. Wenn Sie beispielsweise eine NAT-Regel mit reflexiver Aktion erstellen, geben Sie die externe IPv4-Adresse im Textfeld Übersetzte IP der Regeldefinition an. Die IPv4-Adresse muss zum externen IPv4-Block der NSX VPC gehören und für die Zuteilung verfügbar sein. Andernfalls wird eine Fehlermeldung angezeigt. Derzeit wird im Textfeld Übersetzte IP nur eine einzelne IPv4-Adresse unterstützt. Ein CIDR-Block wird nicht unterstützt.

    Führen Sie diesen Schritt aus, um eingehenden Datenverkehr für jede Arbeitslast-VM zu aktivieren, die an das private Subnetz angehängt ist. Wenn beispielsweise vier Arbeitslast-VMs an das private Subnetz angehängt sind, erstellen Sie vier separate NAT-Regeln.

  3. Fügen Sie eine benutzerdefinierte horizontale Firewallrichtlinie hinzu oder ändern Sie die horizontale Regel in der Standard-Firewallrichtlinie der NSX VPC, damit Datenverkehr die Arbeitslasten in den privaten Subnetzen erreichen kann.

Nach Abschluss dieser Schritte ist der gesamte eingehende Datenverkehr nun für die Arbeitslasten der privaten Subnetze zulässig. Wie im vorherigen Unterabschnitt erwähnt, wird VPC-Benutzern empfohlen, benutzerdefinierte vertikale Firewallregeln in ihren NSX VPC hinzuzufügen, um eingehenden Datenverkehr je nach ihren Sicherheitsanforderungen auf bestimmte Ports zu beschränken.

Das folgende Diagramm zeigt beispielsweise, dass der Datenverkehr von Benutzer 1.1.1.1, der mit einem Tier-0-/VRF-Gateway verbunden ist, NAT in der VPC-N-S-Firewall durchläuft und dann VM 2 im privaten Subnetz erreicht.

In diesem Beispiel lautet die Konfiguration der NAT-Regel wie folgt:

  • Quell-IP: 10.5.0.5 (private IP-Adresse von VM 2)
  • Übersetzte IP: 5.5.100.100 (IP-Adresse aus dem externen IPv4-Adressblock, der VM 2 zugeteilt ist)
  • Aktion: Reflexiv

Diagramm wird im umgebenden Text beschrieben.