OpenVPN (deutsch): Difference between revisions

From
Jump to navigation Jump to search
Line 496: Line 496:
# * ''persist-tun'' Analog fuer den Zugriff auf das TUN/TAP-Device
# * ''persist-tun'' Analog fuer den Zugriff auf das TUN/TAP-Device
'''user nobody'''
'''user nobody'''
'''group nobody'''
'''group nobody''' #bei debian nogroup
'''persist-key'''
'''persist-key'''
'''persist-tun'''
'''persist-tun'''

Revision as of 21:27, 29 July 2005

Einleitung: OpenVPN ist eine leicht zu implementierende und zu wartende VPN-Applikation, die bis auf das notwendige TUN- bzw. TAP-Device komplett im Userspace arbeitet. Dieses Dokument beschreibt die Installation sowohl des Servers (VPN-Gateway) als auch der Clients unter den verbreiteten Betriebssystemen Windows, Linux, Mac OS X und OpenBSD.


Was wird gebraucht?

  • OpenVPN-Programm
  • TUN/TAP-Schnittstelle
  • Konfigurationsdatei für OpenVPN (optional, aber empfohlen)
  • PKI = Public-Key-Infrastruktur (optional, für größere Installationen empfohlen)


Funktionsweise

Grundlage des OpenVPN-Tunnels ist das openvpn-Programm, welches sowohl auf Server als auch auf Clientseite auf einem UDP-Port läuft und mit Hilfe des tun/tap-Treibers eine virtuelle Netzwerkschnittstelle anlegt, welche jeweils ein Ende des Tunnels darstellt. Im Gegensatz zum PPP, welches ähnlich arbeitet, kann der gesamte Netzwerkverkehr auf Grundlage von OpenSSL verschlüsselt werden.

Zur Authentifizierung von Server und Client können zwei Verfahren verwendet werden:

  • Shared-Secret-Authentifizierung (auch Static-Key-Authentifizierung)
  • Zertifikatbasierte Authentifizierung

Shared-Secret-Authentifizierung

Die Shared-Secret-Authentifizierung basiert auf einem symmetrischen Verschlüsselungsverfahren. Dabei müssen die Kommunikationspartner den gemeinsamen Schlüssel (shared key) zuvor über einen sicheren Kanal austauschen. Der gesamte Tunnel-Netzwerkverkehr wird dann mit diesem Schlüssel verschlüsselt und kann von jedem, der ebenfalls den Schlüssel besitzt entschlüsselt werden. Daher muss der Schlüssel bei Kompromittierung auf allen beteiligten Systemen ausgetauscht werden.

Zertifikatbasierte Authentifizierung

Die Zertifikatbasierte Authentifizierung basiert auf einem asymmetrischen Verschlüsselungsverfahren, über welches ein sicherer Kanal erzeugt wird. Da die asymmetrische Verschlüsselung erheblich langsamer im Vergleich zur symmetrischen Verschlüsselung ist, wird ein temporärer symmetrischer Zufallsschlüssel von einem Kommunikationspartner erzeugt und über den sicheren Kanal an sein Gegenüber geschickt. Bei Kompromittierung brauch dann nur noch das entsprechende Zertifikat gesperrt werden (siehe ). Allerdings ist für das Aufsetzen der Public-Key-Infrastruktur ein größerer Konfigurationsaufwand erforderlich.

Siehe auch:


Zertifizierungsstelle (CA) und Public-Key-Infrastruktur (PKI)

Certificate Revocation List (CRL) - Schwarze Liste mit ungültigen Zertifikaten

Installation

Zur Installation von Server und Client wird das openvpn-Programm und ein paar Bibliotheken benötigt. Da diese auf Server- und Clientseite die gleichen sind, reicht es eine Seite zu beschreiben. Auf der anderen Seite - also dem anderen Tunnelende - wird dann entsprechend nur die conf-Datei sowie der Schlüssel und die Zertifikate ausgetauscht.

Die Installationshinweise sind teilweise http://openvpn.sourceforge.net/install.html entnommen.

Windows

