= OpenVPN =

OpenVPN ist ein Softwarepaket, um ein VirtualPrivateNetwork zu
realisieren. Es ist modular
aufgebaut und unterstützt dadurch verschiedene
Verschlüsselungssysteme und auch Kompression.
Das Paket ist scheinbar die einzige VPN-Lösung, die eine
TLS-Infrastruktur für
Authentifizierungen nutzen kann, die auch von SSL benutzt wird.

== Basisprotokoll, Verträglichkeit mit Firewalls ==

Als Basisprotokoll wird UPD benutzt. Einerseits hat es als
verbindungsloses Protokoll keine
Probleme, die durch die Schachtelung von Protokollen auftreten
können (TCPueberTCP),
andererseits ist UDP durch Firewalls gut zu bearbeiten, freizugeben
(nur ein Prt freigeben
und fertig) und wird, da nur ein einziger UDP-Port benutzt wird,
auch evtl. von stateful
Firewalls durchgelassen, während andere Protokolle wie GRE
(VPNmitPPTP) und IPSec
(VPNmitIPSec) von manchen Firewalls nicht richtig erkannt werden.
Hat man eine Firewall, die
dies auch nicht kann, kann man OpenVPN ab Version 2 auch über TCP
betreiben.
(Alternativen siehe auch VirtualPrivateNetwork).

== Debian-Installation ==

Eigentlich installiert man nur das '''openvpn'''-Debian-Paket und
fertig! Die Konfiguration in ''/etc/openvpn'' ist weiter unten
beschrieben.

== Bedingungen an den Kernel ==

Normale Kernel sollten bereits richtig konfiguriert sein. Für
selbstgebackene muss die Unterstützung für das tun/tap-Device
eingeschaltet werden:

 Network-Device-Support / Universal TUN/TAP DEvice Driver Support -> (Y)es oder (M)odule

Wenn tuntap als Modul erzeugt ist, muss noch mit '''modconf'''
dafür gesorgt werden, das es
auch geladen wird.

Das Modul stellt das Device /dev/net/tun zur Verfügung. Dieses muss
ggf. noch manuell angelegt werden mit:

 mkdir /dev/net
 mknod /dev/net/tun c 10 200

== Konfiguration für die Verbindung von 2 Rechnern ==

Im Verzeichnis ''/etc/openvpn'' wird die Konfiguration abgelegt.
Zur Verschlüsselung gibt es ein etwas komplizierteres Verfahren,
das mit SSL arbeitet und ein einfacheres, das mit festen Schlüsseln
arbeitet. Ich habe hier letzteres benutzt. Dazu muss mit


 openvpn --genkey --secret /etc/openvpn/verbindung.key

eine Schlüsseldatei erzeugt werden. Diese muss sodann auf beide
beteiligte Rechner an die gleiche Stelle kopiert werden.

Dann muss eine Datei '''/etc/openvpn/verbindung.conf''' erzeugt
werden, die z.B. dieses enthält:

 remote adresseder.gegenstell.le
 float
 port 4711
 dev tun
 ifconfig 192.168.4.3 192.168.4.131
 persist-tun
 comp-lzo
 ping 30
 # verb 5
 secret /etc/openvpn/verbindung.key
 # Key erzeugen mit folgender Zeile und dann mit scp auf den anderen Rechner
 # schaffen:
 # openvpn --genkey --secret /etc/openvpn/verbindung.key

Auf der anderen Verbindungsseite müssen die ''ifconfig''-Adressen
entsprechend vertauscht werden. Damit sollte das VPN auch schon
laufen, wenn der Dienst mit '''/etc/init.d/openvpn restart''' neu
gestartet wird.

Der "remote"-Eintrag sollte aber nur auf einer Seite stehen, sonst
beschäftigt openvpn die
CPU ohne Unterlass --SusanneWenz

