Fix more paragraphs

MA-Inhalt.tex

@@ -192,7 +192,7 @@ Nachdem die VPN-Software für das Vorhaben dieser Arbeit ausgewählt wurde, wird
 Laut \ref{req:users} aus Kapitel~\ref{par:requirements} gehören Beschäftigte und Studierende der Abteilung Informatik in der Größenordnung von etwa 50-500~Benutzern zur Zielgruppe des Dienstes.
 Beschäftigte und Studierende sollen im zeitlichen Rahmen Ihrer Tätigkeiten in der Abteilung Informatik über das VPN Zugriff erhalten.
 
-\paragraph{Methoden zur Benutzerauthentisierung} \label{par:user_auth_methods}
+\paragraph{Methoden zur Benutzerauthentisierung:} \label{par:user_auth_methods}
 OpenVPN ermöglicht die Authentisierung von Benutzern mit den folgenden Methoden:
 \begin{itemize}
 \item Authentisierung mit X.509-Public-Key-Zertifikaten
@@ -201,7 +201,7 @@ OpenVPN ermöglicht die Authentisierung von Benutzern mit den folgenden Methoden
 \end{itemize}
 Somit muss entschieden werden, ob die Authentisierung von VPN-Benutzern über Zertifikate oder über Zugangsdaten in Form von Benutzername und Passwort durchgeführt werden soll.
 
-\paragraph{Authentisierung mit Zugangsdaten} \label{p:auth_cred}
+\paragraph{Authentisierung mit Zugangsdaten:} \label{p:auth_cred}
 Die Verwendung von Zugangsdaten zur Authentisierung bietet dem Benutzer einen hohen Komfort:
 Die Eingabe einer Kombination aus Benutzername und Passwort erfordert keine individuellen Konfigurationen am OpenVPN-Client.
 Zusätzlich ist denkbar, dass bereits existierende Zugangsdaten - wie zum Beispiel das Hochschulkonto des Benutzers - zur Authentisierung verwendet werden könnten.
@@ -218,7 +218,7 @@ Ein weiterer Nachteil ergibt sich dadurch, dass Zugangsdaten zum Zweck der Benut
 Die involvierten Programme erhöhen die Menge des Quellcodes, der aufgrund seiner Position als Angriffsfläche keine Schwachstellen enthalten darf.
 Da die Abwesenheit von Schwachstellen in Quellcode nicht garantiert werden kann, ergibt sich der Verwendung von Zugangsdaten zur Benutzerauthentisierung ein erhöhtes Bedrohungsrisiko.
 
-\paragraph{Authentisierung mit Zertifikaten} \label{p:auth_cert}
+\paragraph{Authentisierung mit Zertifikaten:} \label{p:auth_cert}
 Die Authentisierung von Benutzern anhand von Zertifikaten erfordert den Aufbau und die Verwaltung einer \textit{Public-Key-Infrastructure} (PKI) und bringt somit erst einmal eine Reihe Nachteile mit sich:
 Für die Benutzer ergibt sich ein zusätzlicher Aufwand durch das regelmäßige Beantragen von neuen Zertifikaten, sowie die Notwendigkeit der Anpassung der OpenVPN-Clientkonfiguration.
 Auch für den Systemadministrator ergibt sich dieser zusätzliche Aufwand in Bezug auf die regelmäßige Erneuerung des Serverzertifikats und der \textit{Certificate Revocation List} (CRL).
@@ -233,7 +233,7 @@ Sollte ein privater Schlüssel dennoch kompromittiert werden, besteht jederzeit
 Zusätzlich gilt, dass ein kompromittierter Schlüssel lediglich zur Benutzung des VPN-Dienst berechtigt.
 Dadurch reduziert sich der potentielle Schaden, den ein Angreifer mit einem kompromittierten Schlüssel anrichten könnte.
 
