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.

 _______                   ___ ___ ______ _______      _______
|.  _   |_____ _____ _____|:  |:  |:  __ \ :  |: |    |:'   __| ____ ____ __ __ _____ ____
|: |_| :|: _  |: -__|:    |:  |:  |:   __/   .   |    |__    '|' -__|:  _|: |: |: -__|:  _|
|_______|:  __|_____|__|__|\_____/|___|  |__|____|    |_______|_____|__|  \___/|_____|__|
        |__|
 _______                   ___ ___ ______ _______      _______
|.  _   |_____ _____ _____|:  |:  |:  __ \ :  |: |    |:'   __| ____ ____ __ __ _____ ____
|: |_| :|: _  |: -__|:    |:  |:  |:   __/   .   |    |__    '|' -__|:  _|: |: |: -__|:  _|
|_______|:  __|_____|__|__|\_____/|___|  |__|____|    |_______|_____|__|  \___/|_____|__|
        |__|


 OpenVPN Server unter
 
Ubuntu 20.04 LTS (Focal Fossa) 
 tun/NAT : routing : Layer 3
 2020-02-10 ┬ę ctaas.de, A. Schr├Âder [Impressum]



OpenVPN ist eine kostenlose OpenSource Software die ein virtuelles privates Netzwerk (VPN) implementiert.
Viele verschiedene Konfigurationsvarianten sind m├Âglich, wie Beispielsweise:
Standortvernetzung (Punkt-zu-Punkt), Standort-zu-Site, Roadwarrior, die Absicherung des Netzwerkverkehrs in ├Âffentlichen Netzen uvm.
Hier soll es haupts├Ąchlich darum gehen Clients einen gesicherten Zugang zu einem privaten Netzwerk (zu Hause/in der Firma) bereitzustellen.
Diese Anleitung (Howto) erkl├Ąrt wie man einen OpenVPN Server mit tun/NAT, Layer 3, routing und Protokollierung einfach & sicher unter Ubuntu einrichtet.

Nr. OpenVPN Server Handbuch Inhalt:
1 OpenVPN installieren
3 EasyRSA installieren und konfigurieren: vars
9 Server vorbereiten: server.crt, server.key, ta.key & dh.pem erstellen
15 Client Zertifikat & Schl├╝ssel erstellen
19 Die Server Konfiguration erstellen: server.confserver.conf (gek├╝rzt)
30 Die Client Konfiguration erstellen: client.confclient.conf (gek├╝rzt)
34 Client Skript zum erstellen der .ovpn Datei
36 Verbindungen protokollieren (optional/empfohlen)
43 Protokolle im Netzwerk freigeben mit lighttpd (optional)
46 Zertifikate sperren
51 Portfreigabe/Portweiterleitung/Port-Forwarding Anpassungen im Router
53 optimale MTU herausfinden und abschlie├čende Hinweise


Kurze Farberkl├Ąrung zur Dokumentation:
 grau  kennzeichnet Variablen, Men├╝eintr├Ąge und ├Ąhnliches, sowie Werte die man eher nicht ├Ąndern sollte (gegebene Eintr├Ąge).
 gr├╝n  sind wichtige Eingaben. Eingaben die man der eigenen Umgebung anpassen kann sind  gr├╝n/rot  dargestellt.
 gelb  sind optionale Eingaben. Eingaben die man optional ├Ąndern kann sind  gelb/rot  dargestellt.
 rot!  sind Eintr├Ąge die man l├Âschen muss, zeigt m├Âgliche Fehler bei Fehlkonfigurationen und kennzeichnet sonstige wichtige Hinweise.

Wichtige Links:
openvpn.net, Community Wiki, FAQ/Documentation, OpenVPN 2.4 Manpage, Forum, Download (Client/Server-Setup)

OpenVPN installieren:


  1.
System Voraussetzungen:
Zur Umsetzung dieses Tutorials verwendet man am besten einen Ubuntu Server 20.04 LTS (empfohlen/getestet ok).
Dieses Tutorial geht auch f├╝r alle ├Ąlteren
systemd-Versionen, also auch f├╝r Ubuntu 15.04, 15.10, 16.04, 16.10, 17.04, 17.10, 18.04 LTS (Bionic Beaver/getestet ok), 18.10, 19.04 und 19.10.
Andere Varianten auf Ubuntu/Debian aufbauende Systeme wie Xubuntu, Mate, Gnome, Linux Mint, Debian 10, Raspberry Pi usw. gehen mehr oder weniger auch. Ggf. k├Ânnen hier aber kleinere systemspezifische Abweichungen auftreten (z. B. bei der Firewall unter Debian).
Ein root-Zugang zum Server wird ebenso vorausgesetzt. Bei einer Neuinstallation eines Ubuntu Servers w├Ąhlt man keine der optionalen Pakete mit an. Es wird nur ein reines "clean" Grundsystem ben├Âtigt.
Voraussetzung ist am besten eine saubere Grundsysteminstallation eines Ubuntu Server Systems. Wie man dieses aufsetzt habe ich bereits hier beschrieben.
Die hier gezeigte VPN L├Âsung kann man auch unter VirtualBox oder Hyper-V problemlos installieren.
Als Servername empfehle ich: OpenVPN-tun

  2.
System Updaten und OpenVPN installieren:
apt-get update && apt-get dist-upgrade
apt-get install openvpn -y
apt-get install pluma -y # optional:
Mein empfohlener Text-Editor bei einer GUI Umgebung.


EasyRSA herunterladen & konfigurieren:


  3.
Als n├Ąchstes muss man eine eigene einfache Zertifizierungsstelle (CA) einrichten.
F├╝r den Aufbau der CA Public Key Infrastruktur (PKI) kann man EasyRSA verwenden.
Hierzu l├Ądt man die neueste Version von EasyRSA [1] aus dem offiziellen GitHub-Repository herunter:
wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.6/EasyRSA-unix-v3.0.6.tgz
# EasyRSA herunterladen.
tar -xvzf EasyRSA-unix-v3.0.6.tgz
# Das Archiv entpacken.


  4.
In das EasyRSA Verzeichnis wechseln und die Datei 'vars.example' kopieren nach 'vars' (ohne Dateiendung):
cd ~/EasyRSA-v3.0.6/
cp vars.example vars


  5.
Verschl├╝sselungsst├Ąrke, G├╝ltigkeitsdauer und Umgebungswerte f├╝r die eigene Zertifizierungsstelle Certificate Authority (CA) festlegen:
# Hier nur eine Variante w├Ąhlen:
nano vars  # im Terminal/ohne GUI
pluma vars # im Desktop/mit GUI


Die vars Datei wie folgt anpassen
(beachtet die blauen Kommentare):
# Easy-RSA 3 parameter settings # NOTE: If you installed Easy-RSA from your distro's package manager, don't edit # this file in place -- instead, you should copy the entire easy-rsa directory # to another location so future upgrades don't wipe out your changes. # HOW TO USE THIS FILE # # vars.example contains built-in examples to Easy-RSA settings. You MUST name # this file 'vars' if you want it to be used as a configuration file. If you do # not, it WILL NOT be automatically read when you call easyrsa commands. # # It is not necessary to use this config file unless you wish to change # operational defaults. These defaults should be fine for many uses without the # need to copy and edit the 'vars' file. # # All of the editable settings are shown commented and start with the command # 'set_var' -- this means any set_var command that is uncommented has been # modified by the user. If you're happy with a default, there is no need to # define the value to its default. # NOTES FOR WINDOWS USERS # # Paths for Windows *MUST* use forward slashes, or optionally double-esscaped # backslashes (single forward slashes are recommended.) This means your path to # the openssl binary might look like this: # "C:/Program Files/OpenSSL-Win32/bin/openssl.exe" # A little housekeeping: DON'T EDIT THIS SECTION # # Easy-RSA 3.x doesn't source into the environment directly. # Hier nichts ├Ąndern. # Complain if a user tries to do this: if [ -z "$EASYRSA_CALLER" ]; then echo "You appear to be sourcing an Easy-RSA 'vars' file." >&2 echo "This is no longer necessary and is disallowed. See the section called" >&2 echo "'How to use this file' near the top comments for more details." >&2 return 1 fi # DO YOUR EDITS BELOW THIS POINT # This variable is used as the base location of configuration files needed by # easyrsa. More specific variables for specific files (e.g., EASYRSA_SSL_CONF) # may override this default. # # The default value of this variable is the location of the easyrsa script # itself, which is also where the configuration files are located in the # easy-rsa tree. #set_var EASYRSA "${0%/*}" # If your OpenSSL command is not in the system PATH, you will need to define the # path to it here. Normally this means a full path to the executable, otherwise # you could have left it undefined here and the shown default would be used. # # Windows users, remember to use paths with forward-slashes (or escaped # back-slashes.) Windows users should declare the full path to the openssl # binary here if it is not in their system PATH. #set_var EASYRSA_OPENSSL "openssl" # # This sample is in Windows syntax -- edit it for your path if not using PATH: #set_var EASYRSA_OPENSSL "C:/Program Files/OpenSSL-Win32/bin/openssl.exe" # Edit this variable to point to your soon-to-be-created key directory. By # default, this will be "$PWD/pki" (i.e. the "pki" subdirectory of the # directory you are currently in). # # WARNING: init-pki will do a rm -rf on this directory so make sure you define # it correctly! (Interactive mode will prompt before acting.) #set_var EASYRSA_PKI "$PWD/pki" # Define X509 DN mode. # This is used to adjust what elements are included in the Subject field as the DN # (this is the "Distinguished Name.") # Note that in cn_only mode the Organizational fields further below aren't used. # # Choices are: # cn_only - use just a CN value # org - use the "traditional" Country/Province/City/Org/OU/email/CN format #set_var EASYRSA_DN "cn_only" set_var EASYRSA_DN "org" # Verwendung des CN-Formats aktivieren. Nur dann werden die nachfolgenden Werte genutzt. # Organizational fields (used with 'org' mode and ignored in 'cn_only' mode.) # These are the default values for fields which will be placed in the # certificate. Don't leave any of these fields blank, although interactively # you may omit any specific field by typing the "." symbol (not valid for # email.) # Die folgenden Werte entsprechend ├Ąndern, z. B. so: #set_var EASYRSA_REQ_COUNTRY "US" # DE = euer Land #set_var EASYRSA_REQ_PROVINCE "California" # TH = euer Bundesland #set_var EASYRSA_REQ_CITY "San Francisco" # Kahla = eure Stadt #set_var EASYRSA_REQ_ORG "Copyleft Certificate Co" # Computertechnik = eure Organisation #set_var EASYRSA_REQ_EMAIL "me@example.net" # mail@ctaas.de = eure E-Mailadresse #set_var EASYRSA_REQ_OU "My Organizational Unit" # IT-VPN = Organisationseinheit/Abteilung Wichtig: Entfernt hier auch die f├╝hrenden Kommentarzeichen (#). # Choose a size in bits for your keypairs. The recommended value is 2048. Using # 2048-bit keys is considered more than sufficient for many years into the # future. Larger keysizes will slow down TLS negotiation and make key/DH param # generation take much longer. Values up to 4096 should be accepted by most # software. Only used when the crypto alg is rsa (see below.) #set_var EASYRSA_KEY_SIZE 2048 # Wichtig: Den Wert sollte man ├Ąndern, um Brute-Force-Angriffe mit vorberechneten Rainbow-Tabellen entgegen zu wirken. # Auch Deep Packet Inspection kann man so ggf. etwas erschweren, da die Pakete dann etwas vom ├╝blichen Standard abweichen. # Ich empfehle daher die Verwendung eines beliebigen nicht auf 1024-fach liegenden Wertes. # Die ├╝blichen Standardwerte wie 2048, 3072, 4096, 8192 usw. sollte man daher nicht verwenden. # Erfahrungsgem├Ą├č funktionieren alle anderen "krummen" Werte ebenso problemlos. # Verwendet daher irgendeinen eigenen Wert zwischen 4096 und 8192, wie z. B.: ... 3313 ... 4447 ... 6113 ... # The default crypto mode is rsa; ec can enable elliptic curve support. # Note that not all software supports ECC, so use care when enabling it. # Choices for crypto alg are: (each in lower-case) # * rsa # * ec #set_var EASYRSA_ALGO rsa # Define the named curve, used in ec mode only: #set_var EASYRSA_CURVE secp384r1 # In how many days should the root CA key expire? #set_var EASYRSA_CA_EXPIRE 3650 # In wie vielen Tagen soll der Root-CA-Schl├╝ssel ablaufen? Standardm├Ą├čig sind hier rund 10 Jahre voreingestellt. # Optional ├Ąndern in: 5475 = 15 Jahre, 7300 = 20 Jahre, 9125 = 25 Jahre. # In how many days should certificates expire? #set_var EASYRSA_CERT_EXPIRE 1080 # In wie vielen Tagen sollen die Zertifikate ablaufen? Standardm├Ą├čig sind hier rund 3 Jahre voreingestellt. # Optional ├Ąndern in: 3650 = 10 Jahre, 5475 = 15 Jahre, 7300 = 20 Jahre, 9125 = 25 Jahre. # Beachtet bei Apple Systemen ab iOS 13 bzw. macOS 10.15 die ge├Ąnderten Sicherheitsanforderungen (maximal 824 Tage). # How many days until the next CRL publish date? Note that the CRL can still be # parsed after this timeframe passes. It is only used for an expected next # publication date. # How many days before its expiration date a certificate is allowed to be # renewed? #set_var EASYRSA_CERT_RENEW 30 #set_var EASYRSA_CRL_DAYS 180 # Support deprecated "Netscape" extensions? (choices "yes" or "no".) The default # is "no" to discourage use of deprecated extensions. If you require this # feature to use with --ns-cert-type, set this to "yes" here. This support # should be replaced with the more modern --remote-cert-tls feature. If you do # not use --ns-cert-type in your configs, it is safe (and recommended) to leave # this defined to "no". When set to "yes", server-signed certs get the # nsCertType=server attribute, and also get any NS_COMMENT defined below in the # nsComment field. #set_var EASYRSA_NS_SUPPORT "no" # When NS_SUPPORT is set to "yes", this field is added as the nsComment field. # Set this blank to omit it. With NS_SUPPORT set to "no" this field is ignored. #set_var EASYRSA_NS_COMMENT "Easy-RSA Generated Certificate" # A temp file used to stage cert extensions during signing. The default should # be fine for most users; however, some users might want an alternative under a # RAM-based FS, such as /dev/shm or /tmp on some systems. #set_var EASYRSA_TEMP_FILE "$EASYRSA_PKI/extensions.temp" # !! # NOTE: ADVANCED OPTIONS BELOW THIS POINT # Wichtig: Ab hier sollte man nichts mehr ├Ąndern. # PLAY WITH THEM AT YOUR OWN RISK # !! # Broken shell command aliases: If you have a largely broken shell that is # missing any of these POSIX-required commands used by Easy-RSA, you will need # to define an alias to the proper path for the command. The symptom will be # some form of a 'command not found' error from your shell. This means your # shell is BROKEN, but you can hack around it here if you really need. These # shown values are not defaults: it is up to you to know what you're doing if # you touch these. # #alias awk="/alt/bin/awk" #alias cat="/alt/bin/cat" # X509 extensions directory: # If you want to customize the X509 extensions used, set the directory to look # for extensions here. Each cert type you sign must have a matching filename, # and an optional file named 'COMMON' is included first when present. Note that # when undefined here, default behaviour is to look in $EASYRSA_PKI first, then # fallback to $EASYRSA for the 'x509-types' dir. You may override this # detection with an explicit dir here. # #set_var EASYRSA_EXT_DIR "$EASYRSA/x509-types" # OpenSSL config file: # If you need to use a specific openssl config file, you can reference it here. # Normally this file is auto-detected from a file named openssl-easyrsa.cnf from the # EASYRSA_PKI or EASYRSA dir (in that order.) NOTE that this file is Easy-RSA # specific and you cannot just use a standard config file, so this is an # advanced feature. #set_var EASYRSA_SSL_CONF "$EASYRSA/openssl-easyrsa.cnf" # Default CN: # This is best left alone. Interactively you will set this manually, and BATCH # callers are expected to set this themselves. #set_var EASYRSA_REQ_CN "ChangeMe" # Cryptographic digest to use. # Do not change this default unless you understand the security implications. # Valid choices include: md5, sha1, sha256, sha224, sha384, sha512 #set_var EASYRSA_DIGEST "sha256" # Batch mode. Leave this disabled unless you intend to call Easy-RSA explicitly # in batch mode without any user input, confirmation on dangerous operations, # or most output. Setting this to any non-blank string enables batch mode. #set_var EASYRSA_BATCH ""