Will man mehrere Verbindungen aufbauen, werden einfach mehrere
''*.conf''-Dateien angelegt. Jede openvpn-Instanz läuft dann
getrennt von den anderen für einen Tunnel. Aber nicht vergessen,
dass für Jede neue "*.conf"-Datei auch ein extra Port verwendet
werden muss! Sonst geht es nicht.

Natürlich gibt es noch einige verschiedene Möglichkeiten, Parameter
anzugeben. Dazu sollte man aber am besten die Manpage zu openvpn
lesen. -- ThomasBayen

== Konfiguration als Server für mehrere Clients ==

Um OpenVPN als Server zu betreiben muß man eigene Zertifikate
anlegen und zwar eins zum Unterschreiben Eins für den
Server und für jeden Benutzer eins. Das ist einfacher als es sich
anhört:

Erstmal folgendes lesen: http://openvpn.net/howto.html#pki. Konkret
gebe ich hier nochmal in Kurzform an, welche Schritte wir gemacht
haben, um eine PKI-Infrastruktur aufzubauen:

=== Schlüsselerzeugung (z.B. auf einem dritten Rechner) ===

Die Schlüsselgenerierung kann auf einem beliebigen Rechner
stattfinden. Dies sollte nicht einer der OpenVPN-Endpunkte sein, da
man die CA (Certificate Authority) besser getrennt verwahrt (bzw.
auf eine Diskette schreibt und in den Tresor legt). Dort
installieren wir die Pakete '''openvpn''' und '''openssl''' Auf
diesem Rechner haben wir das Verzeichnis
''/etc/share/doc/openvpn/examples/easy-rsa'' nach ''/etc/openvpn''
kopiert. Dann gehen wir in dieses Verzeichnis.

Man kann die Einträge ''vars'' ganz am Ende der Datei anpassen, es
wird aber später ohnehin nochmals abgefragt.

 gunzip pkitools.gz
 chmod +x pkitools
 . ./vars
 ./clean-all
 ./build-ca
 ./build-dh

Die erzeugten Schlüssel befinden sich im Unterverzeichnis ''keys''.
Hier befinden sich jetzt die Dateien '''ca.crt''' (öffentlicher
Schlüssel) und '''ca.key''' (privater Schlüssel). Der letzte Befehl
hat Diffie-Hellmann-Parameter erzeugt, diese benötigt der Server.

Nun haben wir eine Zertifikat-Autorität, d.h. eine Art
"Ober-Instanz", um damit Schlüssel zu unterschreiben. Wer im Besitz
dieses CA-Schlüssels ist, kann neue Zertifikate ausstellen. Das
wollen wir jetzt tun:

 ./build-key-server server

Dabei muss der "Common Name" auf '''server''' gesetzt werden (ist
bei obigem Programmaufruf schon richtig vorgegeben). Bei "challenge
Password" drücken wir einfach "Return", um auf ein solches zu
verzichten, da unser OpenVPN von selber starten soll (ohne die
Eingabe eines Passwortes abzuwarten). Auch diese Schlüssel werden
im ''keys''-Verzeichnis erstellt. Sie heissen '''server.crt'''
(öffentlich) und '''server.key''' (privat).

Einen Client-Key erzeugt man nun mit dem selben Verfahren über den
folgenden Aufruf und ähnliche Einstellungen für den Client
"client1":

 ./build-key client1

=== Kopieren der Schlüssel ===

Nun kopieren wir

* auf den Server (nach ''/etc/openvpn/'')

 dh1024.pem        (benötigt nur der Server)
 ca.crt
 server.crt
 server.key

* auf den Client (nach ''/etc/openvpn/'')

 ca.crt
 client1.crt
 client1.key

=== Konfigurieren von OpenVPN ===

Auf den Server kommt dann folgende '''server.conf''':

 dev tap0
 ca ca.crt
 cert server.crt
 key server.key
 dh dh1024.pem
 mode server
 tls-server
 comp-lzo
 user nobody
 group nogroup
 persist-key
 persist-tun
 keepalive 30 120
 client-config-dir clientconfig

