Software-defined networking with VMware NSX – Part 02 – Logical switching and NAT with Edge Services Gateway

In meiner 3-teiligen Blogserie „Software-defined networking with VMware NSX“ möchte ich euch zeigen, wie man technisch

• VMware NSX in eine vorhandene VMware vSphere Infrastruktur deploy’t
• mittels VMware NSX ein logisches auf VXLAN basierendes isoliertes VM-Netzwerk erstellt
• per VMware NSX ein hochverfügbares virtuelles Edge Services Gateway mit NAT- und Loadbalancer-Funktionalität bereitstellt und konfiguriert

Zusätzlich zum technischen Deployment dieser Funktionen werde ich die einzelnen Basis“rollen“ und -funktionen der beteiligten NSX-Komponenten in jedem Kapitel beim entsprechenden Schritt erläutern. Wer weiterführende Informationen zu den einzelnen Komponenten und möglichen Konzepten benötigt, wird im VMware® NSX for vSphere (NSX-V) Network Virtualization Design Guide fündig.

Im ersten Teil der „Software-defined networking with VMware NSX“ Blogserie haben wir bereits die NSX Infrastrukturkomponenten implementiert. In diesem Kapitel möchte ich euch näher bringen, wie einfach es ist, ein neues logisches Netzwerk für virtuelle Maschinen zu erstellen, wie man ein hochverfügbares Edge Services Gateway ausrollt und deren NAT-Funktion nutzen kann.

 01. Ausgangssituation

Wo stehen wir? Nach Durchführung der Schritte aus dem 1. Blogartikel der Serie sieht unsere VMware NSX Infrastrukturumgebung wie folgt aus:

Alle Voraussetzungen für den „Rollout“ von logischen Netzsegmenten / logischen Switches auf Basis von VXLAN sind erfüllt.

02. Erstellung eines logischen Switches (= VM-Netzwerk auf Basis von VXLAN)

In diesem Absatz möchte ich aufzeigen, wie man ein neues logisches Netz ausrollt und die ersten virtuellen Maschinen in dieses (noch) isolierte logische Netz hängt.

• im WebClient unter „Networking & Security“ – „logische Switches“ – „+“

• Namen (Label) für das logische Netz vergeben (in unserem Beispiel: NAT-Destinations)
• die Transportzone angeben, über die sich das logische Netzsegment „erstrecken“ soll

• wir haben einen „kleinen“ Demosetup und betreiben das NSX-Konstrukt in einem „flachen“ physikalischen Netzkonstrukt darunter. Durch diese komplette logische Trennung von der Physik ist empfohlener Best-Practice „Unicast“
• nach Klicken von „OK“ bekommt der logische Switch bzw. das neu erstellte logische Netzsegment automatisch aus unserem Segment-ID-Pool eine eindeutige ID zugewiesen (z.B. 5000). Nun ist es möglich, innerhalb der entsprechend konfigurierten Transportzone virtuelle Maschinen in unser logisches Netz „NAT-Destinations“ zu „patchen“.

• über den Punkt „Virtuelle Maschinen hinzufügen“ im Menü „logische Switches“ können wir virtuelle Maschinen der ESXi Hosts in dieses Netzwerk patchen

• „Ich hab da mal was vorbereitet…“ In meiner ESXi Umgebung laufen bereits 6 virtuelle Linux-VMs und 3 virtuelle NetApp Simulatoren. Die VMs demolin04-06 „patchen“ wir in unser neues Netzsegment

• Nach erfolgreichem Patching laufen diese VMs im gleichen Netzsegment auf Basis von VXLAN. Die VMs demolin04-06 können sich nun untereinander über alle Hosts hinweg gegenseitig erreichen. Nach „außen“ ist das Netz bisher allerdings isoliert. Dies realisieren wir im nächsten Schritt.

So einfach ist es, neue logische L2-Netze auszurollen. Mit wenigen Klicks ist ein neues Netzsegment gebaut. Vorbei sind die Zeiten von mühseliger Konfiguration von VLANs über mehrere Komponenten hinweg… 🙂 Dieser Mechanismus erleichtert ebenfalls eine Realisierung einer Micro Segmentation. Viele kleine logisch voneinander getrennte Netze, an die flexibel unterschiedlichste Sicherheitsrichtlinien angehängt werden können – ohne den Überblick zu verlieren und den Aufwand ins „Unermessliche“ zu treiben.

03. Deployment eines hochverfügbaren Edge Services Gateways (NSX Edge)

