VPC Networking mit VCF NSX

This post is also available in: Englisch

Mit der Version 4.0 von NSX, (dem Network Stack in VMware Cloud Foundation) wurde die Mandantenfähigkeit mittels Projekten eingeführt und kurze Zeit später um VPCs erweitert.

Die Einführung von VPCs (Virtual Private Cloud) auf der Netzwerkebene stellt einen “Self-Service” für Netzwerk, Security und weiteren Netzwerk Diensten, in einer isolierten Umgebung, zur Verfügung. Die VPC Verantwortlichen können (innerhalb ihrer Grenzen) Netzwerke und Sicherheitsregeln erstellen und  entlasten so die Netzwerk und Security Teams. Außerdem ermöglicht es kürzere Bereitstellungszeiten neuer Services durch die VPC Eigentümer.

Das Netzwerk und Security Team kann auf Projekt- bzw. auf der globalen Ebene in NSX, Leitplanken für die VPCs definieren und bestimmen welche Ressourcen genutzt werden dürfen.

Verschiebung der Verantwortlichkeiten

Durch das VPC Konstrukt wird die Verantwortung der Netzwerkverwaltung, Netzwerksicherheit und weiterer Services and den oder die VPC-Eigentümer abgegeben. 
Aber…!!! Der VPC-Eigentümer ist nicht zwingend ein Netzwerk- oder Sicherheits- Experte…

Keiner möchte, dass die gesamte Netzwerkinfrastruktur zum erliegen kommt oder man in der Presse mit einem Sicherheitsvorfall landet, weil versehentlich Veränderungen an der Netzwerk Infrastruktur vorgenommen wurden.
Damit die Vorteile eines VPCs genutzt werden können aber gleichzeitig die Infrastruktur nicht gefährdet wird, müssen entsprechende Sicherheitsvorkehrungen getroffen werden.
Hinzu kommt, dass es für den VPC Eigentümer so einfach wie möglich sein muss die Netzwerkanforderungen selbständig zu konfigurieren.
Wäre es nicht schön, wenn man gewisse Aufgaben an die Applikationsverantwortlichen abgeben könnte?

NSX Networking für VMware Cloud Foundation – kurz erklärt

NSX ist Bestandteil der VMware Cloud Foundation von Broadcom und stellt das virtuelle Netzwerk für die private Cloud zur Verfügung.

Durch den Einsatz von NSX werden virtuelle Routing-Funktionalitäten auf den ESX Hosts bereitgestellt (DR – Distributed Router) die für die Kommunikation zwischen den VMs zuständig ist.

Die Kommunikation von VMs auf verschiedenen Hosts erfolgt über Geneve Tunel (Gelb hinterlegt), die unterliegende Netzwerk Infrastruktur sieht “nur” die Geneve Tunel Endpunkte der einzelnen ESXi Server, aber nicht die Kommunikation der Virtuellen Maschinen. 

Die Kommunikation in externe Netze erfolgt über die NSX EDGE, die den Geneve Tunel entfernt und mittels Routing-Protokollen (oder mit statischem Routing) die inneren Netze, nach außen propagiert.

Zusätzlich kann über das VMware vDefend Firewall AddOn eine L4-7 Firewall vor jeder einzelne VM und auf den Gateways aktiviert werden. 

!!!Das Schaubild ist eine High Level Sicht und hat keinen Anspruch auf Vollständigkeit. Es soll lediglich dazu dienen den grundsätzlichen Aufbau zu verstehen, der für die Bildung der VPCs benötigt wird!!!

Logisch ergibt sich daraus folgendes Bild:

• Die virtuellen Maschinen sind an einem Segment angeschlossen, was das jeweilige Subnet repräsentiert.
• Die Segmente sind in der Regel an einem Tier-1 Gateway angeschlossen, der das lokale Routing zwischen den Segmenten übernimmt.
• Das Tier-1 Gateway macht das distributed routing lokal auf den ESX Servern und kann auch weitere Services wie NAT, Firewall und DHCP zur Verfügung stellen. Außerdem tauscht es die Routinginformationen mit dem Tier-0 Gateway aus. Es können mehrere Tier-1 Gateways an einem Tier-0 Gateway angeschlossen werden.
• Das Tier-0 Gateway stellt die Verbindung (mittels der NSX Edge siehe Bild 1) zu dem externen Router her und dort werden die Parameter für das Routing festgelegt.

Projekte und VPCs in NSX

Durch die Einführung von Projekten und VPCs ergeben sich neue Rollen, die unterschiedliche Zugriffs Rechte auf die virtuelle Netzwerk Struktur haben.

In der aktuellen VCF(5.2)/NSX(4.2) Version wird für die Erstellung eines VPCs ein Projekt benötigt. Auf der VMware Explore 2024 wurde unter anderem angekündigt, dass in VCF 9 auch Native VPCs erstellt werden können. -> https://news.broadcom.com/de/releases/vmware-explore-2024-vmware-cloud-foundation

Die nachfolgend beschriebenen Rollen können auch anders gelebt werden und verschiedene Rollen könnten auch von einem Team übernommen werden.

NSX Enterprise Admin

