DaGrrr

Deutsches OpenVPN Howto

Warum dieses Howto

Über OpenVPN gibt es mehr oder weniger gute Howto's, die hauptsächlich das Verschlüsseln mit Preshared-Keys erklären. Da manche so wie ich ein wenig Paranoid sind und das ganze sicherer haben wollen, wollte ich das ganze auch mit Zertifikaten gelöst haben. Bei Google war ein fertiges OpenVPN/SSL Howto so gut wie gar nicht zu finden. Auch das englischsprachige Howto brachte bei mir einige kleine Fehler und so habe ich mich entschlossen meinen Weg zu beschreiben und in Anlehnung an das Entwickler Howto.

Damit das Howto Vollständiger wird werde ich trotz aller Beschreibungen auch nochmal OpenVPN mit Pre-Shared-Keys erklären.
Neben Linux wird auch OpenVPN mit Windows beschrieben, da ein nicht unerheblicher Teil der Benutzer ein heterogenes Netzwerk verwenden.


Was ist ein VPN

Der Sinn eines VPN (Virtuelles Privates Netzwerk) ist die Herstellung eines vertraulichen und sicheren Netzwerks über öffentliche und unsichere Netzwerke wie z.B. das Internet. Das hierbei der Begriff „Privat” verwendet wird, heißt nicht, dass es unbedingt eine verschlüsselte Übertragung sein muß. Genauso kann einfach nur die Integrität der Daten gemeint sein.
Bei einem VPN wird ein Tunnel zwischen VPN-Client und VPN-Server aufgebaut. Dabei gibt es verschiedene Möglichkeiten dies zu realisieren. Die am häufigsten genutzten Varianten ist die Lan-zu-LAN Verbindung (Site-to-Site) oder die des Netwarriors (End-to-Site), wobei sich meist ein Notebook Besitzer am VPN-Server der Firma anmeldet und so Zugriff auf seine Daten bekommt.

Was ist OpenVPN?

OpenVPN ist ein OpenSource Programm zur Herstellung eines VPN's. Es verwendet wahlweise UDP oder TCP als Protokoll und benutzt zur Verschlüsselung und Authentisierung Bibliotheken des Programmes OpenSSL.
Je nach Anforderungen kann der Anwender zwischen verschiedene Authentisierungen wählen. Die Möglichkeiten sind Preshared-Keys, Zertifikate oder per Authentisierungs-Plugin.
Preshared-Keys eignen sich für kleine VPN-Verbindungen, mit wenigen Teilnehmern, wenn es keine Rolle spielt, dass mehrere Teilnehmer den gleichen Schlüssel benutzen.
Zertifikate sind eine wesentlich sichere Methode zur Authentisierung. Ein Client muß ein gültiges Zertifikat vorweisen, um sich am VPN-Server anzumelden.
Mit Authentisierungs-Plugin's kann flexibel auf weitere oder zusätzliche Authentisierungsformen zurück gegriffen werden. Beispielsweise kann ein Benutzername und ein Passwort an einem RADIUS oder LDAP Server geprüft werden.

Anmerkung: In diesem Howto werden nur PreShared-Keys und Zertifikate angesprochen!

OpenVPN steht unter der GPL und ist für verschiedenste Betriebssysteme verfügbar. Darunter befinden sich z.B. Linux, Windows 2000/XP, Mac OSX, *BSD's und einige andere.


OpenVPN im Detail

OpenVPN benutzt den Client/Server Ansatz. Der OpenVPN Client initiiert eine Verbindung zum OpenVPN Server. Dabei wird das X.509 Zertifikat vom Server beim Client auf Echtheit überprüft. Die Prüfung erfolgt anhand des Public-Keys der ausgebenden CA (Certificate Authority). Wurde der Server auf Echtheit überprüft, dann wird die 1. Stufe der Client Authentisierung gestartet.
Wenn die Authentisierung mit einem X.509 Client Zertifikat erfolgt, dann prüft der Server das vom Clienten übermittelte Zertifikat anhand des Public-Keys der ausgegeben Certificate Authority. Steht das Zertifikat nicht in der Certificate Revocation List (CRL) und es ist gültig, dann ist die 1. Stufe der Authentisierung abgeschlossen und die verschlüsselte Verbindung kann starten. Standardmäßig werden mit SSL/TLS die Session-Keys dynamisch ausgehandelt. Beim Up- und Downstream werden jeweils eigene Keys zum verschlüsseln und signieren verwendet.

Bei Shared Keys ist die Authentisierung mit der Verschlüsselung verbunden.
Wenn kein korrekter Schlüssel vorhanden ist, dann kann keine verschlüsselte Verbindung aufgebaut werden. Shared-Keys werden verwendet, um Aktienpakete zu verschlüsseln und zu signieren.

Die private IP-Adresse bezieht der Client vom Server und bekommt die notwendigen Einstellungen bez. DNS, WINS über den Tunnel mitgeteilt.
Als Endpunkte werden virtuelle Interfaces (TUN/TAP) verwendet.
Damit alle Pakete durch den Tunnel geschickt werden, wird die Sprungtabelle manipuliert.
Auf Seite des Servers wird die Kommunikation ebenfalls über ein virtuelles Interface abgehandelt. Die getunnelten IP-Pakete ausgepackt und anschließend mit Network Adress Translation (NAT) auf eine oder mehrere Adressen im lokalen Netz übersetzt.

1) Einleitung OpenVPN
2) Vorbereitungen für OpenVPN
3) Konfigurationsparameter für OpenVPN
4) Zertifikatserstellung
5) PreShared Keys
6) Bridging

