Wir sind unabhängig, neutral und finanzieren uns teilweise über Werbung und Partnerprovisionen.
Danke wenn sie uns unterstützen. Diese Seite verwendet hierzu Cookies & Tracking-Cookies, weitere Informationen finden sie hier. Wenn sie diese Seite weiterhin besuchen, erklären sie sich damit einverstanden. (Danke!)
Wir sind unabhängig, neutral und finanzieren uns teilweise über Werbung und Partnerprovisionen. Danke wenn sie uns unterstützen.
Diese Seite verwendet hierzu Cookies & Tracking-Cookies, weitere Informationen finden sie hier. Wenn sie diese Seite weiterhin besuchen, erklären sie sich damit einverstanden.

 _______                   ___ ___ ______ _______      _______

|.  _   |_____ _____ _____|:  |:  |:  __ \ :  |: |    |:'   __| ____ ____ __ __ _____ ____

|: |_| :|: _  |: -__|:    |:  |:  |:   __/   .   |    |__    '|' -__|:  _|: |: |: -__|:  _|

|_______|:  __|_____|__|__|\_____/|___|  |__|____|    |_______|_____|__|  \___/|_____|__|

        |__|

              2016-05-31 © 
ctaas.de, Arno Schröder (Impressum)

           tap/NAT : bridging : Layer 2 : Protokollierung

OpenVPN
einfach & sicher installieren:
tap/NAT, bridging, Layer 2, Protokollierung
2016-05-31 © ctaas.de, A. Schröder (Impressum)

Diese Anleitung (Howto) erklärt wie man einen OpenVPN Server mit tap/NAT, Layer 2, bridging sowie Protokollierung einfach & sicher unter Ubuntu einrichtet.

Voraussetzung ist am besten eine saubere Grundsysteminstallation eines Ubuntu Server Systems - wie man dieses aufsetzt habe ich bereits hier beschrieben.
Hier nicht richtig? Zum tun/NAT, Layer 3, routing Tutorial geht es hier.

Hinweis:
Diese Dokumentation ist veraltet. Diese Anleitung wurde damals für Ubuntu 14.04 realisiert.
Eine aktualisierte Version finden Sie über diesen Link.

Kurze Farberklärung zur Dokumentation:
grau hebt Variablen, Menüeinträge und ähnliche unveränderliche Werte hervor.
grün markiert wichtige Eingaben. Eingaben die man der eigenen Umgebung anpassen kann sind grün/rot dargestellt.
gelb markiert optionale Eingaben. Eingaben die man optional ändern kann sind gelb/rot dargestellt.
rot! markiert Einträge die man löschen muss, zeigt mögliche Fehler bei Fehlkonfigurationen und kennzeichnet sonstige wichtige Hinweise.

Server-Konfiguration:

1.
Zuerst installiert man die nötigen OpenVPN-Pakete:

apt-get update && apt-get dist-upgrade
apt-get install openvpn easy-rsa bridge-utils

2.
Dann kopiert man die vom Paket bereitgestellten easy-rsa Scripte in ein beliebiges Verzeichnis, um Änderungen durch Paketupdates zu verhindern:

mkdir /etc/openvpn/easy-rsa/
cp -r /usr/share/easy-rsa/* /etc/openvpn/easy-rsa/

3.
Verschlüsselungsstärke, Gültigkeitsdauer und Umgebungswerte für die eigene Zertifizierungsstelle Certificate Authority (CA) festlegen:

nano /etc/openvpn/easy-rsa/vars

...
export KEY_SIZE=4096
# Optional: 2048 (Standard)
...
export CA_EXPIRE=3650
# Optional:
# 5475 = 15 Jahre
# 7300 = 20 Jahre
# 9125 = 25 Jahre
...
export KEY_EXPIRE=3650
# Optional:
# 5475 = 15 Jahre
# 7300 = 20 Jahre
# 9125 = 25 Jahre
...
export KEY_COUNTRY="DE"
export KEY_PROVINCE="TH"
export KEY_CITY="Kahla"
export KEY_ORG="Computertechnik"
export KEY_EMAIL="mail@ctaas.de"
export KEY_OU="IT-Administration"
...
export KEY_NAME="Schroeder-VPN"
...

Parametererklärungen:
Den Wert [KEY_SIZE] ändert man am besten auf mindestens 4096 - schließlich gelten standardmäßig die Zertifikate 10 Jahre (je höher der Wert, je höher die Sicherheit).
Da man das Erstellen von Zertifikaten nicht täglich macht, ist die Änderung auf mindestens 4096 von mir empfohlen.
Auf die Übertragungsgeschwindigkeit hat dieser erhöhte Wert übrigens nahezu keine Auswirkung, nur die Erstellung der Zertifikate dauert etwas länger.
Bei Werten bis einschließlich 2048 geht die Diffie-Hellman-Schlüsselaustausch Erstellung [./build-dh] noch relativ schnell.
Bei einem Wert von 4096 benötigt der [./build-dh] circa 1 Stunde (3 GHz PC).
Verwendet man noch höhere Werte, so kann zum einen die Erstellung schnell mehrere Stunden bzw. Tage dauern und die Client-Kompatibilität kann darunter leiden.

Die Werte [CA_EXPIRE] und [KEY_EXPIRE] legen die Gültigkeitsdauer in Tagen für die Certificate Authority (CA) und die Schlüsseldateien fest.
Standardmäßig sind hier rund 10 Jahre voreingestellt.

Die übrigen Werte haben folgende Bedeutung:
KEY_COUNTRY=DE (euer LAND)
KEY_PROVINCE=TH (euer Bundesland)
KEY_CITY=Kahla (eure Stadt)
KEY_ORG=Computertechnik (eure Organisation)
KEY_EMAIL=mail@ctaas.de (eure E-Mailadresse)
KEY_OU=IT-Administration (Organisationseinheit/Abteilung)
...
KEY_NAME=Schroeder-VPN (euer Name)

Passt diese Werte entsprechend euren Anforderungen an.
Wichtig: Man sollte diese Werte aus Sicherheitsgründen alle ändern.

Hinweis:
Den Link auf die neueste [openssl.cnf] wie in einigen anderen Dokumentationen steht muss man nicht mehr setzen.
Das Kopieren von [cp openssl-x.x.x.cnf openssl.cnf] kann man sich also sparen.
Beim Erzeugen der server- und client-Zertifikate ist es dann ersichtlich - denn da steht:
[Using configuration from /etc/openvpn/easy-rsa/openssl-1.0.0.cnf]
Es wird hier also automatisch die neueste [openssl-x.x.x.cnf]-Version verwendet.

4.
Erstellung einer eigenen Zertifizierungsstelle - Certificate Authority (CA) um Server & Clientzertifikate zu signieren:

cd /etc/openvpn/easy-rsa/
source vars
./clean-all
./build-ca

Den Befehl [source vars] muss man immer starten, bevor man Änderungen an Zertifikaten vornehmen kann (setzt die entsprechenden Umgebungsvariablen).
Danach führt man einmalig [./clean-all] aus - dies löscht ein ggf. vorhandenes [keys]-Verzeichnis komplett!
Wichtig: Den Schritt [./clean-all] also nur einmalig bei der Einrichtung durchführen.
Der Befehl [./build-ca] erzeugt dann die notwendigen Dateien für die Certificate Authority (CA).
Die vorgegebenen Werte einfach mit [Enter] übernehmen.

Wichtig:
Der [Common Name] (CN) muss für jedes Zertifikat einzigartig sein.
Der CN für die CA setzt sich Standardmäßig aus den in den [vars]-Datei angegebenen Umgebungsvariablen [KEY_ORG] und [CA] zusammen.
In dem Beispiel lautet daher der [Common Name] (CN) für die Certificate Authority (CA) daher [Computertechnik CA].

5.
Zertifikat und privaten Schlüssel für den Server erstellen:

./build-key-server server

Der [Common Name] (CN) sollte auf [server] stehen.
Wie in den vorhergehenden Schritten kann man für die meisten Parameter die Standardwerte verwenden [Enter].
Zwei Nachfragen erfordern eine positive Antwort:
Sign the certificate? [y/n]? und
1 out of 1 certificate requests certified, commit? [y/n]?.

6.
Diffie-Hellman-Parameter generieren:

./build-dh

Dies kann je nach Geschwindigkeit des Systems und verwendeter Schlüssellänge eine Stunde und länger dauern.
Also Kaffee holen... ♥ ...und warten, bis wieder eine Eingabeaufforderung erscheint.
Die CPU-Belastung ist fast 100%, so dass anderweitiges Weiterarbeiten wenig Sinn hat.
Hat man nur ein kleineres Embedded-System welches wenig Leistung hat, so empfiehlt es sich die Zertifikate auf zuvor auf einem leistungsstarken PC zu erstellen. Anschließend kopiert man die fertigen Zertifikate über eine gesicherte Verbindung auf das Zielsystem.

Optional:
Man kann auch noch stärkere Diffie-Hellman-Parameter generieren, da diese unabhängig von der Schlüsselstärke sind (die [KEY_SIZE] hat hier keine Bedeutung).
Dieser Schritt wird erst empfohlen wenn alles läuft, verwendet für die Ersteinrichtung also erst mal den Standardwert:

openssl dhparam -out dh8192.pem 8192 # getestet: ok
openssl dhparam -out dh16384.pem 16384 # getestet: nicht empfohlen - funktioniert derzeit (2015-10-20) mit keinem Android-Client.

Nach der Erzeugung der stärkeren Diffie-Hellman-Parameter-Datei, passt man in der [server.conf] nochmals den entsprechenden [dh] Eintrag an und startet OpenVPN neu [service openvpn restart] um die neuen Einstellungen zu übernehmen.

7.
Alle für den Server relevanten Zertifikate und Schlüssel wurden im Unterordner [keys] generiert.
Üblicherweise kopiert man sie in den Ordner [/etc/openvpn/]:

cd /etc/openvpn/easy-rsa/keys/
cp server.crt server.key ca.crt dh4096.pem /etc/openvpn/

8.
tls-auth Schlüssel erstellen:

cd /etc/openvpn/
openvpn --genkey --secret ta.key

tls-auth (der ta.key) bewirkt, dass OpenVPN zusätzliche HMAC-Signaturen zu allen SSL/TLS-handshake-Paketen hinzufügt.
OpenVPN signiert dann alle SSL/TLS-Pakete und kann dadurch schon vor dem Handshake einen unberechtigten Client erkennen und die Verbindung beenden.
Pakete mit einer falschen Signatur werden also sofort verworfen.
Dies kann auch die Geschwindigkeit erhöhen und stabilisieren, da Portscanner die Verbindung nicht blockieren können.
tls-auth verhindert also:
- DoS-Attacken die den Port überfluten,
- Portscanning, der Port ist nicht mehr als VPN ersichtlich,
- Buffer Overflows in der SSL/TLS-Implementation,
- und SSL/TLS-Verbindungen von unautorisierten Maschinen.

9.
Client Zertifikate erstellen:
Der VPN-Client benötigt noch ein Zertifikat um sich gegenüber dem Server zu authentifizieren. Üblicherweise wird für jeden Client ein eigenes Zertifikat erstellt.

cd /etc/openvpn/easy-rsa/
source vars

Wichtig:
Den Befehl [source vars] muss man immer starten bevor man Änderungen an den Zertifikaten vornehmen kann (setzt die entsprechenden Umgebungsvariablen).

Tipp:
Bei der Nummerierung der Clients sollte man nicht mit [01] beginnen, da die [01.pem]-Datei nämlich schon das Server Zertifikat erhalten hat (siehe Punkt 33).

Zertifikate mit Passwort:
Ein Zertifikat mit Passwort erhöht die Sicherheit, da auf dem Client vor dem Aufbau der VPN-Verbindung ein zusätzliches Passwort abgefragt wird.
Wird z. B. ein Notebook gestohlen, so kann der Dieb trotzdem erst mal keine VPN-Verbindung herstellen, da dem Dieb dem das dazu nötige Passwort sicher nicht bekannt ist.

./build-key-pass client02

Gleich zu Beginn wird eine phrase (das Passwort) abgefragt.
Dieses Passwort (phrase) muss der Client-Nutzer dann beim Herstellen einer VPN-Verbindung jedes mal eingeben.
Also bei [Enter PEM pass phrase:das_gewuenschte_Passwort] eingeben.
Der [Common Name] (CN) sollte wieder eindeutig sein und auf [client02] stehen.
Die Fragen am Ende wieder mit [y] bestätigen.

Zertifikate ohne Passwort:

./build-key client03

Der Ablauf ist hier wie beim Zertifikat mit Passwort, nur das hier kein Passwort abgefragt wird.
Der [Common Name] (CN) sollte wieder eindeutig sein und auf [client03] stehen.
Die Fragen am Ende bestätigt man wieder mit [y].
Diese Zertifikate sind dann z. B. für Standorte mit fester/automatischer Verbindung besser geeignet.

Tipp:
Wer noch weitere Keys erstellen will, kann dies gleich tun.
Hierzu einfach die oben beschriebenen [build-key...] -Scripte nochmals aufrufen und eben den [Client03] ändern z. B. hoch zählen (meine Empfehlung).

Wichtig:
OpenVPN zählt Hexadezimal hoch. Nach [client09] kommt also [client0A].
Also am besten folgende Zählweise verwenden: 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21...
Wer nicht mehr weiß wo es weiter geht, sollte einen Blick in die [index.txt]-Datei im [keys]-Ordner werfen.

Dateien für den Client:
Man kopiert die folgenden Dateien unter Verwendung einer sicheren Methode auf den Client:

/etc/openvpn/ca.crt
/etc/openvpn/easy-rsa/keys/client02.crt
/etc/openvpn/easy-rsa/keys/client02.key
/etc/openvpn/ta.key
/etc/openvpn/easy-rsa/client.conf (wird unten erst noch erstellt)

10.
Zusammen mit der OpenVPN-Installation wurden Beispielkonfigurationsdateien zur Verfügung gestellt.
Diese Beispiele kopiert man in ein beliebiges Verzeichnis, um Änderungen durch Paketupdates zu verhindern.
Die server.conf.gz muss man dabei noch entpacken:

cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
gzip -d /etc/openvpn/server.conf.gz

11.
Anpassen der Beispielkonfiguration.
Die server.conf bearbeiten:

nano /etc/openvpn/server.conf

# Am Start folgende Einträge hinzufügen:

# Die HMAC-Authentication von 160-Bit auf 512-Bit erhöhen:
auth SHA512
# Wichtig: Den Eintrag muss man auch in die [client.conf] hinzufügen.
# Mittels [openvpn --show-digests] kann man sich alle Hash-Algorithmen anzeigen.

# Auf gesperrte Zertifikate prüfen:
; crl-verify /etc/openvpn/easy-rsa/keys/crl.pem
# Wichtig:
# Den Eintrag erst aktivieren/hinzufügen wenn wirklich Zertifikate gesperrt wurden!
# Aktiviert man den Eintrag schon vorher, so kann man keine Verbindung aufbauen!
#
# Kurzanleitung Zertifikate sperren:
# Umgebung initialisieren [cd /etc/openvpn/easy-rsa/] & [source vars],
# dann das Zertifikat sperren mit: [./revoke-full clientname].
# Anschließend die Einstellungen neu laden [service openvpn reload]!

# ... und die vorhandenen Einträge wie folgt ändern:

# Der Standardport 1194 kann in fremden Zugängen (Cafes, ...) geblockt sein.
# Daher ändert man den Port auf 443 und tunnelt so den VPN-Zugang über den HTTPS-Port (443) der nahezu überall offen ist.
port 443
# Dies stellt sicher, dass man den Zugang überall nutzen kann.

proto tcp
# Da HTTPS (Port 443) standardmäßig über TCP transportiert wird passt man dies ebenso an.

dev tap0
# tun = routing
# tap = bridging
# Wichtig: Dieses Tutorial geht nur auf bridging ein also auf [tap0] ändern!

# Hier dann die Pfade zu den jeweiligen Zertifikaten angeben:
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
...
dh /etc/openvpn/dh4096.pem

# Den vorhandenen Eintrag:
;server 10.8.0.0 255.255.255.0
# muss man zwingend auskommentieren (dieser ist nur für routing-Netze nötig).

# Um auch andere PCs im Server Netzwerk (PCs im Subnetz des Server) zu erreichen, muss man den folgenden Bridging-Eintrag aktivieren und anpassen:
server-bridge 192.168.0.11 255.255.255.0 192.168.0.250 192.168.0.254
# Erklärung: OpenVPN-Server-IP, Subnetmaske, DHCP-Start-IP, DHCP-End-IP (für Clients)

push "route 192.168.0.9 255.255.255.0"
# Hier trägt man die IP-Adresse des DSL-Routers im Server-Netzwerk ein.
# Standard Netzwerkanfragen werden dann entsprechend ins VPN-Netzwerk geroutet.

# Optional: Will man den kompletten Netzwerkverkehr über das VPN-Netz weiter leiten (als Internetgateway), so muss man noch folgenden Eintrag aktivieren:
;push "redirect-gateway def1 bypass-dhcp"
# Hier bei Bedarf das auskommentierende [;] Semikolon entfernen.
# Hinweis: Es werden dann auch alle DNS-Anfragen
# an den OpenVPN-Server weitergeleitet.
#
# In der Regel empfehle ich diesen Eintrag nicht zu aktivieren, da die Clients (zum Surfen) dann ihren eigenen Internnetzugang nutzen.
# Clients sind dann bei reinen Internetanfragen nicht mehr abhängig von der Uploadgeschwindigkeit des Serveranschlusses.
# Es wird dann also nur der Netzwerktraffic über das VPN-Netz übertragen der Netzintern ist.

# Optional: DNS-Serverübergabe an den Client:
Hier kann man nur DNS-Server angeben die FQDN-DNS-Namen auflösen!
push "dhcp-option DNS 8.8.8.8" # Hier sollte man z. B. den Google DNS-Server angeben.
# Hier bei Bedarf das auskommentierende [;] Semikolon entfernen.
# Auf keinen Fall darf man hier den DSL-Router angeben.

# Optional: Ebenso könnte man einen WINS-Server übergeben (der Eintrag ist nicht vorhanden).
;push "dhcp-option WINS 192.168.0.1" # WINS-Server.

# Optional: Benötigen VPN-Clients den Zugriff untereinander, so aktiviert man folgenden Eintrag:
;client-to-client

# Des weiteren aktiviert man den tls-auth Eintrag (siehe Punkt 8):
tls-auth /etc/openvpn/ta.key 0
# Hier also das führende [;] entfernen und den Pfad ergänzen.

# Weiterhin sollte man noch die Verschlüsselung erhöhen:
# Mittels [openvpn --show-ciphers] kann man sich alle Verschlüsselungsmöglichkeiten anzeigen lassen.
# Empfehlen würde ich hier folgende Einstellung:
cipher AES-256-CBC

# Optional: Begrenzung der maximalen Clients.
;max-clients 100
# Es empfiehlt sich den Wert zu aktivieren und auf ein sinnvolles Maß zu begrenzen.

# Wichtig: Um die Sicherheit weiter zu erhöhen, sollte man den OpenVPN-Daemon mit eingeschränkten Privilegien laufen lassen.
# Man sollte also diese beiden [;] entfernen.
;user nobody
;group nogroup

# Optional: Spezielle Client-Konfigurationen:
# Diese muss man nur aktivieren, wenn man für bestimmte Clients besondere Konfigurationen benötigt.
;client-config-dir /etc/openvpn/ccd
# ccd = client config dir
# Im Verzeichnis [/etc/openvpn/ccd/] legt man hier für die entsprechenden User eine Datei mit dem [Common-Namen] (CN) an (siehe Punkt 9).
# Also z. B. [nano /etc/openvpn/ccd/client02].
# In dieser Datei kann man dann für den entsprechenden Client eigene Direktiven mitgeben.
# Hier könnte z. B. stehen [push "dhcp-option DOMAIN domain.local"] oder [push "redirect-gateway"] ...

# Optional: Für Speed-Tuning die folgenden Einträge hinzufügen:
# Standard sind 8 bzw. 64 KB Puffergröße,
# diese erhöht man auf 256K (262144 Bytes),
# oder optional auf 128K (131072 Bytes),
# um die Geschwindigkeit zu verbessern.
sndbuf 262144
rcvbuf 262144
push "sndbuf 262144" # send to client
push "rcvbuf 262144" # send to client

# tcp tweak: don't wait to queue packets (setting this on the server will also push it to clients)
tcp-nodelay

# Zugriffe Protokollieren:
script-security 2 # Das ausführen von Scripten zulassen - fürs einfache Logging und die Netzwerkbrücke nötig!
client-connect /my/logon.sh # Das angegebene Script wird beim Client-connect auf dem Server gestartet (Erfassung der verbundenen: Clients, Datum, IP usw...).
client-disconnect /my/logoff.sh # Das Script wird beim Client-disconnect auf dem Server gestartet (Erfassung der getrennten: Clients, Datum, IP, Dauer, Traffic usw...).

# Netzwerkbrücke von OpenVPN aktivieren bzw. beenden über entsprechende Shell-Scripte:
up "/etc/openvpn/up.sh br0 tap0 1400" # $1=br0, $2=tap0, $3=1400
down "/etc/openvpn/down.sh br0 tap0" # $1=br0, $2=tap0
# Die Parameter werden in den entsprechenden Shell-Scripten wieder ausgewertet:
# [br0] ist der Name der Netzwerkbrücke,
# [tap0] ist der Name vom virtuellen Netzwerkinterface,
# [1400] bestimmt den MTU Wert (Maximum Transmission Unit).
# Den Optimalen MTU-Wert kann man ermittelt mit [ping -f -l 1464 domain.de] - hierbei den Wert so lange verkleinern bis keine Paketfragmentierung mehr auftritt.
# Von dem ermittelten Wert muss man dann aber noch den OpenVPN Overhead abziehen, so das meist Werte um ca. 1300 - 1400 am besten sein sollten.

# Wichtig: [script-security 2]-Level muss auf 2 stehen, um eigene Shell-Scripte zu ermöglichen.
# Da dieser Eintrag schon unter 'Zugriffe Protokollieren' steht, muss man diesen hier nicht noch einmal angeben.

Startscript anlegen:

nano /etc/openvpn/up.sh

# Hier folgendes hinzufügen:
#!/bin/sh
BR=$1 # = der Brückennname [br0] (Wichtig: Den Kommentar nicht mit übernehmen!)
DEV=$2 # = das Netzwerkinterface [tap0] (Den Kommentar nicht mit übernehmen!)
MTU=$3 # = der MTU-Wert [1400] (Den Kommentar nicht mit übernehmen!)
/sbin/ifconfig $DEV mtu $MTU promisc up
/sbin/brctl addif $BR $DEV
exit 0

Stopscript anlegen:

nano /etc/openvpn/down.sh

#Hier folgendes hinzufügen:
#!/bin/sh
BR=$1
DEV=$2
/sbin/brctl delif $BR $DEV
/sbin/ifconfig $DEV down
exit 0

Die Scripte noch ausführbar machen:

chmod +x /etc/openvpn/up.sh
chmod +x /etc/openvpn/down.sh

Netzwerkinterface für die Brücke zwischen eth0 und tap0 vorbereiten:

nano /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
### den loopback Eintrag so lassen:
auto lo
iface lo inet loopback

### alten Netzwerkeintrag deaktivieren:
# The primary network interface
# auto eth0
# iface eth0 inet static
# address 192.168.0.11                # Server IP-Adresse.
# netmask 255.255.255.0               # Server Subnetmaske.
# gateway 192.168.20.21               # Standard-Gateway (DSL-Router im Server Netzwerk).
# dns-nameservers 192.168.0.9 8.8.8.8 # Der Standard DSL-Router im Server Netzwerk leitet DNS-Anfragen weiter an den Provider & Google DNS-Server (fallback).
# network 192.168.0.0                # Server Netzbereich.
# broadcast 192.168.0.255          # Broadcast im Netzwerk.

### den Netzwerkbrücken Eintrag hinzufügen:
auto br0
iface br0 inet static
address         192.168.0.11        # Server IP-Adresse. (Wichtig: Alle Kommentare hinter Parametern nicht mit übernehmen!)
netmask         255.255.255.0       # Server Subnetmaske.
gateway         192.168.0.9         # Standard-Gateway (DSL-Router im Server Netzwerk).
network         192.168.0.0         # Server Netzbereich.
dns-nameservers 192.168.0.9 8.8.8.8 # Der Standard DSL-Router im Server Netzwerk leitet DNS-Anfragen weiter an den Provider & Google DNS-Server (fallback).
broadcast       192.168.0.255       # Broadcast im Netzwerk.
bridge_ports eth0                   # Über welche Netzwerkkarte soll die Brücke aufgebaut werden?
### Wichtig: Kommentare die hier hinter Parametern stehen muss man unbedingt entfernen.
#            Alternativ kann man diese Erklärungen auch in eine neue extra Zeile verschieben.
#            Lässt man die Kommentare stehen, so startet das Netzwerk nicht korrekt und verschiedenste Funktionen wie z. B. einfache DNS-Auflösungen gehen dann nicht mehr.

### Einstellungen für das lokale Netzwerk:
iface eth0 inet manual
up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc off
down ip link set $IFACE promisc off
down ifconfig $IFACE down

Wichtig: In virtuellen Umgebungen den Promiscuous-Mode anpassen:
Installiert man die hier vorgestellte Lösung unter VirtualBox,
so muss man bei der betreffenden VM über [Einstellungen], [Netzwerk] den [Netzwerkadapter] auf [Netzwerkbrücke] einstellen
und insbesondere sicherstellen dass der [Promiscuous-Modus] auf [erlauben für alle VMs und den Host] eingestellt ist.
Denn nur in diesem Modus werden alle ankommende Netzwerk-Datenpakete entsprechend weitergeleitet.
Sollte man eine andere Virtualisierungslösung wie z. B. einen ESXi Server einsetzen, so muss man dort ebenso den Promiscuous-Modus anpassen.
Installiert man die Lösung auf einen echten physischen PC, so muss man hier in der Regel nichts beachten.
Den Promiscuous-Modus muss man nur beim tap/bridging anpassen - verwendet man tun/routing so wird hier nichts verändert.

VirtualBox Netzwerk Promiscuous-Mode Einstellungen

VirtualBox Netzwerk Promiscuous-Mode Einstellungen

Fehler die auftreten können:
Hat man den Promiscuous-Modus nicht aktiviert, so kann man nur den Server anpingen und das hinter dem Server liegende Netzwerk ist nicht erreichbar.

Damit die neuen Netzwerkeinstellungen auch übernommen werden (die Netzwerkbrücke initialisiert wird) startet man am einfachsten noch mal neu:

reboot

Der Server könnte jetzt schon gestartet werden. Es fehlt allerdings noch...
- das IPv4 Routing,
- die NAT Einstellungen (nur nötig beim routing) und,
- die Firewall Einstellungen
... wenn man das Subnetz hinter dem Server erreichen will.

12.
IPv4-Routing aktivieren:

nano /etc/sysctl.conf

# Hier die folgende Zeile wie folgt ändern:
net.ipv4.ip_forward=1
# Das führende [#] entfernen nicht vergessen.

Um die IP-Forwarding Einstellungen sofort zu übernehmen wird folgende Eingabe benötigt (alternativ geht auch ein [reboot]):

sysctl -p /etc/sysctl.conf

Der Eintrag in der [sysctl.conf] setzt automatisch den Wert [/proc/sys/net/ipv4/ip_forward] auf [1].
Den Aufruf [echo 1 > /proc/sys/net/ipv4/ip_forward] wie in einigen Dokumentationen steht kann man also weg lassen.

13.
Den Punkt iptables muss man nur bei einer tun/routing OpenVPN Verbindung beachten.
Den Punkt kann man daher überspringen - weiter bei Punkt 14.

14.
ufw (Uncomplicated Firewall) - Port 443/TCP in der Firewall öffnen:

ufw allow 443/tcp

Optionale Parameter:
ufw allow 22/tcp oder ufw allow ssh # sofern man SSH-installiert hat, dies erlauben.
ufw allow 1194/tcp # sofern man den Standardport gelassen hat.
ufw default deny # Standard wieder herstellen (alles verbieten).
ufw disable # Firewall deaktivieren (auch nach reboot).
ufw enable # Firewall aktivieren (auch nach reboot).
ufw status # Zeigt den derzeitigen Status der Firewall an.

15.
Jetzt kann man den OpenVPN-Server starten:

service openvpn start

Hinweis: Der Start des OpenVPN-Servers klappt nur, wenn man alle Shell-Scripte angelegt und diese auch ausführbar (chmod +x ...) gekennzeichnet hat.
Hat man in der [server.conf] die verweise auf die Protokollierungs-Shell-Scripte mit vorbereitet, so muss man diese Scripte also erst noch anlegen (siehe Punkte 17-20 - Verbindungen Protokollieren).

Optionale Parameter:
service openvpn restart # Startet OpenVPN neu.
service openvpn reload # Lädt eine neue Konfiguration ein.
service openvpn stop # Beendet OpenVPN.

16.
Optional: Testen ob die Netzwerkbrücke bereit ist (Hilfe zur Fehlersuche):

ifconfig tap0

Wenn hier kein Fehler kommt ist die Netzwerkbrücke bereit.

openvpn /etc/openvpn/server.conf

Startet man openvpn in dem man die Konfiguration als Parameter übergibt, so werden in der Consolenausgabe eventuell auftretende Fehler direkt angezeigt (OpenVPN muss zuvor ggf. über stop beendet werden).

tail -F /var/log/syslog

Standardmäßig Protokolliert OpenVPN die Ausgaben im [syslog].

Verbindungen Protokollieren:

OpenVPN bringt von Haus aus zahlreiche Log-Möglichkeiten mit.
Standardmäßig Protokolliert OpenVPN alles im Systemlog unter [/var/log/syslog]. Hier jedoch vermischen sich die OpenVPN-Meldungen mit verschiedensten anderweitigen Systemmeldungen. Eine Suche nach brauchbaren Infos kann hier aufwendig werden.
Wer mag kann dieses Verhalten in der [server.conf]-Konfigurationsdatei anpassen, hier kann man OpenVPN dazu veranlassen ein extra Logfile anzulegen. Ich habe hier jedoch nichts geändert, da auch diese Logdatei sehr viele Infos enthält - und die meisten Einträge interessieren uns auch nicht mehr wenn alles läuft.

Denn dann ist nur noch wichtig: [wer] sich [wann] über [welche IP-Adresse] verbunden hat.
Weiterhin ist ggf. noch von Interesse [wie lange die Verbindung bestand] und viel [Traffic] die entsprechenden User produziert haben.

Die eingebaute Managementfunktion konnte ich trotz verschiedener Tests und Programme nicht zum Laufen bewegen.
Um die Logdatei auszuwerten wäre fremde Software nötig gewesen, so dass ich auf folgende einfache Lösung zurück gegriffen habe.

In der server.conf (siehe Punkt 11) wurde das Protokollieren über die drei Parameter: [script-security 2], [client-connected] und [client-disconnected] vorbereitet.

Hier nun die Parametererklärung:
[script-security 2] benötigt man um Userscripte auszuführen. Standardmäßig ist das script-security Level auf 1 gesetzt, was nur Netzwerkgrundfunktionen wie z. B. das Hinzufügen von Routen erlaubt. Erst ab Level 2 kann man eigene Scripte ausführen.
[client-connected] bedeutet, dass OpenVPN, nach dem sich ein Client verbunden hat, die dahinter angegebene Scriptdatei ausführt.
[client-disconnected] bedeutet, dass OpenVPN nach dem disconnect eines Clients die dahinter angegebene Scriptdatei ausführt.
Diese drei Parameter fügt man nur in der [server.conf]-Konfigurationsdatei hinzu, die [client.conf]-Konfigurationsdatei bleibt unverändert.

17.
Verzeichnis für die Logging-Scripte und für das User-Log erstellen:

mkdir /my

18.
Nun noch das Login-Script erstellen:

nano /my/logon.sh

# Hier folgendes einfügen:
#!/bin/sh
echo logon , $common_name, $(date "+%Y-%m-%d, %H:%M"), $trusted_ip >> /my/userlog.csv
exit 0

19.
Nun noch das Abmelde-Script erstellen:

nano /my/logoff.sh

# Hier folgendes einfügen:
#!/bin/sh
echo logoff, $common_name, $(date "+%Y-%m-%d, %H:%M"), $trusted_ip, $time_duration, $bytes_sent, $bytes_received >> /my/userlog.csv
exit 0

Parametererklärungen:
[%common_name%] ist der Zertifikats-Common-Name (CN) z. B. [client02] mit der sich der OpenVPN-Client-User verbindet (OpenVPN-Umgebungsvariable). Somit ist eine eindeutige Userzuordnung möglich.
[$(date "+%Y-%m-%d, %H:%M")] ermittelt das Datum und die Uhrzeit für die Protokollierung (System-Umgebungsvariablen).
[%trusted_ip%] ist die öffentliche remote-IP-Adresse, über die der Client mit dem Internet verbunden ist (OpenVPN-Umgebungsvariable).
[%time_duration%] gibt die Zeitdauer in Sekunden an, wie lange der Client verbunden war (OpenVPN-Umgebungsvariable).
[%bytes_sent%] ist die Datenmenge in Bytes, die der Client aus dem Servernetzwerk geladen hat. Beschreibt also die Daten die der VPN-Server zum Client gesendet hat. Ein zu hoher Wert und eine sonst völlig unbekannte IP-Adresse könnte auf einen Missbrauch durch einen dritten hindeuten. Also auf jemanden, der größere Datenmengen herunter lädt (OpenVPN-Umgebungsvariable).
[%bytes_received%] ist die Datenmenge in Bytes die der Client in das Servernetzwerk gesendet hat (OpenVPN-Umgebungsvariable), also die Daten die der VPN-Server empfangen hat.
Der [echo] Befehl speichert den Inhalt der oben erklärten OpenVPN- und System-Umgebungsvariablen dann in der [userlog.csv]-Datei.
Ich empfehle, zwischen den Werten Kommas als Trennzeichen zu verwenden,
denn dann kann man diese Datei dann z. B. leicht in Microsoft Excel oder LibreOffice Calc einlesen und dort zur Analyse weiter verarbeiten.

20.
Als nächstes muss man die Scripte noch ausführbar machen:

chmod +x /my/logon.sh
chmod +x /my/logoff.sh

Wenn man in der [server.conf] die Einträge [user nobody] und [group nobody] aktiviert hat (also die verstärkte Sicherheit eingestellt hat), so muss man dieser noch das schreiben des Logfiles ermöglichen.
Tut man dies nicht, so wird keine [userlog.csv]-Datei angelegt und im Logfile erscheint der Fehler [... cannot create /my/userlog.csv: Permission denied].

Um den Fehler zu umgehen erstellen einfach wir eine neue leere Datei und weisen dieser die entsprechenden Berechtigungen zu:

touch /my/userlog.csv
chmod 666 /my/userlog.csv

Das Logging sollte jetzt problemlos klappen.

Hier ein userlog.csv Beispiel:

logon , client02, 2015-09-11, 10:23, 80.187.103.184
logoff, client02, 2015-09-11, 10:23, 80.187.103.184, 24, 19491, 18463
logon , client02, 2015-09-11, 10:23, 80.187.103.184
logoff, client02, 2015-09-11, 10:23, 80.187.103.184, 11, 16563, 15477
logon , client02, 2015-09-11, 10:23, 80.187.103.184
logoff, client02, 2015-09-11, 10:29, 80.187.103.184, 325, 34841, 30890

In dem Beispiel wurden testweise nur ein paar pings übergeben.

Die [userlog.csv]-Datei kann man beliebig bereitstellen z. B. über Apache, über eine Netzwerkfreigabe, per E-Mail usw... hier sind dann eigene Ideen gefragt.
Solltet Ihr eine gute Lösung haben würde ich mich über Anregungen freuen und diese hier ggf. mit einbringen.

Portweiterleitung im Router konfigurieren:

Wichtig:
Damit der Server auch über das Internet erreichbar ist, muss man im [Router-im-Server-Netzwerk] für das Protokoll [TCP] und den Port [443],
eine Portweiterleitung auf die interne [IP-Adresse des OpenVPN Servers] einrichten.

Anschließend sollte man mittels einem öffentlichen Portscanner (z. B. heise.de/security/dienste/portscan/) prüfen ob dieser erreichbar ist.

Client-Konfiguration:

21.
Als nächstes kopiert man die Beispielkonfigurationsdatei, um Änderungen durch Paketupdates zu verhindern:

cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/easy-rsa/

Hinweis: Man sollte die [client.conf]-Datei nicht in das [/etc/openvpn/]-Verzeichnis kopieren, da sonst der Server versucht parallel zum Serverbetrieb eine Clientverbindung herzustellen. Ins [keys]-Verzeichnis sollte man die Datei am besten auch nicht kopieren, da dieses Verzeichnis durch ein [./clean-all] ebenso gelöscht wird.

22.
Dann passt man die Client-Konfiguration wie folgt an:

nano /etc/openvpn/easy-rsa/client.conf

# Am Start folgende Einträge hinzufügen:

# Die HMAC-Authentication von 160-Bit auf 512-Bit erhöhen:
auth SHA512
# Die Angabe muss mit der Angabe in der [server.conf] übereinstimmen.

route-method exe
# Verhindert auf Windows Clients den Fehler [Route addition via IPAPI failed [adaptive]].

auth-nocache
# Sorgt dafür das, dass Passwort nicht im RAM gespeichert wird (dies trifft nur zu, sofern man ein Zertifikat mit Passwort verwendet).

# Diese optionalen Eintrage sollte man nur aktivieren, wenn man weiß was sie bewirken:

;route-nopull # Das pushen der Routen vom Server verhindern.
;redirect-gateway bypass-dhcp # Gateway-Einstellungen.

# ... und die vorhandenen Einträge wie folgt ändern:

dev tap
# tun = routing
# tap = bridging
# Wichtig: Dieses Tutorial geht nur auf bridging ein also auf [tap] ändern!
# Die Angabe muss mit der Angabe in der [server.conf] zusammen passen.

proto tcp
# Da HTTPS (Port 443) standardmäßig über TCP transportiert wird passt man dies ebenso an.
# Die Angabe muss mit der Angabe in der [server.conf] übereinstimmen.

remote statische-IP-Adresse_oder_eure_DynDNS-Kennung.noip.com 443
# Parametererklärung:
# Hier gibt man an wie man den Server erreicht:
# Man gibt hier also entweder eine [feste/statische IP-Adresse] an,
# oder [die Kennung des DynDNS-Dienstes] an,
# über welche der OpenVPN-Server über das Internet erreichbar ist.
# [443] am Ende ist die Portangabe,
# diese muss mit der in der Angabe in der [server.conf] übereinstimmen (siehe Punkt 11).

# Pfade auf die jeweiligen Zertifikate und Schlüssel anpassen:
ca ca.crt
cert client02.crt
key client02.key
# Pfadangaben muss man in der Regel nicht angeben,
# wenn man die notwendigen Dateien direkt
# im [config]-Ordner des Clients abgelegt hat.
# Wichtig:
# Ist aber, dass die Verweise auf die entsprechenden
# Client-Zertifikate und Client-Schlüsseldateien passen.
#
# Client-Dateien muss man daher entsprechend umbenennen,
# oder hier die entsprechenden Namen angeben (beides ist möglich).
#
# Entweder nennt man also die Datei [client02.crt] in [client.crt] um
# und die Datei [client02.key] in [client.key] um.
#
# Oder man ergänzt hier die Einträge entsprechend.
# z. B. [cert client02.crt] und [key client02.key]

# Des Weiteren aktiviert man den tls-auth Eintrag (siehe Punkt 8):
tls-auth ta.key 1
# Hier also das führende [;] entfernen.
# Pfadangaben sind hier ebenso nicht notwendig.

# Weiterhin sollte man noch die Verschlüsselung erhöhen:
# Mittels [openvpn --show-ciphers] kann man sich alle Verschlüsselungsmöglichkeiten anzeigen lassen.
# Empfehlen würde ich folgende Einstellung:
cipher AES-256-CBC
# Die Angabe muss mit der Angabe in der [server.conf] übereinstimmen.

Wichtig: Sollte man Änderungen an den Server- bzw. Client-Konfigurationsdateien vornehmen,
so muss man immer darauf achten, dass diese Änderungen manchmal beiden Seiten betreffen.

Die Vorbereitungen sind soweit abgeschlossen.

Windows-Client einrichten:

Ich gehe hier hauptsächlich nur auf Windows-Clients ein. Andere Clients kann man hier aber leicht ableiten.

23.
Hier die entsprechenden Client Software (Installer...) herunterladen und die Software ganz normal installieren.

24.
Dateien für den Client:
Man kopiert die folgenden Dateien unter Verwendung einer sicheren Methode auf den Client:

/etc/openvpn/ca.crt
/etc/openvpn/easy-rsa/keys/client02.crt
/etc/openvpn/easy-rsa/keys/client02.key
/etc/openvpn/ta.key
/etc/openvpn/easy-rsa/client.conf

Diese fünf Dateien kopiert man auf dem Client in das Verzeichnis [C:\Programme\OpenVPN\config] oder [C:\Program Files\OpenVPN\config] (der Pfad kann je nach Umgebung 32/64-Bit etwas abweichen).

25.
Wichtig:
Die Datei [client.conf] muss man noch in [client.ovpn] umbenennen.

26.
Danach ggf. nochmals den Client-PC neu starten und die [OpenVPN GUI]-Verknüpfung auf dem Client-Desktop starten.
Wichtig: Damit die die Software die Routen korrekt setzen kann, ist es notwendig dass die [OpenVPN GUI] Software als Administrator gestartet wird.
Über das danach unten rechts in der Taskleiste abgelegte Tray-Icon kann man nun mittels klick über [rechte Maustaste], dann auf [Verbinden] klicken - eine Verbindung herstellen.

27.
Optionale Schnelltests wenn die Verbindung steht:
vom Client aus:

ping 10.8.0.1

... den Server anpingen geht nur, wenn der VPN-Client mit Adminrechten gestartet wurde.

ping 192.168.0.13

Eine andere IP-Adresse im Server-Netzwerk anpingen sollte im tap/bridging Modus ohne Probleme möglich sein wenn der VPN-Client mit Adminrechten gestartet wurde, denn nur dann werden die Routen auf dem Client korrekt hinzugefügt.

ping hostname -4

Ein Ping auf einen Hostamen im Server-Netzwerk sollte problemlos möglich sein, da Bridging alle Netzmerkmale weiterleitet. Auch vom Server aus sollten alle Client-Netz-Endgeräte erreichbar sein (falls nicht winbind installieren).
Beachten sollte man aber:
Die Angabe [-4] sorgt dafür das nur IPv4-Anfragen abgeschickt werden.
IPv6-Routing [-6] ist auf dem Server in diesem Tutorial nicht aktiviert (schlägt daher fehl) - man kann das Setup aber entsprechend erweitern.

vom Server aus:

ping 10.8.0.6

... den Client anpingen.
Wenn dies nicht geht auf dem Client die Firewall und Virenscanner prüfen/anpassen.

Die Windows Client-Konfiguration ist hiermit abgeschlossen.
Wenn jetzt alles läuft, wäre es ein guter Zeitpunkt die Sicherung des Servers zu konfigurieren.

Android-Client einrichten:

Google Android Geräte (egal ob Smartphone oder Tablet) wie auch das Apple iPhone (iOS) unterstützten derzeit keine mit tap/bridge Netze.
Das tap device auf Systemebene bildet eine komplette virtuelle Netzwerkkarte ab über die dann eine Netzwerkbrücke zur normalen Netzwerkkarte gelegt wird.
Diese Funktionalität wird von Android und iPhone Geräten derzeit nicht zur Verfügung gestellt.

Wenn sie ein Android oder iPhones einbinden möchten verwenden sie bitte folgendes tun/routing Tutorial.

Zertifikate sperren:

28.
Verlässt ein Mitarbeiter die Firma oder sind anderweitig Zertifikate in Verdacht geraten, dass sie kompromittiert wurden oder man hat zu einem Zertifikat das dazugehörige Kennwort vergessen, so sollte man diese sperren.

Hierzu wechselt man auf dem Server in das Verzeichnis [/etc/openvpn/easy-rsa/] und lädt dort zuerst mittels [souce vars] die Umgebungsvariablen.

cd /etc/openvpn/easy-rsa/
source vars

29.
Danach sperrt man das Client-Zertifikat durch den Aufruf:

./revoke-full client02

Parametererklärung:
[client02] ist der [Common Name] (CN) (siehe Punkt 9) des Zertifikats welches gesperrt werden soll - den Namen muss man entsprechend anpassen.

Die Ausgabe [error 23 at 0 depth lookup:certificate revoked] am Ende ist normal und kein Fehler. Wer sich das Script anschaut sieht, dass am Ende eine Prüfung erfolgt, ob das Zertifikat auch erfolgreich gesperrt wurde.
Das [./revoke-full]-Script hat nun eine neue [crl.pem]-Datei (Certificate Revocation List) erstellt. Hier werden später alle gesperrten Zertifikate hinzugefügt.
Diese [crl.pem]-Datei wird jetzt bei jeder neuen Verbindung und bei der Erneuerung der Zertifikate im laufenden Betrieb (defaultmäßig jede Stunde) neu eingelesen. Daher kann man diese Datei auch im laufenden Betrieb erneuern.

Wird ein Zertifikat revoked, so kann man den [Common Name] (CN) des Users wieder verwenden. Ich würde diese erneute Nutzung jedoch nicht empfehlen, da dies leicht Verwirrung stiften kann. Besser finde ich die Lösung die Nutzer einfach weiter durchzunummerieren. Hier kann man natürlich selbst entscheiden, wie man es handhabt.

30.
Damit OpenVPN jetzt auch die gesperrten Zertifikate der [crl.pem]-Datei überprüft, muss man in der [server.conf]
den Eintrag [crl-verify /etc/openvpn/easy-rsa/keys/crl.pem] hinzu fügen.

nano /etc/openvpn/server.conf

Sofern man den Eintrag (siehe Punkt 11) schon vorbereitet hat, so braucht man diesen jetzt nur zu aktivieren.
Wichtig: Wenn dieser Eintrag nicht aktiviert wird, bleiben die gesperrten (revoke) Zertifikate weiterhin gültig, obwohl sie gesperrt wurden!
Diesen Eintrag daher unbedingt nach dem Sperren eines Zertifikates aktivieren und ab da immer aktiv lassen.
Wenn dann der [crl-verify]-Parameter aktiv ist prüft OpenVPN jede Stunde und bei jeder Einwahl erneut, ob neue gesperrte Zertifikate vorhanden sind.

31.
Wichtig: Bereits verbundene Clients werden nicht automatisch nach Ablauf dieser Stunde getrennt.
Man muss dem Service diese neuen Einstellungen also bekannt machen:

service openvpn reload

Das Zertifikat ist jetzt ordnungsgemäß gesperrt und wer will kann jetzt hier aufhören.

32.
Welche Zertifikate gesperrt wurden kann man sich auch durch folgenden Befehl anzeigen lassen:

openssl crl -in /etc/openvpn/easy-rsa/keys/crl.pem -noout -text

Man erhält dann eine Ausgabe, die unter anderem die [Serial Number:] der Revoked Zertifikate enthält.
Daher nochmals mein Tipp die Client-Zertifikate entsprechend durchzunummerieren, denn dann behält man am leichtesten den Überblick.

verschiedene Tipps - optional:

Konfigurationsdateien unter Windows editieren:
Wenn man unter Windows Konfigurationsdateien von OpenVPN bearbeiten möchte, benötigt man einen Editor der mit den Linux-Zeilenumbrüchen klar kommt. Windows Notepad kann man hier nicht verwenden.
Hier empfiehlt es sich, den guten Editor Notepad++ zu verwenden (den Auto-Updater kann man bei der Installation abwählen, denn den braucht man nicht).

Konfigurationsdateien zusammenfassen:
Die verschiedenen einzelnen Dateien kann man zu einer Datei zusammenfassen.
Hierzu öffnet man die [client.conf]-Datei mit einem Editor und fügt am Ende in HTML/XML-Syntax die Zertifikate wie folgt ein:

client
...
<ca>
Hier den Inhalt von [ca.crt] einfügen.
</ca>
<cert>
Hier den Inhalt von [client.crt] einfügen.
</cert>
<key>
Hier den Inhalt von [client.key] einfügen.
</key>
# Hinweis 1: Der ta.key ließ sich bei mir nicht mit einbinden.
# Hinweis 2: Derzeit unterstützt der Android Client diese Funktionalität nicht.

Automatischer Verbindungsaufbau:
Soll die Verbindung automatisch hergestellt werden, so kann man den [OpenVPN Service]-Dienst auf [Automatisch] einstellen oder über ein Batchscript mittels [net start] den Dienst z. B. zu geplanten Zeiten starten. Ein automatischer Start klappt nur, wenn kein Passwort abgefragt wird. An diesen Arbeitsplätzen sollte man also ein Zertifikat ohne Passwortabfrage vorsehen (siehe Punkt 9).
Soll OpenVPN immer automatisch starten, braucht man nicht mehr das [OpenVPN GUI]-Tray-Programm vorher zu laden. Der OpenVPN Service-Dienst schaut sobald er gestartet wird selbständig in das Verzeichnis [C:\Programme\OpenVPN\config] und verarbeitet die dort entsprechend abgelegten [*.ovpn]-Konfigurationsdateien.
Der [OpenVPN Service]-Dienst lässt sich auch über die Eingabeaufforderung und so z. B. aus einer Batchdatei heraus starten.
[net start "openvpn service"] startet den Dienst.
[net stop "openvpn service"] beendet den Dienst wieder.

Dienststart unter Windows ohne Adminirechte:
Mittels [runas /user:administrator "net start \"openvpn service\""] in einer Eingabeaufforderung kann man auch als Standarduser den Dienst starten, es wird hierbei jedoch das Administratorpasswort abgefragt. Will man dies nicht preisgeben so kann man dies z. B. über ein Autoit-Script bewerkstelligen. Fügt dazu einfach [runas ("administrator","","P@s$w0rd",0,'net start "openvpn service"')] in eine neue [vpn-start.au3]-Scriptdatei ein, beachtet dabei die verschiedenen Hochkommas und Anführungszeichen. Diese müssen sich unterscheiden damit der [net start]-Befehl korrekt ausgeführt wird.
Natürlich muss man noch das [Administrator] und das [P@s$w0rd] entsprechend dem lokalen Administrator anpassen.
Statt [net start] kann man natürlich auch [net stop] verwenden um den Dienst wieder zu beenden.
Das Autoit-Script kompiliert man jetzt als [vpn-start.exe], so ist das Administrator Passwort für den normalen User nicht mehr sichtbar.
In neuen Windows Versionen muss man ggf. noch die Benutzerkontensteuerung/User Account Control (UAC) anpassen.

Das Routing auf Windowsebene aktivieren (falls nötig):

[HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Tcpip \Parameters]
In der Windows Registry ändert man den Wert [IPEnableRouter] von [0] auf [1].

Das System routet ab sofort IP-Pakete an alle verbundenen Netzwerke.

Erzwingen von bestimmten/neuen TLS-Verschlüsselungen:
Alle verfügbaren Verschlüsselungsvarianten zeigt der Befehl [openvpn --show-tls] an (der Befehl ist in der Regel sowohl auf dem Client als auch auf dem Server möglich).
Die stärksten Verschlüsselungsalgorithmen stehen hierbei in der Regel immer oben/am Anfang.
Mittels [tls-cipher ...:...:...] kann man dann einzelne bestimmte Verschlüsselung erzwingen. Man kann dabei mehrer Varianten angegeben, diese werden jeweils durch einen [:] getrennt. Die Zeile darf maximal nur 256 Zeichen lang sein. Es macht hier also keinen Sinn alle Varianten an zu geben. Um die Sicherheit zu erhöhen sollte man möglichst nur einige wenige aktuelle Standards verwenden (diese müssen sowohl auf Client als auch auf dem Server verfügbar sein).
Bei meinen zahlreichen Test z. B. [tls-cipher DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-CAMELLIA256-SHA:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-AES128-SHA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA] bzw. [tls-cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256] klappte nach Aktivierung der [tls-chipher ...] keine Verbindung mehr.
Da derzeit viele VPN-Clients nur den Standard TLSv1.0 unterstützen empfehle ich derzeit darauf zu verzichten.
Lässt man die Angabe [tls-cipher ...] weg, so handelt OpenVPN selbstständig die höchste verfügbare Verschlüsselung aus.

Auch das festsetzen auf eine neue TLSv1.2 cipher-suite mit dem Parameter [tls-version-min 1.2] klappte derzeit nicht.

Zertifikate/Schlüsseldateien extra absichern:
Da man die Client-Zertifikate ausschließlich auf dem Client benötigt, sollte man sie auf dem Server löschen.
Dies erhöht die Sicherheit da Angreifer keine Zertifikate stehlen können.

Des Weiteren sollte man den [ca.key] insbesondere schützen, da ein Angreifer mit diesem Schlüssel beliebige eigene Schlüssel signieren und darüber ungehinderten Zugriff erlangen könnte. Der Server benötigt den [ca.key] nicht, denn dieser wird nur für die Schlüsselerzeugung benötigt. Eine Möglichkeit der Absicherung ist z. B. die Generierung der Zertifikate/Schlüssel auf einem extra offline PC.

Nicht den Überblick verlieren:

33.
Hier gibt es dann noch ein paar Infos, um Übersicht über die Zertifikate zu behalten.

In der [index.txt]-Datei sind alle Zertifikate übersichtlich aufgelistet:
Wichtig: Man sollte an dieser Datei keine Änderungen vornehmen!

more /etc/openvpn/easy-rsa/keys/index.txt

Wichtig:
Diese [index.txt]-Datei ist tabellenartig aufgebaut,
als Trennzeichen wird der Tabulator verwendet (dieser ist nicht sichtbar!),
daher stehen nicht alle Werte 1:1 untereinander.

Unter anderem kann man hier die Gültigkeit, das erfolgreiche revoke prüfen oder die dazugehörige [.pem]-Datei ausfindig machen.

Hier ein Beispiel:

V    250811100248Z        01    unknown    /C=DE/ST=TH/L=Kahla/O=Computertechnik/OU=VPN/CN=server/name=Schroeder/emailAddress=mail@ctaas.de
R    250811102839Z    150910162115Z    02    unknown    /C=DE/ST=TH/L=Kahla/O=Computertechnik/OU=VPN/CN=client02/name=Schroeder/emailAddress=mail@ctaas.de
V    250811102946Z        03    unknown    /C=DE/ST=TH/L=Kahla/O=Computertechnik/OU=VPN/CN=client03/name=Schroeder/emailAddress=mail@ctaas.de

Parametererklärung (zur besseren Übersicht wurden die Werte farbig hervorgehoben):
Die 1. Spalte kann folgende Werte annehmen:
V = Valid, bedeutet ein gültiges und aktives Client-Zertifikat.
R = Revoked, bedeutet ein ungültiges und gesperrtes Zertifikat.
E = Expired, ist ein abgelaufenes Zertifikat (nach 10 Jahren/Standardmäßig).

Die 2. Spalte zeigt die Gültigkeitsdauer des Zertifikates an:
Zum Beispiel bedeutet [250811102839Z], gültig bis 11.08.2025 um 10:28:39 Uhr.
Die Stunden können sich je nach Zeitzone entsprechende verschieben, da die Datumsangaben und Zeiten immer im UTC-Format abgelegt werden.
Für die Abweichung ist je nach geografischer Lage und Sommer oder Winterzeit die koordinierte Weltzeit - auch UTC (Universal Time Coordinated) - verantwortlich. Bei mir waren es heute z. B. 2 Stunden zu wenig.

Die 3. Spalte zeigt das Sperrdatum und die Uhrzeit an:
Zum Beispiel bedeutet [150910162115Z], gesperrt am 10.09.2015 um 16:21:15 Uhr. Auch hier verschiebt sich die Zeitangabe nach UTC.
Wurde ein Zertifikat gesperrt (revoked), dann steht in der 3. Spalte das Sperrdatum und die Uhrzeit nach dem gleichen Schema, die Gültigkeit nach der 2. Spalte ist hiermit natürlich aufgehoben.
Wichtig: Das Trennzeichen zwischen den Spalten ist ein Tabulator (dieser ist nicht sichtbar!). Da bei gültigen Zertifikaten in der 3. Spalte noch nichts hinterlegt ist, sieht es so aus, als wenn die [.pem]-Nummer in der 3. Spalte steht, es ist aber die 4. Spalte!

Die 4. Spalte zeigt die zum Zertifikat gehörige [.pem]-Nummer an:
Die [.pem]- Nummern habe ich mal orange markiert.

Die 5. Spalte zeigt die gesetzten Umgebungsvariablen an:
Insbesondere ist hier der [Common Name] (CN) interessant.

Daher der Hinweis:
Wer sich die Datei genau ansieht erkennt also, dass zu dem [CN=server]-Zertifikat die [01.pem]-Datei gehört (siehe Zeile 1). Daher war oben mein Rat (siehe Punkt 9), die Nummerierung der Clients erst bei [client02] zu beginnen und [client01] niemals zu verwenden. Dann stimmen die Client-Zertifikats-Dateien z. B. [client02.crt], [client02.key], [client02.csr], exakt mit der [02.pem]-Nummer überein.
Hat man dagegen bei [client01] angefangen ist die [02.pem]-Datei immer eine Nummer höher als die Clientdatei, was beim späteren Bereinigen schnell Verwirrung stiften kann.

Wichtig: Änderungen in dieser Datei bewirken keine längere Zertifikatsgültigkeit, auch kann man hier die Sperrungen (revoked) nicht rückgängig machen.

Optional: Wenn man die zum passenden Zertifikat gültige [.pem]-Datei gefunden hat, kann man diese und die Zertifikatsdateien jetzt in einem anderen Ordner sichern. Das erhöht dann die Übersicht über die noch gültigen Zertifikate.
Hinweis: Das Verschieben der (revoked) Dateien hat keine Auswirkungen auf OpenVPN, da in der [crl.pem]-Datei die Zertifikatssperrung bereits vermerkt ist. Von einem Löschen würde ich trotzdem eher abraten.

Zertifikatsübersicht - Empfehlung:

Da die Zertifikate sehr ähnliche Namen haben, sollte man sich eine Übersicht erstellen, in der folgendes aufgelistet wird:
der [Zertifikatsname/Nr], ob ein Zertifikat noch [gültig] ist, wer es [nutzt] und ggf. das [Passwort].

Weiß man nicht mehr wann man ein Zertifikat erstellt hat und wann es abläuft,
so schaut man sich jeweilige [client02.crt]-Datei bzw. die [index.txt] an.
Man kann sich diese Dateien mit einem beliebigen Editor (unter Windows z. B. mit Notepad++) anzeigen lassen.
Die Tage weichen übrigens meist ab, da immer exakt 30 Tage addiert werden, egal wie lang der Monat ist.

Wichtig: Man sollte hier aber keine Änderungen vornehmen, diese können das Zertifikat ungültig werden lassen.

Abschließende Hinweise:

IP-Adressen, E-Mailadressen, Namen u. ä. wurden für die Dokumentation geändert, hacken ist also zwecklos.
Die Nutzung der Anleitung erfolgt auf eigene Gefahr, für jegliche Schäden wird keine Garantie/Haftung übernommen!
Die Dokumentation entstand aus verschiedenen Tests, sowie produktiven Installationen (unter Ubuntu 14.04 & 16.04) und stellt eine Zusammenfassung wichtiger und empfohlener Schritte dar.
Die hier vorgestellte Dokumentation läuft dabei als VM unter VirtualBox bei uns stabil und zuverlässig.
OpenVPN benötigt dabei egal ob routing oder bridging verwendet wird immer nur eine Netzwerkkarte.
Bevor sie eventuell Fragen stellen bitte ich sie die Dokumentation komplett zu lesen.
Hinweise auf Fehler, Anregungen, Danksagungen oder ähnliches sind immer willkommen.

Design:
© 2018 ctaas.de, Arno Schröder, Kahla (Impressum)