Im Verzeichnis ''/etc/openvpn/clientconfig'' kann ich
Konfigurationen für jeden Client ablegen, was allerdings bei einer
Bridge-Konfiguration normalerweise nicht nötig ist.

Auf den Client kommt folgende '''client1.conf''':

 dev tap0
 client
 ca ca.crt
 cert thinkpad_bridge.crt
 key thinkpad_bridge.key
 ns-cert-type server
 remote bayen.mine.nu
 float
 resolv-retry infinite
 comp-lzo
 user nobody
 group nogroup
 persist-key
 persist-tun
 keepalive 30 120

=== Bridging einrichten ===

Nun müssen wir eine Bridge sowohl auf dem Server als auch auf dem
Client einrichten. Dazu entfernen wir aus
''/etc/network/interfaces'' den auto-Eintrag für eth0 und schreiben
folgenden neuen:

 auto br0
 iface br0 inet static
       address 192.168.230.3
       netmask 255.255.255.0
       pre-up openvpn --mktun --dev tap0
       post-down openvpn --rmtun --dev tap0
       bridge_ports eth0 tap0

Dann starten wir das Interface und dann OpenVPN neu mit

 ifdown eth0
 ifup eth0
 /etc/init.d/openvpn restart

== Hardwarebeschleunigung ==

FranzLischka stellte die Frage nach einer Möglichkeit der
Hardwarebeyschleunigung. Eine Internet-Recherche hierzu hat
ergeben, das der einzige Ansatz hierzu unter Linux wohl über die
[http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ cryptlib] von
[http://www.cs.auckland.ac.nz/~pgut001/ Peter Gutmann] führt. Diese
wird jedoch scheinbar nicht von OpenVPN benutzt. Auf
http://www.closeconsultants.com/~peter/m0n0-ovpn-wifi.html steht
allerdings, das es doch irgendwie geht.



== <<DNS-Information ==

Obwohl es gute Befehle gibt, um das Routing über das VPN richtig einzustellen, gibt es keine direkte Lösung, um bei der Erzeugung einer VPN-Verbindung einen neuen Nameserver einzutragen. Man kann dies jedoch durch entsprechende up- und down-Skripte erreichen.

Unter Debian konfiguriert man nameserver am besten nicht direkt in der Datei ''/etc/resolv.conf'', sondern installiert das Paket '''resolvconf''' und überlässt diesem die Arbeit. Wer einen Nameserver im VPN benötigt, hat nämlich wahrscheinlich sowieso immer mal wieder verschiedene kompliziertere Netzwerksetups und da ist dieses Paket bei der Nameserver-Verwaltung sehr hilfreich. Ich habe dazu folgendes in die ''*.conf'' des Clients eingetragen:

 script-security 2
 up /etc/openvpn/meinclient.up
 down /etc/openvpn/meinclient.down

Die up- und down-Skripte sehen dann folgendermassen aus:

''/etc/openvpn/meinclient.up''

 #!/bin/bash
 echo -e "nameserver 192.168.1.1\nsearch lokaledomain.loc" | resolvconf -a $dev

''/etc/openvpn/meinclient.down''

 #!/bin/bash
 resolvconf -d $dev

In ''/etc/resolvconf/interfaces-order'' kann man bestimmen, in welcher Reihenfolge die verschiedenen Nameserver nun in der resolv.conf stehen, falls man Probleme bekommt. In der Praxis lasse ich alle meine Anfragen nun über meinen VPN-Nameserver laufen, kann das durch die Reihenfolge aber ändern.



== Links ==

* http://openvpn.net/ - die OpenVPN Homepage
* http://www.rm-f.de/drupal/node/10 - Tutorial mit Server-Keys und
Wiederrufen von Client-Keys
* http://freifunk.net/wiki/OpenVPN - Mini Howto in deutscher
Sprache
* http://www.pronix.de/pronix-935.html - gutes Tutorial mit OpenVPN
Server
*
http://www.linux-magazin.de/Artikel/ausgabe/2005/08/openvpn/openvpn.html
- Artikel im Linux Magazin

[{Tag VPN SSL}]