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

This entry is part [part not set] of 3 in the series Software-defined networking with VMware NSX

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:

NSX-Konzept-002411

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.

NSX-Konzept-002412

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

NSX-NAT-001797

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

NSX-NAT-001798

NSX-NAT-001799

  • 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“.

NSX-NAT-001800

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

NSX-NAT-001801

  • „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

NSX-NAT-001802

NSX-NAT-001803

NSX-NAT-001804

  • 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.

NSX-002635Erlä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.

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

NSX-002636

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.

NSX-Konzept-002413

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

NSX-NAT-001805

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

NSX-NAT-001806

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

NSX-NAT-001807

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

NSX-NAT-001808

  • unsere 1. VM soll auf dem demoesx03 laufen

NSX-NAT-001809

  • die Redundanz-VM soll auf dem demoesx04 laufen

NSX-NAT-001810

NSX-NAT-001811

  • Next

NSX-NAT-001812

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

NSX-NAT-001814

  • 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)

NSX-NAT-001815

NSX-NAT-001816

  • ü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

NSX-NAT-001817

NSX-NAT-001818

NSX-NAT-001819

NSX-NAT-001820

NSX-NAT-001821

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

NSX-NAT-001822

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

NSX-NAT-001823

  •  …let’s go…

NSX-NAT-001824

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

NSX-NAT-001825

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

NSX-NAT-001848

NSX-NAT-001849

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.

NSX-Konzept-002414

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

NSX-NAT-001850

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

NSX-NAT-001851

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

NSX-NAT-001852

  • …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“

NSX-NAT-001853

NSX-NAT-001854

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

NSX-NAT-001855

NSX-NAT-001856

  • 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

NSX-NAT-001857

NSX-NAT-001858

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“.

NSX-Konzept-002416

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

NSX-NAT-001859

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

NSX-NAT-001860

NSX-NAT-001861

NSX-NAT-001862

  • 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

NSX-NAT-001863

NSX-NAT-001864

  • wir bestätigen mit „OK“

NSX-NAT-001865

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

NSX-NAT-001866

NSX-NAT-001867

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

NSX-NAT-001868

  • …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… 😉

NSX-NAT-001869

NSX-NAT-001870

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“

NSX-NAT-001871

NSX-NAT-001872

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

NSX-NAT-001873

NSX-NAT-001874

NSX-NAT-001875

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

NSX-NAT-001876

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

NSX-NAT-001877

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

NSX-NAT-RDP-001878

NSX-NAT-RDP-001879

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

NSX-NAT-RDP-001880

NSX-NAT-RDP-001881

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

NSX-NAT-RDP-001882

NSX-NAT-RDP-001883

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

NSX-NAT-RDP-001884

NSX-NAT-RDP-001885

NSX-NAT-RDP-001886

NSX-NAT-RDP-001887

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

Benjamin Ulsamer

Benjamin Ulsamer ist seit Januar 2011 für die Firma Proact Deutschland GmbH tätig. Er startete als Senior Consultant & Trainer und war Teamlead im Bereich Virtualisierung. Im Oktober 2015 wurde er zum Manager Professional Services Region South ernannt. Seit Juni 2017 ist er verantwortlich für die IT-Ausbildung. In den Jahren 2015, 2016 und 2017 hat er für sein Engagement bzgl. Blogging & Wissensvermittlung von VMware die Auszeichnung zum vExpert erhalten. Seit 2021 ist er zudem mit verantwortlich für das Marketing von Proact.

 
Kommentare

Noch keine Kommentare vorhanden.

Hinterlassen Sie einen Kommentar