04.04.2006 Erstellung des Howto: Deutsches OpenVPN Howto (Neufassung)

Fragen zum Thema bitte nur im Forum stellen, ich gebe keinen Support außerhalb des Forums!

__________________
Debian GNU/Linux SID / Kernel 2.6.27-SMP
Private Linux Page

DaGrrr

Vorbereitungen für OpenVPN (Linux)

Wenn ein Kernel selbst kompiliert werden soll, dann muß der Kernel entsprechend konfiguriert werden. OpenVPN benötigt zum funktionieren das TUN/TAP Device.

Kernel 2.6.x
Device Drivers
-> Networking support ->[*] Universal TUN/TAP device driver support
aktivieren und den Kernel neu kompilieren.

Ein Howto wie man einen Kernel kompiliert gibt es hier:
http://www.linuxforen.de/forums/showthread.php?t=161878 (Kernel 2.6)
und
http://www.linuxforen.de/forums/showthread.php?t=20583 (Allgemein)

Bei Distributionskernel ist meist die TUN/TAP Unterstützung als Modul im Kernel bereits vorhanden und muß nur noch geladen werden.

OpenVPN Software

Das aktuelle OpenVPN bekommst du unter:

http://openvpn.net/download.html

Anmerkung:
Falls es Problemen mit der kompilierung gibt, dann bekommst du im Linuxforen.de Forum Hilfestellung.

OpenVPN braucht folgende libary's, damit ein kompilieren möglich (aus dem englischen Howto) ist:

- OpenSSL library – notwendig für die Verschlüsselung http://www.openssl.org/
- LZO library – notwendig für die Link kompression http://www.oberhumer.com/opensource/lzo/
- Pthread libary

Mehr Informationen über OpenSSL gibt es unter:
http://www.pca.dfn.de/certify/ssl/ha...5/ossl095.html (Deutsch)
und natürlich auf der Entwicklersite
http://www.openssl.org/ (Englisch)

Auspacken und Installation von OpenVPN (Linux)
OpenVPN wird mit der Angabe von „--prefix=“ in dem angegebenen Verzeichnis, hier /usr/local installiert.
Damit sollte eine erfolgreiche Installation von OpenVPN möglich sein.

Für Distributionen, die OpenVPN als Binärpaket anbieten, können dieses Paket natürlich auch installieren.
Unter Debian GNU/Linux reicht z.B. ein einfaches “apt-get install openvpn”, um OpenVPN zu installieren.

Installation von OpenVPN unter Windows

OpenVPN für Windows gibt es ebenfalls unter

http://openvpn.net/download.html

Die Installation unter Windows ist kein Problem, da ein Windows Installer ausgeführt wird, der OpenVPN automatisch installiert. Das TAP-Device wird unter Windows automatisch angelegt. Sollte dies nicht der Fall sein, so kann das im Installationsverzeichnis enthaltene Script ausgeführt werden, welches das TAP-Device anlegt.

c:\Programme\OpenVPN\bin\ --> addtap.bat

Bei Installation von OpenVPN unter Windows wird OpenSSL mit installiert, womit auch unter Windows SSL Zertifikate angefertigt werden können.

__________________
Debian GNU/Linux SID / Kernel 2.6.27-SMP
Private Linux Page

DaGrrr

Konfigurationsparameter von OpenVPN


Erstellen der Konfigurationsdatei (Linux)

Pfadangaben unter Linux werden mit einem Slash ( / ) angegeben. Beispiel: /etc/openvpn

Erstellen der Konfigurationsdatei (Windows)

Mit einem Text Editor erstellen wir im Verzeichnis
c:\Programme\Openvpn\config die Datei openvpn_ssl.ovpn
Die Endung .ovpn ist wichtig, da sonst z.B. die Windows GUI die Konfigurationsdatei nicht findet. Ebenfalls ist es dann möglich per Rechtsklick auf die Konfigurationsdatei OpenVPN mit dieser Konfiguration zu starten.
Weitere wichtige Dinge bei Windows in Bezug auf die Konfigurationsdatei sind die Pfadangaben. Die Pfadangaben für die erstellten Zertifikate werden lesbar für Windows eingetragen, das heißt mit doppeltem Backslash ( \\ ).

Vorstellung der Optionen für eine Konfigurationsdatei

dev tun
Erstellt einen gerouteten IP Tunnel. Client und Server.

dev tap
Erstellt einen Ethernet Tunnel und wird für Bridging gebraucht. Client und Server.

dev-node bridgename
Windows braucht den TAP-Win32 Namen, welcher unter Netzwerkverbindungen einsehbar ist, wenn mehr als ein TAP Adapter vorhanden ist. Linux braucht den Parameter dev-node nicht. Server und Client.

proto udp
proto tcp
Welches Protokoll soll verwendet werden, TCP oder UDP? Standard ist UDP und sollte auch verwendet werden, da es mit TCP zu Problemen kommen kann. Wenn angegeben, dann in der Server und Client Konfiguration eintragen.

port Portnummer
Die Portangabe. Standard ist 1194. Wenn angegeben, dann in der Server und Client Konfiguration eintragen.

remote IP-Addresse
Diese Option wird für den Client benutzt, damit dieser weiß wohin er sich verbinden muß. Die IP-Adresse kann auch ein DynDNS Name sein. Möglich ist auch mehrere Angaben von remote, um z.B. bei Ausfall eines VPN Servers einen Ersatz Server zu nehmen. Beispiele: remote 192.168.1.5 oder remote myhome.dyndns.org. Nur Client.

