Google Professional Data Engineer – VPCs and Interconnecting Networks part 5

9. Lab: Bastion Host

In this demo we will first create an application web server which will represent a service supplied to employees of a company. We will then prevent access from this web server out to the Internet by placing a firewall in between. Finally, we will create a maintenance server, also called a bastion host, which will be able to access this web server and we would test the connectivity to that server. We start off by provisioning a virtual machine which will represent our web server. So we go into Compute engine and VM instances where we will create a new VM. Let us call this web server and provision this in the US central zone. We can also specify over here that this host needs Http access which will ensure that the required firewall rules are generated so that this instance can be reached on port 80.

Once that is complete, we just hit Create and wait for the instance to be provisioned. Once the host is ready, we can Ssh into it and we just run some command of the shell just as a sanity check. And once we are satisfied that all is okay, let us try to restrict access to this host. So you will first try to find out what your IP address is and ensure that only you are able to access the host which you just created. So to start off, you can just go to your preferred search engine and search for what is my IP and once you get your IP address you will copy that and use that in a firewall rule to ensure that only you are able to access that host which you provisioned. So we move over to the firewall rules and since your instance was created in the default Vpc network, there is a pre configured firewall rule which will allow Ssh access.

So we edit that. The rule is presently set to allow Ssh access into the network from anywhere. So we will modify that by specifying the source IP range to just your IP address. Once that is complete, we just hit save and then we move over to the instance we Ssh into that again. But we notice that this time the Ssh connection fails. That is because when you try to Ssh into an instance from your browser, it goes through a Google cloud platform resource. So the firewall must either allow connections from all of Google’s IP address range or from anywhere. But for the purposes of this exercise, let’s just reset the firewall rule so that instances on the network can be accessed from anywhere. So once we go into the firewall and edit it to make the change, we then hit save. And once the firewall rule is in place, we go back to our instance.

 And this time we see that an Ssh connection can be established. Since we are in, let us now install a simple web app over here. So we first do an app get update and once that is complete, we can just go on and install Apache. And once Apache has been installed, we just load a simple web page in the VAR HTML directory. All right. And now we are ready with our web app. To test that this app can be accessed from a browser, we just go over to the instance page and we click on its external IP address. The page opens up in a browser and we can see that the page is accessible. So let us not try to restrict Http access to this instance to only your computer. So to do that, we would first need to modify the firewall rules. So we go to the allow Http firewall rule, we edit it, and in the source filter you need to insert your IP address again.

So we just go into the browser and search for what is my IP. And once that is obtained, we just update the firewall rule. Once we hit save, we wait a few seconds for the changes to take effect, and then we go back to the browser and we can see that the app is still reachable. At this point, let us try to restrict access to this virtual machine from the Internet. We can do this by just getting rid of the external IP address. So we click on the instance and then hit Edit. We then navigate down to the Network interfaces section. And over here, we set the external IP from Fml to none. Once this is complete, we save our changes and then we navigate back to the instance page. And over here we see that we no longer have the option to even Ssh into the instance.

Now that our web server can no longer be accessed from the Internet, let us proceed to create our bastion host. So we create a new instance we created in the same US central zone as our web server, and then we hit save and wait for the instance to be ready. And then let us just Ssh into the host. And once we are in, let us see if our web server is accessible from this bastion host. We just do a curl. And yes, we can see that the web page is rendered over here. Let us now see if the web server can be accessed via Ssh, and we see that this works as well. So a web server is no longer accessible from the Internet, but it can be accessed from within the network. And we can also use this bastion host to perform any maintenance on it. That concludes this demo. I hope you found it useful. Thank you.

10. Cloud VPN

Now that we’ve understood how a VPC works on the Google Cloud platform, we can move one step further and we’ll see how we can interconnect networks using the Google Cloud. There are three options for us to provide interconnections between two different networks. These interconnection options allow the Gcp to connect with an on premise network or a network work on another cloud provider. The interconnection can also be between two networks on the Google Cloud. The first of these is a VPN or a virtual private network. This basically sets up a secure tunnel between your on premise network and a network on the Google Cloud. Now, VPNs can use cloud router, in which case they have dynamic routing.

Or they can be configured with static routes, which is more of a pain to maintain because you have to update it each time your network changes with static routes. This updation is manual. The second interconnection option that we have is a dedicated interconnect. Dedicated interconnect is a direct physical connection between Google’s Vpc and your on premise network, where the gateways are located in the same physical location. The amount of data transfer that can occur between networks is much larger using a dedicated interconnect and you might find that costs are lower. The third interconnection option is via Peering. Peering is typically an enterprise grade connection to allow for hybrid cloud workloads.

Peering in the Google Cloud platform can be direct peering directly from your Google Vpc to your on premise network, or can be carrier Peering. This is where a third party and Internet carrier facilitates the peering. We look at each of these options in some detail, starting off with a VPN where we use a secure tunnel to connect our on premise network to the Google Cloud. Vpc connection to the Google cloud VPCs is typically through an Ipsec VPN. This connection is secure. Traffic traveling between the two networks is encrypted by one VPN gateway and then decrypted by the other VPN gateway. This way you know that the data traveling over the network is always secure.