Erg├Ąnzender Hinweis: Dies ist die original vars Datei vom EasyRSA 3.0.6 Release. Die Datei wurde mit einigen Kommentaren erg├Ąnzt.

  6.
Nun startet man das easyrsa utility um die Public Key Infrastruktur zu initialisieren:
./easyrsa init-pki

Wichtig: Diesen Schritt darf man nur einmalig bei der Einrichtung ausf├╝hren.
F├╝hrt man diese sp├Ąter nochmals aus, so wird nach einer R├╝ckfrage die komplette Zertifizierungsstelle zur├╝ckgesetzt.

  7.
OpenVPN verwendet OpenSSL zur Zertifikats-/Schl├╝sselerstellung.
OpenSSL wiederum verwendet zur Erstellung einen Zufallsgenerator CSPRNG (cryptographically secure pseudorandom number generator/kryptographisch sicheren Zufallszahlengenerator).
Dieser wird unter anderem mit einen Startwert dem seed (Samen) initialisiert. Die Qualit├Ąt der Zufallszahlen h├Ąngt also auch von dieser Initialisierung ab.
Insbesondere auf schwachen Embedded-Systemen sollte dieser durch eine nicht deterministische Entrophie initialisiert werden.
Sprich die Vorhersagbarkeit der erzeugten Zufallszahlen soll m├Âglichst nicht ermittelbar sein.
Schwache Systeme erzeugen ggf. immer ├Ąhnliche Zufallszahlen. Erzeugt dann diesen seed vorab auf einem anderen System.

Den Initialisierungswert/seed f├╝r den Zufallsgenerator (RNG) f├╝r OpenSSL erzeugen:
dd if=/dev/urandom of=pki/.rnd bs=256 count=1

Erg├Ąnzende Anmerkung: Der Zufallsgenerator RNG (random number generator) verwendet nat├╝rlich noch weitere initialisierungswerte. Dieser seed ist also nicht die einzige Quelle.

Erzeugt: ~/EasyRSA-v3.0.6/pki/.rnd

  8.
Als n├Ąchstes erzeugt man die Dateien f├╝r die Certificate Authority (CA):
./easyrsa build-ca nopass

Die Frage beim [Common Name] einfach mit Enter best├Ątigen.
Die eigene Zertifizierungsstelle Certificate Authority (CA) ist nun vorbereitet.
Auf diese aufbauend kann man nun die Server und Client Zeritifikate erstellen.

Erzeugt: ~/EasyRSA-v3.0.6/pki/ca.crt

Zertifikat & Schl├╝ssel f├╝r den Server, die HMAC-Signatur (ta.key) und
die Diffie-Hellmannn-Schl├╝sselaustausch (dh.pem) Datei erstellen:


  9.
Nun muss man einen privaten Schl├╝ssel erstellen, um das CA Zertifikat vom Server zu signieren.
Rufen Sie dann das Easyrsa-Skript erneut auf, jetzt mit der Option gen-req, gefolgt von einem Namen f├╝r den Server. In diesem Tutorial wird f├╝r den Common Name des OpenVPN-Servers einfach der Name "server" (klein geschrieben) verwendet.
cd ~/EasyRSA-v3.0.6/ # In den Pfad wechseln.
./easyrsa gen-req server nopass
# Das Server-Zertifikat erstellen.


Erzeugt: ~/EasyRSA-v3.0.6/pki/reqs/server.req und ~/EasyRSA-v3.0.6/pki/reqs/server.key

Hinweis: Wenn Sie hier einen anderen Namen als "server" w├Ąhlen, m├╝ssen Sie einige der folgenden Anweisungen anpassen. Wenn Sie beispielsweise die erzeugten Dateien in das Verzeichnis /etc/openvpn kopieren, m├╝ssen Sie die richtigen Namen ersetzen. Sie m├╝ssen auch die Datei /etc/openvpn/server.conf sp├Ąter ├Ąndern, um auf die richtigen .crt- und .key-Dateien zu verweisen.

  10.
Das "server" Zertifikat signieren:
./easyrsa sign-req server server

Bei [Confirm request details:] yes
eingeben und mit Enter best├Ątigen.

Erzeugt: ~/EasyRSA-v3.0.6/pki/issued/server.crt


  11.
Den tls-crypt (ehemals tls-auth) Schl├╝ssel erstellen:
openvpn --genkey --secret ta.key

Vorab: tls-crypt verbessert tls-auth.

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:

Was ist nun neu an tls-crypt?
tls-crypt (ab OpenVPN 2.4 m├Âglich) verschl├╝sselt und signiert zus├Ątzlich direkt von Beginn an alle Pakete des Handshakes.

tls-ctypt bewirkt damit folgendes:

Der ta.key Schl├╝ssel wird nur f├╝r den SSL/TLS-handshake also nur w├Ąhrend des Verbindungsaufbaus zum Server ben├Âtigt.
Der Server und alle Clients verwenden dabei den selben hier eben erzeugten globalen Schl├╝ssel (pre-shared Key) zur Authentifizierung und Verschl├╝sselung.

Um Kollisionen (ein knacken des Schl├╝ssels) zu verhindern, sollte man diesen Schl├╝ssel alle 2^48 Pakete erneuern.
Beim anf├Ąnglichen Verbindungsaufbau werden etwa 10 Pakete in jede Richtung (zwischen Server und Client) ├╝bertragen.
Angenommen der Verbindungsaufbau ben├Âtigt jeweils h├Âchstens 2^16 (65536) Pakete und es findet jede Minute ein Verbindungsversuch statt,
dann begrenzt dies die Lebensdauer des tls-crypt Schl├╝ssels auf ca. 8171 Jahre (die Daten entstammen der ManPage).

F├╝r die meisten normalen Nutzer bedeutet dies, einmal eingerichtet kann man den ta.key immer verwenden.
Da man eine derart hohe Zahl der Verbindungen wohl nicht erreichen wird.
Gr├Â├čere Installationen mit mehren Usern sollten den ta.key aber h├Ąufiger wechseln, bei 8000 Usern z. B. einmal im Jahr (die Daten entstammen der ManPage).

Sollte es zu einer Kollision (dem knacken des Schl├╝ssels) kommen, so wird die Sicherheit auf das Niveau von einer reinen tls-auth Installation herabgesetzt.
Der Schutz gegen Portscanning, DoS-Angriffe und Man-in-the-Middle-Angriffe bleibt also erhalten.
Haupts├Ąchlich ginge dann die zus├Ątzliche Privatsph├Ąre verloren - gemeint ist hier das verstecken des Aufbaus der Verbindung.
Die reine Daten├╝bertragung sobald der Tunnel steht w├Ąre nach wie vor (auch ohne tls-crypt) sicher.

Problematisch ist hier vor allem das alle Clients den selben globalen Schl├╝ssel verwenden. Das gilt sowohl f├╝r tls-auth wie auch f├╝r tls-crypt.
Ist z. B. ein Client System oder gar der Server kompromitiert und es wurde der ta.key gestohlen, so ist der extra Schutz durch den ta.key f├╝r alle anderen Clients ebenso hinf├Ąllig.
Insbesondere gr├Â├čere Organisiationen und VPN-Anbietern k├Ânnten von einem leak (einer Ver├Âffentlichung) des ta.keys betroffen sein.

