Fix pagebreaks

MA-Inhalt.tex

@@ -54,7 +54,7 @@ Der Auftrag dieser Arbeit ist die Konzeption und Umsetzung eines neuen VPN-Diens
 Dieser neue VPN-Dienst soll den alten VPN-Dienst ablösen.
 Dafür wird vorausgesetzt, dass der neue VPN-Dienst den Zugang zu allen IPv4-Netzen der Abteilung Informatik ermöglicht, die bisher über den alten VPN-Dienst erreichbar sind.
 Zusätzlich soll der neue VPN-Dienst den Zugang zu allen IPv6-Netzen der Abteilung Informatik ermöglichen, die logisch zu den zuvor genannten IPv4-Netzen gehören.
-
+\newpage
 Teil des Auftrags ist die Erstellung eine Konzepts für die Verwaltung der VPN-Benutzer, sowie die Erstellung eines Konzepts für den Betrieb des neuen VPN-Dienstes.
 Die zur Umsetzung verwendete Software ist nicht vorgegeben und soll anhand der aufgestellten Konzepte, Anforderungen und Rahmenbedingungen ausgewählt werden.
 
@@ -171,7 +171,7 @@ Die Details zur Authentisierung von Benutzern und der Verwaltung autorisierter B
 Vor der Benutherauthentisierung muss sich der VPN-Server gegenüber dem VPN-Client authentisieren, damit bei der Benutzerauthentisierung übertragene Zugangsdaten nur durch den VPN-Server der Abteilung Informatik empfangen und verarbeitet werden.
 Das Ausspähen von VPN-Zugangsdaten durch einen Angreifer wird somit verhindert, weil sich ein Angreifer gegenüber VPN-Clients nicht mehr als VPN-Server der Abteilung Informatik ausgeben kann, ohne sich vorher erfolgreich als VPN-Server zu authentisieren.
 Zusätzlich verhindert diese Maßnahme, dass VPN-Clients eine VPN-Sitzung zu dem VPN-Server eines Angreifers aufbauen können - Angriffe gegen Clientrechner durch den VPN-Tunnel stellen in diesem Kontext keine Bedrohung dar.
-
+\newpage
 Die Authentisierung des VPN-Servers könnte über ein zuvor geteiltes, gemeinsames Geheimnis durchgeführt werden.
 Diese Vorgehensweise ist jedoch nicht sinnvoll, da der VPN-Dienst für mindestens 50-500 Benutzer ausgelegt wird.
 Unter diesem Umstand ist ein allen Benutzern bekanntes, gemeinsames Geheimnis für einen Angreifer leichter in Erfahrung zu bringen, je mehr Benutzer dieses Geheimnis kennen.
@@ -272,7 +272,7 @@ Würde man VPN-Benutzer über ihr Hochschulkonto authentisieren, so hätte ein A
 Insgesamt bringt die Authentisierung von Benutzern mit Zertifikaten im Vergleich zur Authentisierung auf Basis von Zugangsdaten einen geringeren Arbeitsaufwand mit sich, da der Betrieb einer PKI weniger komplex ist, als der Betrieb eines eigenen Verzeichnisdienstes.
 Gleichzeitig ist die Angriffsfläche für Brute-Force-Angriffe bei einer Authentisierung auf Basis von Zugangsdaten größer als bei Zertifikaten, weil Passwörter im Vergleich zu RSA-Schlüsseln ab 1024~Bit Länge deutlich geringere Komplexität aufweisen, und durch einen Angreifer leichter ausprobiert werden können.
 