VPNs connecting to the Google Cloud use Ipsec, which is a standard suite of protocols that provide data authentication, integrity, and confidentiality as data is transferred between two communication points. Here it is the gateways. Google offers a 99. 9% service availability SLA when you connect your on premise network with the Vpc. Using a VPN tunnel using a VPN is a tested and a reliable way of interconnecting your networks. Cloud VPN supports site to site VPN so you can have multiple tunnels to a single VPN gateway. So multiple on premise networks can use multiple gateways to connect to the same Vpc network on the Google Cloud. Traffic flowing through the connection is secure.

Traffic is encrypted by one VPN gateway. Say traffic which is leaving your on premise network will be encrypted by your on premise gateway and it’s decrypted on the Google Cloud and vice versa. VPN uses the Internet Key Exchange known as Ike, version One or version Two, as the protocol used to set up a security association, you can have your VPN configuration set up to use either static or dynamic routes. Static routes are when you manually update the routing tables on either gateway if the network changes in any way, dynamic routes is what you set up using a cloud router. Here the gateways exchange information about routes automatically using BGP, and you don’t have to make any manual updates to the routing tables when the network changes.

Here is a diagram of your on premise network connected to Google’s Vpc via a VPN tunnel. On the right, you see the on premise network which needs to be connected to the cloud. It has its own peer gateway with a remote peer IP. It’s remote because it’s on premise, it’s not on the cloud. This peer network can of course be an onpremise network, an existing one that you’re using and you are gradually moving to the cloud, and you want to set up a VPN tunnel to interconnect your networks to manage hybrid workloads. This peer network can also be from another cloud provider, or it can be another Vpc on the Google Cloud platform. One important caveat to note with cloud VPN is that only Ipsec gateway to gateway scenarios are supported by Google.

You cannot use this VPN with client software on a laptop. You absolutely need to have a dedicated physical or virtual Ipsec VPN gateway. On the client side. Cloud VPN does not work with SSL VPN client software, such as in a browser, only with a full Ipsec VPN gateway. Cloud VPN also doesn’t support VPN technologies other than Ipsec. You absolutely need to have a pure VPN gateway for the other side of the tunnel. This must have a static external IP address, because this is the IP address that will configure our cloud VPN to point to. This is where traffic will be routed if the peer VPN gateway is behind a firewall. You need to configure the firewall to pass ESP and Internet Key Exchange or Ike traffic, because that’s what the traffic will comprise of between the networks.

It’s also very important that the Cider IP address range, which applies to your on premise network, should not conflict with the IP address range specified in the cloud Vpc. The VPN tunnel is a secure connection between the two gateways. Traffic is encrypted while passing over this tunnel. This tunnel needs to know what destination IPS are allowed and create routes to forward packets to those IPS. Site to site VPN is what allows multiple fixed locations to establish secure connections with each other. The Google Cloud VPN can have multiple tunnels to a single VPN gateway. That is, it allows site to site VPN. The same cloud VPN gateway can be connected to multiple on premise networks.

And here on the other side of the VPN tunnel is our Vpc network on the Google Cloud platform. It has a Compute engine VPN gateway configured. That is your cloud VPN gateway. There is one important point you have to keep in mind if you are using a VPN. In order to connect your network to the cloud, VPN traffic has to traverse the Internet. The secure tunnel is established over regular internet lines, which means VPN will typically have a higher latency and throughput for traffic as compared with dedicated interconnect and peering options. So if your hybrid cloud setup requires transfer of large amounts of data and you require high speed interconnectivity between your onpremise and cloud networks, VPN may not be the best option.

11. Lab: Working with Cloud VPN

In this demo, we will be setting up a Virtual Private Network by first creating two networks in separate regions and then establishing VPN tunnels between them such that a VM in one of these networks can ping a VM in the other network using its internal IP. To start off, let us create our first Virtual Network by navigating to the Vpc network section. We create a new Vpc network and in this one we include just one subnet in the Asia East region. So we hit Create and then move on to creating a second Virtual Network. So we once again go to create Vpc network. We name this Virtual Network Two, and for the subnet, let us create it in the Asia South region. But when entering the Cider blocks, let’s ensure that the address page does not overlap with the first Virtual Network we created.

So we hit create. Our networks are in place. Let’s go ahead and create our instances. For our first instance, let us name this server One. We will be creating this in the Asia East region which is where our VPN Network One is. So we choose the smallest possible machine type and to set the network to VPN Network One, let us go over to the networking section and once we selected our network, let’s just hit Create and then move on to creating a second instance. So this instance we will name Server Two. We will set the zone to something in the Asia South region which is the location of our second Virtual Network. Again, we will choose a small machine type and to place this in our second Virtual Network, let’s just head over to the networking section and select VPN Network Two.