nobind
Verhindert eine feste Bindung zu einer lokalen Adresse und einem lokalen Port. Diese Option ist nützlich für Rechner, die eine neue Verbindung mit der remote Option aufbauen. Nur Client.

ifconfig A B
Setzt die TUN/TAP Adapter-Parameter. „A“ ist die IP-Adresse des lokalen VPN-Endpunktes. Für unter TUN betriebene Geräte ist „B“ die IP-Adresse des entfernten TUN-Endpunktes, während bei den unter TAP betriebenen Geräten „B“ die Subnetz-Maske des virtuellen Ethernet-Segmentes darstellt, das ins Leben gerufen oder zu dem eine Verbindung aufgebaut werden soll.
Für unter TUN betriebene Geräte, die virtuelle point-to-point IP-Verbindungen ermöglichen, besteht die richtige Benutzung von ifconfig darin, zwei für sich stehende IP-Adressen anzugeben, die nicht zu einem derzeit ans System angeschlossenen Subnetz gehören. Die IP-Adressen können nacheinander nummeriert sein und sollten in einer Reihenfolge angegeben werden, die umgekehrt zu den Einträgen auf dem entfernten Rechner verhält. Nachdem das VPN eingerichtet ist, kann man durch den Ping-Aufruf mit „B“ durch das VPN senden.
Für TAP-Geräte, die dafür vorgesehen sind, virtuelle Netzwerk-Segmente in einem Ethernet bereitzustellen, wird ifconfig dazu benutzt, eine IP-Adresse und eine Subnetz-Maske so einzugeben, wie sie auch bei der Installation eines physikalischen Ethernet-Adapters angegeben werden. Bei einem Verbindungsaufbau zu einer entfernten Ethernet-Brücke muss sichergestellt werden, dass das die angegebene IP-Adresse und die Subnetz-Parameter auf Werte gesetzt werden, die vom anzuschließenden fernen Ethernet sinnvoll interpretiert werden können. (Für diesen Zweck kann auch DHCP verwendet werden.) Bei Benutzung einer unter TAP definierten Schnittstelle sollte ifconfig nicht benutzt werden wenn die Schnittstelle ihre IP-Adresse von einem DHCP-Server zugewiesen bekommt.
Client und Server.

tls-server
Mit „tls-server“ wird festgelegt, wer bei der Authentisierung der Server ist, notwendig wenn Zertifikate verwendet. Nur Server.

tls-client
Mit „tls-client“ wird festgelegt, wer bei der Authentisierung der Client ist, notwendig wenn Zertifikate verwendet. Nur Client.

dh Dieffie-Hellman Parameter
dh gibt den Dieffie-Hellman Parametet an und kommt bei Zertifikaten zur Anwendung. Als Beispiel: dh /Pfad/zum/Zertifikat/dh2048.pem. Nur Server.

ca CA-Certifikat
ca ist das Authentifikationszertifikat, welches jeweils in der Server- und Client Konfiguration angegeben werden muß, wenn Zertifikate verwendet werden. Beispiel: ca /Pfad/zum/Zertifikat/ca.crt
cert Publickey
Angabe des Publickey's, welches in der Server- und Client Konfiguration angegeben werden muß, wenn Zertifikate verwendet werden. Beispiel: cert /Pfad/zum/Zertifikat/server.crt

key Privatkey
Angabe des Privatkey's, welches in der Server- und Client Konfiguration angegeben werden muß, wenn Zertifikate verwendet werden. Beispiel: key /Pfad/zum/Zertifikat/server.key

ifconfig-pool-persist ipp.txt
Enthält eine Liste mit den vergebenen IP-Adressen. Falls OpenVPN abstürzt oder eine Downtime hat, können die gleichen Client Adressen vergeben werden, wie vor der Downtime. Jeder Client behält also seine zuvor zugewiesene IP-Adresse. Nur Server.

server Netzwerkadresse Netzwerkmaske
Diese Option konfiguriert den Server in den Servermodus. Im Servermodus wird OpenVPN auf einem einzigen Port auf eingehende Verbindungen warten. Alle Client Verbindungen werden durch eine einzige TUN- TAP-Schnittstelle geleitet. Preshared-Keys können nicht verwendet werden, da der Servermodus nur mit der SSL/TLS-Authentifikation funktioniert. Wenn Bridging verwendet wird, sollte „server-bridge“ benutzt werden, um den Server Modus zu aktivieren. Nur Server.
Als Beispiel hier die Darstellung für --server 10.8.0.0 255.255.255.0 und was die hier beschriebene Unterstützung daraus macht:
mode server
tls-server

if dev tun:
ifconfig 10.8.0.1 10.8.0.2
ifconfig-pool 10.8.0.4 10.8.0.251
route 10.8.0.0 255.255.255.0
if client-to-client:
push "route 10.8.0.0 255.255.255.0"
else
push "route 10.8.0.1"

if dev tap:
ifconfig 10.8.0.1 255.255.255.0
ifconfig-pool 10.8.0.2 10.8.0.254 255.255.255.0
push "route-gateway 10.8.0.1"

