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.

 _______                   ___ ___ ______ _______      _______
|.  _   |_____ _____ _____|:  |:  |:  __ \ :  |: |    |:'   __| ____ ____ __ __ _____ ____
|: |_| :|: _  |: -__|:    |:  |:  |:   __/   .   |    |__    '|' -__|:  _|: |: |: -__|:  _|
|_______|:  __|_____|__|__|\_____/|___|  |__|____|    |_______|_____|__|  \___/|_____|__|
        |__|
              2017-03-30 © ctaas.de, Arno Schröder (Impressum)
           tun/NAT : routing : Layer 3 : Protokollierung
OpenVPN
einfach & sicher installieren:
tun/NAT, routing, Layer 3, Protokollierung
2017-03-30 © ctaas.de, A. Schröder (Impressum)


Diese Anleitung (Howto) erklärt wie man einen OpenVPN Server mit tun/NAT, Layer 3, routing 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? Das tap/NAT, Layer 2, bridging Tutorial gibt 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

  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. Eine ausführliche Parameterbeschreibung findet man hier.
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]!

# Zugriffe Protokollieren:
script-security 2 # Das ausführen von Scripten zulassen - fürs einfache Logging 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...).

# ... 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 tun
# tun = routing
# tap = bridging
# Wichtig: Dieses Tutorial geht nur auf routing ein also auf [tun] lassen!

# 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

# Um auch andere PCs im Server Netzwerk (PCs im Subnetz des Server) zu erreichen, muss der folgende Routing-Eintrag aktiviert und angepasst werden:
push "route 192.168.0.0 255.255.255.0"
# Hier muss man den Netzbereich des Servers (Subnetz und Subnetmaske) eingeben.

# 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.

# Optional: DNS-Serverübergabe an den Client:
# Die FQDN-Namensauflösung funktioniert in grouteten Netzen nur,
# wenn ein extra installierter DNS-Server die FQDN-Anfragen beantworten kann.
# Ein gewöhnlicher NetBIOS-Broadcast reicht hierzu nicht aus.
# Hier kann man also auch nicht den Router bzw. das Standard-Gateway angeben!
# Beachtet auch das sich der Client wenn er verbunden ist im 10.8.0.0/24er Subnetz befindet.
;push "dhcp-option DNS 192.168.0.1" # z. B. die IP-Adresse eines DNS-Servers auf der Serverseite.
;push "dhcp-option DNS 8.8.8.8" # will man nur Webzugriffe weiterleiten, so kann man z. B. den Google DNS-Server angeben.
# Hier bei Bedarf das auskommentierende [;] Semikolon entfernen.
# Beachtet: Die FQDN-Anfragen sind keine Hostnamen anfragen, sondern
# voll qualifizierte Domain-Namen Anfragen (Full Qualified Domain Name)
# wie z. B. client1.meinedomain.local oder www.ctaas.de.
# Die Auflösung von einem Hostname ist darüber nicht möglich.

# Einen WINS-Server anzugeben macht übrigens keinen Sinn,
# da in einem gerouteten Netzwerk die WINS-broadcast-Anfragen nicht geroutet/weitergeleitet werden.
;push "dhcp-option WINS 192.168.0.1" # WINS-Server (der Eintrag ist nicht vorhanden).

# 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

# Die Kompression unter ...
# Enable compression on the VPN link.
# ... sollte man so ergänzen:
comp-lzo adaptive
# Dies bewirkt, das nur gut komprimierbare Daten komprimiert werden. Nicht mehr komprimierbare Daten werden 1:1 weitergegeben.
# Bei mir hat dies die Datenrate erhöht, obwohl adaptive eigentlich Standardmäßig aktiv sein sollte.
# Möglich sind sonst noch die Parameter 'yes' = immer alles komprimieren, oder 'no' = die Komprimierung dauerhaft deaktivieren.

# 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 128K (131072 Bytes),
# oder optional auf 256K (262144 Bytes),
# um die Geschwindigkeit zu verbessern.
sndbuf 131072
rcvbuf 131072
push "sndbuf 131072" # send to client
push "rcvbuf 131072" # send to client

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

Der Server könnte jetzt schon gestartet werden. Es fehlt allerdings noch...
- das IPv4 Routing,
- die NAT Einstellungen 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.
Die iptable Einstellungen anpassen - Pakete an das Server-Gateway weiterleiten/NAT (Network Address Translation).
Die Weiterleitung an das hinter dem Server-Netzwerk (Server-Subnetz) liegende Netzwerk realisieren.
Pakete die aus dem VPN-Subnetz/Netzwerk 10.8.0.0 kommen, werden ans interne Servernetz an eth0 geroutet.
nano /etc/rc.local

# Hier folgenden Eintrag vor [exit 0] hinzufügen:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Wichtig:
Die Einstellung wird erst nach einem Neustart [reboot] übernommen.
Wenn man keinen Neustart tätigen will, so muss man den Befehl im Terminal nochmals eingeben.

 14.