Once this is done, we hit Create. And now we have our two instances. Our next step is to create Firewall Rules which will allow us to ping and Ssh into the instances we just created. So we head over to the Firewall Rules section and for our first rule, we will apply this to the first Virtual Network and we will allow ping and Ssh from any host. So we set the source IP range. As such, we list down our protocols and once this is created, we move on to creating a second Firewall rule. This rule is pretty much identical to the one we just created, except that it applies to our second Virtual Network, so we select our network. We would like this rule to apply to all hosts within the network. Once we hit our source IP range, we list the ports and protocols and we hit Create.

So now we have our Firewall rules in place. Let’s move on and test the network connectivity between our instances. Let us start off by connecting to our first instance using Ssh and we can see here that the Ssh connectivity works. Our next step is to connect to the second instance from over here using its external IP address. So we ping and we can see that this works as expected, let us now try pinging using its internal IP address. And once we grab that and we can see that in this case the connectivity fails, let us now test the reverse connections. So we head over to our second instance and establish an Ssh connection. Once we’re in, we try to ping the first instance using the external IP address, and again this works.

Let us now move over and use the internal IP address. Just as in the first case, this connection doesn’t work. So our goal is to allow this mutual pinging using the internal IP addresses by setting up a virtual private network. So let us go about doing that. To do this though, we will be using the Google Cloud shell rather than the Gcp console. This is because in the shell you can actually see all the available options and understand how they fit together. The console just conceals much of this complexity and may not be the best option when learning how to set up a VPN. When using the Gcloud shell, we should first set which project we will be referring to. For this, we navigate to the project homepage so that we can grab the project ID.

We bring up the shell from this icon in the top menu, and then we run this command in order to set the project. Now that the initial setup is complete, let us take the first steps to creating our VPN connection, which is creating VPN gateway for each of our networks. So this is the command to execute to create a VPN gateway. So for our first gateway, we link it to our first VPAC network, we give it a name, and we also specify the region of Asia East, which is the location of the subnet for our network. Now that we have our first gateway, let us take the next step, which is to create a static IP address which we will link to it. So this is the command to execute, and once again we have to specify the region.

And once it is ready, we need to grab the actual static IP address for which we execute this command. And once we have our static IP address, the next steps are to create a set of forwarding rules where we direct certain traffic hitting our IP address to our VPN gateway. So the first rule we will create is to direct any ESP connections to our gateway. And this is a command to execute. And now that we have one forwarding rule in place, we create another one to direct all UDP traffic on port 500 to our gateway. So the command to execute is similar to the first one, except over here, the protocol of UDP, and we specify a port of 500, and once that is ready, we create a final forwarding rule where all UDP traffic on port 4500 is directed to our first VPN gateway.

And now that we have our three forwarding rules in place for our first gateway, let us go about creating our second gateway. So the command is familiar to you. However, in this case, our region is Asia South, which is where we have our subnet for that network. And once the gateway is created, let us go about creating our static IP address. Again. You specify the Asia South region. And with this static IP address in place, let us now create the three forwarding rules which will be similar to the ones we created for our first gateway. So first, we create one to direct all ESP traffic. I’m just going to quickly fast forward here. The second one is for UDP traffic on port 500, and finally, all UDP traffic on port 4500.

At this point, let us just do a quick sanity check to see whether our VPN gateways are in place. And yes, once this verification is complete, let us move on to the next step, which is to create tunnels between each of our Vpc networks. So for our first tunnel, we direct traffic from our first network to the second one. And this is the command to execute. The pure address over here references the remote endpoint for this tunnel, so it is set to the static IP address of our second gateway. We set a region, a shared secret, and that the target VPN gateway is our first gateway. The local and remote traffic selectors. You can just use the value specified here, which just means that all traffic will be directed through this tunnel and nothing will be filtered out.

The Ike or Internet Key Exchange version, we don’t really need to get into that. We can just leave it at two. With our first tunnel in place, let us create the second one, where we direct traffic from our second Vpc network to the first one. So over here, the peer address is going to be the static IP of our first gateway. We link this tunnel to our second gateway, and yes, we need to use the same shared secret as we did earlier. Yes, once we have this in place, we have our two tunnels ready. Before we move along, let us do a quick sanity check to see that our tunnels are in place. And yes, once this is complete, let us move along to the final piece of our jigsaw puzzle. When creating a VPN, which is to generate static routes, we would produce one route from each of our networks out to the other.

For our first route, which goes out from our first network out to the second one, this is the command we execute. So we name this route One to two. We link this to our first virtual network, and also to the first tunnel which we created. And the region is also the same as the first tunnel. And finally, the destination IP address range corresponds to the subnet in our second network. So let us now create a second route, which goes from our second network over to the first one. And this is effectively a complement of the first static route we created. And once this is complete, our VPN set up. All we have to do now is to verify the VPN connectivity. You can just do this by going over to each of our instances using Ssh, and then pinging the other instance using its internal IP address. And that concludes our demo for setting up a virtual private network. Thank you.