-Zusätzlich besteht ein reduziertes Bedrohungsrisiko bei kompromittierten privaten Schlüsseln im Vergleich zu kompromittierten Zugangsdaten, welche gegebenenfalls für weitere Dienste gültig sein könnten, oder deren Passwort für mehrere Dienste durch den Benutzer wiederverwendet wurde.
+Zusätzlich besteht ein reduziertes Bedrohungsrisiko bei kompromittierten privaten Schlüsseln im Vergleich zu kompromittierten Zugangsdaten, welche gegebenenfalls für weitere Dienste gültig sein könnten, oder deren Passwort für mehrere Dienste durch den Benutzer wiederverwendet wurde.\newpage
 Bei der Authentisierung von Zugangsdaten besteht die Möglichkeit, dass zusätzlicher Code in Form von Programmen oder Skripten in die VPN-Software integriert werden muss, womit die Zugangsdaten mit Hilfe eines Verzeichnisdienstes geprüft werden.
 Dadurch erhöht sich nicht nur die potentielle Angriffsfläche, sondern auch die Anzahl an potentiellen Fehlerquellen bei der Übertragung und Verarbeitung der Zugangsdaten.
 
@@ -300,7 +300,7 @@ Das Mitarbeiter-Netz wird für diesen Zweck als vertrauenswürdig eingestuft, we
 
 Die öffentlichen Daten der PKI sollen via HTTP über einen Webserver zur Verfügung gestellt werden.
 Zu den öffentlichen Daten der PKI gehören beispielsweise das Wurzelzertifikat oder die \textit{Certificate Revocation List} (CRL).
-Dieser Webserver soll auf dem PKI-Server installiert werden und soll die PKI-Daten im Mitarbeiter-Netz der Abteilung anbieten.
+\newpage Dieser Webserver soll auf dem PKI-Server installiert werden und soll die PKI-Daten im Mitarbeiter-Netz der Abteilung anbieten.
 Weitere Daten, wie zum Beispiel Anleitungen oder Konfigurationsdateien zur Installation und Einrichtung von VPN-Clients für den VPN-Dienst sollen ebenfalls über diesen Webserver den VPN-Benutzern zur Verfügung gestellt werden.
 Damit die VPN-Serverkomponente die aktuelle CRL der PKI über HTTP abrufen kann, soll in der Firewall der Abteilung Informatik eine entsprechende Freigabe eingerichtet werden.
 
@@ -319,7 +319,7 @@ Abbildung~\ref{fig:vpn_service_concept} zeigt das Konzept des VPN-Dienstes logis
 
 In der Abbildung sind zunächst die drei Netzwerk-Sicherheitszonen zu sehen, die in Kapitel~\ref{cpt:netarchitecture} bereits vorgestellt wurden: Das Internet, das DMZ-Netz und das Mitarbeiter-Netz.
 Die Firewall der Abteilung Informatik agiert als Router zwischen diesen Netzen und lässt lediglich die Kommunikation zwischen den Netzen zu, die laut Regelwerk der Firewall erlaubt ist.
-
+\newpage
 Im Mitarbeiter-Netz soll der CA-Server platziert werden, auf dem die PKI eingerichtet wird.
 Damit die öffentlichen Daten der PKI, so wie Anleitungen und Konfigurationsdateien, abrufbar sind, wird auf dem CA-Server zusätzlich eine Webserver-Komponente eingeplant.
 
@@ -375,7 +375,7 @@ IPsec ist ein Internetstandard, der kryptografische Sicherheit für IPv4 und IPv
 Das beinhaltet unter anderem Vertraulichkeit übertragener Daten durch den Einsatz von Verschlüsselung, Authentisierung von Paketen durch Prüfung von Prüfsummen, und Schutz vor Replay-Angriffen \cite[Vergleich][Kapitel 2.1]{RFC4301}.
 Mit IPsec können Richtlinien definiert werden, ob und wie Datenverkehr von einem Host zu einem anderen Host geschützt werden soll.
 Zum Schutz des Datenverkehrs können die Protokolle AH und ESP benutzt werden, die in den folgenden Absätzen kurz vorgestellt werden.