Daher wird vorrausichtlich mit OpenVPN 2.5 ein verbessertes tls-crypt-v2 eingef├╝hrt. Hier erh├Ąlt dann jeder Client seinen eigenen separaten Schl├╝ssel.
tls-crypt-v2 erh├Âht somit die Sicherheit insbesondere bei Installationen mit mehreren Clients. F├╝r den ├ťbergang soll eine gleichzeitige Nutzung von tls-crypt und tls-crypt-v2 m├Âglich sein.
Derzeit gibt es aber noch kein stable Release von OpenVPN das die tls-ctypt-v2 Funktionalit├Ąt direkt enth├Ąlt. Daher setzten wir hier in der Dokumentation nur tls-crypt ein.
F├╝r die meisten privaten Anwender sollte tls-crypt wie es hier eingebunden wurde v├Âllig ausreichen.

erg├Ąnzende Erk├Ąrungen hier: Openvpn24ManPage, serverfault.com, security.stackexchange.com, github.com/OpenVPN ... tls-crypt-v2.txt

Erzeugt: ~/EasyRSA-v3.0.6/ta.key

  12.
Die f├╝r den Server relevanten Zertifikate und Schl├╝ssel in den Ordner /etc/openvpn/ kopieren:
cp pki/private/server.key /etc/openvpn/
cp pki/issued/server.crt /etc/openvpn/
cp pki/ca.crt /etc/openvpn/
cp ta.key /etc/openvpn/


  13.
Diffie-Hellman-Parameter generieren:
./easyrsa gen-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.

Erzeugt: ~/EasyRSA-v3.0.6/pik/dh.pem

Optional:
Man kann auch noch st├Ąrkere Diffie-Hellman-Parameter generieren, da diese unabh├Ąngig von der Schl├╝sselst├Ąrke sind.
Standardm├Ą├čig wird der Wert der Variable [EASYRSA_KEY_SIZE] in der vars Datei verwendet.
Beliebige andere Werte (h├Âhere und niedrigere) sind hier problemlos m├Âglich. Nat├╝rlich macht nur eine Erh├Âhung Sinn.
Verwendet auch hier einen beliebigen nicht auf 1024-fach liegenden Wert.
Der Schritt der Erh├Âhung wird jedoch erst empfohlen wenn alles l├Ąuft, verwendet f├╝r die Ersteinrichtung also erst mal den Standardwert.
Eine st├Ąrkere dh.pem Datei erstellen:
time openssl dhparam -out dh8192.pem 8192
# getestet: Ok
time openssl dhparam -out dh16384.pem 16384
# getestet: Nicht empfohlen. Funktioniert derzeit (2015-10-20) mit keinem Android-Client.

Wenn man eine st├Ąrkere Diffie-Hellman-Parameter-Datei erzeugt hat, dann muss man diese ggf. noch ins entsprechende Verzeichnis kopieren.
Ggf. muss man in der server.conf nochmals den entsprechenden [dh] Eintrag anpassen.
Im Anschluss startet man OpenVPN neu um die neuen Einstellungen zu ├╝bernehmen.


  14.
Die dh.pem Datei in das Verzeichnis /etc/openvpn/ kopieren:
cp pki/dh.pem /etc/openvpn/


Zertifikat & Schl├╝ssel f├╝r den Client erstellen:


  15.
Als n├Ąchstes erstellt man einen neuen Ordner (der Aufruf ist nur einmalig notwendig) wo dann die Client Zertifikate und Schl├╝ssel gespeichert werden:
mkdir -pv ~/client/keys
# Hier liegen sp├Ąter die Client-Keys.


  16.
Ein Client Zertifikat erstellen.
Zertifikate kann man mit und ohne Passwort erstellen. Ein Zertifikat mit Passwort erh├Âht die Sicherheit, da auf dem Client vor dem Aufbau der VPN-Verbindung ein zus├Ątzliches Passwort abgefragt wird.

Empfehlung vorab:
Bei der Nummerierung der Clients w├╝rde ich nicht mit der Nummer 01 beginnen, da das erste Zertifikat schon dem Server zugeordnet ist.
Daher erh├Ąlt in diesem Tutorial der erste Client den Namen client02.
cd ~/EasyRSA-v3.0.6 # In den Pfad wechseln.

# Hier nur eine Variante w├Ąhlen:
./easyrsa gen-req client02 nopass
# Erstellt ein Client Zertifikat ohne Passwort.
./easyrsa gen-req client03
# Erstellt ein Client Zertifikat mit Passwort (mindestens 4 Zeichen).


Bei Zertifikaten mit Passwort bei [Enter PEM pass phrase] und bei [Verifying] das gew├╝nschte Passwort eingeben und jeweils mit Enter best├Ątigen.
Dieses Passwort (phrase) muss der Client-Nutzer dann beim Herstellen einer VPN-Verbindung jedes Mal eingeben.
Die Eingabe bei [Common Name] mit Enter best├Ątigen.

Tipp:
Wer noch weitere Clients erstellen will kann dies gleich tun.
Man ├Ąndert hier nur den clientXX-Namen ab (z. B. durch hochz├Ąhlen - meine Empfehlung)
und ruft das Script einfach noch einmal auf.

Erg├Ąnzender Hinweis:
OpenVPN z├Ąhlt intern Hexadezimal.
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 Datei EasyRSA-v3.0.6/pki/index.txt werfen.
Hier sind alle Zertifikate ├╝bersichtlich aufgelistet. Insbesondere wenn man in der vars Datei die Variable [set_var EASYRSA_DN] auf ["org"] gesetzt hat f├Ąllt eine ├ťbersicht dann leicht.

Erzeugt: /root/EasyRSA-v3.0.6/pki/reqs/clientxx.key und /root/EasyRSA-v3.0.6/pki/private/clientxx.key


  17.
Als n├Ąchstes signiert man die Zertifikatsanforderung f├╝r den Client mit folgendem Befehl:
./easyrsa sign-req client client02

Hier yes eingeben und mit Enter best├Ątigen.

Erzeugt: /root/EasyRSA-v3.0.6/pki/issued/clientxx.crt

  18.
Die f├╝r den Client relevanten Zertifikate und Schl├╝ssel in den Ordner ~/client/keys/ kopieren:
cp pki/private/client02.key ~/client/keys/
cp pki/issued/client02.crt ~/client/keys/
cp /etc/openvpn/ca.crt ~/client/keys/
cp ta.key ~/client/keys/


Hinweis: Passt die Namen/Nummern der Client-Zertifikate/Schl├╝ssel vor dem Kopieren entsprechend an.


Die Server- und Client-Zertifikate sind nun einsatzbereit.

Ein Client ben├Âtigt f├╝r den Verbindungsaufbau somit folgende Dateien:
~/client/keys/clientxx.key ~/client/keys/clientxx.crt ~/client/keys/ca.crt ~/client/keys/ta.key ~/client/client.conf # Die Datei wird hier erstellt.


Tipp: Die einzelnen Client Zertifikatsdateien und Schl├╝ssel kann man auch zu einer einzelnen .ovpn Datei zusammenfassen.

Hinweis:
Zun├Ąchst muss man aber erst noch die Server und Client Konfigurationen erstellen.
Folgt daher bei der Ersteinrichtung erst einmal der fortlaufenden Dokumentation.

Die Server Konfiguration erstellen:


  19.
Als n├Ąchstes muss man den OpenVPN-Dienst so konfigurieren, dass er alle zuvor erstellten Zertifikate verwendet.
Die Beispiel Konfigurationsdatei vom OpenVPN Server in das /etc/openvpn Verzeichnis kopieren und entpacken:
cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
gzip -dkv /etc/openvpn/server.conf.gz


  20.
Die server.conf Datei anpassen:
nano /etc/openvpn/server.conf          
# im Terminal/ohne GUI
nohup pluma /etc/openvpn/server.conf &
# im Desktop/mit GUI


