{"id":30009,"date":"2019-10-31T21:33:10","date_gmt":"2019-10-31T18:33:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vmware-nsx-dlya-samyh-malenkih-chast-1\/"},"modified":"2019-10-31T21:33:10","modified_gmt":"2019-10-31T18:33:10","slug":"vmware-nsx-dlya-samyh-malenkih-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/vmware-nsx-dlya-samyh-malenkih-chast-1","title":{"rendered":"VMware NSX f\u00fcr die Kleinsten. Teil 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VMware
\n
\nWenn man die Konfiguration einer Firewall betrachtet, sieht man h\u00f6chstwahrscheinlich ein Mosaik aus einer Vielzahl von IP-Adressen, Ports, Protokollen und Subnetzen. So werden klassischerweise Sicherheitsrichtlinien f\u00fcr den Zugriff der Benutzer auf Ressourcen umgesetzt. Zun\u00e4chst bem\u00fcht man sich, Ordnung in der Konfiguration zu halten, doch dann wechseln Mitarbeiter von Abteilung zu Abteilung, Server vervielf\u00e4ltigen sich und \u00e4ndern ihre Rollen, Zugriffe f\u00fcr verschiedene Projekte entstehen dort, wo sie normalerweise nicht erlaubt sind, und so entstehen Hunderte unbekannter Pfade.<\/p>\n

Zu einigen Regeln, wenn man Gl\u00fcck hat, sind Kommentare wie \u201eWurde von Vasja angefordert\u201c oder \u201eDas ist der Zugang zur DMZ\u201c vermerkt. Der Netzwerkadministrator verl\u00e4sst das Unternehmen, und alles wird v\u00f6llig unklar. Dann hat jemand beschlossen, die Konfiguration von Vasja zu bereinigen, und SAP ist ausgefallen, weil Vasja einst diesen Zugang f\u00fcr den Betrieb von produktivem SAP ben\u00f6tigt hat.<\/p>\n

\"VMware
\n
\nHeute werde ich \u00fcber die L\u00f6sung VMware NSX sprechen, die dabei hilft, gezielt Richtlinien f\u00fcr die Netzwerkintegration und -sicherheit anzuwenden, ohne Verwirrung in den Firewall-Konfigurationen. Ich werde zeigen, welche neuen Funktionen im Vergleich zu dem, was VMware zuvor in diesem Bereich hatte, hinzugekommen sind. <\/a><\/noindex><\/p>\n

VMWare NSX \u2013 die Plattform zur Virtualisierung und Sicherstellung von Netzwerkinfrastrukturen. NSX l\u00f6st Aufgaben wie Routing, Switching, Lastverteilung, Firewall und bietet viele weitere interessante Funktionen. <\/p>\n

NSX ist der Nachfolger des eigenen Produkts VMware vCloud Networking and Security (vCNS) sowie des \u00fcbernommenen Nicira NVP.<\/p>\n

Von vCNS zu NSX<\/h3>\n

\nFr\u00fcher hatte der Kunde in der auf VMware vCloud basierenden Cloud eine separate virtuelle Maschine vCNS vShield Edge. Diese diente als Gateway, an dem zahlreiche Netzwerkfunktionen wie NAT, DHCP, Firewall, VPN, Lastverteilung usw. eingerichtet werden konnten. vShield Edge beschr\u00e4nkte die Interaktion der virtuellen Maschine mit der Au\u00dfenwelt gem\u00e4\u00df den im Firewall und NAT festgelegten Regeln. Innerhalb des Netzwerks kommunizierten die virtuellen Maschinen frei innerhalb der Subnetze. Wenn man den Datenverkehr wirklich trennen m\u00f6chte, kann man ein separates Netzwerk f\u00fcr verschiedene Teile der Anwendungen (verschiedene virtuelle Maschinen) erstellen und die entsprechenden Regeln f\u00fcr ihr Netzwerkinteraktion im Firewall festlegen. Dies ist jedoch zeitaufwendig, kompliziert und wenig interessant, insbesondere wenn man mehrere Dutzend virtuelle Maschinen hat.<\/p>\n

In NSX hat VMware das Konzept der Mikrosegmentierung durch eine verteilte Firewall implementiert, die im Kern des Hypervisors integriert ist. Darin werden Sicherheits- und Netzwerkinteraktionsrichtlinien nicht nur f\u00fcr IP- und MAC-Adressen, sondern auch f\u00fcr andere Objekte wie virtuelle Maschinen und Anwendungen festgelegt. Wenn NSX innerhalb einer Organisation bereitgestellt wird, k\u00f6nnen solche Objekte beispielsweise ein Benutzer oder eine Benutzergruppe aus Active Directory sein. Jedes dieser Objekte wird zu einem Mikrosegment in seinem eigenen Sicherheitsbereich, im gew\u00fcnschten Subnetz, mit seiner eigenen gem\u00fctlichen DMZ :). <\/p>\n

