OpenVPN (deutsch)
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
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.
yast -i lzo openssl openvpn
OpenVPN 2.0 aus den Quellen installieren (besser, notwendig für PKI-Auth)
- lzo-Bibliothek (für die Kompression) http://www.oberhumer.com/opensource/lzo/download/lzo-1.08.tar.gz
- OpenSSL-Bibliothek
- http://openvpn.sourceforge.net/beta/openvpn-2.0_beta*.tar.gz
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
- OpenVPN GUI für Windows http://www.nilings.se/openvpn/
- OpenVPN-GUI für Mac OS X http://rechenknecht.net/OpenVPN-GUI/
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 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