Die server.conf Datei wie folgt anpassen
(beachtet die blauen Kommentare bzw. die optimierten Versionen danach):
# Achtung: Diese Zeile muss man nur bei der Verwendung vom UDP-Protokoll hinzuf├╝gen. fragment 1200 # Der Eintrag muss 1:1 mit dem Eintrag in der client-Konfigurationsdatei client.conf ├╝bereinstimmen. # Bitte beachten: Zu hohe fragment Werte machen die Verbindung instabil. # Bei einem zu hohem Wert wird die Verbindung zwar aufgebaut. Man kann aber keinerlei Daten ├╝bertragen. # Ein typisches Symptom ist das die Verbindung nur wenige Sekunden nutzbar ist bzw. sobald man Daten ├╝bertragen will scheint die Verbindung zusammenzubrechen. # Und das obwohl die Verbindung nach wie vor steht. Mit dem hier voreingestellten Wert von 1200 habe ich gute Erfahrungen gemacht. # Tendenziell empfehle ich die Verwendung des TCP-Protokolls, da hier weniger Paketverluste auftreten, auch wenn der Paketoverhead bei TCP etwas gr├Â├čer ist. ################################################# # Sample OpenVPN 2.0 config file for # # multi-client server. # # # # This file is for the server side # # of a many-clients <-> one-server # # OpenVPN configuration. # # # # OpenVPN also supports # # single-machine <-> single-machine # # configurations (See the Examples page # # on the web site for more info). # # # # This config should work on Windows # # or Linux/BSD systems. Remember on # # Windows to quote pathnames and use # # double backslashes, e.g.: # # "C:\\Program Files\\OpenVPN\\config\\foo.key" # # # # Comments are preceded with '#' or ';' # ################################################# # Which local IP address should OpenVPN # listen on? (optional) ;local a.b.c.d # Which TCP/UDP port should OpenVPN listen on? # If you want to run multiple OpenVPN instances # on the same machine, use a different port # number for each one. You will need to # open up this port on your firewall. port 1194 # Der Port muss 1:1 mit der Angabe in der client.conf ├╝bereinstimmen. # Optional: # port 443 - HTTPS (Hypertext Transfer Protocol ├╝ber SSL/TLS mit TCP) oder ein anderer beliebiger freier Port von 0 bis 65535. # TCP or UDP server? ;proto tcp proto udp # Das Protokoll muss 1:1 mit der Angabe in der client.conf ├╝bereinstimmen. # Optional: proto tcp/udp4/tcp4 # udp4/tcp4 bedeutet dabei, dass das entsprechende Protokoll nur ├╝ber IPv4 genutzt wird. # Wichtig: Beachtet die erg├Ąnzenden Hinweise am Ende dieser Beispieldatei (explicit-exit-notify 1 am Ende deaktivieren). # "dev tun" will create a routed IP tunnel, # "dev tap" will create an ethernet tunnel. # Use "dev tap0" if you are ethernet bridging # and have precreated a tap0 virtual interface # and bridged it with your ethernet interface. # If you want to control access policies # over the VPN, you must create firewall # rules for the the TUN/TAP interface. # On non-Windows systems, you can give # an explicit unit number, such as tun0. # On Windows, use "dev-node" for this. # On most systems, the VPN will not function # unless you partially or fully disable # the firewall for the TUN/TAP interface. ;dev tap dev tun # Windows needs the TAP-Win32 adapter name # from the Network Connections panel if you # have more than one. On XP SP2 or higher, # you may need to selectively disable the # Windows firewall for the TAP adapter. # Non-Windows systems usually don't need this. ;dev-node MyTap # SSL/TLS root certificate (ca), certificate # (cert), and private key (key). Each client # and the server must have their own cert and # key file. The server and all clients will # use the same ca file. # # See the "easy-rsa" directory for a series # of scripts for generating RSA certificates # and private keys. Remember to use # a unique Common Name for the server # and each of the client certificates. # # Any X509 key management system can be used. # OpenVPN can also use a PKCS #12 formatted key file # (see "pkcs12" directive in man page). ca ca.crt cert server.crt key server.key # This file should be kept secret # Diffie hellman parameters. # Generate your own with: # openssl dhparam -out dh2048.pem 2048 dh dh2048.pem # ├Ąndern in 'dh dh.pem' # Network topology # Should be subnet (addressing via IP) # unless Windows clients v2.0.9 and lower have to # be supported (then net30, i.e. a /30 per client) # Defaults to net30 (not recommended) ;topology subnet # Configure server mode and supply a VPN subnet # for OpenVPN to draw client addresses from. # The server will take 10.8.0.1 for itself, # the rest will be made available to clients. # Each client will be able to reach the server # on 10.8.0.1. Comment this line out if you are # ethernet bridging. See the man page for more info. server 10.8.0.0 255.255.255.0 # Maintain a record of client <-> virtual IP address # associations in this file. If OpenVPN goes down or # is restarted, reconnecting clients can be assigned # the same virtual IP address from the pool that was # previously assigned. ifconfig-pool-persist /var/log/openvpn/ipp.txt # Configure server mode for ethernet bridging. # You must first use your OS's bridging capability # to bridge the TAP interface with the ethernet # NIC interface. Then you must manually set the # IP/netmask on the bridge interface, here we # assume 10.8.0.4/255.255.255.0. Finally we # must set aside an IP range in this subnet # (start=10.8.0.50 end=10.8.0.100) to allocate # to connecting clients. Leave this line commented # out unless you are ethernet bridging. ;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100 # Configure server mode for ethernet bridging # using a DHCP-proxy, where clients talk # to the OpenVPN server-side DHCP server # to receive their IP address allocation # and DNS server addresses. You must first use # your OS's bridging capability to bridge the TAP # interface with the ethernet NIC interface. # Note: this mode only works on clients (such as # Windows), where the client-side TAP adapter is # bound to a DHCP client. ;server-bridge # Push routes to the client to allow it # to reach other private subnets behind # the server. Remember that these # private subnets will also need # to know to route the OpenVPN client # address pool (10.8.0.0/255.255.255.0) # back to the OpenVPN server. ;push "route 192.168.10.0 255.255.255.0" ;push "route 192.168.20.0 255.255.255.0" # Hier muss man den Netzbereich des VPN-Servers (Subnetz und Subnetmaske) eingeben. # Wenn man das interne Netzwerk hinter dem VPN-Server erreichen m├Âchte # kann man push "route x.x.x.0 255.255.255.0" oder "push "redirect-gateway def1 ..." (der Parameter kommt gleich) verwenden. # # Es reicht wenn man sich f├╝r eine Variante entscheidet. Wo liegen nun die Unterschiede? # # Bei 'push "route ...' ist das hinter dem Server liegende Netzwerke erreichbar. # Direkte Zugriffe (├╝ber die IP-Adresse) auf weitere PCs im VPN-Server Netzwerk sind so problemlos m├Âglich. # Aller weiterer Datentransfer wird jedoch ├╝ber das Standard-Gateway vom Client geleitet. # Normaler Internet Traffic auf dem Client wird bei 'push "route ...' somit nicht ├╝ber den VPN-Tunnel geleitet. # # Bei 'push "redirect-gateway def1 ..."' wird der gesamte Datentransfer ├╝ber das Standard-Gateway vom Client geleitet. # ├ťber das Gateway (in der Regel der DSL-Router) sind dann auch die hinter dem Server liegenden PCs (├╝ber die IP-Adresse) erreichbar. # Weiterhin wird auch der komplette Internet Traffic auf dem Client wird ├╝ber den VP-Tunnel geleitet. # To assign specific IP addresses to specific # clients or if a connecting client has a private # subnet behind it that should also have VPN access, # use the subdirectory "ccd" for client-specific # configuration files (see man page for more info). # EXAMPLE: Suppose the client # having the certificate common name "Thelonious" # also has a small subnet behind his connecting # machine, such as 192.168.40.128/255.255.255.248. # First, uncomment out these lines: ;client-config-dir ccd ;route 192.168.40.128 255.255.255.248 # Then create a file ccd/Thelonious with this line: # iroute 192.168.40.128 255.255.255.248 # This will allow Thelonious' private subnet to # access the VPN. This example will only work # if you are routing, not bridging, i.e. you are # using "dev tun" and "server" directives. # EXAMPLE: Suppose you want to give # Thelonious a fixed VPN IP address of 10.9.0.1. # First uncomment out these lines: ;client-config-dir ccd ;route 10.9.0.0 255.255.255.252 # Then add this line to ccd/Thelonious: # ifconfig-push 10.9.0.1 10.9.0.2 # Suppose that you want to enable different # firewall access policies for different groups # of clients. There are two methods: # (1) Run multiple OpenVPN daemons, one for each # group, and firewall the TUN/TAP interface # for each group/daemon appropriately. # (2) (Advanced) Create a script to dynamically # modify the firewall in response to access # from different clients. See man # page for more info on learn-address script. ;learn-address ./script # If enabled, this directive will configure # all clients to redirect their default # network gateway through the VPN, causing # all IP traffic such as web browsing and # and DNS lookups to go through the VPN # (The OpenVPN server machine may need to NAT # or bridge the TUN/TAP interface to the internet # in order for this to work properly). ;push "redirect-gateway def1 bypass-dhcp" # Den gesamten Netzwerkverkehr vom Webbrowser, DNS-Lookups usw. durch das VPN-Netzwerk leiten (optional). # Certain Windows-specific network settings # can be pushed to clients, such as DNS # or WINS server addresses. CAVEAT: # http://openvpn.net/faq.html#dhcpcaveats # The addresses below refer to the public # DNS servers provided by opendns.com. ;push "dhcp-option DNS 208.67.222.222" ;push "dhcp-option DNS 208.67.220.220" # Erm├Âglicht die DNS-Namensaufl├Âsung, '208.67.222.222' und '208.67.220.220' sind IP-Adressen der OpenDNS Server. # Hier kann man auch eigene oder andere ├Âffentliche DNS-Server angeben, hier ein paar Beispiele: # ----------------+----------------------------------------------------------------------------- # 1.1.1.1 | Cloudflare und APNIC # 1.0.0.1 | Cloudflare und APNIC 1.1.1.1 # 8.8.4.4 | google-public-dns-b.google.com developers.google.com/speed/public-dns/ # 8.8.8.8 | google-public-dns-a.google.com # 9.9.9.9 | malware blocklist, DNSSEC validation (empfohlen) Global Cyber Alliance (GCA) und weitere Partner quad9.net # 9.9.9.10 | send EDNS client subnet (no features) # 9.9.9.11 | malware blocklist, send EDNS client subnet & DNSSEC validation (CDN-Friendly) # 9.9.9.12 | malware blocklist, nxdomain only & DNSSEC validation (IoT-Friendly) # 141.1.1.1 | cns1.cw.net Cable & Wireless (ehemals ECRC) # 194.150.168.168 | dns.as250.net; Berlin/Frankfurt vom ccc.de; alternative opennic.org/ # 213.73.91.35 | dnscache.berlin.ccc.de # Erg├Ąnzende Hinweise: # Die FQDN-Namensaufl├Âsung funktioniert in gerouteten 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 daher nicht nur einen einfachen DSL-Router bzw. das Standard-Gateway angeben. # Die FQDN-Anfragen sind keine Hostnamen anfragen, sondern voll qualifizierte # Domain-Namen Anfragen (Full Qualified Domain Name) wie z. B. pc01.meinedomain.local oder www.ctaas.de. # Die Aufl├Âsung von einem Hostnamen (einfachen PC-Namen) ist dar├╝ber nicht m├Âglich. # Ich verwende daher diesen Eintrag meistens nicht (kein Bedarf). # Uncomment this directive to allow different # clients to be able to "see" each other. # By default, clients will only see the server. # To force clients to only see the server, you # will also need to appropriately firewall the # server's TUN/TAP interface. ;client-to-client # Uncomment this directive if multiple clients # might connect with the same certificate/key # files or common names. This is recommended # only for testing purposes. For production use, # each client should have its own certificate/key # pair. # # IF YOU HAVE NOT GENERATED INDIVIDUAL # CERTIFICATE/KEY PAIRS FOR EACH CLIENT, # EACH HAVING ITS OWN UNIQUE "COMMON NAME", # UNCOMMENT THIS LINE OUT. ;duplicate-cn # The keepalive directive causes ping-like # messages to be sent back and forth over # the link so that each side knows when # the other side has gone down. # Ping every 10 seconds, assume that remote # peer is down if no ping received during # a 120 second time period. keepalive 10 120 # For extra security beyond that provided # by SSL/TLS, create an "HMAC firewall" # to help block DoS attacks and UDP port flooding. # # Generate with: # openvpn --genkey --secret ta.key # # The server and each client must have # a copy of this key. # The second parameter should be '0' # on the server and '1' on the clients. tls-auth ta.key 0 # This file is secret # Select a cryptographic cipher. # This config item must be copied to # the client config file as well. # Note that v2.4 client/server will automatically # negotiate AES-256-GCM in TLS mode. # See also the ncp-cipher option in the manpage cipher AES-256-CBC # Die Angabe muss 1:1 mit der Angabe in der client.conf ├╝bereinstimmen. # Enable compression on the VPN link and push the # option to the client (v2.4+ only, for earlier # versions see below) ;compress lz4-v2 # Optional: Komprimierung der Daten vor der ├ťbertragung (neue Version). ;push "compress lz4-v2" # Wichtig: Aus Sicherheitsgr├╝nden sollte man die Komprimierung nicht aktivieren. # For compression compatible with older clients use comp-lzo # If you enable it here, you must also # enable it in the client config file. ;comp-lzo # The maximum number of concurrently connected # clients we want to allow. ;max-clients 100 # It's a good idea to reduce the OpenVPN # daemon's privileges after initialization. # # You can uncomment this out on # non-Windows systems. ;user nobody ;group nogroup # Hier die Kommentarzeichen (;) entfernen. # The persist options will try to avoid # accessing certain resources on restart # that may no longer be accessible because # of the privilege downgrade. persist-key persist-tun # Output a short status file showing # current connections, truncated # and rewritten every minute. status /var/log/openvpn/openvpn-status.log # By default, log messages will go to the syslog (or # on Windows, if running as a service, they will go to # the "\Program Files\OpenVPN\log" directory). # Use log or log-append to override this default. # "log" will truncate the log file on OpenVPN startup, # while "log-append" will append to it. Use one # or the other (but not both). ;log /var/log/openvpn/openvpn.log ;log-append /var/log/openvpn/openvpn.log # Set the appropriate level of log # file verbosity. # # 0 is silent, except for fatal errors # 4 is reasonable for general usage # 5 and 6 can help to debug connection problems # 9 is extremely verbose verb 3 # Silence repeating messages. At most 20 # sequential messages of the same message # category will be output to the log. ;mute 20 # Notify the client that when the server restarts so it # can automatically reconnect. explicit-exit-notify 1 # Wichtig: Wenn man als Protokoll TCP (statt UDP) verwendet, # dann muss man diesen Wert auf 0 setzen oder den Eintrag auskommentieren (;) oder komplett entfernen.

Erg├Ąnzender Hinweis: Dies ist die original mitgelieferte server.conf Datei. Die Datei wurde mit einigen Kommentaren erg├Ąnzt.
Beachtet dabei: Es wurden hier nur die notwendigen Änderungen für eine funktionierende VPN-Verbindung angepasst.
├ťbernehmt f├╝r eine erh├Âhte Sicherheit die Anpassungen aus den folgenden optimierten Konfigurationen.


