Überblick

OpenVPN leitet IP-Verbindungen durch unsichere Netze mithilfe kryptographisch gesicherter Tunnel. Die Nutzdaten werden mit SSL / TLS verschlüsselt, wodurch eine hohe Abhörsicherheit erzielt wird. Die OpenVPN-Software läuft als Hintergrundprozeß ("Daemon"), die Anbindung an den IP-Stack des jeweiligen Betriebssystemes wird durch einen Tunnel-Driver hergestellt.

Der Vorzüge von OpenVPN gegenüber PPTP oder IPsec sind Portabilität, offene Standards und einfache Konfiguration. Für folgende Systeme ist OpenVPN verfügbar:

Ein VPN besteht aus:

  • Einem Server, der den Zugang zum virtuellen Netz kontrolliert und das Routing zwischen den Clients und Nicht-VPN-Netzen regelt,
  • Mehreren Clients, die durch einen VPN-Tunnel mit dem Server kommunizieren. Mit Umweg über den Server ist so auch eine Client-zu-Client-Kommunikation möglich, sofern die Routing-Regeln des Servers dies zulassen. Im Freifunk will man das aber eher nicht.

Im üblichen Aufbau von OpenVPN-Netzen melden sich die Clients über ein SSL-Zertifikat am Server an, wobei der CN (Canonical Name) des Zertifikates als Rechnername verwendet wird, um die korrekte Netzwerk-Konfiguration des Client zu bestimmen. Mehrere Clients können dasselbe Zertifikat benutzen, sofern der Server passend konfiguriert ist.

Einrichtung

Für ein einfaches Client / Server-Setup wird benötigt:

  • SSL-Zertifikate für alle Beteiligten. Um die kostengünstig (umsonst) und einfach zu erhalten, sei eine Anmeldung bei CaCert empfohlen.
  • Ein Netzwerkplan für das VPN, um folgende Fragen zu klären (Melle, bitte ergänzen):
    • Welche LAN-Adressen (nach RFC 1918) sollen für das VPN verwendet werden? Im Folgenden sei 10.0.0.x für das VPN angenommen.
    • Wer darf mit wem kommunizieren? Welches Routing und welche Firewall-Regeln werden dazu auf dem Server benötigt? Bis auf weiteres sei davon ausgegangen, daß Clients Verbindungen ins Internet nutzen dürfen, aber nicht untereinander kommunizieren sollen.
    • Welche Namen haben die VPN-Teilnehmer? Nachfolgend sei vpn-client.freifunk-potsdam.de bzw. vpn-server.freifunk-potsdam.de angenommen.
    • Wo soll der Server laufen? Auf einem AP nahe einem schnellen Uplink oder ganz weit draußen im Internet? Die folgenden Configs gehen von einem AP auf der IP 192.168.1.2 aus, der über das Gateway 192.168.1.1 mit dem Internet verbunden ist.

SSL-Certs

Benötigt werden mindestens ein Server-Cert, und mindestens ein Client-Cert. Um ein Cert zu erstellen, wird ein Key benötigt. Mit OpenSSL geht das so:

openssl genrsa -out vpn.key 2048

Um ein Cert zu erzeugen, braucht man zunächst ein CSR (Certificate Signing Request):

openssl req -new -key vpn.key -out vpn.csr

Es folgt ein Frage-und-Antwort-Spiel. Dabei ist die einzig wichtige Frage: Common Name (eg, YOUR name). Dort den jeweiligen Rechnernamen eintragen, z.B. vpn-server.freifunk-potsdam.de bzw. vpn-client.freifunk-potsdam.de.

Die CSRs klebt man der Reihe nach in das Eingabefeld bei CaCert (unter Server CertificatesNew). Postwendend erhält man ein halbwegs glaubwürdiges Zertifikat. Außerdem braucht man noch das Root-Cert von CACert.

Die Gültigkeitsdauer der Zertifikate beträgt 6 Monate bis 2 Jahre, abhängig von den Assurance-Punkten des Antragstellers. Herrmann kann Punkte vergeben; dk kann Certs bis zu 2 Jahren ausstellen.

Für die Clients kann man entweder individuelle Zertifikate benutzen, oder aber ein Sammel-Zertifikat für alle VPN-Nutzer. Da der Verwaltungsaufwand für individuelle Zertifikate höher ist, und diese in einem prinzipiell offenen Netz nicht wirklich benötigt werden, sei im Folgenden von einem Sammelzertifikat ausgegangen.

Man kann unterschiedliche Keys für Server- und Client-Zertifikate nutzen, aber das bringt nicht wirklich etwas.

Server-Config

Noch nicht final, weil kein VPN-Plan vorhanden

Die Server-Config besteht aus:

  • Der globalen Konfiguration /etc/openvpn/server.conf
  • Einer Konfigurationsdatei pro Client in /etc/openvpn/ccd. Diese muß so heißen wir der Common Name im Client-Cert, in unserem Fall also vpn-client.freifunk-potsdam.de.

Die globale Config in /etc/openvpn/server.conf sieht dann so aus:

port 33469
proto udp

dev tun0

ca /etc/ssl/certs/cacert.org.pem
cert /etc/openvpn/vpn-server.crt
key /etc/openvpn/vpn.key
dh dh1024.pem

server 10.0.0.0 255.255.255.0 

user nobody
group nogroup

client-config-dir ccd
ccd-exclusive
duplicate-cn
keepalive 10 120

comp-lzo

persist-key
persist-tun 

