Quick instructions:
CID=$(docker run -d --privileged -p 443:443/tcp --net=host 0x4139/openvpn)
docker run -t -i -p 8080:8080 --volumes-from $CID 0x4139/openvpn serveconfig
Now download the file located at the indicated URL. You will get a
certificate warning, since the connection is done over SSL, but we are
using a self-signed certificate. After downloading the configuration,
stop the serveconfig
container. You can restart it later if you need
to re-download the configuration, or to download it to multiple devices.
The file can be used immediately as an OpenVPN profile. It embeds all the required configuration and credentials. It has been tested successfully on Linux, Windows, and Android clients. If you can test it on OS X and iPhone, let me know!
If you reboot the server (or stop the container) and you docker run
again, you will create a new service (with a new configuration) and
you will have to re-download the configuration file. However, you can
use docker start
to restart the service without touching the configuration.
When the 0x4139/openvpn
image is started, it generates:
- Diffie-Hellman parameters,
- a private key,
- a self-certificate matching the private key,
- an OpenVPN client profile.
Then, it starts two OpenVPN server processes (one on 1194/udp, another on 443/tcp).
We use tun
mode, because it works on the widest range of devices.
tap
mode, for instance, does not work on Android, except if the device
is rooted.
The topology used is net30
, because it works on the widest range of OS.
p2p
, for instance, does not work on Windows.
The TCP server uses 192.168.255.0/24
and the UDP server uses
192.168.255.128/24
.
For simplicity, the client and the server use the same private key and
certificate. This is certainly a terrible idea. If someone can get their
hands on the configuration on one of your clients, they will be able to
connect to your VPN, and you will have to generate new keys. Which is,
by the way, extremely easy, since each time you docker run
the OpenVPN
image, a new key is created. If someone steals your configuration file
(and key), they will also be able to impersonate the VPN server (if they
can also somehow hijack your connection).
It would probably be a good idea to generate two sets of keys.
It would probably be even better to generate the server key when
running the container for the first time (as it is done now), but
generate a new client key each time the serveconfig
command is
called. The command could even take the client CN as argument, and
another revoke
command could be used to revoke previously issued
keys.