-\paragraph{Wahl der Authentisierungsmethode}
+\paragraph{Wahl der Authentisierungsmethode:}
 Insgesamt bringt die Authentisierung von Benutzern mit Zertifikaten im Vergleich zur Authentisierung auf Basis von Zugangsdaten einen höheren Arbeitsaufwand mit sich.
 Dafür besteht ein reduziertes Bedrohungsrisiko bei kompromittierten privaten Schlüsseln als im Vergleich zu kompromittierten Zugangsdaten, welche gegebenenfalls für weitere Dienste gültig sein können.
 Außerdem ist die Angriffsfläche beim Einsatz von Zertifikaten geringer, da kein zusätzlicher Code in das System integriert wird, durch das Zugangsdaten verarbeitet würden.
@@ -398,7 +398,7 @@ Zusätzlich zeigen die Autoren Aspekte des Wireguard-Protokolls auf, die nicht T
 Die zuvor vorgestellten VPN-Softwarelösungen OpenVPN und Strongswan werden nun in den folgenden Kategorien miteinander verglichen, um im Anschluss die Software zu ermitteln, mit der das Vorhaben dieser Arbeit umgesetzt wird.
 Aufgrund des experimentellen Status von Wireguard wird es für den Aufbau eines produktiv eingesetzten VPN-Servers nicht berücksichtigt.
 
-\paragraph{Kommunikationsprotokolle}
+\paragraph{Kommunikationsprotokolle:}
 OpenVPN kommuniziert über ein eigenes Protokoll auf über UDP (oder in Ausnahmefällen über TCP) auf Port~1194.
 Eine Trennung zwischen Kontrollnachrichten und Datenübertragung erfolgt innerhalb der Software.
 
@@ -407,7 +407,7 @@ Der durch IPsec geschützte Datenverkehr lässt sich daran erkennen, dass in den
 
 Für die Freigabe von IPsec-Datenverkehr in einer Firewall sind somit mehrere Regeln notwendig, während die Freigabe von OpenVPN-Verkehr über UDP-Port~1194 übersichtlicher ausfällt.
 
-\paragraph{Benutzerfreundlichkeit}
+\paragraph{Benutzerfreundlichkeit:}
 OpenVPN steht für Linux/Unix und Windows bereits kompiliert zur Verfügung.
 Für Mac OS wird OpenVPN durch Tunnelblick kompiliert zur Verfügung gestellt.
 Da OpenVPN auf allen Clientbetriebssystemen verfügbar ist, gelten die selben Prinzipien für die Clientkonfiguration auf allen Betriebssystemen.
@@ -423,7 +423,7 @@ Unter Linux kann NetworkManager als grafische Oberfläche für Strongswan verwen
 
 In der Kategorie Benutzerfreundlichkeit schneidet OpenVPN durch die Bereitstellung von vorkompilierter Software und die Verfügbarkeit grafischer Oberflächen besser als Strongswan ab.
 
-\paragraph{Verfügbarkeit des Quellcode}
+\paragraph{Verfügbarkeit des Quellcode:}
 Der Quellcode von OpenVPN ist inklusive der durch OpenVPN verwendeten Bibliotheken, wie zum Beispiel OpenSSL, öffentlich verfügbar.
 Auch der Quellcode von Strongswan ist einschließlich des Quellcode aller durch Strongswan eingesetzten Bibliotheken öffentlich verfügbar.
 
@@ -432,7 +432,7 @@ Der Kernel des eingesetzten Betriebssystems gehört somit auch zur Menge der ein
 Die Verfügbarkeit des Quellcodes des Kernels hängt vom verwendeten Betriebssystem ab und ist somit nicht in jedem Fall garantiert.
 Damit wird die Forderung nach ausschließlich quelloffener VPN-Software nicht erfüllt.
 
-\paragraph{Plattformabhängigkeit}
+\paragraph{Plattformabhängigkeit:}
 Sowohl OpenVPN als auch Strongswan sind für alle in \ref{req:clientos} und \ref{req:serveros} genannten Betriebssysteme verfügbar.
 Sollten Sicherheitslücken innerhalb von beiden Softwareprojekten bekannt werden, können diese in vergleichbarer Zeit geschlossen werden und auf Client- und Serverrechnern gleichermaßen installiert werden.
 