status openvpn-status.log

In /etc/openvpn/ccd befindet sich eine Konfigurationsdatei pro Client, die exakt so heißen muß wie der CN im Zertifikat des Clients, also /etc/openvpn/ccd/vpn-client.freifunk-potsdam.de:

push "redirect-gateway"

Client-Config

Die Clients werden alle identisch konfiguriert, wobei die Zertifikate in client.crt alle denselben CNs vpn-client.freifunk-potsdam.de haben:

client
dev tun
proto udp
remote vpn-server.freifunk-potsdam.de 33469
nobind
persist-key
persist-tun
ca root.crt
cert client.crt
key vpn.key
comp-lzo
verb 3
mute 20

Routing / Firewall

Der Server sollte prinzipiell routen können. Klingt blöd, wird aber gerne vergessen:

echo 1 > /proc/sys/net/ipv4/ip_forward

Die Server-Config (oben) setzt die richtigen Routing-Einträge. Es fehlen nur noch ein paar iptables-Regeln, damit Clients nicht untereinander kommunizieren, und für das Masquerading der VPN-Adressen. Als Runlevel-Skript, z.B. in /etc/init.d/firewall sieht das so aus:

#!/bin/sh

IPTABLES="/sbin/iptables"
MODPROBE="/sbin/modprobe"
LOCAL_IP="192.168.1.2"

case "$1" in
 start)

       # load modules
       ${MODPROBE} ip_tables
       ${MODPROBE} ip_conntrack

       # VPN internet route 
       ${IPTABLES} -A FORWARD -i eth0 -o tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
       
       # masquerading
       ${IPTABLES} -t nat -A POSTROUTING -o eth0 -j SNAT --to-source ${LOCAL_IP}

       # Do not allow connections into the tunnels
       ${IPTABLES} -A OUTPUT -o tun0 -d 10.0.0.0/8 -m state --state ESTABLISHED,RELATED -j ACCEPT
       ${IPTABLES} -A OUTPUT -o tun0 -j REJECT
       ;;

 stop)
       ${IPTABLES} -F INPUT
       ${IPTABLES} -F FORWARD
       ${IPTABLES} -F OUTPUT
       ${IPTABLES} -t nat -F POSTROUTING
       ${IPTABLES} -P INPUT ACCEPT
       ${IPTABLES} -P FORWARD ACCEPT
       ${IPTABLES} -P OUTPUT ACCEPT 
       ;;

 restart)
       $0 stop
       $0 start
       ;;
esac

Client-Anleitung

  • Erzeuge Dir einen privaten Schlüssel
openssl genrsa -out vorname_nachname.key 2048
  • Erzeuge Dir einen Certificate Request
openssl req -new -key vorname_nachname.key -out vorname_nachname.csr
  • Schicke uns die Datei vorname_nachname.csr
  • Du bekommst von uns eine Datei vorname_nachname.cert
  • Das Verzeichnis in dem du nun deinen OpenVPN Client konfigurieren kannst ist je nach Betriebssystem entweder /etc/openvpn/client.ovpn oder c:\Programme\OpenVPN\config\client.ovpn (bei Windows kann man es natürlich auch woanders hin installiert haben)
    • kopiere die Dateien vorname_nachname.cert und vorname_nachname.key in diese Verzeichnis
    • erstelle eine Config-Datei folgendem Inhalt.
client
dev tun
proto udp
remote vpn.freifunk-potsdam.de 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca '''ca.crt'''
cert '''vorname_nachname.cert'''
key '''vorname_nachname.key'''
comp-lzo
verb 3
  • Lade das class3 und class1 Root-Zertifikat von cacert.org herunter. Kopiere beide Zertifikate hintereinander in eine Textdatei c:\Programme\OpenVPN\config\ca.crt.
    • unter Linux kannst du alternativ auch im Verzeichnis /etc/openvpn/ wget https://www.bastla.net/config/ca.crt eingeben. Bitte bedenke allerdings diese Datei (die Zertifikate darin) noch einmal mit denen von CaCert zu vergleichen.
  • Wähle im Kontextmenü der OpenVPN GUI die Option connect.
  • wenn du unter Linux den Konsolen OpenVPN Client nutzt, kann es sein, dass er die Routen nicht automatisch setzen kann. Falls das so ist, ändere die Konfigurationszeile remote vpn.freifunk-potsdam.de 1194 durch remote 78.47.210.100 1194 (halt die IP von iggy) und gebe folgendes in die Shell ein:
# lösche alte default Route (in dem Beispiel ppp0, was eine Modemschnittstelle ist)
# wenn ihr nicht wisst was eure default Route ist schaut mit 'route -n' nach
route del default ppp0 

# Den Weg zu iggy (VPN Server) weisen: 
route add -host 78.47.210.100 dev ppp0 

# Nun das VPN starten (yourConfig ist eure Konfigurationsdatei):
openvpn --config [yourConfig].ovpn  

# Default Route für alle INet Anfragen auf den VPN Tunnel zeigen lassen:
route add default tun0

# Wenn man wie in meinem Fall durch Einwählen über das Handy im VPN des
# Netzbetreibers seid, dann ist dessen DNS natürlich nicht mehr erreichbar.
# Damit der Rechner weiterhin Domains auflösen kann gibt man ein:
echo "nameserver 141.1.1.1" >> /etc/resolv.conf

Nun sollte es funktionieren. Bei Problemen meldet euch bei uns - am Besten bei einem Treffen oder auf der Mailingliste