Zuerst wird das Installationspaket (openvpn-2.0_beta*-install.exe) für OpenVPN und den TUN/TAP-Treiber von:

geholt.

Die Installtion erfolgt - wie unter Windows üblich - durch Starten der EXE-Datei und wiederholtem Klicken auf Next.

Danach findet sich das openvpn-Programm unter C:\Programme\OpenVPN\bin.

Es scheint leider keine Möglichkeit zu geben, den Tunnel als normaler Benutzer aufzubauen. Somit muss man dies evtl. mit Administrator-Rechten tun oder man lässt den Tunnel bereits beim Systemstart hochfahren. Ein entsrechender Dienst wird bei der Installation angelegt.

Linux

Die Installation wird am Beispiel von SuSE-Linux beschrieben, sollte aber vom fähigen Systemadministrator auch auf andere Distributionen übertragen werden können.

SuSE-Distributionspaket (alt, unterstützt nur pre-shared Keys)

yast -i lzo openssl openvpn

OpenVPN 2.0 aus den Quellen installieren (besser, notwendig für PKI-Auth)

SuSE Linux

yast -i openssl-devel 
yast -i lzo-devel (ab SuSE 9.0)

(vor SuSE 9.0 - keine lzo-Bibliothek)
wget http://www.oberhumer.com/opensource/lzo/download/lzo-1.08.tar.gz
tar xzf lzo-1.08.tar.gz
cd lzo-1.08
./configure
make
make install

# Die Version von OpenVPN ist evtl. anzupassen
# (mit Browser unter http://openvpn.sourceforge.net/beta/ herausfinden)
wget http://openvpn.sourceforge.net/beta/openvpn-2.0_beta15.tar.gz

tar xzf openvpn-2.0_beta15.tar.gz
cd openvpn-2.0_beta15

# Bei selbstübersetzter lzo-Bibliothek müssen die beiden Pfade angegeben werden:
#./configure --with-lzo-headers=/usr/local/include --with-lzo-lib=/usr/local/lib
./configure

make
make install

Als unprivilegierter Benutzer starten

Da OpenVPN Änderungen an den Netzwerkeinstellungen vornimmt (ifconfig/route), muss das Programm mit root-Rechten ausgeführt werden. Um den normalen Benutzern nicht das root-Passwort geben zu müssen, kann man statt dessen sudo verwenden. Als root nimmt man mit visudo folgenden Eintrag vor: 

# Komma-separierte Liste der VPN-Nutzer
User_Alias  VPNUSER=vpnuser1, vpnuser2

# Zum testen des VPN sollte man das --daemon weglassen,
# um evtl. Fehler auf stdout zu erhalten.
Cmnd_Alias  OPENVPN=/usr/local/sbin/openvpn --config /etc/openvpn/SAR-VPN.ovpn --daemon
Cmnd_Alias  KILLOPENVPN=/usr/bin/killall openvpn

# NOPASSWD ist optional.
# Soll der Nutzer sein Passwort eingeben muessen lautet der Eintrag wie folgt:
#VPNUSER ALL=OPENVPN
#VPNUSER ALL=KILLOPENVPN
VPNUSER ALL=NOPASSWD:OPENVPN
VPNUSER ALL=NOPASSWD:KILLOPENVPN

In diesem Beispiel wird angenommen, dass die Konfigurationsdatei unter /etc/openvpn/SAR-VPN.ovpn und das openvpn-Programm unter /usr/local/sbin/openvpn zu finden ist.

Der Tunnel kann dann mit 

sudo /usr/local/sbin/openvpn --config /etc/openvpn/SAR-VPN.ovpn --daemon

gestartet und mit 

sudo killall openvpn

beendet werden.

Mac OS X

Die Installation erfolgt analog zu Linux (bei fehlender lzo-Bobliothek). Die Developer-Tools müssen installiert sein! (C-Compiler, make, openssl-devel, etc.) Da Mac OS X (aka Darwin) kein TUN-Device zur Verfügung stellt, muss es nachinstalliert werden. Hier findet man eine detailierte Installationsbeschreibung und ein vorkompiliertes kext-file: http://chrisp.de/en/projects/tunnel.html 