@@ -447,7 +447,7 @@ Ebenso sind unterschiedliche Reaktionszeiten auf auftretende Sicherheitslücken
 Insgesamt kann für VPN 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}
+\paragraph{Komplexität:}
 Im Betrieb besteht OpenVPN aus einem laufenden Programm, das über eine Konfigurationsdatei alle für den Betrieb notwendigen Informationen erhält.
 Eine Konfigurationsdatei für OpenVPN besteht aus einer zeilenweisen Auflistung von Optionen, die das OpenVPN-Programm als Argumente akzeptiert.
 Alle Optionen werden in der Manpage von OpenVPN (nach Meinung des Autors) ausführlich und leicht verständlich erklärt und sollten für Einsteiger mit Grundkenntnissen in Bezug auf Netzwerke und Linux kein Hindernis darstellen.
@@ -459,7 +459,7 @@ Zusätzlich enthalten die Konfigurationsdateien durch Schweifklammern abgegrenzt
 Durch diese Konstrukte ist es beispielsweise möglich, Standardwerte für eine logische IPsec-Verbindung zu definieren, diese später als Grundlage für eine andere IPsec-Verbindung zu verwenden und bei Bedarf Teile der zuvor definierten Parameter zu überschreiben.
 Die verschiedenen Konfigurationsdateien werden in ihren eigenen Manpages detailliert und technisch erläutert, wobei das zusätzlich notwendige Fachwissen für IPsec für einen Einsteiger (nach Meinung des Autors) ein unbequemes Hindernis darstellen kann.
 
-\paragraph{Zusammenfassung und Auswahl}
+\paragraph{Zusammenfassung und Auswahl:}
 In diesem Abschnitt wurden OpenVPN und Strongswan als Lösungen für die Umsetzung eines VPN gegenübergestellt.
 Dabei hat sich gezeigt, dass OpenVPN in den Kategorien Plattformabhängigkeit, Verfügbarkeit des Quellcode, Komplexität und Benutzerfreundlichkeit im Vergleich zu Strongswan besser abschneidet.
 Dadurch ist OpenVPN besser für die Umsetzung eines VPN-Dienst geeignet, der die in Kapitel~\ref{par:requirements} genannten Anforderungen erfüllt.
@@ -498,7 +498,7 @@ Aufgrund des Installationsprozess und den in EasyRSA Version~3.0.5 enthaltenen V
 Bevor mit EasyRSA~3.0.5 eine CA aufgebaut werden kann, muss die Konfiguration von EasyRSA an die Bedürfnisse der CA angepasst werden.
 Die anzupassenden Parameter werden in diesem Abschnitt beschrieben und die dazu getroffenen Entscheidungen erläutert.
 
-\paragraph{Vorgaben}
+\paragraph{Vorgaben:}
 Die folgenden Vorgaben für die CA wurden in Absprache mit dem Auftraggeber und Erstprüfer dieser Arbeit festgelegt:
 Das Wurzelzertifikat soll für 20 Jahre gültig sein.
 Ausgestellte Clientzertifikate sollen für Beschäftigte 5 Jahre lang gültig sein, für Studierende 2 Jahre lang.
@@ -506,7 +506,7 @@ Ausgestellte Serverzertifikate sollen 5 Jahre lang gültig sein.
 In den ausgestellten Benutzerzertifikaten soll der volle Name und die Hochschul-E-Mail-Adresse des Benutzers abgelegt werden.
 Die Serverzertifikate sollen den \textit{vollqualifizierten Domainnamen} (FQDN) enthalten.
 
-\paragraph{Auswahl des Kryptosystems}
+\paragraph{Auswahl des Kryptosystems:}
 EasyRSA unterstützt sowohl RSA-Schlüsselpaare als auch Schlüsselpaare auf Basis der \textit{Elliptische-Kurven-Kryptografie} (EKK).
 Somit stehen RSA und EKK als Kryptosystems zur Auswahl, mit denen die CA aufgebaut werden kann.
 