-
+\newpage
 Das Protokoll \textit{IP Authentication Header} (AH) ist in \cite[][]{RFC4302} definiert und ermöglicht den Versand von authentisierbaren Paketen an eine Gegenstelle.
 Vor dem Versand wird über den Inhalt der beim Transport unveränderlichen Felder des IP-Pakets eine Prüfsumme gebildet.
 Die Gegenstelle kann die Prüfsumme des empfangenen Pakets berechnen und mit der im Paket enthaltenen Prüfsumme abgleichen \cite[Siehe][Kapitel 3.3.3]{RFC4302}.
@@ -403,7 +403,7 @@ Die Protokolle AH und ESP definieren selbst kein Verfahren zum Aushandeln von ve
 Auch der Austausch gemeinsamer Geheimnisse beziehungsweise Schlüsselmaterial wird nicht definiert.
 Dafür wird das \textit{Internet Key Exchange Protocol} (IKE) in Version~2 (IKEv2) verwendet.
 An dieser Stelle kommt Strongswan als IKEv2\footnote{Internet Key Exchange Protokoll Version~2, definiert in \cite[][]{RFC7296}}-Dienst zum Einsatz.
-
+\newpage
 Strongswan kann über IKEv2 authentisiert und verschlüsselt mit IKEv2-Gegenstellen kommunizieren.
 Dabei werden mit der Gegenstelle Schlüssel- und Konfigurationsparameter ausgehandelt beziehungsweise ausgetauscht, anhand derer Strongswan IPsec-Verbindungen im Kernel des Host-Betriebssystems konfigurieren kann.
 Die Verarbeitung des durch IPsec geschützten Datenverkehrs über die Protokolle AH oder ESP wird jedoch direkt im IPsec-Stack des Kernels abgewickelt.
@@ -431,7 +431,7 @@ Gleichzeitig senden sich Client und Server \enquote{keepalive}-Nachrichten durch
 
 Im \enquote{TLS Mode} wird über den Kontrollkanal eine TLS-Sitzung aufgebaut, in der Chiffren und Schlüssel ausgetauscht werden, mit denen der Datenkanal geschützt werden soll.
 Mit dem Aufbau dieser TLS-Sitzung ist die Authentisierung von Client und Server mit X.509-Public-Key-Zertifikaten\footnote{X.509-Public-Key-Zertifikate werden oft als \enquote{SSL-Zertifikate} bezeichnet} möglich.
-Zusätzlich kann \textit{Perfect Forward Secrecy} (PFS) durch Einsatz des Diffie-Hellman-Verfahren für den Schlüsselaustausch erreicht werden \cite[Vergleich][Abschnitt \enquote{TLS Mode Options}]{man:openvpn}.
+\newpage Zusätzlich kann \textit{Perfect Forward Secrecy} (PFS) durch Einsatz des Diffie-Hellman-Verfahren für den Schlüsselaustausch erreicht werden \cite[Vergleich][Abschnitt \enquote{TLS Mode Options}]{man:openvpn}.
 Außerdem können die zur Verschlüsselung des Datenkanals ausgehandelten Schlüssel während der Sitzung mehrfach erneuert werden.
 
 Im \enquote{Static Key Mode} wird beiden Prozessen beim Start ein zuvor geteiltes gemeinsames Geheimnis als Parameter gegeben, mit dem der Datenkanal zwischen den beiden Prozessen symmetrisch verschlüsselt wird \cite[][Option \texttt{--secret}]{man:openvpn}.
@@ -455,7 +455,7 @@ Durch diesen Schritt wird Wireguard weniger komplex; Verwundbarkeiten, wie sie b
 
 Ein Netzwerkteilnehmer wird durch seinen öffentlichen Schlüssel eindeutig identifiziert.
 Dieser öffentliche Schlüssel ist ein Punkt auf der elliptischen Kurve \texttt{Curve25519}, welcher mit 32~Bytes beschrieben wird \cite[][Abschnitt I]{wireguard:intro}.