wget http://www.oberhumer.com/opensource/lzo/download/lzo-1.08.tar.gz
# (oder mit Safari holen, falls wget nicht verfügbar)

tar xzf lzo-1.08.tar.gz
cd lzo-1.08
./configure
make
make install

# Die Version von OpenVPN ist evtl. anzupassen
# (mit Browser unter http://openvpn.sourceforge.net/beta/ herausfinden)
wget http://openvpn.sourceforge.net/beta/openvpn-2.0_beta15.tar.gz
# (oder mit Safari holen, falls wget nicht verfügbar)

tar xzf openvpn-2.0_beta15.tar.gz
cd openvpn-2.0_beta15
./configure --with-lzo-headers=/usr/local/include --with-lzo-lib=/usr/local/lib
make
make install

OpenBSD

wget http://www.oberhumer.com/opensource/lzo/download/lzo-1.08.tar.gz

tar xzf lzo-1.08.tar.gz
cd lzo-1.08
./configure
make
make install

# Die Version von OpenVPN ist evtl. anzupassen
# (mit Browser unter http://openvpn.sourceforge.net/beta/ herausfinden)
wget http://openvpn.sourceforge.net/beta/openvpn-2.0_beta15.tar.gz

tar xzf openvpn-2.0_beta15.tar.gz
cd openvpn-2.0_beta15
./configure --with-lzo-headers=/usr/local/include --with-lzo-lib=/usr/local/lib
make
make install

Andere UNIX-Systeme (ohne TUN-Device)

Installation erfolgt analog zu Mac OS X bzw. OpenBSD. Informationen zur Installationen finden sich unter:

Frontends

Konfiguration

Grundsätzlich können alle Konfigurations-Parameter dem openvpn-Programm an der Kommandozeile in der Form --parameter=wert mitgegeben werden. Alternativ kann man die Konfigurations-Parameter in eine Datei zeilenweise in der Form parameter wert schreiben und den Dateinamen mit dem Parameter --config Dateiname an der Kommandozeile mitgeben, z.B.: 

openvpn --config openvpn.conf

Der erste Test

Zum Testen der OpenVPN-Installation sollte man zunächst eine Shared-Secret-Authentifizierung wählen, da diese einfach zu konfigurieren ist. Mit: 

openvpn --genkey --secret static.key

erstellt man einen gemeinsamen Schlüssel (static.key), den man auf die beiden OpenVPN-Rechner mit den späteren Tunnelenden kopiert.


Angenommen, der Server hat die reale IP-Adresse 192.168.0.1 und der Client die IP-Adresse 192.168.0.2 kann man folgendermaßer eine erste Testverbindung aufbauen:

auf dem Server 

openvpn --dev tun0 --remote 192.168.0.2 --ifconfig 192.168.10.1 192.168.10.2 --secret static.key


auf dem Client 

openvpn --dev tun0 --remote 192.168.0.1 --ifconfig 192.168.10.2 192.168.10.1 --secret static.key


Der Server sollte dann durch den Tunnel vom Client aus über die virtuelle IP-Adresse 192.168.10.1 ansprechbar sein: 

ping 192.168.10.1

analog ist der Client über die virtuelle IP-Adresse 192.168.10.2 erreichbar.

Szenarien

Außendienst-Mitarbeiter (Netz-zu-Host)

Eine häufiger Anwendungsfall für VPNs beschreibt folgendes Szenario: Ein Außendienst-Mitarbeiter (auch Roadwarrior), Tele-Arbeiter oder einfach jemand der zu Hause noch ein Dokument braucht, möchte Zugriff auf die Ressourcen seines Firmen-Netzes erlangen, welches aus Sicherheitsgründen zum Internet aber durch eine Firewall abgeschottet ist.

In der folgenden Betrachtung wird davon ausgegangen, dass das Firmen-Netzwerk im Subnetz 192.168.0.0/24 liegt. Diese Angaben sind bei der Konfiguration natürlich an die lokalen Gegebenheiten anzupassen. Weiterhin soll für als Subnetz, in welchem sich die VPN-Clients befinden, 192.168.10.0/24 angenommen werden.