In der ufw (Uncomplicated Firewall) muss man das forwarding (das weiterleiten der Netzwerkpakete) aktivieren und die benötigten Ports freigeben.
Das forwarding aktivieren:
nano /etc/default/ufw

Hier den vorhandenen Eintrag wie folgt ändern:
...
# Set the default forward policy to ACCEPT, DROP or REJECT. Please note that
# if you change this you will most likely want to adjust your rules
DEFAULT_FORWARD_POLICY="ACCEPT"
...
Hinweis 1: In einigen anderen Anleitungen steht das man noch Regeln in der Datei [/etc/ufw/before.rules] anpassen soll, dies ist nach dieser Anleitung nicht nötig, da die dort einzutragenden iptables Regeln schon unter Punkt 13 definiert wurden (die Lösung ist einfacher).
Hinweis 2: Man sollte hier keine weiteren Einträge vornehmen und den Eintrag direkt editieren.
Beachtet man dies nicht, so kann der Fehler [ERROR: Missing policy for 'forward'] beim starten/beim beenden der ufw auftreten.


Weiterhin muss man den Port 443/TCP (entsprechend der Serverkonfiguration) in der Firewall öffnen und die Firewall aktivieren:
ufw allow 443/tcp
ufw enable

Optionale Parameter:
ufw allow 22/tcp oder ufw allow ssh # sofern man SSH-installiert hat, dies erlauben.
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.

ufw logging low # Protokollierungslevel einstellen [medium], [high], [full]. Vorsicht die Größe der Protokolldatei kann stark ansteigen.
tail -F /var/log/ufw.log # Firewall-Logfile anzeigen.

ufw status numbered # Listet alle Regeln durchnummeriert auf.
ufw delete 1 # Löscht die Firewall-Regel mit der entsprechenden Nummer.

Hinweis:
Sollte man später Probleme haben das hinter dem Server liegende Netzwerk zu erreichen, so kann dies an einer falsch eingerichteten Firewall liegen.

 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.

Wichtig in virtuellen Umgebungen:
Installiert man die hier vorgestellte Lösung unter VirtualBox,
so muss man unter [Einstellungen], [Netzwerk] den [Netzwerkadapter] auf [Netzwerkbrücke] einstellen.
Den [Promiscuous-Modus] sollte man beim routing auf [verweigern (deny)] lassen.
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

 16.
Optional: Testen ob der Tunnel steht (Hilfe zur Fehlersuche):
ifconfig tun0

Wenn hier kein Fehler kommt ist der Tunnel 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] komplett 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:

# Optional hinzufügen und aktivieren:
; redirect-gateway def1 bypass-dhcp
# Bei diesem Client das Standardgateway auf das Servernetzwerk setzen, nur nötig falls man diese Einstellung nicht schon pusht.
# Der komplette Netzwerkverkehr wird dann über das VPN-Netzwerk geleitet.
# Beachtet dabei:
# Hostnamen (Computernamen) Anfragen werden nicht geroutet - diese kann man so nicht auflösen.
# Es kann dann Netzintern nur eine komplette FQDN-Anfrage (www.example.de) beantwortet werden.
# Aller weiterer Traffic (wie normale Internet-Anfragen) wird ebenso über das VPN-Netzwerk geleitet.
# Diese Daten werden dann nur noch so schnell übertragen, wie der VPN-Server die Daten an den Client senden kann.
# Ich nutze diese Option daher i.d.R. nicht und spreche netzinterne Geräte einfach über die IP-Adressen direkt an.

# Analog dazu (Optional) einen weiteren DNS-Server übergeben, sofern dieser nicht schon gepusht wird:
; dhcp-option DNS 192.168.0.1
# Wichtig: Auch mit diesem ist eine Hostnamen Auflösung nicht möglich. Ich persönlich nutze die Option daher nicht.

;route-nopull # Das pushen der Routen vom Server verhindern.
# und die vorhandenen Einträge wie folgt ändern:

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

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.

# Sicherheit verstärken und Feintuning (am besten erst ändern wenn alles läuft):

# In neueren OpenVPN Versionen sollte man folgendes nicht mehr verwenden:
# ns-cert-type server
# kurze Erklärung:
# Diese Sicherheitsfunktion soll sicherstellen, dass sich der Client mit dem richtigen Server verbindet, also man-in-the-middle Attacken verhindern.
# Wichtig: Diese Option 'ns-cert-type-server' ist deprecated (veraltet) und wurde abgelöst.
# Diesen vorhandenen Eintrag sollte man daher deaktivieren.
#
# Stattdessen sollte man diese folgende neue Version verwenden (diese einfach neu hinzufügen):
remote-cert-tls server
# Dieser Eintrag überprüft gemäß RFC3280 TLS Regeln mit Hilfe einer digitalen Signatur
# ebenso die korrekte Verbindung zum Server. Verhindert als ebenso man-in-the-middle Attacken.