Der Enterprise Admin hat Zugriff auf alle Objekte in NSX und ist verantwortlich für die Router Konfiguration zu dem externen Netzwerk. Zusammen mit dem Netzwerk Team wird festgelegt, welche Routingprotokolle genutzt werden, welche IP Addressräume in der Private Cloud verwendet werden dürfen und erstellt zusammen mit dem Sicherheitsteam die grundsätzlichen Sicherheitsregeln auf. Der Enterprise Admin sollte über ausreichend Netzwerk- und Security- Wissen verfügen und optimaler weise eng mit den jeweiligen Teams zusammen arbeiten. 

Zusätzlich verwaltet der Enterprise Admin die einzelnen Projekte (Tenants). Für ein Projekt sollten folgende Einstellungen vorgenommen werden:

• Erstellung von Qoutas (Wieviel Resourcen stehen dem Projekt zur Verfügung? Networking, Security, Inventory,etc.)
• Projekt Name
• Zuweisung der User/User Groups die auf das Projekt zugreifen können
• Festlegung über welches Gateway(s) das Projekt nach außen kommunizieren kann
• Festlegung der externen IP Bereiche aus dem sich die VPCs in dem Projekt bedienen können
• Log Identifier (um die VMs im Log eindeutig identifizieren zu können) 

Projekt Admin

Der Projekt Admin kann die vom Enterprise Admin zugewiesenen Resourcen (Externer Router, Externe IP Addressräume) nutzen, aber nicht verändern. Anders als bei einem VPC besteht aber trotzdem die Möglichkeit auf dieser Ebene zusätzliche Konfigurationen vorzunehmen die zwingend mit dem Enterprise Admin abgesprochen werden müssen.

Der Projekt Admin verwaltet die VPCs seines Projektes. Folgende Aufgaben werden für die Erstellung des VPCs durchgeführt:

• Erstellung von Qoutas (Wieviel Resourcen stehen dem jeweiligen VPC zur Verfügung? Networking, Security)
•  VPC Name
• Zuweisung der User/User Groups die auf das VPC zugreifen können
• Zuweisung über welches Gateway das VPC nach außen kommunizieren kann (natürlich sind nur die Gateways verfügbar, die dem Projekt zugeordnet wurden)
• Zuweisung der externen IP Bereiche aus dem sich das VPC bedienen kann
• Festlegung von privaten IP Bereichen (für die VMs, die nicht von extern erreichbar sein müssen)
• DHCP Service (Falls gewünscht. Entweder über das NSX Management oder externer DHCP Server)
• zusätzliche Services wie Default Outbound NAT für alle VMs in den privaten Netzen, Default Firewall Regeln, Einbindung des NSX Advanced Load Balancers.
• Grundsätzliche Switch Einstellung (QoS, IP Discovery, MAC Discovery, etc.)

VPC Nutzer

Der VPC Nutzer kann in seinem VPC, Netzwerksegmente (virtueller Switch) anlegen und sieht welche Virtuellen Maschinen an den Netzwerksegmenten angeschlossen sind.

Mit dem VMware vDefend Firewall AddOn können Firewall Regeln innerhalb des VPCs erstellt werden, sowie eingehende und ausgehende Firewall Regeln. Firewall Regeln die auf der Globalen Ebene erstellt wurden, gelten vor den VPC Firewall Regeln.

Der VPC Nutzer kann bei der Erstellung eines Segmentes zwischen 3 Netzwerktypen wählen:

• Isolated – Es besteht keine Verbindung zu einem Router und das IP Netz kann frei erstellt werden
• Private – Das Segment erhält ein IP Subnetz aus dem privaten IP Address Raum. Der VPC Admin wählt die Anzahl der benötigten IP Adressen aus einem Dropdown Menü aus und NSX konfiguriert die entsprechende Subnetmaske und das Default Gateway automatisch. Die VMs an einem Private Segment sind nur nur innerhalb des VPCs erreichbar. Kommunikation nach außen ist über NAT möglich. Dafür wird aus dem Externen IP Address Raum eine IP Adresse pro VPC genutzt. Die NAT Einstellungen erfolgen automatisch. Es ist aber auch möglich eigene NAT Regeln sowohl eingehend als auch ausgehend in dem VPC zu erstellen.
• Public – Das Segment erhält ein IP Subnetz aus dem externen IP Address Raum. Auch hier wählt der VPC Admin die Anzahl der benötigten IP Adressen aus einem Dropdown Menü aus. Die VMs an einem Public Segment können ohne NAT nach außen kommunizieren und von Außen erreicht werden.

Zusammenfassung

Durch die Einführung von NSX VPCs, können Unternehmen ihren internen Kunden ein Networking as a Service Model anbieten. Damit können die Administratoren Teams entlastet und den Anwendern mehr Flexibilität gegeben werden, was dazu beiträgt business relevante Services schneller bereit stellen zu können.

Durch klare Strukturen und Rollen, ist gewährleistet das die Endanwender zwar die Resourcen nutzen, aber nicht durch fehlerhafte Eingaben beschädigen können.

Next Steps

In meinem nächsten Blog Eintrag https://vrealize.it/de/2025/02/14/vcf-nsx-vpc-configuration-step-by-step-guide/ ist eine Step by Step Anleitung, um sowohl das VPC in NSX aufzusetzen und gleichzeitig  einen Nutzer im vCenter Zugriff auf die im zugeordneten Netze zu geben.

Ein Blogeintrag mit Automation ist auch schon in Planung und wird spätestens Anfang März veröffentlicht

Stay tuned – Sobald VCF 9 verfügbar ist, werde ich einen weiteren Artikel zu den Veränderungen in NSX erfassen.