Expansion of local infrastructure to the cloud
With the advent of virtual machine technologies (VMs) and virtual networks in Windows Azure, the implementation of hybrid scenarios, when part of the local infrastructure is transferred to the cloud or expanded with the help of cloud resources, becomes an entirely feasible task. Such scenarios suggest a tunnel between the enterprise LAN and the cloud. In this post, I will show how this Site-to-Site (S2S) tunnel is built when Windows Azure acts as a cloud, and the server running Windows Server 2012 R2 is the gateway on the local network. There will be a lot of pictures.
Let's imagine that some company is interested in expanding its local IT infrastructure and would like to transfer part of the workload to Windows Azure. For us, it does not matter now what exactly will move to the cloud: a web server, database, SharePoint portal or something else. It is important that the virtual machines deployed in Windows Azure “see” as part of the local Active Directory (AD) infrastructure, be included (or could be included) in the domain and in essence are just another segment of the corporate network.
The planned configuration is as follows:
')
More precisely, on the left in the picture, what is already there, on the right, what is to be done.
First of all, we will create a virtual network in Windows Azure named VPNnet01. In this network, you must provide at least two subnets - one (several) for the VM, the second for building a tunnel to the local AD. Having a dedicated subnet for the gateway is a requirement of Windows Azure.
Then we organize a tunnel between the created virtual network and the local infrastructure, and this tunnel is first configured from the Windows Azure side, then from the local network side.
Finally, we will create a VM in Windows Azure and make sure that this virtual machine is accessible from the local network and vice versa, the VM can interact with a domain controller located locally.
The whole procedure thus comes down to four main steps:
Go!
I assume that there is already a Windows Azure subscription in the organization. Subscription options are listed here . I also assume that you have an idea about the concept of virtual networks in Windows Azure. If this is not the case, you can check the information in the third module of the course “ Windows Azure for System Administrators ” on the MVA portal. But I will comment on the main steps.
So, you need to go to the Windows Azure management portal and select the creation of a new virtual network in the NETWORKS section by pressing the NEW button.
We set the name of the virtual network and select AFFINITY GROUP , which allows you to locate your VMs within a single Windows Azure data center to reduce network delays. If you don’t have any AFFINITY GROUP yet, you will be asked to create such a group.
On the next page, you must specify the name and IP address of the DNS server (s). Strictly speaking, this field is optional and can be filled / modified later. But for our scenario, all the information about DNS is already there. Since we plan to use VMs in Windows Azure as part of an AD enterprise, here I specify the name and IP address of the domain controller that traditionally performs the role of a DNS server. All VMs created on this network will automatically receive this particular address as the DNS server address. If the field is left blank, then the VMs created later will use Windows Azure for name resolution and, of course, you will not be able to include such machines in the domain. Technically, you can then access a specific VM, for example, using RDP and manually change the DNS address, but the option on this page is much more convenient. In addition, it should be noted that it is generally not recommended to change anything manually in the TCP / IP settings of the virtual machines. These settings are managed by Windows Azure so that you, in turn, have reliable access to your machines.
The second important parameter on the page is the Configure site-to-site VPN checkbox, which you need to remember.
On the Site-to-Site Connectivity page, we set three parameters:
On the Virtual Network Address Spaces page you need to create a virtual address space of the virtual network being created. VMs in the cloud will receive IP addresses from this space. Specifying the address range of the entire network, then you need to split it into subnets. Let me remind you that at least two subnets are required: for the VM and the gateway, respectively. There can be only one gateway subnet in each virtual network.
Press the “Complete” button and wait for the completion of the process of creating a virtual network.
Actually at this first stage is completed, and we can proceed to configure the Windows Azure gateway.
After the network is created, click on it and see the DASHBOARD tab.
In the menu at the bottom of the screen, click CREATE GATEWAY and select Dynamic Routing . Two types of routing currently support Windows Azure. Static routing is based on user-defined policies (access lists), dynamic - on specified routes and the tunnel interface (any packet that enters the tunnel interface is forwarded through the VPN tunnel). In the case of dynamic routing, respectively, if the IP ranges of the virtual and local address spaces when creating a virtual network in Windows Azure were set correctly (do not overlap, not duplicated, etc.), then the packets must be properly routed between Windows Azure and the local infrastructure.
The choice of the type of routing is determined by which gateway is used on the local infrastructure side. See the documentation in the Known compatible VPN devices section for a list of supported gateways and their corresponding routing types.
It remains to wait until Windows Azure configures the gateway. This process takes an average of 15-20 minutes.
At the end of the page, you can see the external IP address of the gateway created in Windows Azure, and this address should be used as the connection end point when setting up the gateway in the corporate network.
For certain models of gateways (VPN devices), including RRAS in Windows Server 2012 / R2, Windows Azure can generate a script that you then need to run on the VPN device and thereby configure this device to establish a tunnel in Windows Azure. To load such a script, you need to create a key used for tunnel authentication by pressing MANAGE KEY ,
and then click the Download VPN Device Script link on the right side of the page.
In the window that opens, select the manufacturer of the gateway, platform and operating system and download the script.
Now the resulting script must be transferred to the VPN device and perform the configuration.
You should make sure that the script obtained in the previous step contains the correct values of the address space of the virtual network and the external address of the Windows Azure gateway. These values are highlighted in the above script fragment.
If everything is correct, it remains to simply run this script on the machine running Windows Server 2012 R2, which will act as a gateway. I emphasize that the above is only a fragment. You need to run, of course, the entire script as a whole, and under an account with administrator rights. For example, this can be done in PowerShell ISE.
From the above fragment, you can see that the script installs and configures the Routing and Remote Access Services (RRAS) service. Let's see what some RRAS tinctures look like after successful execution of the script.
First, in the Network Interfaces section, you can notice the interface with the name corresponding to the external IP address of the gateway in Windows Azure, and the status of this interface should be Connected . If this is not the case, right-click on it and select Connect from the context menu .
In the properties of this interface, used, as you understand, to build a tunnel, we will find the IP address of the Windows Azure gateway,
and also on the Security tab, the protocol used (IKEv2) and the key generated in Windows Azure.
In addition, a static route appeared in the Static Routes section, sending all packets through the tunnel to the recipient addresses belonging to the Windows Azure virtual network.
The RRAS server itself is configured as a router, as can be seen by looking at its properties.
Using the information provided, you can manually configure the RRAS service, if for some reason the script has completed with errors.
If everything is in order, then returning to the DASHBOARD tab of the virtual network created in Windows Azure, you will see something like this:
Or it will become so after pressing the CONNECT button at the bottom of the page.
Now that the tunnel has been created, it remains to verify the configuration.
To do this, let's create a VM in Windows Azure and try to enable this VM in the AD local infrastructure. The steps are fairly standard, in the VIRTUAL MACHINES section, click NEW and select FROM GALLERY ,
as a guest OS we choose, for example, Windows Server 2012,
set the VM name, login and administrator password,
and make sure that the machine will be connected to the previously created virtual network.
On the last page, leave everything unchanged.
After the VM starts up, you can connect to it via RDP and see the IP settings. In this case, it is clear that the VM received the address 10.50.1.4 from the address space of the virtual network, while the address of the domain controller (192.168.3.200) is specified as the DNS server address.
Check the resolution of names and ping on the domain controller, unless of course the Firewall allows ICMP.
Communications are configured, it remains just to enable the VM in the domain, and this is the most usual procedure, which I will not dwell on.
So, we went through all the stages, and now our local infrastructure is expanded by the network segment in Windows Azure. In this segment, you can create additional subnets, start VMs of the desired configuration, transfer the required services to them, configure their monitoring and thus use cloud resources to solve the tasks facing the IT department.
I have given a fairly detailed description of the settings so that you can, if necessary, reproduce the above steps. As mentioned, on the Windows Azure website you can find scripts for different types of VPN gateways. But even if your device is not in this list, you can configure your gateway, I understand the operation logic and the used Windows Azure authentication protocols and mechanisms. In general, the best way to learn technology is to try it yourself. :)
Hope the material was helpful!
Formulation of the problem
Let's imagine that some company is interested in expanding its local IT infrastructure and would like to transfer part of the workload to Windows Azure. For us, it does not matter now what exactly will move to the cloud: a web server, database, SharePoint portal or something else. It is important that the virtual machines deployed in Windows Azure “see” as part of the local Active Directory (AD) infrastructure, be included (or could be included) in the domain and in essence are just another segment of the corporate network.
The planned configuration is as follows:
')
More precisely, on the left in the picture, what is already there, on the right, what is to be done.
First of all, we will create a virtual network in Windows Azure named VPNnet01. In this network, you must provide at least two subnets - one (several) for the VM, the second for building a tunnel to the local AD. Having a dedicated subnet for the gateway is a requirement of Windows Azure.
Then we organize a tunnel between the created virtual network and the local infrastructure, and this tunnel is first configured from the Windows Azure side, then from the local network side.
Finally, we will create a VM in Windows Azure and make sure that this virtual machine is accessible from the local network and vice versa, the VM can interact with a domain controller located locally.
The whole procedure thus comes down to four main steps:
- Creating a virtual network in Windows Azure
- Setup of the gateway in Windows Azure
- Configuring Windows Server 2012 R2 as an S2S Gateway on a Local Area Network
- Creation of VM in Windows Azure and check of a configuration
Go!
Creating a virtual network in Windows Azure
I assume that there is already a Windows Azure subscription in the organization. Subscription options are listed here . I also assume that you have an idea about the concept of virtual networks in Windows Azure. If this is not the case, you can check the information in the third module of the course “ Windows Azure for System Administrators ” on the MVA portal. But I will comment on the main steps.
So, you need to go to the Windows Azure management portal and select the creation of a new virtual network in the NETWORKS section by pressing the NEW button.
We set the name of the virtual network and select AFFINITY GROUP , which allows you to locate your VMs within a single Windows Azure data center to reduce network delays. If you don’t have any AFFINITY GROUP yet, you will be asked to create such a group.
On the next page, you must specify the name and IP address of the DNS server (s). Strictly speaking, this field is optional and can be filled / modified later. But for our scenario, all the information about DNS is already there. Since we plan to use VMs in Windows Azure as part of an AD enterprise, here I specify the name and IP address of the domain controller that traditionally performs the role of a DNS server. All VMs created on this network will automatically receive this particular address as the DNS server address. If the field is left blank, then the VMs created later will use Windows Azure for name resolution and, of course, you will not be able to include such machines in the domain. Technically, you can then access a specific VM, for example, using RDP and manually change the DNS address, but the option on this page is much more convenient. In addition, it should be noted that it is generally not recommended to change anything manually in the TCP / IP settings of the virtual machines. These settings are managed by Windows Azure so that you, in turn, have reliable access to your machines.
The second important parameter on the page is the Configure site-to-site VPN checkbox, which you need to remember.
On the Site-to-Site Connectivity page, we set three parameters:
- NAME is the name of the site, it can be arbitrary and only identifies the set of settings that we form on this page;
- VPN DEVICE IP ADDRESS - external IP-address of the VPN gateway in the local network of the enterprise, as applied to the considered scenario, this is the IPv4-address on the external network interface of the Windows Server 2012 R2 machine;
- ADDRESS SPACE - the address space of the local network or the part to which we want to provide access from Windows Azure.
On the Virtual Network Address Spaces page you need to create a virtual address space of the virtual network being created. VMs in the cloud will receive IP addresses from this space. Specifying the address range of the entire network, then you need to split it into subnets. Let me remind you that at least two subnets are required: for the VM and the gateway, respectively. There can be only one gateway subnet in each virtual network.
Press the “Complete” button and wait for the completion of the process of creating a virtual network.
Actually at this first stage is completed, and we can proceed to configure the Windows Azure gateway.
Setup of the gateway in Windows Azure
After the network is created, click on it and see the DASHBOARD tab.
In the menu at the bottom of the screen, click CREATE GATEWAY and select Dynamic Routing . Two types of routing currently support Windows Azure. Static routing is based on user-defined policies (access lists), dynamic - on specified routes and the tunnel interface (any packet that enters the tunnel interface is forwarded through the VPN tunnel). In the case of dynamic routing, respectively, if the IP ranges of the virtual and local address spaces when creating a virtual network in Windows Azure were set correctly (do not overlap, not duplicated, etc.), then the packets must be properly routed between Windows Azure and the local infrastructure.
The choice of the type of routing is determined by which gateway is used on the local infrastructure side. See the documentation in the Known compatible VPN devices section for a list of supported gateways and their corresponding routing types.
It remains to wait until Windows Azure configures the gateway. This process takes an average of 15-20 minutes.
At the end of the page, you can see the external IP address of the gateway created in Windows Azure, and this address should be used as the connection end point when setting up the gateway in the corporate network.
For certain models of gateways (VPN devices), including RRAS in Windows Server 2012 / R2, Windows Azure can generate a script that you then need to run on the VPN device and thereby configure this device to establish a tunnel in Windows Azure. To load such a script, you need to create a key used for tunnel authentication by pressing MANAGE KEY ,
and then click the Download VPN Device Script link on the right side of the page.
In the window that opens, select the manufacturer of the gateway, platform and operating system and download the script.
Now the resulting script must be transferred to the VPN device and perform the configuration.
Configuring Windows Server 2012 R2 as an S2S Gateway
You should make sure that the script obtained in the previous step contains the correct values of the address space of the virtual network and the external address of the Windows Azure gateway. These values are highlighted in the above script fragment.
# Install RRAS role Import-Module ServerManager Install-WindowsFeature RemoteAccess -IncludeManagementTools Add-WindowsFeature -name Routing -IncludeManagementTools # !!! NOTE: A reboot of the machine might be required here after which the script can be executed again. # Install S2S VPN Import-Module RemoteAccess Install-RemoteAccess -VpnType VpnS2S # Add and configure S2S VPN interface Add-VpnS2SInterface -Protocol IKEv2 -AuthenticationMethod PSKOnly -NumberOfTries 3 -ResponderAuthenticationMethod PSKOnly -Name 137.116.214.169 -Destination 137.116.214.169 -IPv4Subnet @("10.50.0.0/16:100") -SharedSecret 0pCpWdVuzaJuZtJpQq8TbtUAQWk7PtOk Set-VpnServerIPsecConfiguration -EncryptionType MaximumEncryption # Set S2S VPN connection to be persistent by editing the router.pbk file (required admin priveleges) Set-PrivateProfileString $env:windir\System32\ras\router.pbk "137.116.214.169" "IdleDisconnectSeconds" "0" Set-PrivateProfileString $env:windir\System32\ras\router.pbk "137.116.214.169" "RedialOnLinkFailure" "1" # Restart the RRAS service Restart-Service RemoteAccess # Dial-in to Azure gateway (optional) #Connect-VpnS2SInterface -Name 137.116.214.169 If everything is correct, it remains to simply run this script on the machine running Windows Server 2012 R2, which will act as a gateway. I emphasize that the above is only a fragment. You need to run, of course, the entire script as a whole, and under an account with administrator rights. For example, this can be done in PowerShell ISE.
From the above fragment, you can see that the script installs and configures the Routing and Remote Access Services (RRAS) service. Let's see what some RRAS tinctures look like after successful execution of the script.
First, in the Network Interfaces section, you can notice the interface with the name corresponding to the external IP address of the gateway in Windows Azure, and the status of this interface should be Connected . If this is not the case, right-click on it and select Connect from the context menu .
In the properties of this interface, used, as you understand, to build a tunnel, we will find the IP address of the Windows Azure gateway,
and also on the Security tab, the protocol used (IKEv2) and the key generated in Windows Azure.
In addition, a static route appeared in the Static Routes section, sending all packets through the tunnel to the recipient addresses belonging to the Windows Azure virtual network.
The RRAS server itself is configured as a router, as can be seen by looking at its properties.
Using the information provided, you can manually configure the RRAS service, if for some reason the script has completed with errors.
If everything is in order, then returning to the DASHBOARD tab of the virtual network created in Windows Azure, you will see something like this:
Or it will become so after pressing the CONNECT button at the bottom of the page.
Creation of VM in Windows Azure and check of a configuration
Now that the tunnel has been created, it remains to verify the configuration.
To do this, let's create a VM in Windows Azure and try to enable this VM in the AD local infrastructure. The steps are fairly standard, in the VIRTUAL MACHINES section, click NEW and select FROM GALLERY ,
as a guest OS we choose, for example, Windows Server 2012,
set the VM name, login and administrator password,
and make sure that the machine will be connected to the previously created virtual network.
On the last page, leave everything unchanged.
After the VM starts up, you can connect to it via RDP and see the IP settings. In this case, it is clear that the VM received the address 10.50.1.4 from the address space of the virtual network, while the address of the domain controller (192.168.3.200) is specified as the DNS server address.
Check the resolution of names and ping on the domain controller, unless of course the Firewall allows ICMP.
Communications are configured, it remains just to enable the VM in the domain, and this is the most usual procedure, which I will not dwell on.
So, we went through all the stages, and now our local infrastructure is expanded by the network segment in Windows Azure. In this segment, you can create additional subnets, start VMs of the desired configuration, transfer the required services to them, configure their monitoring and thus use cloud resources to solve the tasks facing the IT department.
I have given a fairly detailed description of the settings so that you can, if necessary, reproduce the above steps. As mentioned, on the Windows Azure website you can find scripts for different types of VPN gateways. But even if your device is not in this list, you can configure your gateway, I understand the operation logic and the used Windows Azure authentication protocols and mechanisms. In general, the best way to learn technology is to try it yourself. :)
Hope the material was helpful!
Source: https://habr.com/ru/post/195364/
All Articles