# Weiterhin empfehle ich am Client das Log-Level so zu verändern (0-9 ist möglich):
verb 2

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 noch in [client.ovpn] umbenannt werden.

 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 beliebige andere IP-Adresse im Server-Netzwerk anpingen geht nur, wenn man:
- [push "route x.x.x.x ..."] gesetzt hat,
- den VPN-Client mit Adminrechten gestartet hat,
- das Routing, die iptables und die Firewall entsprechend korrekt konfiguriert hat (siehe Punkte 12-14).

ping hostname

Ein Ping auf einen Computernamen/Hostamen im Server-Netzwerk kann nur ausgeführt werden,
wenn dieser in der [Hosts]-Datei auf dem Client entsprechend bekannt gemacht wird.
Der Eintrag [push "dhcp-option DNS x.x.x.x"] ist hierfür nicht relevant,
da dieser nur FQDN-Namen wie z. B. www.google.de auflöst,
aber keine WINS/NetBIOS-Broadcasts Anfragen aussendet und auswertet.
Wichtig: Standard-DSL-Router leiten DNS-Anfragen (FQDN) zur Namensauflösung in der Regel nur an den DNS-Server vom Provider ins Internet weiter (DNS forwarding).
Dieser DNS-Server vom Internet-Provider kennt allerdings das lokale Netzwerk nicht und kann daher die Namen nicht auflösen.

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:


Unter Android lädt man einfach den OpenVPN Connect Client herunter.

Anschließend kopiert man alle für den Client notwendigen Daten in ein beliebiges Verzeichnis auf der SD-Karte des Android-Gerätes.
Wichtig: Die Datei [client.conf] muss noch in [client.ovpn] umbenannt werden.
Wenn man die App gestartet hat, kann man in der App über [Menü] und [Import] das [client.ovpn]-Profil entsprechend einbinden.
Die weitere Bedienung sollte selbsterklärend sein.

Hinweis - Stand 2015-09-25:
Der offizielle OpenVPN Connect Client unerstützt unter Android derzeit nur 2048-Bit siehe [vars]-Datei.
Verwendet man 4096-Bit so kommt beim Importieren des Zertifikates der Fehler [OpenVPN core error: PolarSSL: error parsing config private key] bzw. [PK - Bad input parameters to function].
Will man die Schlüsselstärke nicht herabsetzen, so kann man den Client OpenVPN für Android von Arne Schwabe verwenden - denn mit diesem klappt auch die Verbindung mit 4096-Bit.

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 der [Common Name] (CN) des Users wieder verwendet werden. 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:


 A.
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).

 B.
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.

 C.
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.

 D.
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.

 E.
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.

 F.
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.

 G.
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.

 H.
Optional - Umwandlung in eine PKCS#12-Zertifikatsdatei:
Will man die Client Zertifikate extra absichern, so kann man diese in eine extra Passwort geschützte PCKS#12-Datei (Public Key Cryptography Standard Datei) zusammenfassen.
openssl pkcs12 -export -in client02.crt -inkey client02.key -certfile ca.crt -name client02 -out client02.p12 # Client Zertifikate in eine PKCS#12-Datei konvertieren.

Gleich am Anfang wird mit der Frage [Enter Export Password:] nach einem Passwort für die Zertifikatsverschlüsselung gefragt. Dieses Passwort ist unabhängig von dem Passwort welches beim Verbindungsaufbau abgefragt wird.
Die Dateien [ta.key] und [client.conf] kann man nicht in die PKCS#12-Datei einbinden - diese Dateien muss man dem Client noch extra zur Verfügung stellen.

 I.
Optional - Private-Key ins RSA-Format konvertieren:
Auch bei Apple Geräten (wie z. B. bei einem iPhone/iPad) kann manchmal eine Konvertierung nötig sein, da diese meist einen RSA-Key erwarten und die original Dateien nicht immer akzeptieren.
openssl rsa -in client02.key -des3 -out client02_conv-des3.key # Nur den Private-Key in einen RSA-3DES-Key umwandeln (Apple fix). Ohne [-des3] wird es ein reiner RSA-Key.


 J.
Optional - Rückumwandlung einer PKCS#12-Zertifikatsdatei in die ursprünglichen Bestandteile:
openssl pkcs12 -in client02.p12 -clcerts -nokeys -nodes -out client02.crt # Exportiert die client.crt-Datei.
openssl pkcs12 -in client02.p12 -nocerts -nodes -out client02.key         # Exportiert die client.key-Datei.
openssl pkcs12 -in client02.p12 -cacerts -nokeys -nodes -out ca.crt       # Exportiert die ca.crt-Datei.
man pkcs12 # Komplette Dokumentation anzeigen. [-nodes] = Ausgabedateien nicht verschlüsseln.

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 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)