Für kleine Netzwerke kann für dieses Szenario auch der Peer-to-Peer-Modus (mit Shared-Secret-Authentifizierung) von OpenVPN verwendet werden. Der Administrationsaufwand steigt bei dieser Realisierung mit der Größe des VPN-Netzes - also mit der Anzahl der VPN-Clients. Außerdem muss pro Client auf der Serverseite ein expliziter Daemon-Prozess mit separatem UDP-Port laufen, was zudem die Firewall-Konfiguration aufwändiger gestaltet. Im folgenden wird daher der Server-Client-Modus von OpenVPN (ab Version 2) mit Hilfe von zertifikatbasierter Authentifizierung beschrieben.

CA aufsetzen

Zur Signierung des Server- und der Client-Zertifikate sollte man eine eigene CA aufsetzen. Das OpenSSL-Paket bringt schon die nötigen Werkzeuge dafür mit. Zur Vereinfach existiert das Skript CA.pl. Das Skript ist wie folgt zu finden:

  • /usr/share/ssl/misc/CA.pl (SuSE)
  • /usr/lib/ssl/misc/CA.pl (Debian)
CA.pl -newca

erstellt im aktuellen Verzeichnis das CA-Verzeichnis demoCA. Nach der Eingabe von:

  • Passwort für privaten Schlüssel (Enter PEM pass phrase)
  • Eigenschaften des Zertifikates:
    • Land (Country Name (2 letter code))
    • Staat (Country Name (State or Province Name (full name))
    • Stadt (Locality Name (eg, city))
    • Firma (Organization Name (eg, company))
    • Abteilung (Organizational Unit Name (eg, section))
    • Name (des Nutzers bzw. des Rechners) (Common Name (eg, YOUR name))
    • E-Mail-Adresse (Email Address)

Also beispielsweise: 

tux@linux:~> /usr/share/ssl/misc/CA.pl -newca
CA certificate filename (or enter to create)

Making CA certificate ...
Generating a 1024 bit RSA private key
.......++++++
.++++++
writing new private key to './demoCA/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Berlin
Locality Name (eg, city) []:Berlin
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Humboldt-Universitaet zu Berlin
Organizational Unit Name (eg, section) []:Informatik
Common Name (eg, YOUR name) []:Tux-CA
Email Address []:

Das CA-Zertitifikat ist anschließend unter demoCA/cacert.pem zu finden.

Zertifikate erstellen

Jetzt werden noch Schlüssel und Zertifikate für den Server und die Clients benötigt: (Die Erstellung verläuft für Server und Clients gleich!)

1. Der private Schlüssel und eine Zertifikat-Anforderung: 

tux@linux:~> /usr/share/ssl/misc/CA.pl -newreq
Using configuration from /etc/ssl/openssl.cnf
Generating a 1024 bit RSA private key
..++++++
..............................................................................................++++++
writing new private key to 'newreq.pem'
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Berlin
Locality Name (eg, city) []:Berlin
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Humboldt-Universitaet zu Berlin
Organizational Unit Name (eg, section) []:Informatik
Common Name (eg, YOUR name) []:TestClient
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Request (and private key) is in newreq.pem

erstellt eine Zertifikat-Anfrage inklusive dem privaten Schlüssel in der Datei newreq.pem.

2. Unterschreiben der Zertifikat-Anforderung mit CA-Key: 

tux@linux:~> /usr/share/ssl/misc/CA.pl -signreq
Using configuration from /etc/ssl/openssl.cnf
7974:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c:329:group=CA_default name=unique_subject
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Nov 29 13:43:20 2004 GMT
            Not After : Nov 29 13:43:20 2005 GMT
        Subject:
            countryName               = DE
            stateOrProvinceName       = Berlin
            localityName              = Berlin
            organizationName          = Humboldt-Universitaet zu Berlin
            organizationalUnitName    = Informatik
            commonName                = TestClient
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                49:88:2F:9A:D6:E3:90:7F:5C:DE:56:F2:20:26:F9:74:2B:46:D4:7E
            X509v3 Authority Key Identifier:
                keyid:C6:AF:33:7D:F2:8F:22:1C:42:D9:F1:AD:7B:73:FE:4C:A2:C1:C8:94
                DirName:/C=DE/ST=Berlin/L=Berlin/O=Humboldt-Universitaet zu Berlin/OU=Informatik/CN=Tux-CA
                serial:00

Certificate is to be certified until Nov 29 13:43:20 2005 GMT (365 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Signed certificate is in newcert.pem

3. Erzeugen einer PKCS#12-Datei (mit CA- und Client-Zertifikat sowie privatem Schlüssel): 

tux@linux:~> /usr/share/ssl/misc/CA.pl -pkcs12 "Test Client"
Enter pass phrase for newreq.pem:
Enter Export Password:
Verifying - Enter Export Password:

Die resultierende Datei newcert.p12 kann anschließend mit OpenVPN zur Authentifizierung verwendet werden. (newreq.pem und newcert.pem können gelöscht werden.)

Für 1 Server-Zertifikat und n Client-Zertifikate würde man also folgendes aufrufen: 

# CA erstellen
/usr/share/ssl/misc/CA.pl -newca

# Server-Zertifikat
/usr/share/ssl/misc/CA.pl -newreq
/usr/share/ssl/misc/CA.pl -signreq
/usr/share/ssl/misc/CA.pl -pkcs12 "Server-Zertifikat"
mv newcert.p12 server.p12
rm newreq.pem newcert.pem

# Client-1-Zertifikat
/usr/share/ssl/misc/CA.pl -newreq
/usr/share/ssl/misc/CA.pl -signreq
/usr/share/ssl/misc/CA.pl -pkcs12 "Client-1-Zertifikat"
mv newcert.p12 client-1.p12
rm newreq.pem newcert.pem
.
.
.
# Client-n-Zertifikat
/usr/share/ssl/misc/CA.pl -newreq
/usr/share/ssl/misc/CA.pl -signreq
/usr/share/ssl/misc/CA.pl -pkcs12 "Client-n-Zertifikat"
mv newcert.p12 client-n.p12
rm newreq.pem newcert.pem

Server-Konfiguration

Im folgenden wird eine Bespiel-Konfiguration für dieses Szenario angegeben. Kommentare werden mit einem # vorangestellt, auskommentierten Optionen folgen einem Semikolon.

Der Server kann anschließend mit: 

openvpn --config Konfigurationsdatei

gestartet werden. 

##############################################################################
# /etc/openvpn/openvpn-server.ovpn
#
# Diese Konfiguartionsdatei beinhaltet Einstellungen
# fuer einen OpenVPN-Server.
#
# Mit
#     openvpn --config /etc/openvpn/openvpn-server.ovpn
# kann der Server gestartet werden.

# OpenVPN laeuft als Server und verwendet 192.168.10.0/24
# als VPN-Subnetz.
server 192.168.10.0 255.255.255.0

# Auf welcher IP-Adresse soll OpenVPN lauschen? (optional)
;local 192.168.0.1
 
# Welcher Port soll verwendet werden? (Standard: UDP/5000)
proto udp
port 5000

# Wir verwenden IP-Tunnel - also das tun-Device.
# Fuer Ethernet-Tunnel ist das tap-Device zu verwenden und ausserdem 
# die server-bridge-Option statt der o.g. server-Option.
;dev tap
dev tun

# Welche Schluessel/Zertifikate sollen verwendet werden?

# In welchem Verzeichnis liegen die Dateien?
# Es wird /etc/openvpn angenommen 
cd /etc/openvpn

# CA-Zertifikat
;ca sample-keys/tmp-ca.crt

# Eigenes Zertifikat
;cert sample-keys/server.crt

# Eigener privater Schluessel
;key sample-keys/server.key  # Diese Datei sollte geheim bleiben 

# Wir verwenden lieber alles in einer Datei!
pkcs12 server.p12

# Diffie-Hellman-Parameter.
# Diese Datei kann wie folgt erstellt werden:
#   openssl dhparam -out /etc/openvpn/dh1024.pem 1024
dh dh1024.pem

# Ein gemeinsamer Schluessel kann ausserdem verwendet.
# So koennen nur die Clients eine Verbindung aufbauen,
# die auch das Geheimnis kennen.
# (Ein kleiner Schutz gegen DoS-Attacken)
tls-auth preshared.key 0

# Welche CRL-Datei wird verwendet?
# Die CRL ist eine von der CA unterschriebene Liste
# mit den Zertifikaten, die sich nicht anmelden dürfen.
crl-verify crl.pem

# Pruefe, ob noch eine Verbindung mit dem Client besteht.
# Jede 10 Sekunden einen Ping, falls nach 60 Sekunden
# keine Antwort ankommt, wird ein Verbindungsabbruch angenommen.
keepalive 10 60

# Erhalte Verbindung falls Client-IP-Adressen
# waehrend der Verbindung sich aendern sollten.
# (z.B. bei Dial-Up-Reconnect)
float 

# Kompression fuer den Tunnel
comp-lzo
 
# Ermoeglich mehrere gleichzeitige Verbindungen mit
# dem gleichen Zertifikat. (nicht empfohlen)
;duplicate-cn

# Abgeben der Prozess-Rechte nach dem Start:
# * user          Nutzer nach Rechteabgabe (mit moeglichst wenig Rechten)
# * group         Gruppe analog
# * persist-key   Lese die Schluessel nicht beim Neustart durch
#                 SIGUSR1 bzw. --ping-restart ein
# * persist-tun   Analog fuer den Zugriff auf das TUN/TAP-Device
user nobody
group nobody #bei debian nogroup
persist-key
persist-tun

# Log-Level:
#
# 0 keine Ausgabe bis auf kritische Fehler
# 4 empfohlen fuer Standardbetrieb
# 5 und 6 zum Debuggen
# 9 maximal
verb 4

# Daemon-Mode: keine Ausgabe auf das Terminal (stdout) sondern ins Syslog
;daemon  # Sollte erst nach fertiger Konfiguration aktiviert werden

Weitere Informationen zur Syntax und Semantik der Konfiguration gibt es hier:

Beispiele unter:

Client-Konfiguration

Analog zum Server (siehe oben) wird der Client gestartet. Es folgt ein Bespiel fuer eine Client-Konfigurationsdatei. 

##############################################################################
# /etc/openvpn/openvpn-client.ovpn
#
# Diese Konfiguartionsdatei beinhaltet Einstellungen
# fuer einen OpenVPN-Client.
#
# Mit
#     openvpn --config /etc/openvpn/openvpn-client.ovpn
# kann der Client gestartet werden.

# OpenVPN laeuft als Client.
client

# Wir verwenden IP-Tunnel - also das tun-Device.
dev tun

# Angabe des Server-Daten.
# Bei mehreren remote-Eintraegen wird ein Load-Balancing versucht.
;remote my.server.local 5000  # Namen sind moeglich
remote 192.168.0.1 5000  # IP-Adressen auch

# Welche Schluessel/Zertifikate sollen verwendet werden?

# In welchem Verzeichnis liegen die Dateien?
# Es wird /etc/openvpn angenommen 
cd /etc/openvpn

# CA-Zertifikat
;ca sample-keys/tmp-ca.crt

# Eigenes Zertifikat
;cert sample-keys/client1.crt

# Eigener privater Schluessel
;key sample-keys/client1.key  # Diese Datei sollte geheim bleiben 

# Wir verwenden lieber alles in einer Datei!
pkcs12 client1.p12

# Diffie-Hellman-Parameter.
# Diese Datei kann wie folgt erstellt werden:
#   openssl dhparam -out /etc/openvpn/dh1024.pem 1024
dh dh1024.pem

# Ein gemeinsamer Schluessel kann ausserdem verwendet.
# So koennen nur die Clients eine Verbindung aufbauen,
# die auch das Geheimnis kennen.
# (Ein kleiner Schutz gegen DoS-Attacken)
# ACHTUNG: Letzter Parameter muss auf Client-Seite == 1 sein!
tls-auth preshared.key 1

# Versuche den Hostnamen des Servers aufzuloesen auch nachdem
# keine Verbindung zum Internet bestand.
# Sinnvoll bei Clients, die keine permanente Internet-Anbindung haben.
resolv-retry infinite

# Clienten brauchen keinen Port binden.
nobind

# Pruefe, ob noch eine Verbindung mit dem Server besteht.
# Jede 10 Sekunden einen Ping, falls nach 60 Sekunden
# keine Antwort ankommt, wird ein Verbindungsabbruch angenommen.
keepalive 10 60

# Kompression fuer den Tunnel
comp-lzo
 
# Abgeben der Prozess-Rechte nach dem Start:
# * user          Nutzer nach Rechteabgabe (mit moeglichst wenig Rechten)
# * group         Gruppe analog
# * persist-key   Lese die Schluessel nicht beim Neustart durch
#                 SIGUSR1 bzw. --ping-restart ein
# * persist-tun   Analog fuer den Zugriff auf das TUN/TAP-Device
user nobody
group nobody # bei Debian statt nobody nogroup
persist-key
persist-tun

# Log-Level:
#
# 0 keine Ausgabe bis auf kritische Fehler
# 4 empfohlen fuer Standardbetrieb
# 5 und 6 zum Debuggen
# 9 maximal
verb 4

# Daemon-Mode: keine Ausgabe auf das Terminal (stdout) sondern ins Syslog
;daemon  # Sollte erst nach fertiger Konfiguration aktiviert werden

# Lege nach dem Verbindungsaufbau automatisch eine Route zum lokalen Netz
# hinter dem Server durch den Tunnel an.
# Beispiel: Subnetz 192.168.2.0/24
;route 192.168.2.0 255.255.255.0

# Default-Route ueber VPN
;route remote_host 255.255.255.255 net_gateway
;route 0.0.0.0 0.0.0.0 vpn_gateway

Transparente Fillialanbindung (Netz-zu-Netz)

Für dieses Szenario kann die Konfiguration aus dem ersten Test verwendet werden. Es wird dann kein expliziter Server ausgewiesen und es braucht keine PKI aufgesetzt werden. Man muss nur den gemeinsamen Schlüssel über einen sicheren Kanal übertragen, z.B. eine verschlüsselte E-Mail.

Sinnvollerweise kann man die Optionen wie im o.g. Szenario in eine Datei schreiben und ein paar zusätzliche Optionen, wie das automatische Setzen von Routen angeben.

Eine Beispiel-Konfiguration wäre also: 

##############################################################################
# /etc/openvpn/openvpn-gateway.ovpn
#
# Diese Konfiguartionsdatei beinhaltet Einstellungen
# fuer einen OpenVPN-Gateway.
#
# Mit
#     openvpn --config /etc/openvpn/openvpn-gateway.ovpn
# kann das Gateway gestartet werden.

remote 192.168.10.2
;remote 192.168.10.1   # auf der anderen Tunnelseite

ifconfig 192.168.10.1 192.168.10.2
;ifconfig 192.168.10.2 192.168.10.1   # auf der anderen Tunnelseite
  
proto udp
port 5000

dev tun

cd /etc/openvpn

secret preshared.key

keepalive 10 60

comp-lzo
 
user nobody
group nobody
persist-key
persist-tun

verb 4

;daemon  # Sollte erst nach fertiger Konfiguration aktiviert werden

Will man mehrere Fillialen an eine Zentrale anbinden, wird man eher zum oben genannten Netz-zu-Host-Szenario greifen. Hierbei spielt das Gateway in der Zentrale die Rolle des Servers und das Gateway der Filliale die Rolle des Clients. Eventuell muss auf Server-Seite noch ein clientspezifisches Skript mit entsprechenden Routing-Eintragungen eingesetzt werden, falls in der Zentrale ein Rechner aus dem Netz der Filliale erreicht werden soll.

Literatur

  • Wikipedia OpenVPN
  • Linux Magazin, Oktober 2003: VPN im Userspace mit OpenVPN
  • c't 9/05 Open-Source-Projekt Open VPN , Seite 194
Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=OpenVPN_(deutsch)&oldid=1600"