-Der Austausch von Sitzungsschlüsseln wird durch das Diffie-Hellman-Verfahren auf elliptischen Kurven durchgeführt, dessen Ergebnisse mit einer Schlüsselableitungsfunktion auf Basis eines HMAC (HKDF) gestreckt werden \cite[][Abschnitt I]{wireguard:intro}.
+\newpage Der Austausch von Sitzungsschlüsseln wird durch das Diffie-Hellman-Verfahren auf elliptischen Kurven durchgeführt, dessen Ergebnisse mit einer Schlüsselableitungsfunktion auf Basis eines HMAC (HKDF) gestreckt werden \cite[][Abschnitt I]{wireguard:intro}.
 Für die Verschlüsselung des VPN-Verkehrs wird die in \cite{RFC7539} konstruierte \textit{Authenticated Encryption with Associated Data} (AEAD)-Chiffre aus ChaCha20 und Poly1205 verwendet \cite[][Abschnitt I]{wireguard:intro}.
 Als Hashfunktion kommt BLAKE2s \cite[][]{blake2s:definition} zum Einsatz \cite[][Abschnitt I]{wireguard:intro}.
 
@@ -480,7 +480,7 @@ Es wird eine Analysemethode gewählt, die eine Trennung von Handshake-Protokoll
 Diese Trennung wird durch minimale Veränderungen am Wireguard-Protokoll herbeigeführt \cite[][Abschnitt 1, \enquote{Our Contributions}]{wireguard:analysis}.
 Im Ergebnis sind durch die Analyse keine Schwachstellen am Wireguard-Protokoll gefunden worden.
 Allerdings wird gezeigt, dass eine saubere Trennung zwischen Schlüsselaustausch und Datentransport im Wireguard-Protokoll benötigt wird.
-Zusätzlich werden Aspekte des Wireguard-Protokolls aufgezeigt, die nicht Teil der Analyse waren, und es wird empfohlen, Wireguard weiteren Analysen zu unterziehen \cite[][Abschnitt 6]{wireguard:analysis}.
+\newpage Zusätzlich werden Aspekte des Wireguard-Protokolls aufgezeigt, die nicht Teil der Analyse waren, und es wird empfohlen, Wireguard weiteren Analysen zu unterziehen \cite[][Abschnitt 6]{wireguard:analysis}.
 
 
 \section{Vergleich der Softwarekandidaten} \label{sct:compare_vpn_software}
