{"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\/en\/blog\/vmware-nsx-dlya-samyh-malenkih-chast-1","title":{"rendered":"VMware NSX for Beginners, Part 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VMware
\n
\nIf you look at the configuration of any firewall, you will likely see a sheet full of IP addresses, ports, protocols, and subnets. This is how network security policies are traditionally implemented for user access to resources. Initially, the configuration is organized, but then employees start moving from department to department, servers proliferate and change their roles, access is granted for different projects where it shouldn't be, resulting in hundreds of unknown convoluted paths.<\/p>\n

Regarding some rules, if you're lucky, there are comments like 'Requested by Vasya' or 'This is a pass in the DMZ.' The network administrator leaves, and everything becomes completely unclear. Then someone decided to clean up the configuration from Vasya's requests, and SAP fell, because at one time, Vasya requested that access to work with the production SAP.<\/p>\n

\"VMware
\n
\nToday, I will talk about the VMware NSX solution that helps to apply network interaction and security policies precisely without the chaos in firewall configurations. I will show you what new features have been added compared to what VMware offered earlier in this area. <\/a><\/noindex><\/p>\n

VMware NSX is a platform for virtualization and securing network services. NSX addresses routing, switching, load balancing, firewalling, and has many other interesting capabilities. <\/p>\n

NSX is the successor of VMware's own product vCloud Networking and Security (vCNS) and the acquired Nicira NVP.<\/p>\n

From vCNS to NSX<\/h3>\n

\nPreviously, the client had a separate virtual machine vCNS vShield Edge in a cloud built on VMware vCloud. It served as a boundary gateway, where many network functions could be configured: NAT, DHCP, Firewall, VPN, load balancer, and more. vShield Edge restricted a virtual machine's interaction with the outside world according to the rules set in the Firewall and NAT. Within the network, virtual machines communicated freely with each other within subnets. If you really want to control traffic, you can create a separate network for different parts of applications (various virtual machines) and set corresponding rules in the firewall for their network interaction. But this is long, complicated, and tedious, especially when you have several dozen virtual machines.<\/p>\n

In NSX, VMware has implemented the concept of micro-segmentation through a distributed firewall that is built into the hypervisor kernel. Security and network interaction policies are defined not only for IP and MAC addresses but also for other objects: virtual machines and applications. If NSX is deployed within an organization, objects can even include users or groups from Active Directory. Each of these objects becomes a micro-segment in its security perimeter, within the necessary subnet, complete with its own cozy DMZ.:) <\/p>\n

\"VMware
\nPreviously, there was a single security perimeter for the entire resource pool, protected by an edge switch. With NSX, it's possible to isolate a single virtual machine from unnecessary interactions even within the same network. <\/i><\/p>\n

Security and networking policies adapt if an object moves to another network. For example, if we migrate a database machine to a different network segment or even to another associated virtual data center, the rules specified for that virtual machine continue to apply regardless of its new location. The application server will still be able to interact with the database.<\/p>\n

The previously used edge gateway vCNS vShield Edge has been replaced by NSX Edge. It includes all the features of the old Edge plus several new useful functions. The discussion will focus on these.<\/p>\n

What's new in NSX Edge?<\/h3>\n

\nThe functionality of NSX Edge depends on the edition<\/a><\/noindex> of NSX. There are five editions: Standard, Professional, Advanced, Enterprise, Plus Remote Branch Office. All new and interesting features can only be seen starting from the Advanced edition. This includes the new interface, which will open in a new tab until the full transition of vCloud to HTML5 (VMware promises summer 2019).<\/p>\n

Firewall.<\/b> As objects to which rules will apply, you can select IP addresses, networks, gateway interfaces, and virtual machines. <\/p>\n

\"VMware
\n
\n\"VMware
\n
\nDHCP.<\/b> In addition to configuring the IP address range that will be automatically assigned to virtual machines in this network, NSX Edge now includes features for Binding<\/b> and Relay<\/b>.<\/p>\n

In the tab Bindings<\/b> you can bind a virtual machine's MAC address to an IP address if you want the IP address to remain unchanged. The only condition is that this IP address must not be part of the DHCP Pool.<\/p>\n

\"VMware
\n
\nIn the tab Relay<\/b> DHCP message relay is configured to DHCP servers located outside your organization in vCloud Director, including physical infrastructure DHCP servers. <\/p>\n

\"VMware
\n
\nRouting.<\/b> With vShield Edge, only static routing could be configured. Now, dynamic routing is available with support for OSPF and BGP protocols. ECMP settings (Active-active) are also available, enabling active-active failover to physical routers.<\/p>\n

\"VMware
\nConfiguring OSPF<\/i><\/p>\n

\"VMware
\nBGP Configuration<\/i><\/p>\n

Another new feature is the ability to configure route exchange between different protocols,
\nroute redistribution. <\/p>\n

\"VMware
\n
\nL4\/L7 Load Balancer.<\/b> X-Forwarded-For for HTTPs headers has been introduced. Without it, everyone was struggling. For example, if you have a website that you are balancing, without forwarding this header everything works, but in your web server statistics, you saw not the visitors' IPs but the load balancer's IP. Now everything is correct. <\/p>\n

Also, in the Application Rules tab, you can now add scripts to directly manage traffic balancing.<\/p>\n

\"VMware
\n
\nVPN. <\/b>In addition to IPSec VPN, NSX Edge supports:<\/p>\n