Um die im vorherigen Schritt angelegten logischen Switches / Segmente miteinander zu verbinden, gibt es in NSX 2 Möglichkeiten: Logical Routing per Distributed Logical Router oder Centralized Routing per NSX Edge Services Gateway.

Erläuterung – Distributed Logical Router: Verbindet unterschiedliche virtuelle und physikalische L2 Netzsegmente. Erledigt Layer3 Routingfunktionen im Hypervisor. Optimiert für den Einsatz bei East-West-Traffic. Die Kommunikation zwischen 2 logischen Switches erfolgt innerhalb des Hypervisors und ermöglicht ein „so nahe wie möglich“ Routing. Die „Data Plane“ läuft als Kernelmodul in jedem Hypervisor. Die „Control Plane“ ist eine virtuelle Maschine.

Erläuterung – Edge Services Gateway: Das Edge Services Gateway ist ein virtueller hochverfügbarer „Allrounder“. Es stellt Gateway-Services wie z.B. Routing, Firewalling, DHCP, VPN und Loadbalancing zur Verfügung. Es ist somit optimal für North-South-Traffic. Control-, sowie Data Plane für alle Funktionen laufen innerhalb einer VM bzw. eines hochverfügbaren VM-Clusters.

Eine schöne Basiserläuterung der Funktionen und Unterschiede findet man hier.

In meinem Beispiel möchte ich nun mein logisches Netz direkt nach „außen“ (North-South-Traffic) über ein Edge Services Gateway per NAT-Funktion zur Verfügung stellen. Im ersten Schritt deployen wir ein hochverfügbares Edge Services Gateway auf unser Mgmt/Edge ESXi-Cluster und stellen den Link nach „außen“ her.

• unter „Networking & Security“ – „NSX Edges“ – „+“ – Konfiguration für den Deploymentwizard anstarten

• Edge-Services-Gateway anwählen und einen Namen vergeben

• Kennwort für den „admin“-User vergeben
• Haken für „High Availability aktivieren“ setzen, damit das Edge-Services-Gateway als VM-Cluster eingerichtet wird

• Datacenter auswählen, Appliance Größe auswählen
• über „+“ definieren, auf welchen Ressourcen die einzelnen „Nodes“ des Edge Service Gateway Clusters laufen sollen

• unsere 1. VM soll auf dem demoesx03 laufen

• die Redundanz-VM soll auf dem demoesx04 laufen

• Next

• über „+“ können wir die Schnittstelle nach „außen“ für das Gateway definieren

• Name „External“, „Uplink“ auswählen und über „Verbunden mit“ die Portgruppe des Mgmt/Edge-Services Clusters auswählen, die nach „außen“ geht (in meinem Fall Mgmt-Office)

• über das „+“ unter „Subnetze konfigurieren“ geben wir dem Gateway eine IP im Netz nach „draußen“ -> das Edge-Services-Gateway kann über diese IP dann von „außen“ angesprochen werden

• in meinem Beispiel steht das Edge-Services-Gateway in einem Netz mit vorhandenem Default Gateway und ich gebe dies als weiteren Hop an

• wir definieren, wie die Firewallrichtlinie zum Start aussehen soll und vergeben für die „Clusterkommunikation“ der beiden Edge-Services-VMs „Cluster-IPs“

•  …let’s go…

• auf dem Mgmt/Edge Cluster wird nun automatisiert das Edge Services Gateway Cluster aus 2 VMs deployed

• nach erfolgreicher Bereitstellung ist das Edge Services Gateway jetzt von außen erreichbar (in meinem teamix Konzeptbild z.B. vom „Admin-PC“)

04. Anbindung des logischen Switches an das Edge Services Gateways

Nachdem das Gateway von „außen“ erreichbar ist, verbinden wir es im nächsten Schritt mit unserem angelegten logischen Switch / Netzwerk.

• unter „Logische Switches“ wählen wir unser Netz „NAT-Destinations“ an und klicken auf „NSX Edge hinzufügen“

• wir wählen unser angelegtes „NAT-Edge“ Gateway aus…

• …wählen eine freie virtuelle Schnittstelle des Gateways aus (unser bereits angelegtes „External“ Netz ist zu sehen)

• …vergeben einen Namen, wählen „Intern“ und vergeben dem Edge Services Gateway über „+“ eine IP-Adresse innerhalb des zu verknüpfenden logischen Netzes „NAT-Destinations“

