📜 ⬆️ ⬇️

Configuring Network Access for Hyper-V Virtual Machines from Different Subnets

It turned out that the other day I had to contend with the problem of one of my clients. The client server is located in the Polish ATMAN Data Center. Despite the fact that this Data Center is large, civilized and nominated for the best in the world in 2013, its work also has its glitches, which ATMAN experts explain by the specifics of building an infrastructure to combat DDOS.
In brief, ATMAN distributes additional network addresses from other sub-networks, which imposes certain restrictions on their use. In the case in question, you need to use them not as aliases on the network interface next to the main address, but as the main IP for virtual machines running Hyper-V.

I tried to find a solution to a similar problem in search engines, but I did not find one, and therefore I decided to write a brief instruction for those who may encounter a similar problem in the future.

In our example, the following network settings will be used:
Primary IP: ***. 189.53.206 / 30
Additional IP: ***. 91.26.173 / 32
The server has two network interfaces, but only one is used. All operations will be performed with him.

image
Fig.1. For convenience, the standard names have been changed to LAN1 (used to access the network) and LAN2 (disabled).
')
image
Fig.2. The main interface is configured according to the data provided by the DC.

Next, you need to configure two virtual routers - the first is of the type “External” with access to the outside world, the second “Internal” for switching the root server with a virtual host. Both virtual switches need to be created in Hyper-V Management Console Virtual Network Manager.

image
Fig.3. For the external interface, you must use a network card with Internet access.

image
Fig.4. For the internal virtual switch settings are used, as shown in this figure.

This completes the preparation of new network interfaces. We should have this:

image
Fig.5. Two additional interfaces - external and internal

When creating an external interface, all connections will break. Make sure that you have another server access (IP-KVM, IPMI or directly physical).
In our case, I was lucky and the DC gives IPMI by default.

In the settings of the internal interface (Internal) specify the settings similar to those used here, in our case it is 192.168.0.1. This interface on the physical server will act as a gateway for virtual machines.

image
Fig.6. Settings for the internal virtual switch.

Further configuration of network interfaces on the root server is completed. Next, you need to configure the RRAS service to redirect traffic to virtual machines and back.

To implement this, you must install the Network Policy and Access Services role in the Server Manager snap-in. I think that there is no need to paint this process - you have already established the role of Hyper-V earlier 

image
Fig.7. The established role is RRAS.

After the installation of this role is completed, it is in the “Stopped” status. Therefore, it must be initially set up before launch.

image
Fig.8. Initial service setup.

You will see the service setup wizard. Perform all actions as shown in the pictures.

image
Fig.9. The service configuration wizard.

image
Fig.10. The choice of a special configuration for our case.

image
Fig.11. We select only address translation and LAN routing.

image
Fig.12. The final stage of configuration. Click "Finish".

image
Fig.13. We agree to the proposal to launch a new service.

After that we will see in the Server Manager a expanded tree of elements of this RRAS service itself.

image
Fig.14. The service is ready to configure.

To redirect traffic to a virtual machine, you need to create an interface through which all requests will pass. PCM on the element "Network Address Translation" select the item "New Interface".

image
Fig.15. Creating a new interface.

In the interface selection window, we need to use an external network interface. Internal is used only for connecting the root server with virtual machines.

image
Fig.16. Select the interface for network address translation.

In the properties of the external interface, we need to enable address translation, as shown below:

image
Fig.17. Enable address translation.

Next, we add a pool of addresses, these are our additional addresses, requests from which will be redirected to the internal addresses of the virtual machines. IMPORTANT: do not specify the mask 255.255.255.255 for these purposes, it will not work. In our case, we have three additional addresses, the mask is indicated / 24 (it does not play a special role).

image
Fig. 18. Fill in the data in the address pool window.

Now you need to reserve an additional address for internal to the virtual machine. All this is done very simply.

image
Fig.19. Reservation of addresses for virtual machines.

In the network settings, we specify the data from the subnet in which the gateway is located. In our case, the internal subnet of the form 192.168.0.0/24, the additional address ***. 91.26.173 we assigned to the internal subnet 192.168.0.3. The network settings of the virtual machine look like this:

image
Fig.20. Network settings of the virtual machine.

If everything is configured correctly, then in the network control center of the virtual machine we will get this view (the machine has access to the Internet). Otherwise - check the settings of the Firewall on the servers.

image
Fig.21. Network management center virtual machine.

By any service we check the correctness of our global settings. Result: the request from the virtual machine should show us exactly the external address, which was reserved by us earlier:

image
Fig.22. The test result on the site 2ip.ru.

On the virtual machine, to check the redirection of ports, traffic, migrants and others, the IIS role was established. We access this address from any PC in the browser, if we see the web server “stub” - everything went fine, we solved the task.

image
Fig.23. That, and sought. Everything is working.

Thus, we can use many different subnets on the same physical server. With the only difference that it will be necessary to create separate virtual switches for different internal subnets.

Thanks for attention. ,

Source: https://habr.com/ru/post/202594/


All Articles