Optimierte server.conf mit dem UDP-Protokoll (f├╝r Copy & Paste):
## Zusammengefasste UDP-Version mit kurzen Kommentaren mit allen wichtigen Parametern und Anpassungen f├╝r mehr Sicherheit. ## fragment 1200 # Paketfragmentierung f├╝r UDP. Bei UDP unbedingt hinzuf├╝gen. remote-cert-tls client # Verhindert man-in-the-middle Attacken. tls-version-min 1.2 # Der Server akzeptiert nur TLS-Version (Transport Layer Security) ab der Version 1.2. # Dies verbietet somit ein downgrade auf einen schw├Ącheren Verschl├╝sselungsstandard, was wiederum die Sicherheit erh├Âht. # Die lokale SSL-Implementierung muss dies unterst├╝tzen. Das klappt in der Regel problemlos, sodass man dies immer nutzen sollte. auth SHA512 # Die HMAC-Authentication wurde aus Sicherheitsgr├╝nden von SHA1 (Standard) auf SHA512 erh├Âht. port 1194 # Hier ggf. den Port anpassen. UDP-Alternativen: 123 NTP, 53 DNS proto udp4 # UDP ├╝ber IPv4. dev tun # Routing im OSI Layer 3. ca ca.crt # Pfadangaben zu den Zertifikaten/Schl├╝sseln und der Diffie-Hellmannn-Schl├╝sselaustausch Datei (dh.pem). cert server.crt key server.key dh dh.pem server 10.8.0.0 255.255.255.0 # Ist der IP-Adressbereich innerhalb des VPN-Netzwerkes. ifconfig-pool-persist /var/log/openvpn/ipp.txt # Speichert die IP-Adressen der Clients. # Den Zugriff auf das Netzwerk hinter dem Server erm├Âglichen. Hier muss man nur eine Variante w├Ąhlen: ;push "route 192.168.20.0 255.255.255.0" # Nur bestimmten Netzwerkverkehr durch routing weiterleiten (empfohlen/hier den Netzbereich anpassen). push "redirect-gateway def1 bypass-dhcp" # Oder den kompletten Netzwerkverkehr durch das VPN-Netzwerk leiten (einfache Variante). keepalive 10 120 # Pr├╝ft ob eine Verbindung besteht. Verbindet nach 120 Sekunden neu. tls-crypt ta.key # HMAC-Signaturen den Paketen hinzuf├╝gen -> die Sicherheit erh├Âhen. Ersetzt den Parameter 'tls-auth ta.key 0'. # Die fehlende 0 ist so richtig. Auch die Angabe der 'key-direction 0' ist bei tls-crypt nicht mehr n├Âtig. # Wichtig: Man darf hier nur eine Variante verwenden, also entweder tls-crypt (empfohlen) oder tls-auth (veraltet). cipher AES-256-CBC # Verschl├╝sselung festlegen. Weitere ├╝ber: "openvpn --show-ciphers" ;compress lz4-v2 # Optional: Komprimierung der Daten vor der ├ťbertragung. ;push "compress lz4-v2" # Aus Sicherheitsgr├╝nden sollte man die Komprimierung nicht aktivieren. user nobody # Einschr├Ąnken der Rechte auf dem Server -> die Sicherheit erh├Âhen. group nogroup persist-key persist-tun status /var/log/openvpn/openvpn-status.log # Logfile mit den aktuellen Verbindungen. # Optional: Separates logging. Bitte beachten, hier nur einen Eintrag aktivieren: ;log /var/log/openvpn/openvpn.log # Entweder Logging immer in ein neues Logfile. ;log-append /var/log/openvpn/openvpn.log # Oder das Logfile wird immer fortgesetzt. verb 3 # Detailgrad des Logfiles festlegen von 0-9, 2-4 empfohlen, 5-9 nur f├╝r Debug.


Optimierte server.conf mit dem TCP-Protokoll (f├╝r Copy & Paste empfohlen) ­čĹŹ:
## Zusammengefasste TCP-Version mit kurzen Kommentaren mit allen wichtigen Parametern und Anpassungen f├╝r mehr Sicherheit. ## remote-cert-tls client # Verhindert man-in-the-middle Attacken. tls-version-min 1.2 # Der Server akzeptiert nur TLS-Version (Transport Layer Security) ab der Version 1.2. # Dies verbietet somit ein downgrade auf einen schw├Ącheren Verschl├╝sselungsstandard, was wiederum die Sicherheit erh├Âht. # Die lokale SSL-Implementierung muss dies unterst├╝tzen. Das klappt in der Regel problemlos, sodass man dies immer nutzen sollte. auth SHA512 # Die HMAC-Authentication wurde aus Sicherheitsgr├╝nden von SHA1 (Standard) auf SHA512 erh├Âht. port 1194 # Hier ggf. den Port anpassen. Empfohlen: 443 HTTPS. Der Standardport 1194 kann in fremden Zug├Ąngen (Cafes usw.) geblockt sein. # TCP-Alternativen: 80 HTTP, 465 SSL/TLS-SMTP, 587 TLS/STARTTTLS SMTP, 995 SSL/TLS-POP3, 993 SSL/TLS-IMAP, 53 DNS, 22 SSH, 21 FTP. ;port-share x.x.x.x port # Verwendet man nur wenn man bereits eine andere Anwendung, wie z. B. einen HTTPS-Server auf dem Port 443 betreibt. # Die von au├čen eingehende Port-Verbindung leitet man nun zuerst zum OpenVPN Server. Der OpenVPN Server verarbeitet # somit erst mal alle eingehenden Pakete. Pakete die nicht OpenVPN betreffen werden ├╝ber einen Proxy automatisch # an die angegebene IP-Adresse + Port weitergeleitet (z. B. port-share 192.168.20.40 443). Beachtet dabei: Zur Zeit # wird nur die Weiterleitung von HTTP/HTTPS (80/443) unterst├╝tzt (andere Protokolle k├Ânnten gehen ohne Garantie). proto tcp4 # TCP ├╝ber IPv4. dev tun # Routing im OSI Layer 3. ca ca.crt # Pfadangaben zu den Zertifikaten/Schl├╝sseln und der Diffie-Hellmannn-Schl├╝sselaustausch Datei (dh.pem). cert server.crt key server.key dh dh.pem server 10.8.0.0 255.255.255.0 # Ist der IP-Adressbereich innerhalb des VPN-Netzwerkes. ifconfig-pool-persist /var/log/openvpn/ipp.txt # Speichert die IP-Adressen der Clients. # Den Zugriff auf das Netzwerk hinter dem Server erm├Âglichen. Hier muss man nur eine Variante w├Ąhlen: ;push "route 192.168.20.0 255.255.255.0" # Nur bestimmten Netzwerkverkehr durch routing weiterleiten (empfohlen/hier den Netzbereich anpassen). push "redirect-gateway def1 bypass-dhcp" # Oder den kompletten Netzwerkverkehr durch das VPN-Netzwerk leiten (einfache Variante). keepalive 10 120 # Pr├╝ft ob eine Verbindung besteht. Verbindet nach 120 Sekunden neu. tls-crypt ta.key # HMAC-Signaturen den Paketen hinzuf├╝gen -> die Sicherheit erh├Âhen. Ersetzt den Parameter 'tls-auth ta.key 0'. # Die fehlende 0 ist so richtig. Auch die Angabe der 'key-direction 0' ist bei tls-crypt nicht mehr n├Âtig. # Wichtig: Man darf hier nur eine Variante verwenden, also entweder tls-crypt (empfohlen) oder tls-auth (veraltet). cipher AES-256-CBC # Verschl├╝sselung festlegen. Weitere ├╝ber: "openvpn --show-ciphers" ;compress lz4-v2 # optional: Komprimierung der Daten vor der ├ťbertragung. ;push "compress lz4-v2" # Aus Sicherheitsgr├╝nden sollte man die Komprimierung nicht aktivieren. user nobody # Einschr├Ąnken der Rechte auf dem Server -> die Sicherheit erh├Âhen. group nogroup persist-key persist-tun status /var/log/openvpn/openvpn-status.log # Logfile mit den aktuellen Verbindungen. # Optional: Separates logging. Bitte beachten, hier nur einen Eintrag aktivieren: ;log /var/log/openvpn/openvpn.log # Entweder Logging immer in ein neues Logfile. ;log-append /var/log/openvpn/openvpn.log # Oder das Logfile wird immer fortgesetzt. verb 3 # Detailgrad des Logfiles festlegen von 0-9, 2-4 empfohlen, 5-9 nur f├╝r Debug.


  21.
IPv4-Forwarding (routing) aktivieren:
nano /etc/sysctl.conf  # im Terminal/ohne GUI
pluma /etc/sysctl.conf # im Desktop/mit GUI


Hier bei dem folgendem Eintrag das Kommentarzeichen (die Raute '#') am Anfang entfernen:
...
# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1
...


  22.
Um die IP-Forwarding Einstellungen sofort zu ├╝bernehmen verwendet man den folgenden Befehl:
sysctl -p

Alternativ hilft auch ein System-Neustart, z. B. mittels [reboot].

  23.
den Namen der Standard-Netzwerkverbindung herausfinden:
ip route show default
# Zeigt Informationen ├╝ber die Standard-Netzwerkverbindung an.
ip route show default | awk '/default/ {print $5}'
# Ermittelt ├╝ber den 5-ten String den Namen der Standard-Netzwerkverbindung, also z. B. eth0, enp0s3, enp0s10f0 usw.

Erg├Ąnzender Hinweis:
In neueren Virtuellen Umgebungen sind oft folgende Standard-Netzwerkverbindungen gegeben:
enp0s3 unter VirtualBox Oracle.
enp0s10f0 unter Hyper-V Microsoft.
Die hier gezeigte VPN L├Âsung kann man auch unter VirtualBox oder Hyper-V problemlos installieren.

  24.
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 geroutet (hier Beispielsweise an enp0s3).
Die iptable Einstellungen anpassen:
nano /etc/ufw/before.rules 
# im Terminal/ohne GUI
pluma /etc/ufw/before.rules
# im Desktop/mit GUI


Gleich am Anfang nach 'ufw-before-forward' folgendes einf├╝gen:
... #   ufw-before-output #   ufw-before-forward # Hier die folgenden Eintr├Ąge hinzuf├╝gen: *nat :POSTROUTING ACCEPT [0:0] -A POSTROUTING -s 10.8.0.0/8 -o enp0s3 -j MASQUERADE COMMIT ...

Beachtet dabei, dass der Name der Standard-Netzwerkverbindung zum System passen muss.
Setzt hier also den eben ermittelten Namen f├╝r die Standard-Netzwerkverbindung ein.

  25.
In der ufw (Uncomplicated Firewall) muss man das forwarding (das weiterleiten der Netzwerkpakete) erlauben.
Das forwarding aktivieren:
nano /etc/default/ufw 
# im Terminal/ohne GUI
pluma /etc/default/ufw
# im Desktop/mit GUI


Hier den folgenden Wert ├Ą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" # Hier DROP durch ACCEPT ersetzen. ...

Wichtig: Man sollte hier keine weiteren Eintr├Ąge vornehmen und den Eintrag direkt editieren.

  26.
Nun muss man noch die entsprechenden Ports in der ufw (Uncomplicated Firewall) freigeben:
ufw allow 1194/udp
# Beim UDP-Protokoll verwenden oder ...
ufw allow 1194/tcp
# beim TCP-Protokoll Verwenden. Den Port und das verwendete Protokoll ggf. entsprechend anpassen.
ufw allow OpenSSH  
# Optionale Freigabe des SSH-Zugangs (Port 22/TCP).


  27.
Die Einstellungen der Firewall ├╝bernehmen und den Autostart der Firewall beim System-Neustart einschalten:
ufw enable  
# Die Firewall einschalten und den automatischen Start konfigurieren.
ufw status  
# Den Status der Firewall anzeigen (listet auch die eingestellten Regeln auf).
ufw disable
# Die Firewall ausschalten (auch nach reboot, nicht empfohlen).

Tipp: Beachtet dabei, dass andere Dienste wie Samba, Apache, SSH usw. dann ggf. ebenso gesperrt sind.

erg├Ąnzende ufw Befehle (optional):
ufw default deny # Den Standard wieder herstellen (alles verbieten). ufw logging low # Protokollierungslevel einstellen off, low, medium, high und 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, hier die 1. Regel.


  28.
Nun kann man den OpenVPN-Server starten und den Autostart konfigurieren:
systemctl start openvpn@server  
# Den OpenVPN Server starten.
systemctl enable openvpn@server  
# Den automatischen Start beim booten des Systems einschalten.
systemctl status openvpn@server  
# Den aktuellen Status vom OpenVPN Server Dienst anzeigen (pr├╝fen ob der Server l├Ąuft).
Beenden mit der Taste: q.
systemctl restart openvpn@server
# Den OpenVPN Server Dienst neu starten um Änderungen zu übernehmen (optional).
systemctl stop openvpn@server    
# Den OpenVPN Server Dienst beenden.


Das Journal kann man wie folgt ansehen (optional):
journalctl -xe
# Insbesondere hilfreich bei Fehlern.
Beenden mit der Taste: q.


  29.
Testen ob der VPN-Tunnel steht (optional):
ip addr show tun0

Wenn der VPN-Tunnel bereit steht sollte man eine Ausgabe in der Art erhalten:
13: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100 link/none inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::7488:52fa:144d:463/64 scope link stable-privacy valid_lft forever preferred_lft forever