server-bridge gateway netmask IP-Start-Bereich IP-End-Bereich
Wenn Bridging (TAP Device) verwendet wird, dann diese Zeile
eintragen und die Option „server“ entfernen oder muß kommentiert ( werden. Die Parameter „gateway“ und netmask für „server-bridge“ können entweder auf die Werte der IP/Netzmaske der Bückenschnittstelle gesetzt werden, oder auf die IP/Netzmaske des "gebrückten“ Subnetzes.
Als Letztes muss ein Bereich von IP-Adressen im "gebrückten“ Subnetz reserviert werden, der mit IP-Start-Bereich bis IP-End-Bereich definiert wird, damit OpenVPN die Möglichkeit hat, diese Adressen den Clients zuzuordnen, die sich zum OpenVPN-Server verbinden wollen. Nur Server. Beispiel:
Der Server bekommt die IP 192.168.1.1, die verwendete Subnetzmaske 255.255.255.0 und der IP Pool für die Clients von 192.168.1.100 bis 192.168.1.110.
„server-bridge 192.168.1.0 255.255.255.0 192.168.1.100 192.168.1.110“ interpretiert folgendes bzw. ist damit gleich zu setzen:
mode server
tls-server

ifconfig-pool 192.168.1.100 192.168.1.110 255.255.255.0
push "route-gateway 192.168.1.0"

push „Optionen“
push schickt dem Clienten Optionen die verwendet werden sollen. Das könnte eine Route sein, damit der Client weiß wie er das Netzwerk hinter dem OpenVPN Server erreicht. Beispiel: push „route 192.168.10.0 255.255.255.0“
Es könnten aber auch DHCP, Gateway Optionen sein, z.B. push „dhcp-option DNS 192.168.1.1“ wird für Windows spezifische Netzwerk Einstellungen verwendet oder push „redirect-gateway“ konfiguriert alle Clients, dass sämtlicher Verkehr durch das VPN geht. Das heißt surfen, E-Mails abrufen etc. wird durch das VPN geroutet und die Anfrage geht von dort ins Internet. Nur Server.

pull
Wenn push beim Server verwendet wird, braucht der Client die pull Option. Nur Client.

client-to-client
Mit dieser Option können sich die Clienten untereinander sehen. Normalerweise sieht ein Client nur den Server, was auch die Default Einstellung ist. client-to-client funktioniert nur wenn die Option „server“ gesetzt wurde. Nur Server.

cipher Algorithmus
Mit der Angabe Cipher wird bestimmt, welcher Verschlüsselungsalgorithmus verwendet werden soll, wenn Zertifikate benutzt werden. Default ist Blowfish, wenn keine Angabe erfolgt. Es gibt weitere Algorithmen z.B. AES oder Triple-DES. Client und Server. Beispiele: cipher BF-CBC cipher AES-128-CBC
cipher AES-256-CBC cipher DES-EDE3-CBC

secret /Pfad/zur/Datei
Diese Option setzt den Statischen-Schlüssel-Verschlüsselungsmodus, wenn z.B. keine Zertifikate verwendet werden sollen. Die vorher mit dem Befehl „openvpn --genkey Dateiname“ erstellte Datei mit dem PreShared-Key. Der Schlüssel muß auf dem Server und Client gleich sein. Ist der Schlüssel auf dem Server erstellt worden, dann wird diese Datei über eine sichere Verbindung z.B. SSH an den Client geschickt. Server und Client.

log openvpn.log
log-append openvpn.log
Per default wird mit syslog (Linux) und bei Windows nach c:\Programme\OpenVPN\log geloggt. Beide Varianten übergehen die default Einstellung und man kann eine andere Datei angeben. „log openvpn.log“ überschreibt bisherige Einträge, während „log-append openvpn.log“ neue Eintrage z.B. nach einem Neustart von OpenVPN neue Einträge an das Ende der bisherigen Datei anhängt. Client und Server.

user nobody
group nogroup
Erhöht die Sicherheit von OpenVPN, weil nach Inbetriebnahme der OpenVPN-Prozess dem user nobody und der Gruppe nogroup gehört und nicht mehr root. Nur für nicht Windows Rechner! Client und Server.

status /Pfad/zur/Datei/openvpn-status.log
Erstellt die Datei openvpn-staus.log im angebenen Verzeichnis
und erlaubt das Anzeigen von momentanen Verbindungen
Beispiel: status /etc/openvpn/openvpn-status.log. Nur Server.

comp-lzo
Wenn OpenVPN mit LZO-Kompression kompiliert wurde, dann kann diese Option eingetragen werden. Komprimiert die Daten. Server und Client

verb Level
Verbosity Level zur Detail Angabe von Meldungen die OpenVPN anzeigt.
Bereich 0-11.
0 – keine Ausgabe, außer Fehlermeldungen
1-4 – normale Ausgaben
5- bei Aktivitäten werden die Buchstaben „R“ und „W“ ausgegeben, klein für TCP/UDP Pakete und GROSS für TUN/TAP Pakete
6-11 – Ausführliches Debuging
Beispiel: verb 3

up Kommando
Ist ein Befehlszeilenkommando, dass nach erfolgreicher Installation eines TUN/TAP-Gerätes durchgeführt wird. Mit „up“ kann ein Script gestartet werden, um z.B. Routing-Kommandos zu spezifizieren. Server und Client. Beispiel: up ./server.up. In diesem Script könnte z.B. stehen:
#!/bin/bash
route add -net 10.0.1.0 netmask 255.255.255.0 gw $5

keepalive n m
Diese Hilfansweisung wird benutzt, um die Befehle „ping“ und „ping-restart“ in der Serverkonfiguration zu vereinfachen. Der Befehl „keepalive 10 60“ neinhaltet folgende Anweisungen:
if mode server: Wenn Server-Modus:
ping 10 ping 10
ping-restart 120 ping neustart 120
push „ping 10“ führe aus „ping 10”
push „ping-restart 60” führe aus „ping-neustart 60”
else im anderen Fall (kein Server-Modus)
ping 10 ping 10
ping-restart 60 ping-neustart 60

__________________
Debian GNU/Linux SID / Kernel 2.6.27-SMP
Private Linux Page

DaGrrr

Zertifikatserstellung


Unter Linux gibt es viele Möglichkeiten Zertifikate zu erstellen.
Ich stelle hier in diesem Howto die manelle und easy-rsa script Möglichkeit vor. Unter Windows ist es ebenfalls möglich Zertifikate zu erstellen und ich möchte dies ebenfalls aufzeigen, wie dies unter Windows funktioniert anhand der easy-rsa Scripte.
Im Anschluß der Zertifikatserstellung folgen Beispiele für die Konfiguration.

Zertifikatserstellung mit easy-rsa

Wir erstellen Zertifikate mit den easy-rsa Scripten aus dem OpenVPN-Paket. Ich werde hier die Vorgehensweise für Linux und Windows darstellen. Die Beschreibung lehnt sich stark an die Original-Dokumentation von OpenVPN an und kann als Übersetzung ins Deutsche verstanden werden, mit Kommentaren und Erweiterungen von mir.

Als erstes kopieren wir das easy-rsa Verzeichnis in unser /etc/openvpn Verzeichnis, was zur besseren Übersicht dient. Wir wechseln danach in das Verzeichnis /etc/openvpn/easy-rsa.
Unter Windows wechseln wir in der Command-Shell (cmd.exe) das Verzeichnis nach c:\Programme\OpenVPN\easy-rsa.

Anmerkung für Windows:
Wir führen init-config.bat aus, dabei werden existierende vars.bat und openssl.cnf Dateien überschrieben.

Anmerkung für Linux:
Eventuell muß die enthaltene OpenSSL Konfigurationsdatei opennssl.cnf entpackt werden, da sonst die Datei nicht gefunden wird.

Nun editieren wir die vars.bat (Windows) / vars (Linux) und setzen die Variablen für die Zertifikatserstellung. Die Angaben hinter dem „=“ Zeichen können anders lauten, es muß nicht z.B. =Berlin heißen. Es kann auch eine andere Stadt eingetragen werden, je nach Bedarf. Das gilt ebenfalls für die anderen Variablen.

KEY_COUNTRY=DE
KEY_PROVINCE=Bezirk
KEY_CITY=Berlin
KEY_ORG=IT-Abteilung
KEY_MAIL=holgi@domain.de

Dabei sollte keine dieser Variablen leer bleiben.

Wer Paranoid ist, kann auch den Wert „KEY_SIZE=1024“ höher setzen, z.B. auf 2048 oder 4096.


Wir erstellen nun in dem kommenden Abschnitt die Zertifikate und Schlüssel für die Root-CA, den Server und den oder die Clients.

Wir führen nun folgende Befehle aus:
Nach dem ausführen von build-ca (Linux) oder build-ca.bat (Windows) beginnt die Erstellung des/der Certificate Authority (CA) Zertifikats und des dazu gehörigen Schlüssels.
Nun kann man entsprechende Werte setzen aber da wir die Variablen bereits in der Datei vars (Linux) / vars.bat (Windows) gesetzt haben, brauchen wir nur noch mit der Return-Taste bestätigen.

Achtung: Der einzige Wert den wir explizit setzen müssen ist der „Common Name“. Der Common Name muß einzigartig sein und darf in keinem anderen Zertifikat vorkommen.

Ich habe für das Root-CA Zertifikat „OpenVPN-CA“ gewählt.

Erstellung des Zertifikats und des Schlüssels für den OpenVPN Server

Wie zuvor können wir die Parameter aus der Datei vars (Linux) / vars.bat (Windows) übernehmen und mit der Return-Taste übernehmen.

Achtung: Auch hier muß ein „Common Name“ per Hand eingetragen werden und wie schon gesagt muß der Name einzigartig sein.

Ich habe als Common Name „Vpn-Server“ gewählt.

Nach Ausführung müssen wir noch 2x mit [y] (Ja) bestätigen.


Erstellung der Zertifikate und Schlüssel für den/die Clients

Soll der Client Key Passwort geschützt werden, dann nehmen wir hier eine andere Datei und zwar:


Denk daran, dass der „Common Name“ für jedes Zertifikat anders lauten muß.
Ich habe als Common Name „client1“ ausgewählt. Für weitere Clients könnte man das fortführen und als Common Name client2, client3 usw. nutzen.

Wieder bestätigen wir 2x mit [y] (Ja).

Generieren des Diffie Hellman Parameters

Der Diffie Hellman Parameter wird für den OpenVPN Server erstellt und verbleibt auf diesem.

WindowsLinux
build-dh.bat ./build-dh

Die Erstellung von DH kann eine weile dauern. Die Geschwindigkeit ist abhängig von der CPU-Leistung und der gewählten Bitlänge. Je höher die Bitlänge, um so länger dauert die Erstellung.

Zugehörigkeit unser neu erstellten Zertifikate und Schlüssel

http://www.linux-technik.de/downloads/links/zert.png

Der nächste Schritt ist, die erstellten Schlüssel und Zertifikate an den entsprechenden Ort zu kopieren. Auf entfernte PCs sollte man fürs kopieren eine sichere Übertragungsart wählen. Entweder manuell z.B. per Usb-Stick (falls möglich) oder per SSH.


Manuelle Erstellung der Zertifikate unter Linux

Anmerkung: Ich habe in der Konfigurationsdatei für OpenSSL einige Pfadangaben geändert. Im Anhang füge ich die bearbeitete openssl.cnf bei.
Es sollte zur Vermeidung von eventuellen Problemen meine openssl.cnf verwendet werden.

Wir erstellen erstmal ein Arbeitsverzeichnis indem wir alle weiteren Schritte durchführen werden.

wechseln in das Arbeitsverzeichnis
Nun kopieren wir die openssl.cnf (OpenSSL Konfigurationsdatei), die ich als Download angehängt habe und die Datei CA.pl womit wir eine CA Zertifizierungstelle erstellen werden, in unser Arbeitsverzeichnis.

Die Datei CA.pl befindet sich bei Debian unter
/usr/lib/ssl/misc/CA.pl.

Sollte die CA.pl an einem anderen Ort liegen, können wir mit den beiden folgenden Befehlen den Ort ausfindig machen und sie dann in unser Arbeitsverzeichnis kopieren.
(vorher updatedb als root ausführen)

oder

(normalerweise in /usr zu finden)

Nun erstellen wir die Datei “serial“

und fügen folgenden Inhalt ein:

(Entertaste drücken!) und dann abspeichern.

Als letztes erstellen wir uns eine index.txt die leer bleibt.

Damit nun openssl weiß welche openssl.cnf wir jetzt verwenden werden, führen wir folgenden Shell Befehl aus:

Mit dem Befehl "env" können wir das überprüfen ob der Wert gesetzt wurde.
Bevor wir nun anfangen, können wir noch die openssl.cnf nach unseren wünschen verändern zb können wir den Standard Wert von 1024Bit auf 2048Bit setzen. Für ganz Paranoide ist wohl auch 4096Bit möglich, was ich aber nicht getestet habe.
Ist die openssl.cnf editiert (kein muss) können wir uns nun an die Erstellung der Zertifikate wenden:

Erstellung der CA:

Ist das erledigt (Passwort gut merken), gehts weiter...

Master Zertifikat:

Diffie Hellman Parameter für den Server erstellen:

(kann sehr lange dauern!)

Zertifikat für Server:
Zertifikat für den Client:

Anmerkung:
Der Common Name muss immer verschieden sein, ansonsten gibt es ein Database Error!

Immer alle *.old files löschen nach dem erstellen von Zertifikaten.

Nun können wir die Dateien client1.crt, client1.key und ca.crt über einen sicheren Weg z.B. SSH auf den Clienten übertragen. Die Zertifikate für den Server kommen auf dem OpenVPN Server.

Beispiel Konfigurationen

Routing:
Wenn geroutet werden soll, was bei Verwendung des TUN-Adapters ja notwendig ist, dann muß Routing bei dem Linux Rechnern aktiviert werden. Bei Verwendung von iptables-Paketfilter muß entsprechend eine weitere Regel hinzugefügt werden.

Das Routing aktivieren:

iptables Regel:


Ausgangslage für Beispiel 1) und 2)
OpenVPN Server: Netzwerk Home: 192.168.1.1/24, VPN Adresse: 10.1.0.1
OpenVPN Client: Netzwerk Home; 192.168.1.1/24, VPN Adresse; 10.1.0.2