@@ -530,13 +530,13 @@ Auch auf die im Vergleich zu RSA effizienteren Verfahren in EKK zum Signieren un
 
 Laut BSI kann RSA über das Jahr 2023 hinaus eingesetzt werden \cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}.
 
-\paragraph{Festlegen der Schlüssellänge}
+\paragraph{Festlegen der Schlüssellänge:}
 Im nächsten Schritt wird die Länge der RSA-Schlüssel festgelegt, die in allen durch die CA ausgestellten Zertifikaten zum Einsatz kommen soll.
 OpenVPN empfiehlt eine Schlüssellänge von mindestens 2048 Bit: \textit{\enquote{OpenVPN will migrate to 'preferred' as default in the future. Please ensure that your keys already comply.}}.
 Das Profil \enquote{preferred} ist dabei wie folgt definiert: \textit{\enquote{SHA2 and newer, RSA 2048-bit+, any elliptic curve.}} \cite[Aus][Option \texttt{--tls-cert-profile}]{man:openvpn}.
 Das BSI empfiehlt den Schlüssellängen von mindestens 3000 Bit für Verwendungen über das Jahr 2023 hinaus \cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}.
 
-\paragraph{Metadaten}
+\paragraph{Metadaten:}
 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.
@@ -553,7 +553,7 @@ Für alle weiteren Felder werden folgende Vorgaben festgelegt:
 \texttt{Org}: \enquote{Hochschule Hannover},
 \texttt{OU}: \enquote{Abteilung Informatik}.
 
-\paragraph{Gültigkeitsdauer der CRL}
+\paragraph{Gültigkeitsdauer der CRL:}
 OpenVPN kann die von der CA ausgestellte \textit{Certificate Revocation List} (CRL) benutzen kann um die Gültigkeit von Clientzertifikaten zu überprüfen.
 Da dieses Feature benutzt werden soll, sind Einstellungen in Bezug auf die CRL für diese Arbeit relevant. 
 
@@ -571,7 +571,7 @@ Für den Betrieb der Zertifizierungsstelle wird in Absprache mit dem IT-Team ein
 Unter Berücksichtigung der Anforderung \ref{req:serveros} aus Kapitel~\ref{par:requirements} wird Debian~9 nach den Vorgaben des IT-Teams auf der virtuellen Maschine installiert.
 Das EasyRSA-Paket wird unterhalb von \texttt{/root} ausgepackt und für den Einsatz als CA für den VPN-Dienst konfiguriert.
 
-\paragraph{Berechtigungen}
+\paragraph{Berechtigungen:}
 Durch die Platzierung der CA unterhalb von \texttt{/root} kann nur der Benutzer \texttt{root} die Zertifizierungsstelle benutzen und auf den privaten Schlüssel des Wurzelzertifikats zugreifen.
 Lokale Benutzer können über \texttt{sudo} für die Benutzung der CA berechtigt werden.
 Zusätzlich können direkte Zugriffsrechte durch die Verwendung von SSH-Schlüsseln für den \texttt{root}-Login verteilt werden.
@@ -579,7 +579,7 @@ Zusätzlich können direkte Zugriffsrechte durch die Verwendung von SSH-Schlüss
 Gleichzeitig beinhaltet der \texttt{root}-Benutzer eine Warnfunktion: Die Berechtigung für Zugriffe auf die CA impliziert viel Verantwortung und verlangt sorgfältiges Vorgehen bei der Benutzung der CA.
 Auch die regelmäßige Kontrolle aller erteilten Berechtigungen und die überlegte Erteilung von Berechtigungen soll zusätzlich motiviert werden.
 
-\paragraph{Öffentliche Daten}
+\paragraph{Öffentliche Daten:}
 VPN-Benutzer benötigen bestimmte Dateien, um die CA zu verwenden.
 Neben dem Wurzelzertifikat der CA und der aktuellen CRL benötigen Benutzer eine vorkonfigurierte Version des EasyRSA-Pakets zur Erzeugung von Zertifikatsanträgen.
 Um diese Daten zur Verfügung zu stellen, wird auf der virtuellen Maschine der Webserver \texttt{apache2} installiert, welcher ausschließlich das für diesen Zweck erzeugte Verzeichnis \texttt{/public} über HTTP ausliefern soll.