• wir erhöhen die MTU-Size auf 1600 und schließen die Konfiguration mit „Beenden“ ab

• wenn wir in unseren VMs des logischen Switches (demolin04-06) die entsprechende Gateway-IP des Edge Services Gateways vergeben, ist dieses per ping von „innen“ aus diesem Netzsegment erreichbar

05. Konfiguration einer DNAT-Rule im Edge Services Gateways für „Zugriff von außen“

Wir können von „außen“ mit unserem Edge-Gateway kommunizieren und das Edge Services Gateway „intern“ mit unseren VMs des Netzsegmentes. Let’s do some NAT-stuff… Im folgenden Beispiel richten wir eine DNAT-Rule ein, mit der wir durch Angabe von Port 5012 der Edge Services Gateway IP von „außen“ weitergeleitet werden auf einen bestimmten Linux-Gast Port 22 (SSH) „innen“.

• unter „NSX Edges“ – Doppelklick auf unseren angelegten NSX Edge

• „NAT“ – „+“ – „DNAT-Regel hinzufügen“

• Alles was von „External“ auf die „äußere“ IP unseres Edge Services Gateways auf Port 5012 ankommt, soll weitergeleitet werden auf die IP unserer demolin06-VM Port 22

• wir bestätigen mit „OK“

• über „Änderungen veröffentlichen“ schalten wir die neu angelegte Regel aktiv

• im Linux Zielsystem demolin06 noch schnell SSH starten und die Firewall deaktivieren…

• …und von „außen“ per putty erfolgreich über die IP des Edge Services Gateway und den Port 5012 auf die in der DNAT-Rule angegebene IP der Linux-VM und Port 22 zugreifen… Läuft… 😉

06. Überwachung der Zugriffe per Flow Monitoring

Ebenfalls integriert in VMware NSX ist ein Monitoring. Den Traffic der soeben aufgebauten Verbindung würde ich gerne ansehen.

• unter „Flow Monitoring“ – „Konfiguration“ den Flow Monitor „Aktivieren“

• im Reiter „Live-Flow“ über vNIC „Durchsuchen“ unseren demolin06 anwählen und den Live-Monitor „Starten“

• in der putty-Session von „außen“ gebe ich mehrfach den Befehl „hostname“ ein, damit ein bisschen Traffic entsteht…

• …und siehe da, die Session taucht im Live-Monitor auf.

07. Ändern der DNAT-Rule im Edge Services Gateways von SSH zu RDP

Zur Vorbereitung für den 3. Teil der NSX-Blogserie stellen wir die vorhandene DNAT-Rule von SSH um auf RDP und testen den Zugriff.

•  ich installiere in den Linux-Gästen xrdp und starte den entsprechenden Dienst, dass per RDP auf die Linux-VMs des logischen Switches zugegriffen werden kann

• wir bearbeiten die vorhandene DNAT-Rule, ändern den Port von 22 (SSH) auf RDP (Port 3389)…

• …und schalten die Änderung über „Änderungen veröffentlichen“ aktiv

• ein Test von „außen“ zeigt, wir haben alles richtig gemacht 😉

In diesem Blogartikel haben wir gesehen, wie einfach es ist, neue logische VM-Netze auf Basis von VXLAN zu deployen und wie wir über ein hochverfügbares Edge Services Gateway „von außen“ auf diese Netze zugreifen können.

Im 3. Teil der „Software-defined networking with VMware NSX“ Blogserie möchte ich euch näher bringen, wie man mittels Edge Services Gateway ein Load Balancing realisieren kann.

 

– I wish I could be a Virtual Machine –

 

Benjamin Ulsamer

Senior Consultant & Trainer

teamix GmbH

 

PS: Wer selbst erste technische Erfahrungen mit VMware NSX machen möchte, aber nicht die Zeit hat, sich eine eigene Lab-Umgebung zu bauen, der kann dies kostenfrei in den VMware Hands-On-Labs tun. Die entsprechenden Labs sind:

• HOL-SDC-1403 – VMware NSX Introduction (Component Overview, Logical Switching, Logical Routing, Distributed Firewall, Edge Services Gateway)
• HOL-SDC-1425 – VMware NSX Advanced (DHCP Relay, Scale Out L3, L2VPN, Trend Micro Integration, Riverbed Integration)

Series Navigation

<< Software-defined networking with VMware NSX – Part 01 – Deployment of a NSX infrastructureSoftware-defined networking with VMware NSX – Part 03 – Load balancing with Edge Services Gateway >>