|
|
| Zeile 1: |
Zeile 1: |
| == Ü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: [http://openvpn.se/ GUI + Installer]
| |
| * Mac OS X: [http://tunnelblick.net/ 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 [http://cacert.org 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 <tt>10.0.0.x</tt> 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 <code>vpn-client.freifunk-potsdam.de</code> bzw. <code>vpn-server.freifunk-potsdam.de</code> 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 <tt>192.168.1.2</tt> aus, der über das Gateway <tt>192.168.1.1</tt> 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: <code>Common Name (eg, YOUR name)</code>. Dort den jeweiligen Rechnernamen eintragen, z.B. <code>vpn-server.freifunk-potsdam.de</code> bzw. <code>vpn-client.freifunk-potsdam.de</code>.
| |
|
| |
| Die CSRs klebt man der Reihe nach in das Eingabefeld bei [http://www.cacert.org/ CaCert] (unter <tt>Server Certificates</tt> → <tt>New</tt>). Postwendend erhält man ein halbwegs glaubwürdiges Zertifikat. Außerdem braucht man noch das [http://www.cacert.org/certs/root.crt 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 <code>/etc/openvpn/server.conf</code>
| |
| * Einer Konfigurationsdatei pro Client in <code>/etc/openvpn/ccd</code>. Diese muß so heißen wir der Common Name im Client-Cert, in unserem Fall also <code>vpn-client.freifunk-potsdam.de</code>.
| |
|
| |
| Die globale Config in <code>/etc/openvpn/server.conf</code> 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 <code>/etc/openvpn/ccd</code> befindet sich eine Konfigurationsdatei pro Client, die exakt so heißen muß wie der CN im Zertifikat des Clients, also <code>/etc/openvpn/ccd/vpn-client.freifunk-potsdam.de</code>:
| |
| push "redirect-gateway"
| |
|
| |
| === Client-Config ===
| |
| Die Clients werden alle identisch konfiguriert, wobei die Zertifikate in <code>client.crt</code> alle denselben CNs <code>vpn-client.freifunk-potsdam.de</code> 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 <tt>iptables</tt>-Regeln, damit Clients nicht untereinander kommunizieren, und für das Masquerading der VPN-Adressen. Als Runlevel-Skript, z.B. in <code>/etc/init.d/firewall</code> 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 == | | == Client-Anleitung == |
|
| |
|