Note that there are three components to this. The first is Corente Gateway running in your data center. The second is Corente Gateway running in the Oracle Cloud. The third is the Corente App Net Manager Service Portal. The basic idea behind this is that we are going to create a second network as we did with hiding a server in the cloud. We initially setup one instance so that we could access it through a public IP address 126.96.36.199. It also has a private IP address for inside the Oracle Cloud of 10.196.135.XXX. I didn't record the internal IP address because I rarely use it for anything. The key here is that by default a subnet range of 10.196.135/24 was configured. We were able to connect to our second server at 10.196.135.74 because we allowed ssh access on the private subnet but not on the public network. When this blog was initially written Oracle did not support defining your own subnet and assigned you to a private network based on the rack that you got provisioned into inside the Cloud data center. As of OpenWorld, subnet support was announced so that you could define your own network range. One of the key feedbacks that Oracle got was that customers did not like creating a new subnet in their data center to match the Oracle subnet. They would rather define their own subnet in the Oracle Cloud to match the subnets that they have in their own data center.
Let's take each of these components one at a time. First the Corente Gateway running in your data center. This is a virtual image that you download or software components that you install on a Linux system and run in your data center. The concept here is that you have a (virtual) computer that runs in your data center. The system has two network interfaces attached. The first can connect to the public internet through network address translation or is directly connected to the internet or through a router. The second network interface connects to your private subnet. This IP address is typically not routable like a 10. or 192.168. network. There is not mistake that your are hoping to get to a machine on the internet because these networks are non-routable. The key is that the Corente Gateway actually has a listener that looks for communications intended for this non-routable network and replicates the packets through a secure tunnel to the Corente Gateway running in the Oracle Cloud. All of the traffic passes from your local network which is non-routable to another network hundreds or thousands of miles away and gives you the ability to talk to more computers on that network. This effectively gives you a private virtual network from your data center to a cloud data center.
Rather than using a software virtual gateway you can use a hardware router to establish this same connection. We are not going to talk about this as we go through our setup exercises but realize that it can be done. This is typically what a corporation does to extend resources to another data center, another office, or a cloud vendor for seasonal peak periods or cheaper resources. The benefit to this configuration is that it can be done by corporate IT and not by an individual.
The key things that get setup during this virtual private network connection are name parsing (DNS), ip routing (gateways and routers), and broadcast/multicast of messages. Most VPN configurations support layer 3 and above. If you do a arp request the arp is not passed through the VPN and never reaches the other data center. With Corente it uses the GRE tunneling protocol which is a layer 2 option. Supporting layer 2 allows you to route ping requests, multicast requests, and additional tunnel requests at a much lower and faster level. As we discussed in an earlier blog, Microsoft does not allow layer 2 to go into or out of their Azure cloud. Amazon allows layer 2 inside their cloud but not into and out of their cloud. This is a key differentiator between the AWS, Azure, and Oracle clouds.
The second component of the virtual private network is the Oracle Cloud Corente Gateway. This is the target side where the gateway in your data center is the initiator. Both gateways allow traffic to go between the two networks on the designated subnet. Both gateways allow for communication between servers in the data center and servers in the Oracle cloud. When you combine the VPN gateways with the Security Lists and Security Rules you get a secure network that allows you to share a rack of server and not worry about someone else who is using the Oracle Cloud from accessing your data center even if they are assigned an IP address on the same subnet. When you define a Security List or Security Rule, these exceptions and holes allow for traffic from computers in your account to access the VPN. No one else in the same rack or same cloud data center can access your VPN or your data center.
The third component is the app net management service portal. This portal establishes connections and rules for the other two components. When you install each of the components it communicates with the admin portal to get configuration information. If you need to change a configuration or keys or some aspect of the communication protocol this is done in the admin portal and it communicates to the other two components to update the configuration. This service also allows you to monitor traffic and record traffic between the Oracle Cloud and your data center.
The network resources for your data center installed service will look like
with br0 being your public facing connection and br1 connecting to your subnet in your data center. A similar configuration is done in the Oracle Cloud but this is pre-configured and can be provisioned as a public image. The only thing that you need to configure is the subnet address range and relationship with the app net management service portal.
Today was a lot of theory and high level discussions. Tomorrow we will dive into configuration of the gateway in your data center. The day after that we will look at provisioning the gateway in the Oracle Cloud and connecting the two. Just a quick reminder, we talked about how to establish a connection between your desktop and a cloud server. By going the a VPN configuration we will get around having to hide a server in the cloud. We can setup all of our servers to have private network links and only open up web servers or secure web servers to talk to the public internet. We can use ssh and rdp from our desktops at home or in our offices to communicate to the cloud servers. Setting up the VPN is typically a corporate responsibility and giving you access to the resources. What you need to know are what cloud resources you have access to and how much money you have in your budget to solve your business problem.