\"VMware
\nFr\u00fcher gab es einen einzigen Sicherheitsperimeter f\u00fcr das gesamte Ressourcenset, der von einem Grenz-Switch gesch\u00fctzt wurde. Mit NSX ist es m\u00f6glich, sogar innerhalb eines Netzwerks eine separate virtuelle Maschine vor unerw\u00fcnschten Interaktionen abzugrenzen. <\/i><\/p>\n

Sicherheits- und Netzwerkinteraktionen passen sich an, wenn ein Objekt in ein anderes Netzwerk wechselt. Wenn wir beispielsweise eine Datenbankmaschine in ein anderes Netzwerksegment oder sogar in ein anderes verbundenes virtuelles Rechenzentrum verschieben, bleiben die f\u00fcr diese virtuelle Maschine festgelegten Regeln unabh\u00e4ngig von ihrem neuen Standort weiterhin g\u00fcltig. Der Anwendungsserver kann weiterhin mit der Datenbank interagieren.<\/p>\n

Der vorherige Grenzgateway vCNS vShield Edge wurde durch NSX Edge ersetzt. Dieses bietet die gesamte Funktionalit\u00e4t des alten Edge sowie einige neue n\u00fctzliche Funktionen. Darum wird es im Folgenden gehen.<\/p>\n

Was ist neu bei NSX Edge?<\/h3>\n

\nDie Funktionalit\u00e4t von NSX Edge h\u00e4ngt von der Version<\/a><\/noindex> NSX ab. Insgesamt gibt es f\u00fcnf: Standard, Professional, Advanced, Enterprise, Plus Remote Branch Office. Neuheiten und interessante Funktionen sind erst ab Advanced verf\u00fcgbar. Dazu geh\u00f6rt auch die neue Benutzeroberfl\u00e4che, die bis zum vollst\u00e4ndigen Wechsel von vCloud auf HTML5 (VMware verspricht Sommer 2019) in einem neuen Tab ge\u00f6ffnet wird.<\/p>\n

Firewall.<\/b> Als Objekte, auf die die Regeln angewendet werden, k\u00f6nnen IP-Adressen, Netzwerke, Gateway-Schnittstellen und virtuelle Maschinen ausgew\u00e4hlt werden. <\/p>\n

\"VMware
\n
\n\"VMware
\n
\nDHCP.<\/b> Neben der Konfiguration des IP-Adressbereichs, der automatisch an virtuelle Maschinen in diesem Netzwerk zugewiesen wird, stehen in NSX Edge neue Funktionen zur Verf\u00fcgung. Bindung<\/b> und Relay<\/b>.<\/p>\n

Im Tab Bindings<\/b> Es ist m\u00f6glich, die MAC-Adresse einer virtuellen Maschine an eine IP-Adresse zu binden, wenn die IP-Adresse nicht ge\u00e4ndert werden soll. Wichtig ist, dass diese IP-Adresse nicht im DHCP-Pool enthalten ist.<\/p>\n

\"VMware
\n
\nIm Tab Relay<\/b> Es wird die Weiterleitung von DHCP-Nachrichten an DHCP-Server, die au\u00dferhalb Ihrer Organisation in vCloud Director liegen, einschlie\u00dflich DHCP-Server der physischen Infrastruktur, konfiguriert. <\/p>\n

\"VMware
\n
\nRouting.<\/b> Bei vShield Edge konnte nur statisches Routing konfiguriert werden. Jetzt steht dynamisches Routing mit Unterst\u00fctzung f\u00fcr die Protokolle OSPF und BGP zur Verf\u00fcgung. Auch ECMP (Active-active) Einstellungen sind verf\u00fcgbar, was ein Failover im aktiven aktiven Modus auf physische Router erm\u00f6glicht.<\/p>\n

\"VMware
\nOSPF-Konfiguration<\/i><\/p>\n

\"VMware
\nBGP-Konfiguration<\/i><\/p>\n

Eine weitere Neuerung ist die Konfiguration der Weitergabe von Routen zwischen verschiedenen Protokollen.
\nRoutenredistribution. <\/p>\n

\"VMware
\n
\nL4\/L7 Lastenausgleich.<\/b> X-Forwarded-For f\u00fcr den HTTPs-Header wurde eingef\u00fchrt. Ohne ihn war alles problematisch. Zum Beispiel haben Sie eine Website, die Sie mit einem Load Balancer ausgleichen. Ohne diesen Header funktioniert alles, aber in den Statistiken des Webservers sehen Sie nicht die IPs der Besucher, sondern die IP des Load Balancers. Jetzt ist alles korrekt. <\/p>\n

Im Reiter Application Rules k\u00f6nnen nun auch Skripte hinzugef\u00fcgt werden, die direkt die Lastenverteilung des Traffics steuern.<\/p>\n

\"VMware
\n
\nVPN. <\/b>Zus\u00e4tzlich zu IPSec VPN unterst\u00fctzt NSX Edge:<\/p>\n