@@ -591,7 +591,7 @@ Gleichzeitig signalisieren die Dateirechte, dass die Inhalte unter \texttt{/publ
 
 Die Veröffentlichung von Konfigurationsdateien und Anleitungen für VPN-Benutzer kann über diesen Webserver ebenfalls stattfinden.
 
-\paragraph{Aktualisierung der CRL}
+\paragraph{Aktualisierung der CRL:}
 Damit der OpenVPN-Server immer Zugriff auf eine aktuelle CRL hat, wird ein Cronjob via \texttt{crontab -e} unter dem Benutzer \texttt{root} eingerichtet, der über die EasyRSA-Skripte eine neue CRL erzeugt und diese anschließend mit den zuvor erläuterten Dateirechten in \texttt{/public} platziert.
 
 Details zur Benutzung der CA sind in dem Dokument \enquote{Dokumentation der Zertifizierungsstelle für den IPv6-VPN-Dienst} im Anhang dieser Arbeit zu finden.
@@ -604,7 +604,7 @@ Die Konfiguration des Betriebssystems erfolgt dabei nach den Vorgaben des IT-Tea
 
 \section{Konfiguration des Serverbetriebssystems} \label{sct:config_server}
 
-\paragraph{Netzwerkkonfiguration}
+\paragraph{Netzwerkkonfiguration:}
 Da der OpenVPN-Dienst aus dem Internet heraus erreichbar sein soll, wird der Server an das DMZ-Netz angeschlossen.
 Das IT-Team hat dafür insgesamt vier IPv4- und IPv6-Adressen vergeben, um den Server und den darauf existierenden Dienst logisch zu trennen.
 Über die vergebenen IPv4- und IPv6-Hostadressen kann der physische Server angesprochen werden, um zum Beispiel für administrative Aufgaben eine SSH-Sitzung zu dem Server aufzubauen.
@@ -615,7 +615,7 @@ Für IPv4 wurde das private Netz \texttt{10.2.0.0/16} durch das IT-Team vergeben
 Für IPv6 wurde das Netz \texttt{2001:638:614:1750::/64} vergeben, welches durch die Firewall der Abteilung Informatik an die zuvor vergebene IPv6-Dienstadresse geroutet wird.
 Damit VPN-Clients über IPv4 mit dem Abteilungsnetz kommunizieren können, wird der private IPv4-Adressbereich für die VPN-Clients durch den VPN-Server via \textit{Network Address Translation} (NAT) auf die IPv4-Dienstadresse übersetzt.
 
-\paragraph{Failover}
+\paragraph{Failover:}
 Durch die Unterscheidung zwischen physischem Server und Dienst bezüglich der vergebenen IP-Adressen kann ein manuelles Failover zwischen zwei identisch konfigurierten Servern (in diesem Beispiel A und B genannt) durchgeführt werden.
 Um bei einem Defekt von Server~A ein Failover auf den Server~B durchzuführen, werden zunächst die IP-Dienstadressen auf A deaktiviert.
 Anschließend werden die IP-Dienstadressen auf B aktiviert.
@@ -624,7 +624,7 @@ Sollte dieses Verfügbarkeitsniveau nicht mehr ausreichen, so muss lediglich ein
 Damit ist ein Parallelbetrieb von zwei OpenVPN-Diensten möglich, die sich in der Konfiguration nur durch ihre IP-Dienstadresse und das verwendete IPv6-Netz für VPN-Clients unterscheiden.
 In der OpenVPN-Clientkonfiguration können beide VPN-Dienste eingetragen werden, sodass die Clients bei Ausfall eines Servers automatisch eine Sitzung mit dem zweiten Server aufbauen können.
 
-\paragraph{Lokale Firewall}
+\paragraph{Lokale Firewall:}
 In Absprache mit dem Erstprüfer dieser Arbeit wurde die folgende Firewall-Richtlinie für den VPN-Server geplant und wird unter Nutzung von \texttt{iptables} umgesetzt.
 Diese lokale Richtlinie wird durch die Firewall der Abteilung Informatik ergänzt.
 
@@ -649,7 +649,7 @@ Alle Details zu Installation und Betrieb des VPN-Servers sind in dem Dokument \e
 Nach Einrichtung des Servers wird in diesem Schritt die Konfiguration des OpenVPN-Servers im Detail erläutert.
 Nähere Informationen zu den verwendeten Optionen können in \cite[][]{man:openvpn} nachgeschlagen werden.
 
-\paragraph{Erreichbarkeit des Dienstes}
+\paragraph{Erreichbarkeit des Dienstes:}
 Laut Anforderung~\ref{req:dualstack} aus Kapitel~\ref{par:requirements} soll der VPN-Dienst über IPv4 und IPv6 aus dem Internet erreichbar sein.
 Als Ausgangspunkt dafür wird der DNS-Name des VPN-Dienst verwendet, der auf die IPv4- und IPv6-Dienstadresse zeigt.
 
@@ -676,7 +676,7 @@ remote vpn-test.inform.hs-hannover.de 1194
 Das UDP-Protokoll verwendet, weil das TCP-Protokoll in Kombination mit stark ausgelasteten Netzwerken oder beim Transport von TCP-Paketen durch den VPN-Tunnel Performanceeinbußen verursachen kann \cite[][Option \texttt{--proto}]{man:openvpn}.
 Bei Interesse kann eine detaillierte Analyse der Probleme der TCP-in-TCP-Situation in \cite[][]{analysis:tcpintcp} nachgelesen werden.
 
-\paragraph{OSI-Layer des VPN-Tunnels}
+\paragraph{OSI-Layer des VPN-Tunnels:}
 OpenVPN unterstützt den Aufbau eines VPN-Tunnels auf OSI-Layer~2 und OSI-Layer~3.
 Im Prinzip könnten beide Tunnelvarianten für den Anwendungsfall dieser Arbeit verwendet werden.
 Da im Rahmen dieser Arbeit nur die Erreichbarkeit über IPv4 und IPv6 relevant ist, wird ein VPN-Tunnel auf OSI-Layer~2 nicht benötigt.
@@ -686,7 +686,7 @@ Aus diesen Gründen fällt die Wahl auf VPN-Tunnel auf OSI-Layer~3 und wird mit
 dev tun
 \end{lstlisting}
 
-\paragraph{IP-Adressen im VPN-Tunnel}
+\paragraph{IP-Adressen im VPN-Tunnel:}
 Die vom IT-Team vergebenen IP-Adressbereiche für VPN-Clients werden durch den OpenVPN-Server an die Clients vergeben.
 Für das vergebene IPv4-Netz wurde berücksichtigt, dass bis zu 500 VPN-Clients mit IP-Adressen versorgt werden können, indem ein \texttt{/16}-Block vergeben wurde.
 In der Konfiguration des Clients sind keine Anweisungen notwendig.
@@ -699,7 +699,7 @@ server-ipv6 2001:638:614:1750::/64
 Mit \texttt{topology subnet} wird festgelegt, dass die IPv4-Adressvergabe so durchgeführt werden soll, als wären alle VPN-Clients mit dem VPN-Server in einem Subnetz.
 Anschließend werden mit \texttt{server} und \texttt{server-ipv6} die IP-Netze festgelegt, die an die VPN-Clients vergeben werden sollen.
 
-\paragraph{Erreichbare Netze im VPN}
+\paragraph{Erreichbare Netze im VPN:}
 In der \textbf{Serverkonfiguration} werden \texttt{push}-Anweisungen eingetragen, über die IPv4- und IPv6-Routen an die VPN-Clients bekannt gegeben werden können.
 Ein VPN-Client ist durch die Anweisung \texttt{client} implizit auch mit dem Parameter \texttt{pull} konfiguriert, sodass die vom Server über \texttt{push} bekanntgegebenen Optionen übernommen werden.
 Zunächst werden alle IPv4-Routen bekanntgegeben:
@@ -726,7 +726,7 @@ push "route-ipv6 2001:638:614:1744::/64 2001:638:614:1750::1"	# experimental ipv
 \end{lstlisting}
 Da der Platzhalter \texttt{vpn\_gateway} für IPv6-Routen leider nicht funktioniert, muss hier die IPv6-Adresse des VPN-Servers im VPN direkt als Ziel der Route angegeben werden.
 
-\paragraph{Kompression}
+\paragraph{Kompression:}
 Auf die Kompression des VPN-Datenverkehrs wird aufgrund der in diesem Absatz aufgeführten Punkte verzichtet.
 Am 03.06.2018 wurden Hinweise in der Manpage von OpenVPN eingefügt\footnote{\url{https://github.com/OpenVPN/openvpn/commit/6795a5f3d55f658fc1a28eb9f3b11d1217e3329c}}, in denen vor der Verwendung von Kompression gewarnt wird.
 Diese Hinweise sind in der Manpage von OpenVPN in Version~2.4.6 noch nicht enthalten, da diese Version von den Entwicklern bereits am 19.04.2018\footnote{\url{https://github.com/OpenVPN/openvpn/releases/tag/v2.4.6}} freigegeben wurde.
@@ -734,7 +734,7 @@ Zusätzlich wird in der \enquote{Best Current Practice} RFC~7525 zur Deaktivieru
 
 Auf der DEFCON~26 wurde mit \enquote{VORACLE} ein in diesem Kontext relevanter Angriff auf OpenVPN vorgestellt\footnote{\url{https://media.defcon.org/DEF\%20CON\%2026/DEF\%20CON\%2026\%20presentations/Nafeez/DEFCON-26-Nafeez-Compression-Oracle-attacks-on-VPN-Networks.pdf}}, der auf aktivierter Kompression aufbaut.
 
-\paragraph{Zertifikatgestützte Authentisierung}
+\paragraph{Zertifikatgestützte Authentisierung:}
 Um die in Kapitel~\ref{sct:user_concept} beschriebene Zertifizierungsstelle zur Benutzerauthentisierung zu verwenden und die VPN-Kommunikation nach Anforderung~\ref{req:traffic} aus Kapitel~\ref{par:requirements} abzusichern, wird OpenVPN im TLS-Modus betrieben.
 
 In der \textbf{Clientkonfiguration} wird dafür der Parameter \texttt{tls-client} gesetzt, in der \textbf{Serverkonfiguration} wird analog dazu der Parameter \texttt{tls-server} verwendet.
@@ -758,7 +758,7 @@ Analog dazu wird in der \textbf{Serverkonfiguration} mit dem selben Parameter ve
 remote-cert-tls client
 \end{lstlisting}
 
-\paragraph{Kryptografische Parameter}
+\paragraph{Kryptografische Parameter:}
 Wie in Kapitel~\ref{ssct:openvpn} bereits erläutert wurde, unterscheidet OpenVPN bei der Kommunikation zwischen zwei OpenVPN-Prozessen zwischen Datenkanal für Nutzdaten und Kontrollkanal für Steuernachrichten.
 Während OpenVPN im TLS-Modus über den Kontrollkanal den TLS-Sitzungsaufbau durchführt und den Kontrollkanal anschließend über TLS absichert, wird für den Datenkanal eine separat konfigurierbare, symmetrische Chiffre verwendet.
 Das gemeinsame Geheimnis für den Schutz des Datenkanals wird dabei über den durch TLS geschützten Kontrollkanal ausgetauscht.
@@ -805,7 +805,7 @@ Um zu verhindern, dass eine veränderte Clientkonfiguration zu einer möglicherw
 ncp-disable
 \end{lstlisting}
 
-\paragraph{Sitzungsparameter}
+\paragraph{Sitzungsparameter:}
 VPN-Client und VPN-Server sollen zeitnah reagieren, wenn eine Sitzung durch Verlust der Internetverbindung abbricht.
 Mit \texttt{keepalive} kann in der \textbf{Serverkonfiguration} angegeben werden, in welchem Intervall eine Ping-Nachricht an die Gegenseite geschickt werden soll.
 Ein zweiter Parameter erlaubt die Definition eines Zeitlimits, nachdem dessen Ablauf eine Sitzung für abgebrochen erklärt wird.
@@ -838,7 +838,7 @@ Dadurch kann ein Benutzer den VPN-Zugang auf mehreren Geräten gleichzeitig benu
 duplicate-cn
 \end{lstlisting}
 
-\paragraph{Lokale Sicherheit}
+\paragraph{Lokale Sicherheit:}
 Auf den Betriebssystemen Linux und Mac OS kann OpenVPN nach seinem Start nicht mehr benötigte Berechtigungen abgeben und im Kontext eines lokalen Benutzers weiterlaufen.
 Dies kann in \textbf{Client- und Serverkonfiguration} bewerkstelligt werden.
 OpenVPN kann unter diesen Bedingungen nicht auf bestimmte Ressourcen neuen Zugriffe starten.
@@ -860,7 +860,7 @@ Mit der folgenden Option kann OpenVPN gezwungen werden, ein solches Passwort nic
 auth-nocache
 \end{lstlisting}
 
-\paragraph{Protokollierung}
+\paragraph{Protokollierung:}
 Um die Gesprächigkeit von OpenVPN zu steuern, können in der \textbf{Client- und Serverkonfiguration} die Parameter \texttt{verb} und \texttt{mute} verwendet werden.
 Der Parameter \texttt{verb} steuert dabei den Detailgrad der protokollierten Meldungen über einen Bereit von 0 (keine Meldungen) über 1-4 (normale Meldungen), 5 (Für jedes verarbeitete Paket wird ein Buchstabe in das Log geschrieben) bis hin zu 6-11 (Für Fehlersuche in der Entwicklung).
 Standardmäßig wird der Wert 1 verwendet; der Wert 3 wird für übersichtliche Protokolle mit mehr Informationen empfohlen.
@@ -903,14 +903,14 @@ Allerdings bedeutet die erfolgreiche Inbetriebnahme eines neuen Produktivsystems
 Es lohnt sich jederzeit, die Aktualisierung und Weiterentwicklung eines Dienstes im Auge zu behalten.
 Als Motivation dafür seien mögliche Gewinne in den Punkten IT-Sicherheit, Effizienz, Benutzerfreundlichkeit oder schlicht ein reduzierter Aufwand bei Wartung und Pflege des Dienstes genannt.
 
-\paragraph{Nachfolger OpenVPN~3}
+\paragraph{Nachfolger OpenVPN~3:}
 Während für diesen Dienst OpenVPN ab Version~2.4.0 zum Einsatz kommt, befindet sich mit OpenVPN~3\footnote{\url{https://github.com/OpenVPN/openvpn3}} ein Nachfolger in Entwicklung.
 Der OpenVPN~3 Linux-Client\footnote{\url{https://github.com/OpenVPN/openvpn3-linux}} verfolgt einen modularen Ansatz, bei dem die verschiedenen Module nur mit unbedingt notwendigen Privilegien ausgestattet werden sollen.
 Die Kommunikation zwischen den einzelnen Modulen soll über D-Bus ablaufen\footnote{Siehe \url{https://github.com/OpenVPN/openvpn3-linux/blob/master/README.md}}.
 Zum aktuellen Zeitpunkt (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.
 
-\paragraph{Alternative Wireguard}
+\paragraph{Alternative Wireguard:}
 Wie in Kapitel~\ref{ssct:wireguard} dieser Arbeit bereits erwähnt wurde, ist Wireguard zum aktuellen Zeitpunkt (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.
 Die bisherigen Angaben in Bezug auf Effizienz, Wahl der kryptografischen Parameter und Benutzerfreundlichkeit sprechen nach Meinung des Autors stark dafür, dass ein Umstieg von OpenVPN auf Wireguard vorteilhaft sei.