1) Einfacher OpenVPN Tunnel mit Zertifikaten, 1 Server, 1 Client (Linux)

Server:


Client:


2) OpenVPN Tunnel mit Zertifikaten, Routing, 1 Server, x Client's (Linux)

In der ersten Beispielkonfiguration konnte nur ein Client mit dem VPN Server eine Verbindung aufbauen. Des Weiteren war kein Zugriff auf hinter dem OpenVPN Server liegendem Netzwerk möglich, da keine Routing Optionen gesetzt wurden.
In der folgenden Konfiguration wird der OpenVPN Server als DHCP Server dienen, sprich den Clienten eine IP Adresse zuweisen. Damit das funktioniert, muß das Routing stimmen. Außerdem ersetzen wir den Verschlüsselungsalgorithmus „Blowfish“ durch AES mit 256Bit.

Server:

Client:

Für weitere Clients, brauchen wir natürlich weitere Client Zertifikate, die wir vorher erstellt haben.


3) OpenVPN Tunnel mit Zertifikaten, Site-to-Site, 2 Server (Linux)

Ausgangslage für Beispiel 3)
OpenVPN Server1: Netzwerk Home: 192.168.1.1/24, VPN Adresse: 10.1.0.1, DnyDNS Name: berlin.dyndns.org
OpenVPN Server2: Netzwerk Home; 192.168.3.1/24, VPN Adresse; 10.1.0.2

