Advanced guide: Adding a private network to a City Cloud server

ozgurCity CloudLeave a Comment

All virtual servers in City Cloud come with a virtual network card and a public IP address assigned. This way, you can start accessing your server as soon as it boots up.

More often than not, we stumble against the decision of increasing security on our server, website or database. The scope of which exceeds the current post by several orders of magnitude, however today we are focusing on one, creating an internal network between our public website and our private database.

Read on to find out how.

Private networks

Private neworks are everywhere. If you have a router at home and several computers, you have a private network. If you dwell between the confines of an enterprise, you have a private network. These networks have computers connected against each other using a special private address (usually in the form of 192.168.x.x or 10.0.x.x). For further information, read here.

People use them for a variety of reasons. Mostly because you are not directly connected to the Internet and you need a router that can translate packets coming from the outside and redirect them transparently to nodes inside and vice versa (a process known as Network Address Translation or NAT for short). Sometimes you specifically set them up for increased security, since private computers can be shielded against attacks by the means of routers and firewalls.

How to do it

In City Cloud you get only one network card by default. This card has assigned a public IP address automatically (through DHCP).

At one point, you will probably ask yourself: What if I want a server that is not accessible directly from Internet?

The answer is, you need to have a private server. How do you make it private? Simple, by setting a private network. In order to do that, first you have to ask us to add a network just for you. Just contact us and we’ll assign a private network ID to your account.

Once we answer your request, you’ll have it available on your servers. Next step is to add a new virtual network card.

Go to server details, and click on the Network tab. Here you have all the network cards available for that server. Go ahead and click on the New Interface button. A popup will appear, here you need to select the new network we added, the name is arbitrarily set by us but as a rule of thumb, it’s the one that is not the default one.

Now, this is important. You will have to do this on all the servers you want to connect internally. In our tests we used two, but you can use any number of servers. Naturally, if you want a server with only a private address, you don’t need to add any new network cards since, as we mentioned, one is provided by default. In that case, you’ll basically change the current one.

Now, at this point, you should have a server with two network cards and one server with one private (or whatever you prefer). It’s time to set the internal ip address on both servers. We are going to edit the file that has the configuration of the network interfaces. In our example we used Debian, so please check with your distribution documentation. In any case, it usually is located under /etc/network/interfaces.

So, let’s load up your text editor of choice (Vim in our case) and edit the file.

vim /etc/network/interfaces

Basically, what you need to do is add the following lines to your file:

auto eth1

iface eth1 inet static

address 192.168.1.1

netmask 255.255.255.0

 

Some notes on this. Auto tells Linux to setup this card on system start or when restarting networking. The iface command tell us that this card has a static IP address (instead of an automatic assigned one via DHCP). And last, the addresspart sets the IP address. Here you can choose whatever you want, we have used 192.168.1.1 but you can use any valid private address. You can even use the same one, as your private network does not overlaps with any other private network.

So, in our example the public server has two network cards. One with a public IP address and one with a private one (192.168.1.1). You can go ahead and edit the other one (we used 192.168.1.2 for the second one), remember that if you only have one card you will probably have to use the interface eth0 instead of eth1 and remove any DHCP configuration (look for the line that says iface eth0 inet dhcp and remove it) . You can check all the available network cards with the command:

ifconfig –a

Finally, to test everything, we recommend you to restart your servers, just in case. A good practice that will give you peace of mind in the long term. If all went well, you should have now both servers communicated internally via private network. To check this just ping the other server and it should return the following:

ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=0.025 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.032 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=0.027 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=0.038 ms

That’s about it. You have now successfully configured your private network. From now on you can use this for several scenarios.

Possible uses

One common way this is used is when we have a database server connected to our website. We usually do not want to have our database server out in the open.

The other general usage of this is to have a gateway as a point of entry into our private network, and have several firewall rules that protect our servers from unwanted access.

Last but not least, you can have your entire private network connected to your own local network via VPN (with the entry point located on the public server). This is usually the case for companies that have services on the cloud.

Conclusions

What we just described is a mandatory step when dealing with production servers and faced with the need to scale.

Security is something that shouldn’t be an after thought but an integral part of the initial system design strategy.

Next stop, we’ll show you how to setup a simple firewall on Ubuntu. Trust us, at the end of the day, being able to go to sleep without those servers alarm ringing everywhere, is worth it.