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 alsovpn-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