In diesem Konfigurations Beispiel soll eine Site-to-Site dargestellt werden.
Es werden sozusagen 2 Firmenstandorte miteinander verbunden.
Das heißt, es gibt keine Clients in dem Sinne wie in den anderen Beispielen, wo z.B. ein Roadwarrior, also von unterwegs per Notebook auf das Netzwerk zugegriffen werden soll.
Es soll aber jeder Client das andere Netzwerk erreichen können. Damit das klappt, muß das Routing auf beiden Seiten modifiziert werden. Des Weiteren muß einer der OpenVPN Server als Server konfiguriert und der andere als Client konfiguriert werden.

Server:

up-Script für Server 1:

mit folgenden Inhalt:
Unter Windows würde eine Angabe so aussehen:

„-p“ sorgt dafür, dass die gesetzte Route permanent gesetzt wird.

Server 2:

up-Script für Server 2:

mit folgenden Inhalt:
Unter Windows würde eine Angabe so aussehen:

„-p“ sorgt dafür, dass die gesetzte Route permanent gesetzt wird.

Angehängte Dateien

openssl_cnf.tar.gz (3,0 KB, 357x aufgerufen)

__________________
Debian GNU/Linux SID / Kernel 2.6.27-SMP
Private Linux Page

DaGrrr

Konfiguration von OpenVPN mit Pre-Shared Keys

