Wie man den kompletten Internet-Verkehr über OpenVPN tunnelt

Ein Anwendungsszenario für OpenVPN ist es, den gesamten Internet-Verkehr zu tunneln, weil man sich z.B. gerade in einem nicht vertrauenswürdigen Netz (z.B. unverschlüsseltes WLAN) aufhält und gezwungen ist, unverschlüsselte Protokolle zu benutzen oder bestimmte Dienste blockiert sind. Es wird davon ausgegangen, daß der OpenVPN-Server sich in einem zumindest vertrauenswürdigeren Netzwerk befindet.

Im Folgenden wird eine mögliche Konfiguration beschrieben unter RHEL / CentOS 4.

Da OpenVPN auf den Einsatz von SSL-Zertifikaten setzt, muß zunächst einmal eine eigene Certification Authority (CA) eingerichtet werden. Das OpenVPN-EPEL-Packet für CentOS4 bringt dafür schon eine einigermaßen komfortable Skriptsammlung namens Easy-RSA mit, die man in /usr/share/openvpn/easy-rsa/2.0/ findet.

Die CA wird wie in der README-Datei beschrieben mit pkitool aufgesetzt. Zum Erzeugen der  DH-Parameter muß noch das Script ./build-dh aufgerufen werden.

Die Konfiguration in /etc/openvpn/server.conf sieht dann wie folgt aus (zur Erklärung siehe die einzelnen Kommentare):

# Use some non-standard port:
port 14533

# UDP should be used preferably, as it tuneling ip over TCP is generally a
# bad idea:
proto udp

# Route IP packets, not ethernet frames. We don't want to interconnect on
# MAC layer:
dev tun

# Crypto stuff:
ca /etc/openvpn/ca.crt
cert /etc/openvpn/servername.de.crt
key /etc/openvpn/servername.de.key
dh /etc/openvpn/dh2048.pem

# server mode is needed for multiclient capability
mode server

# Allocate a /30 subnet per client.
# p2p would allocate a single IP address per client but cannot be used
# together with windows clients
# This is already the default, but we set it explictely.
topology net30

# Activate inter-client routing
client-to-client

# server is a helper directive and expands to:
#
# ifconfig 10.8.3.1 10.8.3.2
# => Local endpoint (server) is 10.8.3.1, remode (client) is 10.8.3.2
#
# ifconfig-pool 10.8.3.4 10.8.3.251
# => IP range to choose /30 nets for clients
#
# route 10.8.3.0 255.255.255.0
# => Add route to client subnet on server side
#
#    if client-to-client:
#       push "route 10.8.3.0 255.255.255.0"
#    else if topology == net30:
#       push "route 10.8.3.1"
# => Add routing on client side, either only to server or to other clients too
server 10.8.3.0 255.255.255.0

# Store mapping client<->IP, so that IP is not changed every time client
# reconnects:
ifconfig-pool-persist ipp.txt

# Shortcut to
#   ping 10
#   ping-restart 120
#   push "ping 10"
#   push "ping-restart 60"
# Useful for stateful firewalls to not timeout udp connections and for
# OpenVPN to detect and restart broken down connections.
# In case of no traffic send every 10 seconds a ping packet from server to
# client and vice versa (push option).
# On server restart client connection after 120 seconds without ping receiption.
# On client restart whole client on client after 60 seconds without ping
# receiption. This forces also re-resolve server hostname, useful if server
# hostname is provided e.g. by dyndns.org and IP changes from time to time.
keepalive 10 60

# Clear connection / tun device after 10 minutes of inactivty
inactive 600

# Clients should route all internet traffic trough this VPN
# Also prevents error messages like
# "MULTI: bad source address from client [1.2.3.4], packet dropped" in servers log
push "redirect-gateway def1"

# Server may turn on compression if it detects compressable data.
# Needs to be set on client to to allow push.
comp-lzo adaptive

# Use own user/group to seperate privileges:
user openvpn
group openvpn

# Don't re-read key file on SIGUSR1 or ping-restart.
# Useful on restart when process is no longer root.
persist-key

persist-tun
status openvpn-status.log
verb 

Der IP-Adressen-Pool für die Clients (10.8.3.0/24 in diesem Fall) darf weder auf Server- noch auf Client-Seite verwendet werden. Dadurch ergibt sich potentiell folgendes Problem: Wenn man nicht gerade ein paar offizielle IPs übrig hat, wird man gezwungen sein, private IP-Adressenbereiche einzusetzen. Als Road-Warrior weiss man aber nicht immer, mit welchem privaten IP-Adressen-Bereich man es im lokalen Netzwerk vor Ort zu tun hat. Eine mögliche, aber wenig praktikable Lösung wäre schlich mehrere Server mit IP-Adressenbereichen laufen lassen.

Auf dem Server muß noch Routing aktiviert sein. Sonst kann ein OpenVPN-Client nur mit dem Server sprechen. Dazu in der Datei /etc/sysctl.conf die folgende Zeile setzen:

net.ipv4.ip_forward = 1

Anschließend geht es darum, die eingesetzen privaten Adressen zu NATen (Shell-Eingabe):

iptables -t nat -A POSTROUTING -o eth0 -s 10.8.3.1/24 -j MASQUERADE

service iptables save

Der letzte Befehl sorgt dafür, daß die aktuellen Firewall-Einstellungen nach /etc/sysconfig/iptables geschrieben werden, wo sie das System beim Starten von /etc/init.d/iptables wieder herstellt.

Die Client-Konfiguration ist ein wenig übersichtlicher:

# We run in client mode, use tun dev and UDP
client
dev tun
proto udp

# The remote name as defined in server config
remote servername.de 14533

# Only connect to a server which provides a valid certificate with this
# specific common name, don't allow openvpn connections to other hosts:
tls-remote servername.de

# Crypto stuff
ca ca.crt
cert desktop.crt
key desktop.key

persist-key
persist-tun

# Allow server to use adaptive compression with push:
comp-lzo
verb 3