StrongSwan: Securely cross-linked
When servers need to communicate with each other...
It may happen that one server isn't enough for a particular project or you just
want to make use of redundancy to provide for a server failure – or simply to
distribute the tasks that incur within a network across several servers so that
one of them doesn't have to take the full load. There are many reasons why
servers need to communicate with each other. However, all scenarios have one
thing in common: A network connection must be established between the involved
servers.
This isn't a problem only when you may link the servers by means of a network
that is independent from the 'Net so that the data stream doesn't have to leave
the section in which the servers are residing. Here you can simply set up
another network to which the servers have access.
When a LAN isn't available...
Unfortunately there are a lot of scenarios that make this impossible. For example, what about boxes that don't have a connection to such a LAN, or what about boxes that reside in different data centers that don't have a physical connection to each other? Here you are bound to establishing a connection via the Internet that permits the server to communicate with each other.
However, in this case it is mandatory that you don't leave this connection
unprotected, because otherwise you can only wager a guess on who could be doing
what, and in order to achieve this, IPsec virtually obtrudes itself on you.
As described in the previous chapter IPsec
prevents reading along and manipulating the data stream and so establishes a
network connection that can be seen equal to a wired, private LAN. Whatever is
transmitted there stays confidential and that which can be seen by outsiders
can confidently be described as noise, because the the transferred data
resembles like a random sequence of symbols.
This way your serves may securely communicate with each other; you only have to
see to not take on any bad eggs, but that shouldn't be a problem when you watch
out whom you are granting permission to connect.
Closing the gap
In order to bridge the space between the servers all you need to do is setting
up StrongSwan at both ends and instruct each to connect with the other
respectively. However, it isn't necessary to keep the connection open at all
times. It is merely necessary to open it again when the servers need to
exchange data, but you also may instruct StrongSwan to do so.
After successfully establishing the connection you may unblock everything that
is needed for inter-server communication. This may be an NFS, for example to
expand the hard disk space available for a server. This permits setting up a
central web server that hosts multiple domains, for example, whose
subdirectories can be distributed across multiple servers. Or you spread
different parts of your web project across multiple servers, e. g. divided by
topic.
You may also relocate authentication against a RADIUS server to another box as
well as a potentiyl MySQL database or your LDAP or NIS server. Your options are
virtually unlimited here.
It is also possible to set up a server so that it regularly collects and stores backups from other servers – and does an automatic playback when the need arises, e. g. after a server has failed and now has to be completely set up again. In this case you only have to reestablish the connection to your backup server which is going to take care of the rest.
to the topAccess to the network at home
You may even set up an access point to your network at home the same way. For
this you merely need a small server on which you set up IPsec (virtual server
aren't necessarily suitable for this when improperly configured – please ask
your provider for details in this case) and have to leave your IPsec gateway at
home running. You may directly access your local network via the IPsec tunnel
in this case, and since a virtual IP address is assigned to your IPsec gateway
inside of the tunnel you don't have to figure out the current public IP address
of your gateway, but you can instead use the inner IP address – and when
everything has been properly set up you may even access the network behind as
if you are connected directly to your LAN at home.
The only thing that you need to ascertain is that no stranger can intrude your
private LAN by means of your server – but this doesn't constitute a problem at
all with the proper safeguards.