Lead Image © markovka, 123RF.com

Lead Image © markovka, 123RF.com

Roll out hybrid clouds with Ansible  automation

Mixing Allowed

Article from ADMIN 44/2018
Designing your own hybrid IT structure as a digital mix of your servers and public or private clouds might be technically elegant and cost effective, but setup is time consuming. Thanks to Ansible, it might take less work than you think.

According to reliable estimates, half of all corporations will be operating a hybrid cloud architecture by next year. Obviously, the advantages of mixing the historic IT landscape, which physically resides in-house, and public or private clouds from external service providers is something that appeals to admins. Lower running costs are often the deciding factor in favor of hybrid setups. In many cases, however, the combination also might have functional advantages. Companies with hybrid IT structures are said to be more successful than their competitors [1].

The reason the hybrid cloud is not yet widely used is probably because of the great effort needed to set it up. In this article, I seek to demonstrate that every admin can take a considerable step toward achieving a hybrid cloud with little effort, while gaining enough experience to outsource more parts of the local IT structure. With Amazon Web Services (AWS) as an example, I show how you can use two Linux virtual machines (VMs) to build a secure infrastructure that is even capable of multitenancy. The best part is that you do not need to do all this work yourself; instead, Ansible will carry out the setup steps. (For more information on Ansible, refer to earlier articles in this magazine [2][4].)

Many users still think that VMs in the cloud are always publicly available. However, administrators who have been involved with virtual network infrastructures, such as AWS or Azure, know that private networks, VPNs, and routers are also common in the cloud. AWS and Azure even offer VPNs to the private corporate network as a (commercial) service (see the "Amazon Network Glossary" box).

Amazon Network Glossary

The AWS Elastic Compute Cloud service allows complex networking of VMs, much like OpenStack or VMware. However, the admin has to follow Amazon's logic. To explain the target architecture used in this article, a short introduction to the concepts is helpful.

The highest hierarchy level is an account, which can belong to a company, for example. Multiple employees then have access to the environment, its VMs, and other resources. The account is comparable to the OpenStack project.

AWS divides the infrastructure offered to the customer into regions, or the data center's geographical location (where the data is located). Each network setup is also relative to a region. If you want to operate your hybrid cloud in Ireland and Germany, you need to set up the solution presented in this article twice.

Within the account are Virtual Private Clouds (VPCs). Five VPCs per region and account are possible. In a VPC, the user can create up to 200 separate subnets. (An AWS document [5] shows the limits.) Between VPCs (also between accounts), you can create peering that specifically routes traffic. Both peering partners need to agree, which is especially important when establishing a connection between two accounts.

VMs in subnets initially receive only one address from the address block assigned to the subnet and cannot be reached from outside. If you use the public IP address option, the VM additionally gets an IP address from the AWS public address blocks. For closed VMs to reach the Internet, a network address translation (NAT) gateway must be assigned to the subnet. When creating a subnet, you can specify that every VM you connect to this network is assigned a public IP automatically.

AWS stores routes in routing tables as expected, and administrators maintain these as separate units, which are then assigned to a VPC.

AWS Security Groups describe a set of IP filters (inbound and outbound) that the customer applies to a VM to control externally which packets it can send or which packets can reach the VM.

AWS offers its own, rather expensive VPN as a Service (VPNaaS). Therefore, the setup in this article uses its own VPN VM, which is cheaper – or to be more precise, might be cheaper, because with a large, expensive Amazon instance, the costs could be higher.

Target Architecture

Figure 1 shows the architecture I set up for the project here. In the local data center on the right, a VPN gateway establishes the connection to the gateway in the AWS universe. This can be implemented with a firewall or through a separate gateway. Ansible also configures a local OpenVPN instance; since I have already built VPN playbooks for Libreswan, Fortinet, and Juniper firewalls, I could easily replace the component.

Figure 1: This hybrid architecture is my goal. On the right, you can see the relevant part of the in-house IT; on the left, you can see the setup to be created in the Amazon cloud.

On the AWS side, the structure is a bit more complicated, because I want to develop a multitenant solution – a VM facing the Internet that forwards to different closed environments. The VPN data in the closed environments will not be known to the front end. However, an incoming control based on IP addresses will still take place there. Therefore, the AWS VM uses socat to forward the incoming packets to the actual VPN service in the closed network so that an encrypted end-to-end connection is still established. If you do not want multitenant capability, you can omit this redirection from the structure.

The AWS subnet has a routing table that ensures the routing between the local networks of your data center and the AWS VM with OpenVPN occurs correctly.

Networks and Peering

As with other virtualization environments, you start by setting up the virtual network infrastructure so that the VMs ultimately end up on the correct networks. For AWS, you first create two VPCs: the inner one for the closed environment, the outer one for the gateway VM (Figure 2). Both have a private IP network.

Figure 2: Two VPCs to be created form the basis on the AWS side.

The inner VPC should be selected so that it does not collide with the network in your data center, because on the local side, the routes into this network area must point to the local VPN gateway. In the external block, it is sufficient to select a small network area, because it only serves as a transition point. AWS now needs subnet objects whose IP networks each have to be a subset of the VPC's total range.

In the next step, you set up the VPC peering connection, which is like adding a virtual cable between your two VPCs (Figure 3). You need to accept this peering in a separate step. So that the VMs can find their way out of the outer VPC later on, you now need to create an Internet gateway.

Figure 3: This dialog lets you set up the peering connection; you must confirm this in a separate step.

VPN Routing

The configurations up to now simulate Layer 2 cabling, which would also be necessary for a physical structure. Now the IP routing follows. In the routing table for the inner VPC, you should define a route to the outer subnet. Because the VPN connections are forwarded at the application level (socat), there is no direct IP connection between the VPN gateway and the Internet. The goal of these routers is VPC peering – comparable to setting an interface route with:

ip route add dev eth0

Conversely, the external VPC must know how to find the internal VPC, which requires routes to the internal subnet and also to VPC peering. Additionally, the external VPC's default route must point to the previously created Internet gateway.

The security configuration completes the setup of the virtual network: The VPN gateway in the internal VPC needs the VPN port (for OpenVPN, port 1194/UDP; for IPsec with NAT traversal, ports 500/UDP and 4500/UDP). To allow the admin to access the VM itself, SSH access is also required (i.e., incoming port 22/TCP). The same applies to the external gateway computer. Here, the VPN input can then be limited to the local VPN gateways' static IPs – if available. This does not offer very strong protection (especially for UDP), but it at least limits the Internet background noise a bit.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=