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.

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

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].
Muster Zertifikats├╝bersicht:

Zertifikats-Nr.  | G├╝ltig?: | Erstellt am: | G├╝ltig bis: | Nutzer/Abteilung: | Passwort:
----------------------------------------------------------------------------------------
client02         | Ja       | 2015-09-08   | 2025-09-06  | Test02/Tutorial   | GeH3im%
client03         | Nein     | 2015-09-08   | 2025-09-06  | Test03/Howto      | -kein-
...

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)