Ebenso kann man das syslog/openvpn.log Pr├╝fen (optional):
tail -F /var/log/syslog
# Standardm├Ą├čig Protokolliert OpenVPN die Ausgaben im syslog.
tail -F /var/log/openvpn/openvpn.log
# Falls man das separate Logging in der server.conf aktiviert hat.



Die Client Konfiguration erstellen:


  30.
Als n├Ąchstes erstellt man einen neuen Ordner wo dann die Client Konfigurationen gespeichert werden:
mkdir -pv ~/client/files
# In diesem Ordner liegen sp├Ąter alle .ovpn Zertifikate der Clients.


  31.
Die externe/zugewiesene IP-Adresse vom Provider (Internet-Zugang) herausfinden.
curl https://ctaas.de/curl_ip.php
# Hinweis: Eine dauerhafte Verf├╝gbarkeit dieses Dienstes wird nicht garantiert.

In der Standardausgabe (im Terminal) wird hier die vom Provider aktuell zugewiesene IP-Adresse ausgegeben (diese ist f├╝r die Server-Einwahl wichtig).

Kurze Erkl├Ąrung:
Das Script unter https://ctaas.de/curl_ip.php enth├Ąlt nur das folgende kurze PHP-Script:
<?php echo ''.$_SERVER['REMOTE_ADDR']; ?>

Beachtet dabei: Eine dauerhafte Verf├╝gbarkeit dieses Dienstes wird nicht garantiert.
Hostet diesen Dienst (dieses Script) bitte selbst, wenn ihr diesen Dienst ├Âfter ben├Âtigt.

Die eben ermittelte IP-Adresse sollte man nur verwenden, wenn man eine feste (statische) IP-Adresse vom Provider zugewiesen bekommt.
Also wenn die IP-Adresse bei jeder Einwahl (jeden Tag) immer gleich ist.
Erh├Ąlt man vom Provider bei jeder Internet-Einwahl eine andere, neue (dynamische) IP-Adresse zugewiesen,
dann muss man einen DynDNS-Dienst wie z. B. noip.com verwenden um die Einwahl zum Server zu gew├Ąhrleisten.

  32.
Die Beispieldatei kopieren:
cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf ~/client/client.conf


  33.
Die client.conf bearbeiten:
nano ~/client/client.conf          
# im Terminal/ohne GUI
nohup pluma ~/client/client.conf &
# im Desktop/mit GUI


Die client.conf Datei wie folgt anpassen (beachtet die blauen Kommentare bzw. die optimierten Versionen danach):
# Achtung: Diese Zeile muss man nur bei der Verwendung vom UDP-Protokoll hinzuf├╝gen. fragment 1200 # Der Eintrag muss 1:1 mit dem Eintrag in der server-Konfigurationsdatei server.conf ├╝bereinstimmen. # Die folgenden zwei Eintr├Ąge muss man nur bei Linux Clients aktivieren: # script-security 2 # up /etc/openvpn/update-resolv-conf # down /etc/openvpn/update-resolv-conf ############################################## # Sample client-side OpenVPN 2.0 config file # # for connecting to multi-client server. # # # # This configuration can be used by multiple # # clients, however each client should have # # its own cert and key files. # # # # On Windows, you might want to rename this # # file so it has a .ovpn extension # ############################################## # Specify that we are a client and that we # will be pulling certain config file directives # from the server. client # Use the same setting as you are using on # the server. # On most systems, the VPN will not function # unless you partially or fully disable # the firewall for the TUN/TAP interface. ;dev tap dev tun # Windows needs the TAP-Win32 adapter name # from the Network Connections panel # if you have more than one. On XP SP2, # you may need to disable the firewall # for the TAP adapter. ;dev-node MyTap # Are we connecting to a TCP or # UDP server? Use the same setting as # on the server. ;proto tcp proto udp # Das Protokoll muss 1:1 mit der Angabe in der server.conf ├╝bereinstimmen. # Optional: proto tcp/udp4/tcp4 # udp4/tcp4 bedeutet dabei, dass das entsprechende Protokoll nur ├╝ber IPv4 genutzt wird. # The hostname/IP and port of the server. # You can have multiple remote entries # to load balance between the servers. remote my-server-1 1194 # Statt my-server-1 tr├Ągt man hier die ;remote my-server-2 1194 # eigene statische IP-Adresse (x.x.x.x) oder die eigene DynDNS-Kennung (xyz.noip.com) ein. # 1194 ist die Angabe des Ports, dieser muss 1:1 mit der Angabe in der server.conf ├╝bereinstimmen. # Choose a random host from the remote # list for load-balancing. Otherwise # try hosts in the order specified. ;remote-random # Keep trying indefinitely to resolve the # host name of the OpenVPN server. Very useful # on machines which are not permanently connected # to the internet such as laptops. resolv-retry infinite # Legt die Anzahl der Wiederholungen fest, # wenn die Aufl├Âsung des remote hosts fehlschl├Ągt (infinite = unendlich viele). # Most clients don't need to bind to # a specific local port number. nobind # Downgrade privileges after initialization (non-Windows only) ;user nobody ;group nogroup # Diese zwei Eintr├Ąge darf man nur bei Linux Clients aktivieren. # Try to preserve some state across restarts. persist-key persist-tun # If you are connecting through an # HTTP proxy to reach the actual OpenVPN # server, put the proxy server/IP and # port number here. See the man page # if your proxy server requires # authentication. ;http-proxy-retry # retry on connection failures ;http-proxy [proxy server] [proxy port #] # Wireless networks often produce a lot # of duplicate packets. Set this flag # to silence duplicate packet warnings. ;mute-replay-warnings # SSL/TLS parms. # See the server config file for more # description. It's best to use # a separate .crt/.key file pair # for each client. A single ca # file can be used for all clients. ca ca.crt cert client.crt key client.key # Hier wird auf die Zertifikatsdateien verwiesen (ggf. die Pfade anpassen). # Eventuell vorhandene f├╝hrende Kommentarzeichen (Rautezeichen #) entfernen. # Verify server certificate by checking that the # certicate has the correct key usage set. # This is an important precaution to protect against # a potential attack discussed here: # http://openvpn.net/howto.html#mitm # # To use this feature, you will need to generate # your server certificates with the keyUsage set to # digitalSignature, keyEncipherment # and the extendedKeyUsage to # serverAuth # EasyRSA can do this for you. remote-cert-tls server # If a tls-auth key is used on the server # then every client must also have the key. tls-auth ta.key 1 # Select a cryptographic cipher. # If the cipher option is used on the server # then you must also specify it here. # Note that v2.4 client/server will automatically # negotiate AES-256-GCM in TLS mode. # See also the ncp-cipher option in the manpage cipher AES-256-CBC # Die Angabe muss 1:1 mit der Angabe in der server.conf ├╝bereinstimmen. # Enable compression on the VPN link. # Don't enable this unless it is also # enabled in the server config file. #comp-lzo # Veraltete Variante (nicht mehr empfohlen). ;compress lz4-v2 # Optional: Komprimierung der Daten vor der ├ťbertragung (neue Version, den Eintrag ggf. hinzuf├╝gen). # Wichtig: Aus Sicherheitsgr├╝nden sollte man die Komprimierung nicht aktivieren. # Set log file verbosity. verb 3 # Silence repeating messages ;mute 20

Erg├Ąnzender Hinweis: Dies ist die original mitgelieferte client.conf Datei. Die Datei wurde mit einigen Kommentaren erg├Ąnzt.
Beachtet dabei: Es wurden hier nur die notwendigen Änderungen für eine funktionierende VPN-Verbindung angepasst.
├ťbernehmt f├╝r eine erh├Âhte Sicherheit die Anpassungen aus den folgenden optimierten Konfigurationen.


Optimierte client.conf mit dem UDP-Protokoll (f├╝r Copy & Paste):
## Zusammengefasste client.conf UDP-Version mit kurzen Kommentaren mit allen wichtigen Parametern und Anpassungen f├╝r mehr Sicherheit. ## fragment 1200 # Paketfragmentierung f├╝r UDP. Bei UDP unbedingt hinzuf├╝gen. auth-nocache # Das Zertifikatspasswort nicht im RAM zwischenspeichern. auth SHA512 # Die HMAC-Authentication wurde aus Sicherheitsgr├╝nden von SHA1 (Standard) auf SHA512 erh├Âht. verify-x509-name server name # Verhindert man-in-the-middle-Attacken. Hier muss man den Common-Name (CN) f├╝r das Serverzertifikat einsetzen. # Hinweis: In diesem Tutorial lautet der Server-CN einfach nur "server". client # Client Konfiguration. dev tun # Routing im OSI Layer 3. proto udp4 # UDP ├╝ber IPv4. remote x.x.x.x 1194 # Hier die ├Âffentliche IP-Adresse (x.x.x.x) oder die DynDNS-Kennung zum VPN-Server sowie den verwendeten Port eingeben. resolv-retry infinite # Den Verbindungsaufbau bei Fehlern unendlich oft wiederholen. Alternativ die Angabe in Sekunden (Zeitdauer der Versuche). nobind ;user nobody # Einschr├Ąnken der Rechte auf dem Server -> die Sicherheit erh├Âhen. Diese Eintr├Ąge sollte man nur f├╝r Linux Clients aktivieren. ;group nogroup persist-key persist-tun ca ca.crt # Pfadangaben zu den Zertifikaten/Schl├╝sseln. cert client.crt key client.key remote-cert-tls server # Verhindert man-in-the-middle Attacken. tls-crypt ta.key # HMAC-Signaturen den Paketen hinzuf├╝gen -> die Sicherheit erh├Âhen. Ersetzt den Parameter 'tls-auth ta.key 1'. # Die fehlende 1 ist so richtig. Auch die Angabe der 'key-direction 1' ist bei tls-crypt nicht mehr n├Âtig. # Wichtig: Man darf hier nur eine Variante verwenden, also entweder tls-crypt (empfohlen) oder tls-auth (veraltet). cipher AES-256-CBC # Verschl├╝sselung festlegen. Weitere ├╝ber: "openvpn --show-ciphers". ;compress lz4-v2 # Optional: Komprimierung der Daten vor der ├ťbertragung. Aus Sicherheitsgr├╝nden sollte man die Komprimierung nicht aktivieren. verb 3 # Detailgrad des Logfiles festlegen von 0-9, 2-4 empfohlen, 5-9 nur f├╝r Debug.


Optimierte client.conf mit dem TCP-Protokoll (f├╝r Copy & Paste empfohlen) ­čĹŹ:
## Zusammengefasste client.conf TCP-Version mit kurzen Kommentaren mit allen wichtigen Parametern und Anpassungen f├╝r mehr Sicherheit. ## auth-nocache # Das Zertifikatspasswort nicht im RAM zwischenspeichern. auth SHA512 # Die HMAC-Authentication wurde aus Sicherheitsgr├╝nden von SHA1 (Standard) auf SHA512 erh├Âht. verify-x509-name server name # Verhindert man-in-the-middle-Attacken. Hier muss man den Common-Name (CN) f├╝r das Serverzertifikat einsetzen. # Hinweis: In diesem Tutorial lautet der Server-CN einfach nur "server". client # Client Konfiguration. dev tun # Routing im OSI Layer 3. proto tcp4 # TCP ├╝ber IPv4. remote x.x.x.x 1194 # Hier die ├Âffentliche IP-Adresse (x.x.x.x) oder die DynDNS-Kennung zum VPN-Server sowie den verwendeten Port eingeben. resolv-retry infinite # Den Verbindungsaufbau bei Fehlern unendlich oft wiederholen. Alternativ die Angabe in Sekunden (Zeitdauer der Versuche). nobind ;user nobody # Einschr├Ąnken der Rechte auf dem Server -> die Sicherheit erh├Âhen. Diese Eintr├Ąge sollte man nur f├╝r Linux Clients aktivieren. ;group nogroup persist-key persist-tun ca ca.crt # Pfadangaben zu den Zertifikaten/Schl├╝sseln. cert client.crt key client.key remote-cert-tls server # Verhindert man-in-the-middle Attacken. tls-crypt ta.key # HMAC-Signaturen den Paketen hinzuf├╝gen -> die Sicherheit erh├Âhen. Ersetzt den Parameter 'tls-auth ta.key 1'. # Die fehlende 1 ist so richtig. Auch die Angabe der 'key-direction 1' ist bei tls-crypt nicht mehr n├Âtig. # Wichtig: Man darf hier nur eine Variante verwenden, also entweder tls-crypt (empfohlen) oder tls-auth (veraltet). cipher AES-256-CBC # Verschl├╝sselung festlegen. Weitere ├╝ber: "openvpn --show-ciphers". ;compress lz4-v2 # Optional: Komprimierung der Daten vor der ├ťbertragung. Aus Sicherheitsgr├╝nden sollte man die Komprimierung nicht aktivieren. verb 3 # Detailgrad des Logfiles festlegen von 0-9, 2-4 empfohlen, 5-9 nur f├╝r Debug.


