i'm using several OpenVPN tunnel to connect my laptop to different private networks provided by:
my traffic to these networks (assuming that they are using distinct private networks) gets routed over the internet through an encrypted tunnel. my internet traffic goes through my default route using through ISP. that's fine when i'm at home or work, where i can control the network environment. but during vacation i often find myself using an untrusted default route or even public unencrypted WI-FI. there i cannot control the network envireonment. i don't know about their data privacy policies and don't want my traffic be scanned (or even altered).
all my VPNconnections are safe, my mail-client uses encryption, SSH does its own encryption, but most of my web-traffic is unencrypted. since i've already setup several VPN connections i want to use one of them to route all my traffic through.
here i describe a simple way to do this for gentoo linux by using an init script. this way it's easy to use, handles depencencies (is network configured?, is VPN tunnel started?) and integrates well with my system environment. the downside is that you won't have much fun using it out-of-the-box on other systems.
while i'm using OpenVPN for my VPN tunnel it doesn't matter what to use as long as it can handle routed traffic (using a virtual network device). so you can just use any equal VPN technology.
best viewed in clean style!
make sure you've already setup the following:
you don't actually need the first three services to be started, since gentoo's init framework will detect them as dependencies. just make sure they are prepared.
IPs used here are just an example. the configuration will refer to them.
all this script does is changing your default route to go through a previously established VPN tunnel. since the IP packets your tunnel is encapsulated in are going over your default route, it will break without injecting a hostroute to the VPN servers public IP, first:
removing the routing is basically reversing the above process:
preserving/restoring the original default route is optional and done only if there's one default route without a metric. if the default route has a metric (higher than 0) these route is less preferred and the original one can be kept.
download /etc/init.d/default-route_tunnel, make it executeable and create a symlink /etc/init.d/default-route_tunnel.work to it:
cd /etc/init.d/ wget http://struction.de/projects/gentoo_def_gw_tunnel/default-route_tunnel chmod a+x default-route_tunnel ln -s default-route_tunnel default-route_tunnel.work
create a config file /etc/conf.d/default-route_tunnel.work:
# init script openvpn.work needs to be started before RC_NEED="openvpn.work" # gateway of the tunnel (e.g. OpenVPN server with IP forwarding enabled) # this should be an internal network GW_INTERNAL_IP=10.0.0.1 # external IP of the tunnel server GW_EXTERNAL_IP=198.51.100.100
start and stop it like any other gentoo init script:
/etc/init.d/default-route_tunnel.work start /etc/init.d/default-route_tunnel.work status /etc/init.d/default-route_tunnel.work stop
if you're using several VPN tunnel, you can create multiple symlinks to /etc/init.d/default-route_tunnel. e.g. /etc/init.d/default-route_tunnel.uni and /etc/init.d/default-route_tunnel.home.
now you can create the correspondinf config files /etc/conf.d/default-route_tunnel.work and /etc/conf.d/default-route_tunnel.work.
you can now choose between all your symlinked init scripts to decide which VPN tunnel you want to use for your default route. this way you can choose your IP visible from the internet. (sometimes university partner sites restrict access to come from the campus network)
keep in mind that you have to configure a trusted DNS server by yourself. keeping the one given to you from your potentially hostile local network still discloses some information and benefits man-in-the-middle-attacks. prefer a DNS server provided by your VPN private network or at least an unrelated from the internet (whose traffic gets routed through the default gateway).
this init script works well in simple network environments (one default route). however - if things are more complex it may break some assumptions. e.g. imagine multiple default routes for different devices with different metrics. it tries to guess and restore metrics, but you have to see for yourself if it works.
my default routes have metrics assigned, so that newly created routes automatically take precedence and the old ones don't have to be removed.