@@ -506,7 +506,7 @@ Je nach Plattform stehen unterschiedliche grafische Oberflächen zur Verfügung,
 Strongswan hingegen muss für die Benutzung unter Windows zuvor vom Anwender mit Hilfe einer MinGW\footnote{Minimalist GNU for Windows, siehe \url{http://www.mingw.org}}-W64-Umgebung kompiliert werden \cite{strongswan:onwindows}.
 Die Mac-Version kann über \texttt{brew}\footnote{\enquote{The missing package manager for macOS}, siehe \url{https://brew.sh}} bezogen werden \cite{strongswan:onmac}.
 Für Linux/Unix stehen kompilierte Versionen zur Verfügung.
-Wurde Strongswan auf den jeweiligen Clientbetriebssystemen erfolgreich installiert, so läuft die Konfiguration wie bei OpenVPN auf allen Betriebssystemen nach den selben Prinzipien ab.
+\newpage Wurde Strongswan auf den jeweiligen Clientbetriebssystemen erfolgreich installiert, so läuft die Konfiguration wie bei OpenVPN auf allen Betriebssystemen nach den selben Prinzipien ab.
 Da unter Mac OS und Windows bereits IPsec-Funktionalität durch das Betriebssystem zur Verfügung gestellt wird, wird seitens Strongswan keine grafische Oberfläche entwickelt.
 Unter Linux kann NetworkManager als grafische Oberfläche für Strongswan verwendet werden.
 
@@ -532,7 +532,7 @@ Wie bereits in Kapitel~\ref{ssct:strongswan} erläutert wurde, kann Strongswan n
 Die in \ref{req:clientos} und \ref{req:serveros} genannten Betriebssysteme enthalten unterschiedliche Kernel, die jeweils eine individuelle Implementierung von IPsec enthalten.
 Aus diesem Grund kann nicht garantiert werden, dass die verschiedenen Kernel die aktuellen Empfehlungen \cite[Aktuell aus][]{RFC8221} bezüglich kryptografischer Algorithmen zeitnah gemeinsam unterstützen.
 Ebenso sind unterschiedliche Reaktionszeiten auf auftretende Sicherheitslücken zu erwarten, die einen oder mehrere Kernel betreffen.
-Insgesamt kann für VPNs auf Basis von IPsec nicht garantiert werden, dass ein einheitliches Sicherheitsniveau über die verschiedenen Betriebssysteme aufrecht erhalten werden kann.
+\newpage Insgesamt kann für VPNs auf Basis von IPsec nicht garantiert werden, dass ein einheitliches Sicherheitsniveau über die verschiedenen Betriebssysteme aufrecht erhalten werden kann.
 Erschwerend kommt hinzu, dass Strongswan auf Windows keine Unterstützung für die Einrichtung virtueller IP-Adressen bietet, welche bei IPsec-VPNs im Tunnelmodus zum Einsatz kommen \cite[][Abschnitt \enquote{Important notes}]{strongswan:onwindows}.
 
 \paragraph{Komplexität:}
@@ -576,7 +576,7 @@ Die Notwendigkeit zum selbstständigen Entwickeln von Skripten zum Erreichen ein
 Das über Debian~9 beziehbare Paket enthält EasyRSA in Version~2.3.x.
 Die heute (01.10.2018) über GitHub\footnote{\url{https://github.com/OpenVPN/easy-rsa/releases/tag/v3.0.5}} beziehbare Version von EasyRSA trägt die Nummer 3.0.5.
 EasyRSA wurde in Version~3 von Grund auf neu geschrieben und verfügt über ein im Vergleich zu EasyRSA Version~2 vereinfachtes Benutzerinterface, welches nun von einem einzigen Kommandozeilenbefehl zur Verfügung gestellt wird.
-Zusätzlich hinzugekommen sind neue Features, wie etwa die Unterstützung des \textit{Elliptische-Kurven-Kryptosystems} (EKK), Unterstützung von UTF-8, oder die Verwendung von AES256 zum verschlüsselten Speichern von privaten Schlüsseln\footnote{Vergleich \url{https://github.com/OpenVPN/easy-rsa/blob/v3.0.5/ChangeLog}}.
+\newpage Zusätzlich hinzugekommen sind neue Features, wie etwa die Unterstützung des \textit{Elliptische-Kurven-Kryptosystems} (EKK), Unterstützung von UTF-8, oder die Verwendung von AES256 zum verschlüsselten Speichern von privaten Schlüsseln\footnote{Vergleich \url{https://github.com/OpenVPN/easy-rsa/blob/v3.0.5/ChangeLog}}.
 
 Die Installation von EasyRSA wird durch das Kopieren sämtlicher Dateien von EasyRSA in ein neues Verzeichnis durchgeführt.
 Eine auf diese Weise eingerichtete CA kann aus diesem Grund nicht durch den Debian-Paketmanager mit Updates versorgt werden.
@@ -655,7 +655,7 @@ Durch die Verwendung von DHE kann \textit{Perfect Forward Secrecy} (PFS) gewähr
 
 Die gewählte TLS-Chiffre stammt aus der Liste der empfohlenen Chiffren in RFC~7525 \cite[][Abschnitt 4.2]{RFC7525}.
 Laut BSI kann diese Chiffre durch Dienstanbieter optional unterstützt werden \cite[][Kapitel 3]{bsi:tls-checkliste}.
-Die eng verwandte Chiffre TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 setzt PFS mit ECDHE anstelle von DHE um, und wird laut BSI für Dienstanbieter empfohlen \cite[][Kapitel 3]{bsi:tls-checkliste}, wodurch sich unter der Voraussetzung, dass ECDHE und DHE einen vergleichbar sicheren Schlüsselaustausch ermöglichen, auch für die gewählte TLS-Chiffre eine Eignung für die langfristige Verwendung ableiten lässt.
+\newpage Die eng verwandte Chiffre TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 setzt PFS mit ECDHE anstelle von DHE um, und wird laut BSI für Dienstanbieter empfohlen \cite[][Kapitel 3]{bsi:tls-checkliste}, wodurch sich unter der Voraussetzung, dass ECDHE und DHE einen vergleichbar sicheren Schlüsselaustausch ermöglichen, auch für die gewählte TLS-Chiffre eine Eignung für die langfristige Verwendung ableiten lässt.
 Diese Voraussetzung wird durch einen aktuellen Bericht\footnote{Dieser Bericht löst einen vorangegangenen Bericht der ENISA \cite{enisa:algorithms} von 2014 ab \cite[][Kapitel 1, \enquote{Executive Summary}]{ecrypt-csa:algorithms}.} der ECRYPT-CSA\footnote{Siehe \url{http://www.ecrypt.eu.org/csa/}} vom Februar 2018 untermauert \cite[][Kapitel 8.1]{ecrypt-csa:algorithms}.
 
 \textbf{Anmerkung}: TLS-Chiffren mit Ephemeral-Diffie-Hellman-Verfahren auf Basis von elliptischen Kurven (ECDHE) können im Rahmen dieser Arbeit nicht verwendet werden.
@@ -673,7 +673,7 @@ Gelingt es einem Angreifer den Kontrollkanal zu dechiffrieren, so erhält er Ken
 Gelingt es einem Angreifer den Datenkanal zu dechiffrieren, so erhält er Kenntnis über alle übertragenen Daten.
 Die Vertraulichkeit der über den VPN-Dienst übertragenen Daten hängt demnach gleichermaßen von der Verschlüsselung beider Kanäle ab.
 Der logische Schluss daraus ist die Verwendung der selben Chiffre zur Verschlüsselung beider Kanäle.
-
+\newpage
 \paragraph{Statische Konfiguration kryptografischer Parameter:}
 Damit alle VPN-Sitzungen die zuvor erläuterten, kryptografischen Parametern einhalten, werden diese Parameter in Client- und Serverkonfiguration hinterlegt.
 OpenVPN unterstützt die Aushandlung der verwendeten TLS-Chiffre für den Kontrollkanal, sowie der Chiffre für den Datenkanal.
@@ -699,7 +699,7 @@ Da die Aktualisierung der VPN-Clientsoftware im Einzelfall nicht unmittelbar erf
 Aufgrund des damit verbundenen Arbeitsaufwands wird erwartet, dass insgesamt mehr neue Chiffren aktiviert werden, als alte Chiffren deaktiviert werden.
 Die Prüfung, ob alle erlaubten Chiffren noch ausreichend sicher sind, wird dadurch aufwändiger; die Wahrscheinlichkeit, dass eine unsichere Chiffre übersehen wird, steigt.
 Für einen Angreifer steigt die Angriffsfläche, da ältere VPN-Clients durch die Wahl einer älteren Chiffre von modernen Clients unterschieden werden könnten.
-Gleichzeitig können in einer VPN-Sitzung unterschiedliche Chiffren für den Schutz von Kontroll- und Datenkanal ausgehandelt werden, sodass die effektive Vertraulichkeit von der jeweils schwächeren Chiffre bestimmt wird.
+\newpage Gleichzeitig können in einer VPN-Sitzung unterschiedliche Chiffren für den Schutz von Kontroll- und Datenkanal ausgehandelt werden, sodass die effektive Vertraulichkeit von der jeweils schwächeren Chiffre bestimmt wird.
 
 Insgesamt bringt der Ansatz zur flexiblen Aushandlung und Anpassung von Chiffren mehr kontinuierlichen Arbeitsaufwand mit sich, während die statische Konfiguration der Chiffren für Klarheit in Bezug auf die verwendeten Parameter sorgt und im schlimmsten Fall, dessen Eintrittswahrscheinlichkeit als hinreichend gering eingeschätzt wird, eine große Konfigurationsanpassung für alle VPN-Benutzer erfordert.
 Deshalb wird die statische Konfiguration aller kryptografischen Parameter, und der damit verbundene Verzicht auf jegliche dynamische Aushandlung beim Sitzungsaufbau, für den VPN-Dienst gewählt.
@@ -751,7 +751,7 @@ Damit die CA für 20 Jahre sicher betrieben werden kann, wird auf Basis dieser E
 EasyRSA unterstützt zwei Varianten, um den Inhalt des \texttt{Subject}-Felds eines X.509-Zertifikat zu füllen.
 Im Modus \enquote{cn\_only} wird nur der \texttt{Common Name} in das \texttt{Subject}-Feld gesetzt.
 Im Modus \enquote{org} wird ein \texttt{Distinguished Name} in dem \texttt{Subject}-Feld abgelegt, der die Felder \texttt{Country}, \texttt{Province}, \texttt{City}, \texttt{Org}, \texttt{OU}, \texttt{email} und \texttt{CN} beinhaltet.
-
+\newpage
 Laut Vorgaben soll der volle Name und die Hochschul-E-Mail-Adresse der Benutzer in den Clientzertifikaten abgelegt werden.
 Somit muss EasyRSA auf den Modus \enquote{org} eingestellt werden.
 Für Clientzertifikate wird festgelegt, dass der volle Name im Feld \texttt{Common Name} abgelegt wird, und die E-Mail-Adresse im Feld \texttt{Email Address}.
@@ -910,7 +910,7 @@ key inform/aither.inform.hs-hannover.de.key
 dh inform/dh.pem
 crl-verify inform/crl.pem
 \end{lstlisting}
-
+\newpage
 Um zu unterbinden, dass Clientzertifikate zum Betrieb eines OpenVPN-Servers verwendet werden, wird mit dem Parameter \texttt{remote-cert-tls} in der \textbf{Clientkonfiguration} angegeben, dass von der Gegenseite ein Zertifikat mit \enquote{Serverrolle} präsentiert werden muss:
 \begin{lstlisting}
 remote-cert-tls server
@@ -1105,7 +1105,7 @@ Der OpenVPN~3 Linux-Client\footnote{\url{https://github.com/OpenVPN/openvpn3-lin
 Die Kommunikation zwischen den einzelnen Modulen soll über D-Bus ablaufen\footnote{Siehe \url{https://github.com/OpenVPN/openvpn3-linux/blob/master/README.md}}.
 Heute (13.10.2018) ist OpenVPN~3 noch nicht bereit für den produktiven Einsatz.
 Sollte sich das jedoch ändern, könnte im Rahmen einer neuen Arbeit untersucht werden, welche Verbesserungen OpenVPN~3 mit sich bringt, und ob ein Umstieg von OpenVPN~2.4.0 auf OpenVPN~3 lohnenswert ist.
-
+\newpage
 \paragraph{Alternative Wireguard:}
 Wie in Kapitel~\ref{ssct:wireguard} dieser Arbeit bereits erwähnt wurde, ist Wireguard heute (13.10.2018) noch in einem experimentellen Zustand.
 Sobald Wireguard für den produktiven Einsatz geeignet ist und Clientsoftware für alle benötigten Betriebssysteme zur Verfügung steht, kann in einer neuen Arbeit untersucht werden, ob die sich die Ablösung des VPN-Dienstes aus dieser Arbeit mit einer neuen Lösung auf Basis von Wireguard lohnt.