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.

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)