SSH tunneling
On the SSH client side (which can be whichever server in our setup) we enable VPN tunneling in "/etc/ssh/ssh_config"
cat <SSHEOF >>/etc/ssh/ssh_config
Tunnel yes
ServerAliveInterval 60
SSHEOF
On the corresponding SSH server side we enable VPN tunneling in "/etc/ssh/sshd_config" and then restart "sshd" daemon (the "ssh" service):
cat <SSHDEOF >>/etc/ssh/ssh_config
PermitTunnel yes
SSHDEOF
#
/etc/init.d/ssh restart
At this point an SSH VPN tunnel between two servers can be established as follows:
From one server (be that "Folsom2") acting as SSH client we initiate, an SSH connection to other server's public IP address -- be that "Folsom1" -- by logging in as root using a pre-shared key (this SSH key can be generated and distributed in advance using standard SSH mechanisms):
root@Folsom2:~# ssh -fNT -w 99:99 -v -2 -i ./tunnelkey root@<the_public_ip_address_of_Folsom1> /bin/true
As a result on both "Folsom2" and "Folsom1" we will have a "tun99" point-to-point interface. On both ends of the tunnel we can now use this interface for routing the traffic to the private IP address of the other server through the tunnel, as follows:
On server "Folsom2" we route all traffic to "Folsom1" private IP address through the "tun99" interface:
root@Folsom2:~# ifconfig tun99 0.0.0.0 mtu 9000
root@Folsom2:~# route add -host <the_private_ip_address_of_Folsom1> dev tun99
And then perform the corresponding actions on the "Folsom 1" server:
root@Folsom1:~# ifconfig tun99 0.0.0.0 mtu 9000
root@Folsom1:~# route add -host <the_private_ip_address_of_Folsom2> dev tun99
At this point all the traffic between the private IP addresses of "Folsom1" and "Folsom2" flows through the SSH tunnel as an unfiltered point-to-point link (i.e. traffic between the private IP addresses of server "Folsom1" and "Folsom2" is not subject to their respective Security Group constraints).
Same procedure can be performed between any other two nodes in our desired setup (with the corresponding adjustment in "tunXX" tunnel interface index via ssh's "-w" option and, respectively, the corresponding private IP addresses of the two servers).
A few notes on this procedure:
The procedure above assumes a "public IP address" and a "private IP address", with the "private IP address" being re-purposed (via adding a host route) to carry the tunnel traffic. While this is a typical scenario in public cloud environment, in e.g. a virtualized environment that role -- the "private IP address" used for the host route -- has to be substituted accordingly. This can be done by by e.g. assigning the "tunXX" interface IP addresses at both tunnel endpoints, as follows:
root@Folsom2:~# ifconfig tun99 192.168.1.1 192.168.1.2 mtu 9000
and, respectively, at the other end of the tunnel:
root@Folsom1:~# ifconfig tun99 192.168.1.2 192.168.1.1 mtu 9000
In this way we form a "numbered" point-to-point link between "Folsom1" and "Folsom2".
As mentioned above, this mechanism can be used for instantiating several overlay networks. While the dual IP addressing scheme use in public cloud environments allow us to re-purpose the "private IP address" as a numbering scheme for one of those overlays, for any additional networks that we need to instantiate we will need to devise a different IP addressing scheme between the nodes -- with one addressing scheme for each overlay network. One way this can be achieved is by assigning IP addresses to the tunnel endpoints (like illustrated above). Other, better alternatives are possible. However, this is outside the scope of this article so we will leave that as an exercise to the reader.
In a public cloud environment this procedure can be scaled-out to large number of nodes by automating those steps during server boot-up process and then cloning multiple servers from the resulting server image.