Als Ausgangsbasis benutzen wir unser Arbeitsverzeichnis /etc/openvpn (Linux) oder c:\Programme\OpenVPN\config (Windows).
Für die Konfiguration mit Preshared Keys ist weniger Arbeit notwendig, als mit Zertifikaten und es ist einfacher bzw. Fehler lassen sich schneller finden.

Wir wechseln in unser Arbeitsverzeichnis, wo wir später unsere Konfigurationsdatei anlegen werden.
Unter Windows können wir den Befehl zur Key Erstellung genauso verwenden wie unter Linux, da die Syntax gleich ist.

Wir erstellen jetzt einen Key mit dem unser VPN Tunnel später verschlüsselt wird:
Dieser Key wird für jede Gegenstelle gebraucht und muß daher auf jeden Teilnehmer kopiert werden.
Der Schlüsselaustausch sollte über ein sicheres Medium wie z.B. per SSH ausgetauscht werden!
Hat ein fremder diesen Schlüssel so kann er den VPN Tunnel knacken!

Beispiel Konfigurationen

Ausgangslage
OpenVPN Server: Netzwerk Home: 192.168.1.1/24, VPN Adresse: 10.1.0.1
OpenVPN Client: Netzwerk Home; 192.168.2.10/24, VPN Adresse; 10.1.0.2

Server:

Unser server.up Script für die Route
mit folgenden Inhalt:
Unter Windows würde eine Angabe so aussehen:

„-p“ sorgt dafür, dass die gesetzte Route permanent gesetzt wird.

Client:

Für den Clienten die Route setzen:
Mit folgenden Inhalt:
Unter Windows würde eine Angabe so aussehen:

„-p“ sorgt dafür, dass die gesetzte Route permanent gesetzt wird.

Auf beiden Seiten starten wir nun unser VPN mit folgendem Befehl
Nun sollte die Verbindung stehen.

Wir testen die Verbindung auf dem Clienten mit
Kommt hier eine positive Message... Glückwunsch der VPN Tunnel funktioniert.

__________________
Debian GNU/Linux SID / Kernel 2.6.27-SMP
Private Linux Page

DaGrrr

Unterschiede zwischen TUN und dem TAP Device

Bisher haben wir nur mit dem TUN-Adapter gearbeitet. Da nun Ethernet Bridging behandelt wird, sollte nun auch der Unterschied zwischen TUN- und TAP Adapter erklärt werden.

Ein TAP Device ist ein virtueller Ethernet Adapter, während das TUN Device eine virtuelle Point-to-Point IP Verbindung ist.
Vielleicht etwas genauer gesagt:

TAP überträgt Ethernetframes (Layer 2)
Layer 2 Protokolle z.B. NETBUI, DHCP, Broadcasts können so über das VPN transportiert werden. Applikationen, die diese Protokolle brauchen, können so völlig transparent über das VPN benutzt werden.

TUN überträgt IP-Pakete (Layer 3)
Layer 3 oder auch Vermittlungsschicht genannt, beschäftigt sich mit der Steuerung des Subnetz-Betriebes. Die wichtigste Aufgabe ist die Bestimmung von Paketleitwegen vom Ursprungs- zum Bestimmungsort (Routing).

Man kann beide Devices nicht mixen, z.B. TUN auf dem Server und TAP auf dem Client.


Was ist Bridging?

Bridging ist eine Technik für das Erstellen eines virtuellen Wide-Area Ethernet LAN, welches in einem einzigen Subnetz läuft. Kurz gesagt können mit Bridging zwei oder mehr getrennte Subnetze logisch in eines verschmelzen, als ob sie ein einzelnes Subnetz wären. Als Beispiel kann hier gesagt werden, dass es mit Bridging möglich ist, dass SMB Protokoll ohne Probleme nutzen zu können. Um Bridging mit OpenVPN verwenden zu können, muß das TAP Device verwendet werden.


Wichtiger Hinweis zum Site-to-Site Bridging:
Wenn kein Router verwendet wird, dann darf auch nicht die Netzwerkkarte überbrückt werden die mit dem DSL Modem verbunden ist, weil diese Netzwerkkarte eine IP-Adresse vom Internet Service Provider (ISP) bekommt. Sollte keine weitere Netzwerkkarte in dem Rechner installiert sein, dann wird auch kein Bridging benötigt, weil kein Netzwerk an diesem PC angeschlossen ist. Wenn eine zweite Netzwerkkarte vorhanden ist, und an dieser ein Netzwerk angeschlossen wurde, dann muß diese mit dem TAP-Adapter gebridged werden.

Bridging konfigurieren

Anhand folgendem Beispiels, wird ein OpenVPN Server-Side Ethernet Bridge erstellt. Mehrere Clients können so zur Bridge Verbindung aufnehmen und jedem Client-TAP-Device wird eine IP-Adresse zugeteilt.

Es gibt zwei Methoden für die IP Zuweisung:

1)OpenVPN verwaltet seinen eigenen Client IP Pool
2)Konfigurieren eines DHCP Servers im LAN


Bei diesem Beispiel benutzen wir die erste Methode. Der OpenVPN Server verwaltet also seinen eigenen IP-Address-Pool.

Folgende Bridge Einstellungen werden wir hier verwenden:


Ethernet Interface -- eth -- eth0
Lokale IP-Addresse -- eth_ip -- 192.168.1.1
Lokale Netzwerkmakse -- eth_netmask -- 255.255.255.0
Lokale Broadcast Addresse -- eth_broadcast -- 192.168.1.255
VPN Client IP-Address Pool -- 192.168.1.100-192.168.1.110
Virtueles Bridge Interface -- br -- br0
Virtuelles TAP Interface -- tap -- tap0


