OpenVPN-Server

Ü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:

• Linux: In den meisten Distributionen vorhanden.
• Windoze: GUI + Installer
• Mac OS X: Tunnelblick
• allen BSD Derivaten
• Solaris

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 Certificates → New). 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