Script to set up and tear down openvpn tunnels easily
Shell
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
hacking
BUGS
README
TODO
vpn-tunnel
vpn-tunnel-if-up-postdown

README

This is for easy and automatic setup of a VPN using openvpn in the
case where you've got root ssh access to the server, and, currently,
only have one client. It uses preshared keys, and ssh is used to share
the keys, get the necessary serverside information and set up and tear
down the openvpn daemon.

FEATURES:

 - should only need one single setting for configuration, the address
   (or name as configured in the ssh client configuration) of the
   server
 - tunnels everything, including DNS traffic
 - comes with hooks that when used will activate the tunnel whenever
   the network comes up

NOTE: a previous version of this script did selective routing of
traffic according to user/group ids; this has now been moved to a
separate 'selective' Git branch.


LIMITATIONS:

 - only tested on Debian

 - it currently probably only works for one client per server, unless
   you also change at least the following settings (UNTESTED): dev
   network server_port


DEPENDENCIES:

 - on both the client and the server, it requires some tools from my
   "chj-bin" repository to be present and accessible in PATH
   (ssh_config-ref, daemonize, is_if_up). These could relatively
   easily be replaced with something else or hard coded constants,
   the biggest difficulty will be to replace the use of the daemonize
   --restart and --status features with whatever the alternative tool
   provides.


SETUP:

Install the dependencies on both client and server:

 * chj tools
    cd /opt; mkdir chj; cd chj
    git clone https://github.com/pflanze/chj-bin.git bin
    git clone https://github.com/pflanze/chj-perllib.git perllib
    mkdir -p /usr/local/lib/site_perl/
    ln -s /opt/chj/perllib/Chj/ /usr/local/lib/site_perl/
    # add /opt/chj/bin to PATH in /root/.bashrc, or create symlinks
    #   to the used tools to a location in PATH
    # (ln -s /opt/chj/bin/{ssh_config-ref,is_if_up,daemonize} /usr/local/bin/
    # might do, I haven't verified this though.)

 * apt-get install openvpn

On client only:

 * cd /opt/chj
   git clone https://github.com/pflanze/openvpn-tunnel-setup.git
   # add to PATH if you like

 * create a file /etc/chj/vpn-tunnel.sh which contains a variable assignment
      sshserver=yourserver.yourdomain.yourtld
   or
      sshserver=yourservername
   if yourservername is defined in /etc/ssh/ssh_config; alternatively, define
   vpn-tunnel-server in ssh_config.

 * vpn-tunnel start  # or stop|restart|status, or startrouting|stoprouting|restartrouting

When the host interface (the interface where the encrypted traffic is
passing through) goes down, this needs to be issued:

 # vpn-tunnel stoprouting

and when the interface comes back up,

 # vpn-tunnel startrouting

Failing to issue the "stoprouting" (or "stop") command will lead the
openvpn process on the client to enter an endless recursion, because
when the host interface goes down it takes the route used by openvpn's
own encrypted traffic with it and hence that will take the route
through the VPN, hence leading to ever deeper encapsulation of the
always same packets, if my analysis is correct.

"stoprouting" and "startrouting" don't access the network, hence are
fast and "stoprouting" can be run when offline. "stop" and "start"
include stoprouting and startrouting calls. Unless there are
configuration changes or the client or server are rebooted, there's no
need to issue "stop"/"start"/"restart".

The need for stoprouting/startrouting actions can be fulfilled
automatically with:

  * cd /etc/network
  * ln -s /opt/chj/openvpn-tunnel-setup/vpn-tunnel-if-up-postdown if-up.d/
  * ln -s /opt/chj/openvpn-tunnel-setup/vpn-tunnel-if-up-postdown if-post-down.d/

If you use this and the VPN stops working, then probably the server
was rebooted, and you need to issue 'vpn-tunnel restart'.

Also, if the client is rebooted, the daemon on the client side is not
up anymore, and the VPN will not be activated in this case.

(Should it automatically restart the connection in these cases? 
Probably it should.)