Bridge Server mit Linux

Damit Bridging benutzt werden kann, muß als erstes das „bridge-util“ Paket installiert werden.

Danach werden wir im folgenden Script unsere Werte aus der Tabelle einfügen. Gesetzt werden müssen:
br, tap, eth, eth_ip, eth_netmask und eth_broadcast

Das Script speichern wir ab z.B. unter dem Namen „startbridge.sh“ und machen es mit „chmod +x startbridge.sh“ ausführbar.
Zum stoppen des Bridging Modus, können wir folgendes Script verwenden:

Ebenfalls speichern wir das Script unter dem Namen „stopbridge.sh“ und führen wir „chmod +x stopbridge.sh“ aus.
Danach starten wir das Script mit „sh startbridge.sh“ . Das Script kreiert ein festes tap0 Interface und „bridgt“ es es mit unserem Ethernet Interface (eth0).
Nun müssen wir noch unsere OpenVPN Konfiguration (Server) bearbeiten, damit OpenVPN die Bridge benutzen kann.
Wir ersetzen in der Konfiguration

durch

Wenn wir mehrere Bridges erstellt haben, dann ist es notwendig diese zu kennzeichnen. Realisiert wird dies unter Linux mit Zahlen, die die jeweils zu verwendende Brücke kennzeichnet. Beispiel: tap0, tap1, tap2 etc.

Des Weiteren ersetzen oder löschen folgende Zeile mit der Option „server“ (falls vorhanden)


durch

Hierbei wird auch der IP-Address-Pool gesetzt.

Wir setzen folgende zusätzliche iptables Regeln, die es erlauben, dass die Pakete durch unsere neu erstellten tap0 und br0 Interfaces geleitet werden.

Die OpenVPN Bridge kann nun gestartet und gestoppt werden mit folgender Reihenfolge:
1)sh startbridge.sh
2)OpenVPN starten z.B. mit openvpn --config openvpn.conf
3)Openvpn stoppen
4)sh stopbridge.sh


Bridge Server mit Windows XP

Bridging unter Windows 2000 ist als „Server“ nicht möglich, da es nicht unterstützt wird. Daher benutzen wir Windows XP oder höher als Server. Allerdings kann Windows 2000 als Bridging Client eingesetzt werden.
Wenn OpenVPN unter Windows installiert wurde, wird ein virtueller TAP-Win32 Adapter mit dem Namen „Lan-Verbindung X“ kreiert. X ist eine Zahl und bezeichnet das X'te Netzwerkadapter. Als erstes benennen wir Lan-Verbindung X in „tap-bridge“ um.
Als zweiten Schritt klicken wir mit der rechten Maustaste auf „tap-bridge“ und wählen „Verbindungen überbrücken“ . Das wird ein neues Bridge Device erstellen unter Netzwerkverbindungen.
Das ganze stelle ich hier als Screenshots vor:
(Die Namen der Adapter unterscheiden sich von den hier dargestellten Bildern!)

http://www.linux-technik.de/downloads/links/1.jpg
http://www.linux-technik.de/downloads/links/2.jpg
http://www.linux-technik.de/downloads/links/3.jpg
http://www.linux-technik.de/downloads/links/4.jpg
http://www.linux-technik.de/downloads/links/5.jpg

Unter TCP/IP Eigenschaften setzen wir die IP 192.168.1.1 und eine Subnetzmaske 255.255.255.0.

In unserer OpenVPN Konfiguration „openvpn.ovpn“ ersetzen wir
mit


Weiterhin schreiben in der Serverkonfiguration folgendes rein:
Wird Windows XP mit Servicepack 2 verwendet, dann schalten wir in der Systemsteuerung --> Windows Firewall, Filterung für den TAP und Bridge Adapter aus.


Bridge Client Konfiguration

In der Client Konfigurationsdatei (Windows / Linux) ist es notwendig „dev tun“ durch „dev tap“ zu setzen. Das ist alles.

Beispiel Konfigurationen

Ausgangslage
OpenVPN Server: Netzwerk Home: 192.168.1.1/24, bekommt VPN Adresse: 10.1.0.1
OpenVPN Clients: Netzwerk Home; 192.168.1.2-192.168.1.12/24, bekommt VPN Adresse; 10.1.0.10-10.1.0.20

1) Bridge OpenVPN Tunnel mit Zertifikaten, 1 Server, 10 Client's (Linux)


Server:

Client's:


2) OpenVPN Tunnel mit Zertifikaten, Site-to-Site, 2 Server (Linux)

Ausgangslage für Beispiel 3)
OpenVPN Server1: Netzwerk Home: 192.168.1.1/24, VPN Adresse: 10.1.0.1, DnyDNS Name: berlin.dyndns.org
OpenVPN Server2: Netzwerk Home; 192.168.3.1/24, VPN Adresse; 10.1.0.2

In diesem Konfigurations Beispiel soll eine Site-to-Site dargestellt werden.
Es werden sozusagen 2 Firmenstandorte miteinander verbunden.
Das heißt, es gibt keine Clients in dem Sinne wie in dem vorigen Beispiel, wo z.B. ein Roadwarrior, also von unterwegs per Notebook auf das Netzwerk zugegriffen werden soll.
Des Weiteren muß einer der OpenVPN Server als Server konfiguriert und der andere als Client konfiguriert werden.


Server1:


Server 2:

__________________
Debian GNU/Linux SID / Kernel 2.6.27-SMP
Private Linux Page