I recently had a scenario where I needed to connect servers belonging to:
- Digitalocean, on data center X
- Digitalocean, on data center Y
- A private data center
and each architecture needed to be replicated on a number of "logical" environments (e.g. 'development', 'testing', 'production').
They needed to "see" each other, in a secure way.
Note that virtual machines on Digitalocean (they call them 'droplets') can belong to different data centers. When the droplets use the optional private interface there are two things to consider:
1. Traffic inside the same data center is potentially visible to any equipment on the same data center.
In other words, the fact that two droplets belong to the same customer account doesn't mean that their private traffic is isolated from any other traffic belonging to droplets on other accounts.
You are responsible to secure that traffic.
2. Droplets on different data centers cannot directly communicate via their private interfaces. This is intuitive but nevertheless important to highlight.
This of course screamed for a VPN, and I directed my attention to openvpn. As for the rest of the system and application setup I wanted to use Puppet to manage the client and server configuration with openvpn.
A quick search on Puppet Forge brought me to luxflux' openvpn module, which at that moment was the most popular. I experimented a little with it and found it working properly, on the debian virtual machines I was using.
You need just some designing of the private network addressing, and you'll be fine.
The key point to use this module is understanding that each VPN client you declare on the VPN server will cause the generation of client certificates on the server machine. You then need to copy them into the VPN client hosts.
On the server side I just needed three elements:
1. Server configuration (some elements omitted/changed on purpose):
2. Define the list of clients:
3. For each client, define the IP address, e.g.:
On the client side I've created a new Puppet module. It just installs the certificates and keys generated by the openvpn module running on the server host, then instructs the openvpn client to connect to the remote VPN server. (This is a fairly generic module, so it could probably be open sourced).
To make the architecture easier to understand, I assigned a different subnet for each "real" data center. So, even if the clients all belong to the same VPN, at a glance you can see what's the hosting data center.
The VPN server is on one of the data centers, and clients can connect securely on the public interface. An additional level of security was to firewall access to the openvpn listening port (with iptables), so that only authorized source IP addresses could potentially be used to build the VPN.
During this work I submitted a few patches, which the author has kindly accepted to merge:
1. Add an optional parameter to enable the client-to-client option
2. Add optional parameters to enable the openvpn management interface
3. Add an option to remove a client-specific configuration file (for example when a client is removed from the VPN).
You can see the commits here.
I hope this is useful; please let me know if you're interested in a specific or more detailed example.
Please also see my other open source Puppet modules (puppet-asterisk and puppet-kamailio) and feel free to comment, raise issues and contribute!
A previous post about applications deployment with Puppet, related to Kamailio, can be found here.
- Digitalocean, on data center X
- Digitalocean, on data center Y
- A private data center
and each architecture needed to be replicated on a number of "logical" environments (e.g. 'development', 'testing', 'production').
They needed to "see" each other, in a secure way.
Note that virtual machines on Digitalocean (they call them 'droplets') can belong to different data centers. When the droplets use the optional private interface there are two things to consider:
1. Traffic inside the same data center is potentially visible to any equipment on the same data center.
In other words, the fact that two droplets belong to the same customer account doesn't mean that their private traffic is isolated from any other traffic belonging to droplets on other accounts.
You are responsible to secure that traffic.
2. Droplets on different data centers cannot directly communicate via their private interfaces. This is intuitive but nevertheless important to highlight.
This of course screamed for a VPN, and I directed my attention to openvpn. As for the rest of the system and application setup I wanted to use Puppet to manage the client and server configuration with openvpn.
A quick search on Puppet Forge brought me to luxflux' openvpn module, which at that moment was the most popular. I experimented a little with it and found it working properly, on the debian virtual machines I was using.
You need just some designing of the private network addressing, and you'll be fine.
The key point to use this module is understanding that each VPN client you declare on the VPN server will cause the generation of client certificates on the server machine. You then need to copy them into the VPN client hosts.
On the server side I just needed three elements:
1. Server configuration (some elements omitted/changed on purpose):
openvpn::server { $::fqdn :
country => '...',
province => '...',
city => '...',
organization => '...',
email => '...',
local => '0.0.0.0',
proto => 'udp',
server => '10.19.0.0 255.255.0.0',
ipp => true,
c2c => true,
keepalive => '10 120',
management => true,
management_ip => 'localhost',
management_port => 7543,
}
2. Define the list of clients:
openvpn::client { [
'vm1',
'vm2',
'vm3',
]: server => $::fqdn,
}
3. For each client, define the IP address, e.g.:
openvpn::client_specific_config { 'vm1':
server =>$::fqdn,
ifconfig => '10.19.28.101 10.19.28.102'
}
On the client side I've created a new Puppet module. It just installs the certificates and keys generated by the openvpn module running on the server host, then instructs the openvpn client to connect to the remote VPN server. (This is a fairly generic module, so it could probably be open sourced).
To make the architecture easier to understand, I assigned a different subnet for each "real" data center. So, even if the clients all belong to the same VPN, at a glance you can see what's the hosting data center.
The VPN server is on one of the data centers, and clients can connect securely on the public interface. An additional level of security was to firewall access to the openvpn listening port (with iptables), so that only authorized source IP addresses could potentially be used to build the VPN.
During this work I submitted a few patches, which the author has kindly accepted to merge:
1. Add an optional parameter to enable the client-to-client option
2. Add optional parameters to enable the openvpn management interface
3. Add an option to remove a client-specific configuration file (for example when a client is removed from the VPN).
You can see the commits here.
I hope this is useful; please let me know if you're interested in a specific or more detailed example.
Please also see my other open source Puppet modules (puppet-asterisk and puppet-kamailio) and feel free to comment, raise issues and contribute!
A previous post about applications deployment with Puppet, related to Kamailio, can be found here.