Client Skript zum Erstellen der .ovpn Datei:


  34.
Konfigurationsdateien zusammenfassen:
Die verschiedenen einzelnen Dateien kann man zu einer Datei zusammenfassen.
Man erstellt daf├╝r am einfachsten folgendes Script:
nano ~/client/make_client_ovpn.sh 
# im Terminal/ohne GUI
pluma ~/client/make_client_ovpn.sh
# im Desktop/mit GUI


Hier folgendes einf├╝gen:
#!/bin/bash # $1 ist der zuerst ├╝bergebene Parameter (der Client-Name). # Dieses Script erzeugt die *.ovpn Datei f├╝r den angegebenen Client. KEY_DIR=~/client/keys OUT_DIR=~/client/files cat ~/client/client.conf > ${OUT_DIR}/$1.ovpn echo -e "<ca> \n $(cat ${KEY_DIR}/ca.crt) \n</ca>" \ "<cert> \n $(cat ${KEY_DIR}/$1.crt) \n</cert>" \ "<key> \n $(cat ${KEY_DIR}/$1.key) \n</key>" \ "<tls-crypt>\n $(cat ${KEY_DIR}/ta.key) \n</tls-crypt>" >> ${OUT_DIR}/$1.ovpn # Hinweis: # Verwendet beim ta.key entweder 'tls-crypt' ab OpenVPN 2.4 oder 'tls-auth' f├╝r alte Versionen.


  35.
Die Client-Konfigurationsdatei (.ovpn) erzeugen:
chmod 700 ~/client/make_client_ovpn.sh
# Das Script ausf├╝hrbar Kennzeichen (nur einmalig n├Âtig).
~/client/make_client_ovpn.sh client02
# Erzeugt f├╝r den User client02 (entsprechend anpassen) die client02.ovpn-Datei.
ls -l ~/client/files/
# Pr├╝fen ob die .ovpn Datei f├╝r den Client erzeugt wurde.

Die erzeugte .ovpn-Datei liegt im
Ordner '~/client/files'.

Die Server Konfiguration ist hiermit abgeschlossen.

Verbindungen protokollieren (optional/empfohlen):


  36.
Um die VPN-Verbindungen zu protokollieren muss man in der server.conf ein noch ein paar Eintr├Ąge hinzuf├╝gen.
Man ├Âffnet daher die server.conf Datei nochmal mit einem Editor:
nano /etc/openvpn/server.conf        
# im Terminal/ohne GUI
nohup pluma /etc/openvpn/server.conf
# im Desktop/mit GUI

Hier f├╝gt man der server.conf Datei die folgende Eintr├Ąge (am einfachsten direkt am Anfang) hinzu:
script-security 2 # Das Ausf├╝hren von Scripten zulassen (wird f├╝rs Logging ben├Âtigt). client-connect /adm/logon.sh # Das angegebene Script wird beim Client-connect auf dem Server gestartet. Erfassung von: verbundenen Clients, Datum, IP usw. client-disconnect /adm/logout.sh # Das Script wird beim Client-disconnect auf dem Server gestartet. Erfassung von: getrennten Clients, Datum, IP, Dauer, Traffic usw.

Hinweis: Bitte beachtet dabei, dass der OpenVPN Server jetzt erst wieder startet, wenn man die hier angegebenen Scripte entspechend angelegt hat.
Folgt also zuerst weiter der Anleitung bevor Ihr den Server neu startet.

  37.
Verzeichnis f├╝r die Logging-Scripte und f├╝r das User-Log erstellen:
mkdir -pv /adm


  38.
Das logon-Script (client-connect) erstellen:
nano  /adm/logon.sh
# im Terminal/ohne GUI
pluma /adm/logon.sh
# im Desktop/mit GUI

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

exit 0


  39.
Das logout-Script (client-disconnect) erstellen:
nano  /adm/logout.sh
# im Terminal/ohne GUI
pluma /adm/logout.sh
# im Desktop/mit GUI

Hier folgendes einf├╝gen:
#!/bin/sh
echo logout, $common_name,
$(date "+%Y-%m-%d, %H:%M"), $trusted_ip, $time_duration, $bytes_sent, $bytes_received >> /adm/userlog.csv.txt

exit 0


Parametererkl├Ąrungen:

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.
Die Dateiendung .txt wurde f├╝r die Logdatei gew├Ąhlt, da die Datei so direkt im Webbrowser einsehbar ist.

  40.
Als n├Ąchstes muss man die Scripte noch ausf├╝hrbar machen:
chmod +x /adm/logon.sh
chmod +x /adm/logout.sh


Wenn man in der server.conf die verst├Ąrkte Sicherheit eingestellt hat, also die Eintr├Ąge 'user nobody' und 'group nobody' aktiviert hat, dann muss man nun noch das Schreiben des Logfiles erm├Âglichen.
Tut man dies nicht, so wird keine userlog.csv.txt Datei angelegt und im Logfile erscheint der Fehler '... cannot create /adm/userlog.csv: Permission denied'.

  41.
Ein leeres Logfile f├╝r die Protokollierung anlegen und die Dateiberechtigungen anpassen:
touch /adm/userlog.csv.txt    
# Eine neue leere Datei anlegen.
chmod 666 /adm/userlog.csv.txt
# Die Dateiberechtigungen setzen.

Wichtig: Wenn man die Datei mal l├Âschen sollte. Dann muss man diese wieder mit diesen Berechtigungen neu anlegen.

  42.
Um die Einstellungen f├╝r die Protokollierung zu ├╝bernehmen muss man den OpenVPN Server nochmals neu starten:
systemctl restart openvpn@server


Hier noch kurz ein Beispiel-Logfile:
logon , client02, 2020-02-04, 13:15, 185.66.194.29 logout, client02, 2020-02-04, 13:16, 185.66.194.29, 29, 5134, 77031 ...


Das Logging ist hier abgeschlossen.

Protokolle im Netzwerk freigeben mit lighttpd (optional):


  43.
Wenn man nun das Logfile t├Ąglich einsehen m├Âchte, dann empfiehlt sich die Installation eines schlanken Webservers.
Aus der vielzahl der verf├╝gbaren Web-Server hat sich lighttpd als bester Kandidat herausgestellt.
lighttpd [1] [2] ist derzeit einer der Top Webserver.
lighttpd wird aktuell aktiv weiter Entwickelt. Die Software ist also aktuell und sicher.
Weiterhin ist der Webserver wie es der Name schon sagt 'light' (leicht). Das bedeutet, der Ressourcenverbrauch ist relativ gering.
Auch die Konfiguration ist deutlich leichter und schlanker zu bewerkstelligen als z. B. bei einem Apache Tomcat Webserver.
Somit spricht also alles f├╝r den lighttpd (meine Empfehlung).

Den Webserver installieren:
sudo apt-get install lighttpd


  44.
Die Webserver Konfiguration anpassen:
nano  /etc/lighttpd/lighttpd.conf
# im Terminal/ohne GUI
pluma /etc/lighttpd/lighttpd.conf
# im Desktop/mit GUI


Hier bei dem markierten Eintrag den Pfad und Dateinamen zum Logfile anpassen:
... server.modules = ( "mod_indexfile", "mod_access", "mod_alias", "mod_redirect", ) server.document-root = "/adm/userlog.csv.txt" server.upload-dirs = ( "/var/cache/lighttpd/uploads" ) server.errorlog = "/var/log/lighttpd/error.log" server.pid-file = "/var/run/lighttpd.pid" server.username = "www-data" server.groupname = "www-data" server.port = 80 ...


  45.
Um die Änderungen zu übernehmen muss man den Webserver neu starten.
Weiterhin muss man um den Zugriff im Netzwerk zu erm├Âglichen noch die Firewall freigeben:
systemctl restart lighttpd
# Den Webserver neu starten.
ufw allow 80/tcp
# Den Webserver in der Firewall freigeben.


Das Logfile sollte nun im Webbrowser ├╝ber http://127.0.0.1 (localhost) am Server direkt bzw. ├╝ber http://x.x.x.x
(hier die lokale Server IP-Adresse anpassen) von ├╝berall im LAN einsehbar sein.
Hier kann man nun jederzeit die verschiedensten Einwahldaten, die Dauer sowie das ├╝bertragene Datenvolumen einsehen.

Zertifikate sperren:


  46.
Ein Client-Zertifikat bzw. Server-Zertifikat sperrt man durch den Aufruf:
cd ~/EasyRSA-v3.0.6
./easyrsa revoke client02

Das sperren mit der Eingabe yes und ENTER best├Ątigen.

Wichtig:
Durch den Aufruf wird das Zertifikat von der Zertifizierungsstelle (CA) wiederrufen.
Der OpenVPN Server selbst, pr├╝ft jedoch nicht ob Clients gesperrt wurden.
Clients haben somit immer noch Zugang zum VPN. Um dies zu korrigieren muss man eine Sperrliste (CRL) auf dem Rechner der Zertifizierungsstelle (CA) erstellen.

  47.
Mit dem folgenden Aufruf erstellt man auf dem PC der Zertifizierungsstelle (CA) die ben├Âtigte
Certificate Revocation List (CRL):
./easyrsa gen-crl


Erzeugt: ~/EasyRSA-v3.0.6/pki/crl.pem

  48.
Die crl.pem Datei in den Ordner /etc/openvpn/ kopieren:
cp ~/EasyRSA-3.06/pki/crl.pem /etc/openvpn/


  49.
Nun muss man noch in der OpenVPN server.conf Datei auf die Certificate Revocation List (crl.pem) verweisen:
nano /etc/openvpn/server.conf 
# im Terminal/ohne GUI
pluma /etc/openvpn/server.conf
# im Desktop/mit GUI

Hier muss man folgende Zeile hinzuf├╝gen:
crl-verify crl.pem # Diese Zeile bevorzugt am Ende (es ist egal wo) hinzuf├╝gen.

Wichtig: Diesen Eintrag darf man erst hinzuf├╝gen wenn mindestens ein Zertifikate gesperrt wurde.
Aktiviert man den Eintrag schon vorher, dann kann man keine Verbindung aufbauen (OpenVPN startet dann nicht mehr).

  50.
Zuletzt muss man OpenVPN neu starten um die gesperrten Zertifikate zu ber├╝cksichtigen:
systemctl restart openvpn@server

Die gesperrten Clients k├Ânnen sich dann nicht mehr verbinden.
Bereits verbundene Clients werden kurz getrennt.

Im Router die Portfreigabe einrichten:


Freigabe im Router einrichten:
Damit der Server auch ├╝ber das Internet erreichbar ist, muss man im [DSL-Router-im-VPN-Server-Netzwerk]
den verwendeten Port [1194] mit dem verwendeten Protokoll [UDP oder TCP] (entsprechend anpassen) auf die interne [IP-Adresse des OpenVPN-Servers] weiterleiten. Man muss also eine Portweiterleitung/Port-Forwarding/Portfreigabe im Router einrichten.
Ich stelle hier zwei Varianten vor, einmal mit einer handels├╝blichen Fritz!Box und einmal mit einem Business LANCOM Router.

  51.
Den Port gibt man in der Fritz!Box 7590 wie folgt frei:
1. Klickt links im Men├╝ auf [Internet] und [Freigaben].
2. Dann auf den Karteireiter [Portfreigaben] klicken und unten rechts auf [Ger├Ąt f├╝r Freigaben hinzuf├╝gen] klicken.
3. W├Ąhlt hier zun├Ąchst bei [Ger├Ąt] euren VPN-Server aus oder gebt die entsprechenden interne IP-Adresse des VPN-Servers manuell ein.
Klickt hier dann unten rechts auf [Neue Freigabe].
4. In dem sich neu ├Âffnenden Fenster stellt man dann folgendes ein:

Anwendung     [Andere Anwendung]
Bezeichnung   [VPN]
Protokoll     [UDP] = hier UDP oder TCP einstellen.
Port an Ger├Ąt [1194] bis Port [1194] = dies ist der Port auf dem der VPN-Server intern lauscht.
Port extern gew├╝nscht [1194] = dies ist der Port ├╝ber den der VPN-Server sp├Ąter extern erreichbar sein soll.
[Ôťô] Freigabe aktivieren

5. Das ganze dann einfach mit [OK] und [├ťbernehmen] speichern.
6. Wenn alles geklappt hat sollte die Portfreigabe jetzt mit einem gr├╝nen Punkt in der ├ťbersicht erscheinen.
Sonstige weitere Routeranpassungen muss man nicht vornehmen.

Zur besseren Verdeutlichung habe ich die Schritte hier noch mal als Animation vorbereitet.
Beachtet auch den Mauszeiger dieser zeigt immer den n├Ąchsten Schritt an.
Animation: FritzBox Portfreigabe f├╝r OpenVPN Einrichten
Hinweise: Dies ist eine Schritt-f├╝r-Schritt-Animation, die Bilder wechseln alle 10 Sekunden automatisch.
Die Animation wird derzeit nur auf Webbrowsern gezeigt die webp Unterst├╝tzen (nicht im Internet-Explorer).


  52.
Das Portforwarding im LANCOM R884VA Router einrichten:
LANCOM Router: Port-Forwarding-Tabelle f├╝r OpenVPN anpassen
Hinweis: In der Testumgebung wurde hier das TCP- und UDP-Protokoll weitergeleitet. Im produktiven Betrieb reicht es wenn man nur das tats├Ąchlich verwendete Protokoll weiterleitet.

Das Port-Forwarding richtet man ├╝ber die folgenden Men├╝punkte ein:
[Konfiguration], [IP-Router], [Maskierung] und [Port-Forwarding-Tabelle]
Hier unten auf [Hinzuf├╝gen] klicken und die entsprechenden Werte eingeben. Der Rest sollte dann klar sein.

Sonstige weitere Routeranpassungen muss man nicht vornehmen.

Die optimale MTU Gr├Â├če ermitteln:


  53.
Wenn man gr├Â├čere Daten ├╝bertragen m├Âchte, dann werden diese nicht am St├╝ck ├╝bertragen sondern in viele kleine Datenpakete (fragmente) verpackt. Die MTU (maximum transmission unit) legt nun fest wie gro├č die jeweiligen TCP/IP-Datenpakete sind.
Die Datenpakete enthalten dabei nicht nur Daten, sondern eine vielzahl von weiteren Informationen (Header-Daten) wie Beispielsweise: Quelle, Ziel, Status, Fragmentierung, Pr├╝fsumme.
Daraus kann man ableiten, je gr├Â├čer der MTU-Wert ist, desto g├╝nstiger wird das Verh├Ąltnis von TCP/IP-Header zu Nutzdaten.
Eine gr├Â├čere MTU w├╝rde die Verbindung somit beschleunigen.

Doch Vorsicht!
Datenpakete die zu gro├č sind werden bei der ├ťbertragung auf Routern (bzw. in der Firewall u. ├Ą.) oft einfach verworfen. Dies trifft vor allem auf verbindungslose UDP-Datenpakete zu.
Zwar k├Ânnten Router zu gro├če Datenpakete entsprechend umfragmentieren. Dies wird aber heutzutage h├Ąufig nicht mehr durchgef├╝hrt, da dies Leistung kostet. Daher werden zu gro├če Pakete in der Regel einfach verworfen.
Das verwerfen von Paketen kann auch unterwegs auf dem Router beim Internetprovider passieren.

Wichtig: Zu hohe MTU/fragment Werte machen die Verbindung daher ggf. instabil.
Bei einem zu hohem MTU-Wert wird die Verbindung zwar meist aufgebaut. Man kann aber oft nicht vern├╝nftig Daten ├╝bertragen.

Typische Symptome sind:

Und all das obwohl die VPN-Verbindung in der Regel nach wie vor steht.

  54.
Wie findet man nun den optimalen MTU-Wert heraus?
Wenn mehrere Verbindungen zur Verf├╝gung stehen (verschiedene Standorte, Mobilfunk, Freifunk usw.) dann testet diese alle.
Beachtet in dem Zuge auch, Routen sind im Internet niemals statisch. ├änderungen auch w├Ąhrend der Laufzeit sind immer m├Âglich.
Man sollte daher von dem ermittelten Maximalwert ggf. auch eine kleine Reservere f├╝r ungeplantes (andere Orte, andere MTU) abziehen.

Beim ermitteln der optimalen MTU beginnt man zun├Ąchst mit einem gr├Â├čeren Wert (1500 bei Standard Ethernet),
diesen verkleinert man nun so lange bis die Pakete nicht mehr fragmentiert werden.
Beachtet dabei, dieser ermittelte Wert ist nur der netto Datenwert (Datenbytes).
Um die optimale MTU zu erhalten f├╝gt man noch 28 Bytes (Header-Bytes) hinzu.
Die Berechnung des optimalen MTU-Wertes (f├╝r IPv4) erfolgt daher wie folgt:

nicht_fragmentierter_Ping_Wert + 28 = optimale MTU

  55.
Test unter Windows:
ping -f -l 1252 1.1 # unter Windows

Parametererkl├Ąrungen:
-f = Pakete nicht fragmentieren (gilt nur f├╝r IPv4).
-l 1252 = Bestimmt die Paketgr├Â├če. Diese kann man anpassen von 68 (Minimum) bis 1500 (Standard Ethernet).
Man beginnt bei 1500 und verkleinert den Wert so lange bis das Datenpaket nicht mehr fragmentiert wird.
Im Freifunk Netz von saar.freifunk.net ist 1252 (Stand 2020-01-14) die gr├Â├čte Paketgr├Â├če (Datenbytes ohne Header).
Wenn man die Verbindung auch Unterwegs (von verschiedenen Standorten aus) nutzen will, dann sollte man die Paketgr├Â├če nicht zu hoch einstellen.
Ich habe daher den MTU-Wert oben im Tutorial auf 1200 gesenkt (meine Empfehlung wenn man UDP verwendet/sehr stabiler Betrieb). Werte bis 1280 sind sicher auch noch f├╝r die meisten Ok. Noch h├Âhere Werte k├Ânnen die eben beschriebenen Probleme verursachen.
1.1 ist hier das Ping-Ziel. 1.1 ist dabei die Kurzform von 1.0.0.1.
Man kann hier auch eine andere beliebige Domainnamen wie z. B. www.ctaas.de verwenden.
Screenshot: ping unter Windows fragmentiert mit DF-Flag
Hinweise: Hier ein Beispiel ping unter einer typischen Windows 10 Installation.
Der erste ping mit einer Paketgr├Â├če von 1465 schl├Ągt hier fehl. Das Datenpaket m├╝sste hier fragmentiert werden. Was jedoch durch den Parameter -f verboten wurde. Die Daten├╝bertragung schl├Ągt also fehl.
Der zweite ping mit einer Paketgr├Â├če von 1464 klappt. Die optimale MTU-Gr├Â├če w├Ąre hier 1492 (1464 Datenbytes + 28 Header-Bytes).
Beachtet hier aber, dass unterwegs wie z. B. in Hotels, bei mobilen und freien Netzen wie z. B. Freifunk der gr├Â├čte nicht fragmentierte MTU-Wert viel kleiner sein kann.
Im Freifunk Netz von saar.freifunk.net ist der gr├Â├čtm├Âgliche MTU Wert z. B. nur 1280 (1252 Datenbytes + 28 Header-Bytes).


Die MTU-Werte vom Windows System anzeigen:
netsh interface ipv4 show interfaces # unter Windows

netsh Screenshot MTU-Werte vom System anzeigen.
Hinweise: Hier ein Beispiel unter Windows 10 mit installiertem VirtualBox Netzwerkadapter.

  56.
Test unter Linux:
ping -c 4 -s 1464 -M do 1.1 # unter Linux

Parametererkl├Ąrungen:
-c 4 = (count) Bestimmt die Anzahl der zu sendenden Pakete.
-s 1464 = (size) Legt die Gr├Â├če der zu sendenden Pakete fest von 68 (Minimum) bis 1500 (Standard Ethernet).
-M do = (pmtudisc_option) Legt die "Path MTU Discovery" variante fest.

Hierbei bedeutet:
do = verbiete ├╝berall die Fragmentierung (auch lokal).
want = F├╝hre "Path MTU Discovery" aus, fragmentiere lokal wenn das Paket zu gro├č ist.
dont = DF nicht setzen.

1.1 ist hier wieder das Ping-Ziel. 1.1 ist dabei die Kurzform von 1.0.0.1.
Man kann hier auch eine andere beliebige Domainnamen wie z. B. www.ctaas.de verwenden.
ping unter Linux optimalen MTU Wert ermitteln
Hinweise: Hier ein Beispiel ping unter Xubuntu 20.04 LTS.
Der erste ping mit einer Paketgr├Â├če von 1465 schl├Ągt hier mit der Meldung: 'ping: lokaler Fehler Nachricht zu lang, ...' fehl.
Das Datenpaket m├╝sste hier fragmentiert werden. Was jedoch durch den Parameter '-M do' verboten wurde. Die Daten├╝bertragung schl├Ągt also fehl.
Beachtet man die Meldung genau, dann f├Ąllt einem auf, dass am Ende bereits die maximale MTU ausgegeben wird, hier 'MTU=1492'
Der zweite ping mit einer Paketgr├Â├če von 1464 klappt. Die optimale MTU-Gr├Â├če w├Ąre hier 1492 (1464 Datenbytes + 28 Header-Bytes).


Die MTU-Werte vom Linux System anzeigen:
ip link  # unter Linux - neue Systeme
ifconfig # unter Linux - ├Ąltere Systeme

ip link MTU Werte unter Linux anzeigen.
Hinweise: Hier ein Beispiel unter Xubuntu 20.04 LTS mit gestartetem OpenVPN Server (tun0 Netzwerkadapter).

Fazit:
Mit dem hier im Tutorial voreingestellten Wert von 1200 (nur bei UDP) habe ich gute Erfahrungen gemacht.
Tendenziell empfehle ich die Verwendung des TCP-Protokolls, da hier weniger Paketverluste auftreten, auch wenn der Paketoverhead bei TCP etwas gr├Â├čer ist.
Denn die TCP-Pakete werden automatisch an die entsprechende Paketgr├Â├če angepasst. Die Geschwindigkeit passt sich somit bei unterschiedlichen Gegebenheiten viel besser an.
Weiterhin muss man bedenken, der Gewschwindigkeitsunterschied zwischen UDP und TCP ist dank moderner Internet-Verbindungen heutzutage kaum noch feststellbar.
Fr├╝her bei langsamen ISDN oder Modem Verbindungen war dies vielleicht noch ausschlaggebend, heutzutage mit GLAN und MBit Verbindungen kann man dies vernachl├Ąssigen.
TCP-Verbindungen sind definitiv stabiler und daher meine Empfehlung.

Abschlie├čende Hinweise:


Facebook 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 und stellt eine Zusammenfassung wichtiger und empfohlener Schritte dar.
Bevor sie eventuell Fragen stellen bitte ich sie die Dokumentation komplett zu lesen.
Hinweise auf Fehler, Anregungen, Danksagungen oder ├Ąhnliches sind immer willkommen.

Alte Tutorial Versionen finden Sie archiviert hier:
OpenVPN tun/NAT : routing : Layer 3 : Protokollierung - gegeigent f├╝r Ubuntu 14.04/14.10 (veraltete Archiv-Version)
OpenVPN tap/NAT : bridging : Layer 2 : Protokollierung - gegeigent f├╝r Ubuntu 14.04/14.10 (veraltete Archiv-Version)

Design:
┬ę Computertechnik Schr├Âder, A. Schr├Âder - Kahla, Impressum