masterthesis/MA-Inhalt.tex

\chapter{Einleitung} \label{cpt:introduction}
Die Menge der noch verfügbaren IPv4-Adressen neigt sich dem Ende zu.
Laut Angaben des RIPE NCC\footnote{RIPE Network Coordination Centre} vom Juni 2018 sind noch ungefähr 8,63 Millionen IPv4-Adressen verfügbar\footnote{\url{https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph}, abgerufen am 03.06.2018}.
Das entspricht etwa der Hälfte der nutzbaren Host-Adressen eines \texttt{/8}-Blocks.
Betrachtet man die Vergabegeschwindigkeit von IPv4-Adressen aus den letzten drei Jahren, so könnte man den Zeitpunkt der Erschöpfung von IPv4-Adressen zwischen 2019 und 2021 vermuten\footnote{\url{https://ipv4.potaroo.net/}, abgerufen am 03.06.2018}.

Vor diesem Hintergrund wird IPv6 als Nachfolger von IPv4 zunehmend verwendet:
Immer mehr Internetdienste können über IPv6 erreicht werden, und auch die Internetanbieter stellen ihren Kunden IPv6-fähige Internetanschlüsse zur Verfügung.
Der Anteil von Suchanfragen, die über IPv6 an Google gestellt wurden, hat von 5,84\% am 1. Januar 2015 auf 21,11\% am 1. Juni 2018 zugenommen\footnote{\url{https://www.google.com/intl/en/ipv6/statistics.html}, abgerufen am 03.06.2018}.
Am AMS-IX\footnote{Amsterdam Internet Exchange}, dem Internet-Austauschpunkt in Amsterdam, hat sich der Durchfluss von IPv6-Verkehr in den letzten 12 Monaten im Durchschnitt von etwa 55~Gbit/s im August 2017 auf etwa 85~Gbit/s im Mai 2018 gesteigert\footnote{\url{https://ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic},\\abgerufen am 03.06.2018}.

An der Hochschule Hannover ist die Abteilung Informatik Vorreiter in der Erprobung von IPv6.
Seit Anfang 2018 ist das Netz der Abteilung über IPv6 direkt an das Internet angebunden.
Damit ist die Voraussetzung gegeben, um Netzwerkgeräte für IPv6 zu konfigurieren und bestehende Netzwerkdienste auch über IPv6 anzubieten.

Beschäftigten und Studierenden der Abteilung Informatik steht ein VPN-Dienst zur Verfügung, um Zugang in das Netz der Abteilung aus dem Internet heraus zu erhalten.
Bisher ist dieser Dienst nur über IPv4 erreichbar und ermöglicht den Zugang in das Abteilungsnetz ausschließlich über IPv4.

\newpage
In dieser Masterarbeit soll ein neuer, IPv6-fähiger VPN-Dienst konzipiert werden, der die Idee des bisherigen IPv4-VPN-Dienst aufgreift.
Der genaue Arbeitsauftrag dahinter wird in Kapitel~\ref{cpt:the_task} erläutert.
Dort werden alle Anforderungen und Rahmenbedingungen erfasst, die bei der Konzeption des neuen VPN-Dienst berücksichtigt werden müssen.
Im Anschluss wird die zukünftige Umgebung des VPN-Dienstes in Kapitel~\ref{cpt:netarchitecture} vorgestellt: Die Netzarchitektur der Abteilung Informatik inklusive Firewallkonzept.
Auf Basis der daraus gewonnenen Informationen werden dann in Kapitel~\ref{cpt:service_concept} Konzepte für den VPN-Dienst und dessen Benutzerverwaltung abgeleitet.
Anhand der Konzepte wird in Kapitel~\ref{cpt:choosing_software} dann nach Software zur Realisierung des VPN-Dienstes gesucht, mögliche VPN-Software präsentiert und die Auswahl begründet.
Anhand der ausgewählten Software wird das in Kapitel~\ref{cpt:service_concept} vorgestellte VPN-Konzept in Kapitel~\ref{cpt:openvpn_concept} auf die gewählte VPN-Software zugeschnitten.
Im Anschluss wird in Kapitel~\ref{cpt:implement_vpn_server} der VPN-Dienst installiert und konfiguriert.
In Kapitel~\ref{cpt:implement_ca} wird die Benutzerverwaltung umgesetzt.
In Kapitel~\ref{cpt:conclusion} werden die Ergebnisse und gewonnen Erkenntnisse dieser Arbeit bewertet und Ideen für weiterführende Arbeiten aufgeführt.

Die während der Durchführung dieser Arbeit erzeugten Dokumente sind dem Anhang beigefügt.


\chapter{Arbeitsauftrag} \label{cpt:the_task}
Die Abteilung Informatik betreibt einen VPN-Dienst auf Basis von OpenVPN, der von Beschäftigten und Studierenden benutzt werden kann, um über das Internet auf das Netz der Abteilung Informatik zuzugreifen.
Dieser Dienst ist bisher nur über IPv4 erreichbar, und ermöglicht auch nur über IPv4 den Zugriff auf das Netz der Abteilung Informatik durch das VPN.

\paragraph{VPN:} \label{par:explain_vpn}
Hinter der Abkürzung \enquote{VPN} verbirgt sich der Begriff \textit{Virtual Private Network}.
Ein VPN ist ein \textit{virtuelles} Netz zwischen mindestens zwei Teilnehmern eines physischen Netzes.
Es ist virtuell, weil es nicht für alle Teilnehmer des physischen Netzes existiert, sondern nur für die VPN-Teilnehmer logisch existiert.

Ein VPN ist aus mehreren Gründen ein \textit{privates} Netz:
Zunächst muss man von dem VPN Kenntnis haben, um daran teilnehmen zu können.
Zusätzlich kann die Authentisierung gegenüber einem oder mehreren VPN-Teilnehmern als Zugangsvoraussetzung bestehen.
Die Verschlüsselung des VPN-Datenverkehrs vor dessen Übertragung über ein physisches Netz ist ebenfalls ein Grund, weshalb ein VPN ein privates Netz ist.

Verschickt ein VPN-Teilnehmer ein Datenpaket über das VPN an einen anderen VPN-Teilnehmer, so wird das Paket vom Sender in ein neues Datenpaket gekapselt und über das physische Netz an den anderen VPN-Teilnehmer verschickt.
Der Empfänger erhält das gekapselte Datenpaket über das physische Netz und kann das über das VPN übertragene Datenpaket daraus herausholen.
Das VPN schafft somit eine direkte, logische Verbindung zwischen beiden Teilnehmern, während die eigentliche Datenübertragung über das physische Netz geleitet wird.

\paragraph{Auftrag:}
Der Auftrag dieser Arbeit ist die Konzeption und Umsetzung eines neuen VPN-Dienstes, der sowohl über IPv4 und IPv6 erreichbar ist und den Zugriff auf das Abteilungsnetz über diese beiden Protokolle ermöglicht.
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.

\paragraph{Ermittelte Anforderungen:} \label{par:requirements}
In diesem Abschnitt werden alle Anforderungen und Rahmenbedingungen vorgestellt, die bei der Konzeption des neuen VPN-Dienst berücksichtigt werden müssen.
Es handelt sich hier um Vorgaben, die im persönlichen Gespräch mit dem Auftraggeber und Erstprüfer dieser Arbeit ermittelt wurden.

\begin{enumerate}[label=Anf\arabic*]
\item \label{req:dualstack} \textbf{Dual-Stack-Betrieb:} Der VPN-Dienst soll aus dem Internet über IPv4 und IPv6 erreichbar sein und auch innerhalb des VPN diese beiden Protokolle anbieten.
\item \label{req:routing} \textbf{VPN-interner Datenverkehr:} Nur die internen Netzbereiche der Abteilung Informatik sollen für Benutzer über das VPN erreichbar sein.
Das betrifft alle Sicherheitszonen außer dem Internet.
Neue Verbindungen aus allen Sicherheitszonen in das VPN-Netz sind verboten.
VPN-Clients dürfen nicht im VPN untereinander kommunizieren.
VPN-Clients dürfen durch das VPN nicht auf NFS\footnote{\textit{Network File System} (NFS) ist ein Dienst für netzwerkübergreifenden Dateiaustausch}-Dienste zugreifen.
\item \label{req:traffic} \textbf{VPN-externer Datenverkehr:} Die Kommunikation zwischen VPN-Client und VPN-Server soll authentisiert und vertraulich stattfinden.
\item \label{req:users} \textbf{Benutzer:} Der VPN-Dienst soll nur von autorisierten Beschäftigten und Studierenden aus der Abteilung Informatik benutzt werden können.
Die Benutzer des VPN-Dienstes sollen durch die Administratoren des VPN-Dienstes einfach verwaltet werden können.
Der Dienst soll 50-500 VPN-Benutzer bedienen können.
\item \label{req:serveros} \textbf{Betrieb des VPN-Servers:} Die Serverkomponente des VPN-Dienstes soll auf einer aktuellen Version von Debian (9 oder höher) betrieben werden.
\item \label{req:clientos} \textbf{Betrieb der VPN-Clients:} Die VPN-Clientsoftware soll für aktuelle Versionen gängiger Betriebssysteme zur Verfügung stehen.
Darunter fallen Microsoft Windows 10 (Version~1709 oder höher), Apple MAC OS (ab Version~10.13) und Linux-Distributionen (ab Kernel Version~3.10).
\item \label{req:logging} \textbf{Betriebsprotokoll:} In Bezug auf die \textit{Datenschutzgrundverordnung} (DSGVO) soll der VPN-Dienst im Regelbetrieb keine personenbezogenen Daten protokollieren.
\item \label{req:finance} \textbf{Finanzieller Rahmen:} Für die Umsetzung des VPN-Dienstes muss auf kostenfreie Software und die bestehende Infrastruktur (Server, Netze, \dots) der Abteilung Informatik zurückgegriffen werden, da keine finanziellen Mittel für den Erwerb einer VPN-Lösung zur Verfügung stehen.
\end{enumerate}


\chapter{Netzarchitektur der Abteilung Informatik} \label{cpt:netarchitecture}
Das Netz der Abteilung Informatik wird durch eine Firewall von Netzen außerhalb der Abteilung getrennt.
Zu den Netzen außerhalb der Abteilung gehören (1) das Netz der Hochschule Hannover und (2) das Internet.

An der Firewall sind zwei lokale Netze angeschlossen: (1) Die \textit{Demilitarisierte Zone} (DMZ) und (2) das interne Abteilungsnetz, welches durch einen zentralen Switch in mehrere \textit{virtuelle Netze} (VLANs) unterteilt wird.
Zusätzlich sind die Netze des Netzwerklabors und des IT-Sicherheitslabors über je einen eigenen Router an den Switch angeschlossen.
Eine Skizze der Netztopologie mit den für diese Arbeit relevanten Teilen zeigt Abbildung~\ref{fig:topology_simple}.
\begin{figure}[ht]
\centering
% Trim, da diese Grafik als PDF auf DIN A4 vorliegt.
\frame{\includegraphics[trim=75 540 75 75,clip,width=\textwidth]{img/Netzwerktopologie_simpelv2_with_addresses.pdf}}
\caption{Skizze der Netztopologie der Abteilung Informatik}
\label{fig:topology_simple}
\end{figure}

\label{pos:firewall}
Die im Netz der Abteilung Informatik verwendeten Netze werden im Firewallkonzept als verschiedene Sicherheitszonen betrachtet.
Für diese Arbeit sind die folgenden Zonen relevant:

\paragraph{Internet:}
Das \enquote{Internet} bezeichnet den Bereich außerhalb des Netzes der Abteilung Informatik.
Diese Zone umfasst neben dem Internet auch das Netz der Hochschule Hannover inklusive eduroam.
Verbindungen in das Internet sind aus allen Zonen, außer der DMZ, erlaubt.
Verbindungen aus dem Internet werden nur zu Diensten in der DMZ (wie zum Beispiel VPN), sowie zu dem SSH-Dienst im Mitarbeiter-Netz zugelassen.

\paragraph{DMZ:}
Von der Abteilung Informatik betriebenen Server stellen in diesem Netz Dienste zur Verfügung, die sowohl innerhalb der Abteilung als auch über das Internet erreichbar sind.
Verbindungen in die DMZ zu Diensten wie VPN sind aus allen anderen Zonen heraus erlaubt.
Verbindungen aus der DMZ in alle anderen Zonen sind verboten, um im Fall eines Sicherheitsvorfalls Angriffe auf alle anderen Zonen zu verhindern.
Eine Ausnahme für dieses Verbot sind Verbindungen vom VPN-Dienst, die in das Mitarbeiter-Netz aufgebaut werden dürfen.

\paragraph{Mitarbeiter-Netz:}
An dieses Netz sind die Rechner aller Beschäftigten der Abteilung Informatik angeschlossen.
Auch die internen Server der Abteilung, wie zum Beispiel Dateiserver oder der SSH-Server, sind an dieses Netz angeschlossen.
Verbindungen in das Mitarbeiter-Netz aus dem Pool-PC-Netz und den Labor-Netzen sind erlaubt.
Außerdem sind Verbindungen von dem VPN-Dienst aus der DMZ in das Mitarbeiter-Netz erlaubt.
Zusätzlich ist der SSH-Server für SSH-Zugriffe aus dem Internet erreichbar.
Verbindungen aus dem Mitarbeiter-Netz sind in alle anderen Zonen erlaubt.

\paragraph{Pool-PC-Netz:}
Enthält die Rechner in allen Poolräumen, die von Studierenden und Mitarbeitern der Abteilung Informatik benutzt werden.
Verbindungen in das Pool-PC-Netz sind aus dem Mitarbeiter-Netz und den Labor-Netzen erlaubt.
Verbindungen aus dem Pool-PC-Netz sind in alle anderen Zonen erlaubt.

\paragraph{Labor-Netze:}
Das Netzwerklabor und das Labor für IT-Sicherheit werden für diese Arbeit unter der Zone \enquote{Labor-Netze} zusammengefasst.
Verbindungen aus den Labornetzen heraus sind in alle anderen Zonen erlaubt.
Verbindungen in die Labornetze sind aus dem Mitarbeiter-Netz und aus dem Pool-PC-Netz heraus erlaubt.

Ein Überblick der erlaubten Verbindungen zwischen den Sicherheitszonen ist in Tabelle~\ref{tab:firewall_zone_access} skizziert.

\begin{table}[ht]
\centering
\caption{Überblick über erlaubte Verbindungen zwischen Sicherheitszonen}
\begin{tabular}{ *{6}{|l}| }
\hline
 & \multicolumn{5}{c|}{\dots in die Zone \dots} \\
Aus der Zone \dots & Internet & DMZ & Mitarbeiter & Pool-PC-Netz & Labor-Netze \\
\hline
Internet			& --- 	& erlaubt	& verboten	& verboten	& verboten	\\
DMZ					& verboten	& ---	& verboten	& verboten	& verboten	\\
Mitarbeiter			& erlaubt	& erlaubt	& ---	& erlaubt	& erlaubt	\\
Pool-PC-Netz		& erlaubt	& erlaubt	& erlaubt	& ---	& erlaubt	\\
Labor-Netze			& erlaubt	& erlaubt	& erlaubt	& erlaubt	& ---	\\
\hline
\end{tabular}
\label{tab:firewall_zone_access}
\end{table}


\chapter{Konzeptphase} \label{cpt:service_concept}
In diesem Abschnitt soll aus dem Arbeitsauftrag aus Kapitel~\ref{cpt:the_task} ein konkretes Vorhaben entstehen.
Dafür wird in diesem Kapitel das Konzept für den VPN-Dienst und das Konzept für die Benutzerverwaltung anhand der in Kapitel~\ref{cpt:the_task} ermittelten Anforderungen und Rahmenbedingungen erstellt.


\section{Konzept des VPNs} \label{sct:vpn_concept}
Um VPN-Benutzern einen Zugang zum Netz der Abteilung Informatik zu ermöglichen, muss ein Zugangspunkt im Netz der Abteilung geschaffen werden, der für die VPN-Benutzer über das Internet erreichbar ist.
Deshalb wird das VPN in Client-Server-Architektur aufgebaut, wobei der VPN-Server zum Zugangspunkt wird.
Damit der VPN-Dienst auf dem VPN-Server über das Internet erreichbar ist, muss eine entsprechende Freigabe auf der Firewall der Abteilung Informatik eingereichtet werden.

Das Betriebssystem für den VPN-Server soll Debian~9 sein (\ref{req:serveros}).
Der Server wird an das DMZ-Netz der Abteilung Informatik angeschlossen, weil Server in diesem Netz Dienste anbieten können, die im Internet erreichbar sind.
Um den Dual-Stack-Betrieb zu ermöglichen, werden dem Server jeweils eine IPv4- und IPv6-Adresse zugewiesen (\ref{req:dualstack}).

Damit nur Benutzer den VPN-Zugang benutzen können, die als Beschäftigte oder Studierende zur Abteilung Informatik gehören (\ref{req:users}), müssen sich VPN-Benutzer gegenüber dem VPN-Server authentisieren.
Die Details zur Authentisierung von Benutzern und der Verwaltung autorisierter Benutzer werden in Kapitel~\ref{sct:user_concept} behandelt.

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.
Deshalb soll die Authentisierung des VPN-Servers gegenüber den VPN-Clients mit X.509-Public-Key-Zertifikaten durchgeführt werden.

Die Kommunikation innerhalb des VPNs soll auf OSI-Schicht~3 stattfinden, da lediglich IPv4- und IPv6-Datenverkehr durch das VPN übertragen werden soll (\ref{req:routing}).
Sonstige Protokolle auf OSI-Schicht~2 und 3 werden nicht benötigt.
Die Übertragung von Ethernet-Frames durch den VPN-Tunnel ist nicht notwendig, und würde durch unnötige Datenübertragung nur zusätzliche Netzwerklast verursachen.

Für die IP-Netze der Abteilung Informatik, die über das VPN erreichbar sein sollen (\ref{req:routing}), werden für die Dauer der VPN-Sitzung Einträge in der Routingtabelle des Clients erzeugt.
IP-Pakete, die der Client an Computer im Abteilungsnetz schickt, sollen so durch den VPN-Tunnel geroutet werden.
Damit die Pakete ihr Ziel auch erreichen, wird der VPN-Server als Router konfiguriert, der Pakete zwischen VPN-Tunnel und Abteilungsnetz weiterleitet.

Damit IP-Pakete auch aus dem Abteilungsnetz über den VPN-Tunnel zu den VPN-Clients geschickt werden können, müssen für die VPN-internen IP-Adressen der Clients entsprechende Routen zum VPN-Server auf den Routern im Abteilungsnetz konfiguriert sein.
Da diese Konfiguration nur durch die Administratoren der Router vorgenommen wird, muss eine Lösung gewählt werden, die einheitlich für alle VPN-Clients funktioniert.
Deshalb werden in Absprache mit dem IT-Team der Abteilung Informatik ein IPv4- und ein IPv6-Netz gewählt, aus denen die Clients VPN-interne IP-Adressen vom Server erhalten.
Die Konfiguration von Routen für die beiden IP-Netze ist dadurch unabhängig von individuellen VPN-Sitzungen und kann einmalig vorgenommen werden.

Da keine öffentlichen IPv4-Netze für diesen Zweck verfügbar sind, wird ein Netz aus dem privaten Adressbereich \texttt{10.0.0.0/8} gewählt.
Weil IP-Adressen aus diesem privaten Bereich nicht geroutet werden sollen, führt der VPN-Server \textit{Network Address Translation} (NAT) durch.
IPv4-Datenverkehr von VPN-Clients ins Abteilungsnetz trägt somit die öffentliche IPv4-Adresse des VPN-Servers.
Dazugehörige Antwortpakete können dadurch zurück zum VPN-Server geroutet werden, welcher diese nach der NAT-Übersetzung an den richtigen VPN-Client weiterleitet.

Für IPv6 wurde ein \texttt{/64}-Netz aus dem Bereich \texttt{2001:638:614:1700::/56} gewählt.
Die Router im Abteilungsnetz wurden konfiguriert, Pakete an Hosts in diesem Netz an die öffentliche IPv6-Adresse des VPN-Servers weiterleiten.

Damit keine Verbindungen aus allen Sicherheitszonen zu VPN-Clients möglich sind, die VPN-Clients über das VPN nicht untereinander kommunizieren können, und der NFS-Dienst über das VPN nicht benutzt werden kann (\ref{req:routing}), soll eine lokale Firewall auf dem VPN-Server eingerichtet werden, die alle Regeln aus \ref{req:routing} umsetzt.

Damit die Kommunikation zwischen VPN-Clients und VPN-Server vertraulich bleibt (\ref{req:traffic}), soll der Datenverkehr zwischen Client und Server mit modernen Chiffren verschlüsselt werden.
Um \textit{Perfect Forward Secrecy} (PFS) zu errreichen, soll beim Aufbau der VPN-Sitzung ein entsprechend geeignetes Verfahren zum Schlüsselaustausch verwendet werden, sodass die ausgehandelten Sitzungsschlüssel im Nachhinein nicht rekonstruiert werden können.

Die Protokolleinstellungen des VPN-Servers sollen vor der Inbetriebnahme so angepasst werden, dass nach DSGVO keine personenbezogenen Daten protokolliert werden (\ref{req:logging}).

Um die Wartbarkeit des VPN-Dienstes zu erhöhen, sollen bei der Installation und Konfiguration des VPN-Servers (und gegebenenfalls zusätzlicher Server) die existierenden Konzepte des IT-Teams zum Betrieb von Servern berücksichtigt werden.

Um das in diesem Abschnitt beschriebene Konzept umzusetzen, soll eine passende VPN-Software gewählt werden, deren Serverkomponente auf Debian~9 läuft (\ref{req:serveros}), und für die kompatible Clientkomponenten auf allen gängigen Betriebssystemen (\ref{req:clientos}) verfügbar sind.


\section{Konzept der Benutzerverwaltung} \label{sct:user_concept}
Neben dem Konzept des VPNs muss auch ein Konzept zur Verwaltung der VPN-Benutzer definiert werden.
Laut \ref{req:users} aus Kapitel~\ref{par:requirements} gehören Beschäftigte und Studierende der Abteilung Informatik zur Zielgruppe des Dienstes.
Der VPN-Dienst wird für mindestens 50-500 gleichzeitig aktive Benutzer ausgelegt.
Beschäftigte und Studierende dürfen während ihrer Zugehörigkeit zur Abteilung Informatik den VPN-Zugang benutzen.

\paragraph{Methoden zur Benutzerauthentisierung:} \label{par:user_auth_methods}
Die Authentisierung von VPN-Benutzern ist mit den folgenden Methoden möglich:
\begin{itemize}
\item X.509-Public-Key-Zertifikate
\item Angabe von Benutzername und Passwort
\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}
Die Verwendung von Zugangsdaten zur Authentisierung bietet dem Benutzer einen hohen Komfort, da keine individuelle Konfiguration des VPN-Clients erforderlich ist, und der Benutzer sich seine Zugangsdaten leicht merken kann.

Zusätzlich ist denkbar, dass bereits existierende Zugangsdaten - wie zum Beispiel das Hochschulkonto des Benutzers - zur Authentisierung verwendet werden könnten, indem der VPN-Server an den Verzeichnisdienst der Hochschule Hannover angebunden wird.
In diesem Fall erfolgt die Aktualisierung der Benutzerkonten durch die Hochschul-IT, sodass nur die Benutzerkonten aktiv sind, deren Benutzer gerade als Beschäftigte oder Studierende zur Hochschule gehören.
Der Administrator des VPN-Servers könnte die Menge der erlaubte VPN-Benutzer durch Gruppenmitgliedschaften im Verzeichnisdienst der Hochschule, oder durch eine vom Verzeichnisdienst getrennte geführte Liste steuern.

Die genannten Vorteile ziehen allerdings auch Nachteile mit sich:
Ein VPN-Dienst, der Benutzer über eingegebene Zugangsdaten authentisiert, kann zu einem Ziel für einen Brute-Force-Angriff werden.
Kompromittierte Zugangsdaten können in diesem Fall für den Missbrauch des VPN-Dienstes verwendet werden.

Zusätzlich ist denkbar, dass kompromittierte Zugangsdaten auch für den Missbrauch anderer Systeme verwendet werden können, für die diese Zugangsdaten gültig sind.
Das ist der Fall, wenn Benutzer ihr VPN-Passwort für weitere Dienste verwenden, und ein Angreifer sich mit diesen kompromittierten Zugagnsdaten Zugang zu diesen Diensten verschaffen kann.
Das Schadenspotential umfasst in diesem Fall zusätzlich zu über den VPN-Zugang begangene Straftaten auch das Ausspähen von persönlichen Daten, die über die kompromittierten Zugangsdaten zugänglich sind.

Ein solches Schadenspotential besteht auch dann, wenn der VPN-Dienst an den Verzeichnisdienst der Hochschule Hannover angebunden würde.
Dann könnten die kompromittierten Zugangsdaten verwendet werden, um beispielsweise die E-Mails des betroffenen Benutzers zu lesen, Daten von dessen Homelaufwerk zu stehlen, oder - im Fall eines Studierenden - über das Prüfungsverwaltungssystem Ergebnisse und weitere persönliche Daten auszuspähen.
Eine Anbindung des VPN-Dienstes an den Verzeichnisdienst der Hochschule Hannover kommt aufgrund des damit verbundenen Risikos nicht in Frage.

Ein weiterer Nachteil ergibt sich dadurch, dass Zugangsdaten zum Zweck der Benutzerauthentisierung durch VPN-Client und -Server, sowie zusätzlich durch auf dem Server eingebundene Authentisierungsprogramme verarbeitet und übertragen werden müssen.
Die involvierten Programme erhöhen die Menge des Quellcodes, der aufgrund seiner Position als Angriffsfläche keine Schwachstellen enthalten sollte.
Da die Abwesenheit von Schwachstellen in Quellcode nicht garantiert werden kann, ergibt sich bei der Verwendung von Zugangsdaten zur Benutzerauthentisierung ein erhöhtes Bedrohungsrisiko.

Auch auf den Administrator des VPN-Servers kommt ein erheblicher Mehraufwand hinzu, wenn ein eigener Verzeichnisdienst (wie zum Beispiel ein OpenLDAP-Server) installiert werden soll, um die Zugangsdaten der VPN-Benutzer zu speichern und zu verwalten.
Dieser zusätzliche Aufwand umfasst neben der Installation und dem Betrieb auch die Bereitstellung von Infrastruktur, über die Benutzer ihr VPN-Passwort gegebenenfalls ändern oder zurücksetzen können.
Auch die Absicherung des Verzeichnisdienst ist notwendig, um Manipulation oder Auslesen der gespeicherten Daten durch einen Angreifer zu verhindern.

\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 VPN-Clientkonfiguration, um die neuen Zertifikate zu benutzen.
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).
Zusätzlich ist der Systemadministrator mit der Betreuung der \textit{Zertifizierungsstelle} (CA) beschäftigt, indem er die Zertifikatsanträge der Benutzer entgegennimmt, prüft, und Benutzerzertifikate ausstellt.
Der daraus resultierende Aufwand ist proportional zur Anzahl der VPN-Benutzer.

Dennoch gibt es Vorteile, die diesen zusätzlichen Aufwand rechtfertigen:
Zertifikate haben eine klar definierte Laufzeit, die bei Ausstellung des Zertifikates festgelegt wird.
Aufgrund der Länge der verwendeten Schlüssel ist es für einen Angreifer nicht möglich, diese in akzeptabler Zeit durch Brute-Force-Angriffe zu finden.
Auch das Stehlen von privaten Schlüsseln kann einem Angreifer weniger attraktiv gemacht werden, wenn man die privaten Schlüssel nur verschlüsselt abspeichert.

Sollte ein privater Schlüssel dennoch kompromittiert werden, besteht jederzeit die Möglichkeit, diesen durch eine Ergänzung der CRL seitens der CA unbrauchbar zu machen.
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, da der Angreifer lediglich den VPN-Dienst im Namen des Besitzers des kompromittierten Schlüssels benutzen könnte.
Würde man VPN-Benutzer über ihr Hochschulkonto authentisieren, so hätte ein Angreifer mit einem kompromittierten Hochschulkonto beispielsweise Zugriff auf E-Mails, das Homelaufwerk oder Prüfungsergebnisse des Kontobesitzers.

\paragraph{Wahl der Authentisierungsmethode:} \label{p:choice_user_auth_method}
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.\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.

Unter Abwägung dieser Vor- und Nachteile werden Zertifikate zur Authentisierung von Benutzern verwendet.

\paragraph{Installationskonzept für die PKI:} \label{p:concept_pki_deployment}
Die PKI, die zur Ausstellung von Zertifikaten für die VPN-Benutzer und den VPN-Server benutzt werden soll, muss auf einem Computer installiert werden.
Damit die PKI später von den zuständigen Administratoren aus dem IT-Team der Abteilung Informatik bedient werden kann, empfiehlt sich die Einrichtung der PKI auf einem Server, zu dem nur die Administratoren über SSH Zugang haben.

Da bereits ein Server für den Betrieb der VPN-Serverkomponente verwendet werden soll, liegt der Gedanke nahe, die PKI ebenfalls auf diesem Server zu installieren.
Davon sollte jedoch abgesehen werden, weil die VPN-Serverkomponente über das Internet erreichbar ist, und somit das Risiko besteht, dass ein entfernter, nicht authentisierter Angreifer unter Ausnutzung von Sicherheitslücken in der VPN-Serverkomponente die Kontrolle über den VPN-Server erlangen kann.
In diesem Fall ist die Vertraulichkeit des privaten Schlüssels vom Wurzelzertifikat der PKI gefährdet.
Wird dieser private Schlüssel einem Angreifer bekannt, kann sich der Angreifer gültige Client- und Serverzertifikate ausstellen, und diese beispielsweise für Man-in-the-Middle-Angriffe verwenden.

Die Vertraulichkeit, die Authentizität und die Integrität des VPN-Dienstes wären ab diesem Zeitpunkt verletzt.
VPN-Clients könnten nicht mehr darauf vertrauen, dass sie eine Sitzung mit dem VPN-Server der Abteilung Informatik aufgebaut haben.
Ebenso könnte der VPN-Server nicht mehr darauf vertrauen, dass VPN-Clients mit gültigem Benutzerzertifikat wirklich im Auftrag legitimer VPN-Benutzer agieren.
Insgesamt stellt das Szenario des kompromittierten, privaten Schlüssels des Wurzelzertifikats der PKI einen Totalschaden dar.
Die einzige Abhilfe ist ein vollständiger Neuaufbau der PKI.

Um dieses Risiko im Vorfeld zu reduzieren, soll die PKI auf einem eigenen Server eingerichtet werden, der nur für diesen Zweck installiert wird.
Dieser Server soll nur von den Administratoren aus dem IT-Team bedient werden können, und bietet keine Dienste an, die über das Internet erreichbar sind.
Eine Platzierung des Servers in dem Mitarbeiter-Netz der Abteilung Informatik ist deshalb sinnvoll.
Das Mitarbeiter-Netz wird für diesen Zweck als vertrauenswürdig eingestuft, weil nur Mitarbeiter und Studierende, die zur Abteilung Informatik gehören, Zugriffe in dieses Netzwerk vornehmen dürfen.

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


\section{Gesamtkonzept des VPN-Dienstes} \label{sct:whole_abstract_concept}
Die geplante Konfiguration des VPN-Servers und dessen Platzierung im DMZ-Netz der Abteilung Informatik wurde in Kapitel~\ref{sct:vpn_concept} bereits dargelegt.
Ein Konzept für die Installation der PKI auf einem separaten Server im Mitarbeiter-Netz wurde in Kapitel~\ref{sct:user_concept} erläutert.
Abbildung~\ref{fig:vpn_service_concept} zeigt das Konzept des VPN-Dienstes logisch zusammengefasst.

\begin{figure}[ht]
\centering
\frame{\includegraphics[width=\textwidth]{img/VPN-Service-Concept.pdf}}
\caption{Installationskonzept für den VPN-Dienst}
\label{fig:vpn_service_concept}
\end{figure}

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.

Im DMZ-Netz soll der VPN-Server platziert werden, auf dem die VPN-Serverkomponente installiert wird.
Da die VPN-Serverkomponente eine aktuelle CRL von der PKI benötigt, muss der HTTP-Zugriff vom VPN-Server auf den CA-Server in der Firewall der Abteilung Informatik erlaubt werden.

Im Internet steht beispielhaft der Clientcomputer eines VPN-Benutzers.
Die auf dem Clientcomputer installierte VPN-Clientkomponente baut über ein VPN-Protokoll eine VPN-Sitzung mit der VPN-Serverkomponente auf.
Diese Kommunikation zwischen Clientcomputern im Internet und dem VPN-Server im DMZ-Netz muss ebenfalls in der Abteilungsfirewall erlaubt werden.


\chapter{Softwareauswahl} \label{cpt:choosing_software}
Das Umfeld, in dem der VPN-Dienst errichtet werden soll, wurde in Kapitel~\ref{cpt:netarchitecture} bereits vorgestellt.
In diesem Kapitel wird die Software ausgesucht, mit welcher der VPN-Dienst umgesetzt werden soll.
Die bereits in Kapitel~\ref{cpt:the_task} ermittelten Anforderungen und Rahmenbedingungen sollen dabei berücksichtigt werden.
Dann werden passende Softwarekandidaten vorgestellt, und für die Auswahl der in dieser Arbeit zu verwendenden Software gegenübergestellt.
Im Anschluss soll auf Basis der gewählten VPN-Software gegebenenfalls noch benötigte Software zur Umsetzung der Benutzerverwaltung ausgewählt werden.

\paragraph{Anforderungsprofil:} \label{p:software_req_profile}
Aufgrund des finanziellen Rahmens (\ref{req:finance}) kommt nur kostenfreie Software in Frage, deren Serverkomponente mit aktuellem Debian (\ref{req:serveros}) kompatibel ist.
Die Clientkomponenten der gesuchten Software müssen unter den aktuellen Betriebssystemen laufen (\ref{req:clientos}).

Die Vorgabe von vertraulicher und authentisierter Kommunikation zwischen VPN-Client und VPN-Server (\ref{req:traffic}) impliziert, dass in der gesuchten Software Algorithmen zum Verschlüsseln und Signieren von Daten verwendet werden.
Damit die Implementation dieser kryptografischen Algorithmen von jedermann nachvollzogen werden kann, soll ausschließlich quelloffene Software für den VPN-Dienst verwendet werden.
Dadurch sind unabhängige Untersuchungen der Software auf mögliche Sicherheitslücken von jedermann jederzeit möglich.
Dadurch erhöht sich die Wahrscheinlichkeit bestehende Sicherheitslücken zu finden, und die Implementation der kryptografischen Algorithmen kann auf Korrektheit überprüft werden.

Außerdem kann vermutet werden, dass gefundene und behobene Sicherheitslücken besser kommuniziert werden, da alle Änderungen am Quellcode der Software öffentlich sichtbar sind.
Das wirkt sich auch auf Reaktionszeiten der Software-Distributoren aus: Entsprechend aktualisierte Softwarepakete stehen in der Regel zeitnah bereit und können sofort installiert werden.

Weiterhin soll die gesuchte Software IPv4 und IPv6 unterstützen (\ref{req:dualstack}), die Routingtabellen der VPN-Clients (\ref{req:routing}) anpassen können und in Bezug auf Protokollierung (\ref{req:logging}) konfigurierbar sein.


\section{Kandidaten für VPN-Serversoftware} \label{sct:software_candidates}
Ausgangspunkt für die Suche nach passender VPN-Software ist die Wahl der Serverkomponente: Sie soll quelloffen sein und auf einem Server mit Debian~9 eingesetzt werden können.
Deshalb sind die Debian-Paketquellen die erste Anlaufstelle für die Suche.
Durch die Nutzung der Paketquellen ist das Installieren von Sicherheitsaktualisierungen über den Debian-Paketmanager möglich.
Arbeitsschritte, wie das Anpassen und Kompilieren des Quellcodes, sowie Tests und das Packen der Software, werden von den Verwaltern der Debian-Pakete ausgeführt.
Die Authentizität der Pakete wird anhand von GPG-Signaturen durch den Paketmanager vor der Installation überprüft \cite[][Kapitel 6.5]{book:debian}.

Um den Wartungsaufwand des VPN-Servers zu reduzieren, kann die Installation von Updates durch den Debian-Paketmanager automatisiert werden \cite[][Kapitel 6.7 und 6.8]{book:debian}.
Somit muss der Systemadministrator lediglich Upgrades zur nächsthöheren Debian-Version durchführen, da dabei Anpassungen an der Systemkonfiguration notwendig werden.

Im Folgenden werden mögliche Software-Kandidaten aus den Debian-Paketquellen vorgestellt.


\subsection{Strongswan} \label{ssct:strongswan}
Strongswan\footnote{\url{https://wiki.strongswan.org/projects/strongswan/wiki/IntroductionTostrongSwan},\\zuletzt abgerufen am 18.07.2018} ist eine quelloffene, modular aufgebaute Software, die unter den in \ref{req:serveros} und \ref{req:clientos} genannten Betriebssystemen läuft.
Sie kann in Kombination mit IPsec-fähigen Betriebssystem-Kerneln geschützte Verbindungen zwischen zwei oder mehr Computern einrichten.
Strongswan wird unter der GPLv2-Lizenz verbreitet\footnote{\url{https://wiki.strongswan.org/projects/strongswan/wiki/Contributions},\\ zuletzt abgerufen am 04.09.2018}.

IPsec ist ein Internetstandard, der kryptografische Sicherheit für IPv4 und IPv6 (sowie darüber übertragenen Daten) bieten soll.
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}.
Die Funktion zur Berechnung der Prüfsumme wird nicht explizit definiert und kann daher anhand der zur Zeit aktuellen Vorgaben \cite[definiert in][]{RFC8221} gewählt werden.
Abhängig von der gewählten Funktion fließen bereits im Vorfeld ausgehandelte, gemeinsame Geheimnisse oder Signaturalgorithmen in die Berechnung der Prüfsumme ein, sodass eine korrekte Prüfsumme ein Paket authentisiert.
Eine Verschlüsselung der Paketinhalte ist im AH-Protokoll nicht vorgesehen.

Das Protokoll \textit{IP Encapsulating Security Payload} (ESP) ist in \cite[][]{RFC4303} definiert und ermöglicht den Versand von Paketen mit vertraulichen Inhalten an eine Gegenstelle.
Ähnlich wie bei dem AH-Protokoll ist auch im ESP-Protokoll die Authentisierung von Paketen mit einer Prüfsumme vorgesehen \cite[Siehe][Kapitel 2.8]{RFC4303}.
Aktuell empfohlene Algorithmen zum Berechnen der Prüfsumme oder zum Verschlüsseln der Paketinhalte sind in \cite[][]{RFC8221} aufgeführt.
Durch die Verschlüsselung der Paketinhalte vor dem Transport wird die Vertraulichkeit der übertragenen Inhalte gewährleistet.
Als Schlüssel wird ein zwischen Sender und Empfänger im Vorfeld ausgehandeltes gemeinsames Geheimnis verwendet.
Auch die verwendeten Verschlüsselungsalgorithmen müssen zwischen Sender und Empfänger ausgehandelt werden.

IPsec kann im Transportmodus und im Tunnelmodus betrieben werden.
Im Transportmodus werden die Inhalte von IP-Paketen in AH- beziehungsweise ESP-Pakete gekapselt.
Da die Sender- und Empfängeradressen der IP-Pakete hierbei nicht verändert werden, kann dieser Modus nur für direkte Ende-zu-Ende-Kommunikation der beteiligten Sender und Empfänger verwendet werden.
Der Schutz von zu routendem Datenverkehr zwischen zwei Routern ist damit nicht möglich.

Im Tunnelmodus werden die IP-Paketen selbst in AH- beziehungsweise ESP-Pakete gekapselt.
Im Anschluss werden die AH- beziehungsweise ESP-Pakete dann in neue IP-Pakete gekapselt, deren Sender- und Empfängeradressen sich von denen des inneren IP-Paketes unterscheiden dürfen.
Somit ist der Tunnelmodus im Prinzip für die Umsetzung eines VPN geeignet.

Die Protokolle AH und ESP definieren selbst kein Verfahren zum Aushandeln von verwendeten Prüfsummenfunktionen, kryptografischen Algorithmen oder allgemeiner Konfigurationsparameter.
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.
Dadurch ist der Einsatz von IPsec für lokal ausgeführte Programme transparent.


\subsection{OpenVPN} \label{ssct:openvpn}
OpenVPN ist eine quelloffene Software zur Einrichtung von VPNs in Peer-to-Peer- oder Client-Server-Architektur \cite[][Abschnitt \enquote{Server Mode}]{man:openvpn}.
Sie läuft unter den in \ref{req:serveros} und \ref{req:clientos} genannten Betriebssystemen und wird unter der GPLv2-Lizenz verbreitet.
OpenVPN verwendet die in der Bibliothek OpenSSL enthaltenen Implementationen von kryptografischen Algorithmen \cite[][Abschnitt \enquote{Introduction}]{man:openvpn}.

OpenVPN unterstützt IPv4 und IPv6 sowohl als Transportprotokoll innerhalb eines VPN, als auch als Hüllenprotokoll zur Kommunikation zwischen OpenVPN-Prozessen.
Die Kommunikation zwischen zwei OpenVPN-Prozessen erfolgt durch den Versand von UDP-Paketen.
Wird UDP durch eine Firewall blockiert, kann man auf TCP ausweichen\cite[][Option \texttt{--proto}]{man:openvpn}.
OpenVPN läuft im Benutzerkontext und unterstützt nach dem Programmstart den Wechsel in einen nicht-privilegierten Benutzerkontext \cite[Siehe][Option \texttt{--user}]{man:openvpn}, um im Fall eines erfolgreichen Angriffs den potentiellen Schaden zu begrenzen.

Für die Bereitstellung einer virtuellen Netzwerkkarte als Schnittstelle zum VPN wird ein TUN/TAP-Treiber verwendet.
Über die Routingtabellen auf Client und Server wird bestimmt, welcher Datenverkehr durch das VPN geleitet wird.
Für lokal ausgeführte Programme entspricht der Einsatz von OpenVPN der Installation einer zusätzlichen Netzwerkkarte im lokalen Rechner.

Die Kommunikation zwischen OpenVPN-Client und -Server enthält zwei Kanäle: Einen Datenkanal und einen Kontrollkanal \cite[][Abschnitt \enquote{TLS Mode Options}]{man:openvpn}.
Der Kontrollkanal wird zur Kommunikation zwischen zwei OpenVPN-Prozessen verwendet.
Über ihn werden Konfigurationsparameter vom Server an den Client übertragen \cite[][Option \texttt{--pull}]{man:openvpn}.
Gleichzeitig senden sich Client und Server \enquote{keepalive}-Nachrichten durch den Kontrollkanal, um die VPN-Sitzung bei Inaktivität auf dem Datenkanal aufrecht zu halten \cite[][Option \texttt{--keepalive}]{man:openvpn}.

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.
\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}.


\subsection{Wireguard} \label{ssct:wireguard}
Wireguard ist ein Softwareprojekt, mit dem ein geschützter Netzwerktunnel zwischen zwei Netzwerkteilnehmern aufgebaut werden kann.
Aktuell (am 12.10.2018) befindet sich Wireguard noch in Entwicklung, der Quellcode wird noch als experimentell eingestuft\footnote{Vergleich \url{https://www.wireguard.com/install/}}.
Wireguard wurde als Kernel-Modul für Linux entwickelt, welches einen Umfang von weniger als 4000 Zeilen Code hat \cite[][Abschnitt VII]{wireguard:intro}, wodurch Audits und Reviews erleichtert werden \cite[][Abschnitt VII]{wireguard:intro}.
Im Vergleich zu OpenVPN und IPsec arbeitet Wireguard als Kernel-Modul schneller und effizienter \cite[][Abschnitt VIII]{wireguard:intro}.
Für MacOS, FreeBSD und Windows (Unterstützung für Windows ist noch nicht fertiggestellt) wird mit \texttt{wireguard-go} eine in Go geschriebene Wireguard-Implementation entwickelt.
Eine auf Rust aufbauende Implementation wird unter der Bezeichnung \texttt{wireguard-rs} entwickelt\footnote{Siehe \url{https://www.wireguard.com/xplatform/}}.

Wireguard arbeitet nur auf OSI-Schicht~3 und unterstützt IPv4 und IPv6 sowohl zur Kommunikation zwischen zwei Netzwerkteilnehmern, als auch für den Transport durch den Netzwerktunnel \cite[][Abschnitt I]{wireguard:intro}.
Die durch Wireguard geschützten IP-Pakete werden in UDP-Paketen gekapselt zwischen den Netzwerkteilnehmern übertragen \cite[][Abschnitt III]{wireguard:intro}.
Durch das periodische Senden von \enquote{Keepalive}-Nachrichten \cite[][Abschnitt VI, Absatz E]{wireguard:intro} können Wireguard-Sitzungen, auch hinter \textit{Network Address Translation} (NAT) \cite[][Abschnitt II]{wireguard:intro}, aufrecht gehalten werden.

Während OpenVPN und IPsec die Konfiguration der zu verwendenden kryptografischen Algorithmen und Parameter erlauben, gibt Wireguard diese fest vor.
Sollten Schwachstellen in der verwendeten Kryptografie vorliegen, so müssen alle Wireguard-Endpunkte mit Sicherheitsaktualisierungen versorgt werden \cite[][Abschnitt I]{wireguard:intro}.
Durch diesen Schritt wird Wireguard weniger komplex; Verwundbarkeiten, wie sie bei SSL/TLS häufig aufgetreten sind, werden vermieden \cite[][Abschnitt I]{wireguard:intro}.

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}.
\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}.

Bevor eine Wireguard-Sitzung zwischen zwei Teilnehmern konfiguriert werden kann, müssen die beiden Teilnehmer ihren öffentlichen Schlüssel austauschen.
Dieser Austausch ist mit Absicht nicht durch Wireguard spezifiziert und wird, wie auch bei OpenSSH, den Teilnehmern selbst überlassen \cite[][Abschnitt I]{wireguard:intro}.
Um eine Sitzung mit einem anderen Teilnehmer zu konfigurieren, muss zunächst die eigene Wireguard-Netzwerkschnittstelle konfiguriert werden \cite[Vergleich][Abschnitt II]{wireguard:intro}.
Dafür wird das Schlüsselpaar des Teilnehmers benötigt, sowie die Angabe, über welchen UDP-Port Wireguard Pakete empfangen und verschicken soll.
Als nächstes kann die Liste der bekannten Sitzungsteilnehmer mit einem neuen Eintrag versehen werden.
Der andere Sitzungsteilnehmer wird durch seinen öffentlichen Schlüssel identifiziert.
In einer Liste werden IP-Adressen hinterlegt, die der anderen Sitzungsteilnehmer innerhalb des Netzwerktunnels verwenden darf.
Optional ist eine Angabe von IP-Adresse und UDP-Port des anderen Sitzungsteilnehmers möglich, damit eine Sitzung direkt aufgebaut werden kann.
Wird diese Angabe weggelassen, lernt Wireguard diese Informationen aus den empfangenen Paketen des anderen Teilnehmers automatisch.
Durch diese Flexibilität können Teilnehmer ihre IP-Adresse wechseln, ohne dass die Wireguard-Sitzung dadurch abgebrochen wird.
Mehr Details zur Benutzung von Wireguard unter Linux können anhand eines Beispiels in \cite[][Abschnitt IV]{wireguard:intro} eingesehen werden.

Seit Veröffentlichung des Wireguard-Papers \cite[][]{wireguard:intro} im Frühling 2017 ist im Juli 2018 eine kryptografische Analyse des Wireguard-Protokolls \cite[][]{wireguard:analysis} erschienen.
In der Analyse wird auf den Schlüsselaustausch des Protokolls via \textit{One Roundtrip Handshake} (1-RTT) eingegangen.
Aufgrund einer direkten Abhängigkeit zwischen dem Schlüsselaustausch-Protokoll und der ersten Nachricht des darauf folgenden Datentransport-Protokolls, welche den Sitzungsinitiator gegenüber dem anderen Sitzungsteilnehmer authentisiert, sei die Sicherheit des Schlüsselaustauschs nicht beweisbar.
Technisch betrachtet sei die Phase des Schlüsselaustauschs dadurch kein 1-RTT, da der andere Teilnehmer erst dann mit der Datenübertragung beginnen könne, nachdem der Sitzungsinitiator sich mit der ersten Datentransport-Nachricht authentisiert habe \cite[][Abschnitt 1, \enquote{Security of WireGuard}]{wireguard:analysis}.

Es wird eine Analysemethode gewählt, die eine Trennung von Handshake-Protokoll und Datentransport-Protokolls verlangt.
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.
\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}
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:}
OpenVPN kommuniziert mit einem eigenen Protokoll über UDP auf Port~1194.
Eine Trennung zwischen Kontrollnachrichten und Datenübertragung erfolgt innerhalb der Software.

Strongswan kommuniziert mit kompatiblen Gegenstellen über das IKEv2-Protokoll, welches über UDP auf Port~500 (bei stattfindender \textit{Network Address Translation} (NAT) auf Port~4500) übertragen wird.
Der durch IPsec geschützte Datenverkehr lässt sich daran erkennen, dass in den übertragenen IPv4- beziehungsweise IPv6-Paketen das Protokoll AH oder ESP eingetragen ist.

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:}
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.
Wird OpenVPN mit X.509-Public-Key-Zertifikaten verwendet, so reicht es aus, diese als Datei im PEM-Format bereitzustellen.
Je nach Plattform stehen unterschiedliche grafische Oberflächen zur Verfügung, welche die Benutzung von OpenVPN zusätzlich erleichtern können: Für Linux kann NetworkManager verwendet werden, unter Windows kann OpenVPN-Gui benutzt werden, und unter Mac OS steht Tunnelblick als GUI 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.
\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.

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:}
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.

Die Umsetzung eines VPN auf Basis von IPsec impliziert, dass Code aus dem verwendeten Betriebssystemkernel den durch IPsec geschützten Datenverkehr kryptografisch verarbeitet.
Der Kernel des eingesetzten Betriebssystems ist damit aktiv an der Umsetzung des VPNs beteiligt und sollte somit ebenfalls die an die VPN-Software gestellten Kriterien erfüllen.
Die Verfügbarkeit des Quellcodes des Kernels hängt vom verwendeten Betriebssystem ab und ist deshalb nicht in jedem Fall garantiert.
Damit wird die Forderung nach ausschließlich quelloffener VPN-Software von Strongswan nicht erfüllt.

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

Bei einem auf OpenVPN gestützten VPN ist es möglich, TLS-Chiffren, Hashfunktionen und Verschlüsselungsalgorithmen vorzugeben, die unabhängig vom eingesetzten Betriebssystem durch OpenVPN verwendet werden.

Für ein VPN mit Strongswan auf Basis von IPsec sieht die Situation anders aus:
Wie bereits in Kapitel~\ref{ssct:strongswan} erläutert wurde, kann Strongswan nur in Kombination mit dem Betriebssystem-Kernel ein IPsec-VPN aufbauen.
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.
\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:}
Im Betrieb besteht OpenVPN aus einem Prozess, der über eine Konfigurationsdatei alle für den Betrieb notwendigen Informationen erhält.
Eine Konfigurationsdatei für OpenVPN besteht aus einer Liste von Optionen, die das OpenVPN-Programm als Argumente akzeptiert.
Alle Optionen werden in der Manpage von OpenVPN (nach meiner Meinung) ausführlich und leicht verständlich erklärt, und sollten für Einsteiger mit Grundkenntnissen in Bezug auf Netzwerke und Linux kein Hindernis darstellen.

Strongswan ist modular aus einer Sammlung von Programmen aufgebaut, die abhängig von einer Sammlung von Konfigurationsdateien (vorgegebene Beispielszenarien enthalten typischerweise Inhalte für vier verschiedene Konfigurationsdateien) zum Einsatz kommen.
Zusätzlich ist beim Einsatz von Strongswan immer der Kernel des Betriebssystems involviert, da die Verarbeitung des IPsec-Datenverkehrs im Kernel durchgeführt wird.
Die Konfigurationsdateien bestehen aus Zeilen mit Parametern.
Zusätzlich enthalten die Konfigurationsdateien durch Schweifklammern abgegrenzte Abschnitte, in denen Konfigurationen für bestimmte Kontexte hinterlegt werden.
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 meiner Ansicht) ein unbequemes Hindernis darstellen kann.


\section{Zusammenfassung und Auswahl der VPN-Software} \label{sct:vpn_software_choice}
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.
Somit wird OpenVPN als VPN-Software zur Umsetzung des VPN-Dienst ausgewählt.


\section{Auswahl von Software zur Benutzerverwaltung} \label{sct:choice_easyrsa}
Nach der Wahl der VPN-Software soll in diesem Abschnitt diskutiert werden, mit welcher Software eine PKI umgesetzt werden soll, über welche die VPN-Benutzer mit Zertifikaten ausgestattet werden.

OpenVPN benötigt zur Laufzeit die Bibliothek OpenSSL.
OpenSSL stellt seine Funktionen auch als Kommandozeilenwerkzeug zur Verfügung, mit denen alle Basisfunktionen einer Zertifizierungsstelle, wie zum Beispiel die Erzeugung von Schlüsselpaaren und Zertifikatsanträgen, sowie das Ausstellen von Zertifikaten auf Basis von Zertifikatsanträgen, möglich ist.
Man kann mit OpenSSL eine \textit{Zertifizierungsstelle} (CA) betreiben.
Diese Vorgehensweise verlangt jedoch Fachwissen und Sorgfalt von den Betreibern der CA und eignet sich aufgrund des hohen Aufwands nur für die Verwaltung weniger Benutzer oder zu Zwecken der Lehre.

Mit der Installation von OpenVPN wird die Installation der Software \enquote{EasyRSA} durch den Debian-Paketmanager empfohlen, welches ebenfalls von den OpenVPN-Entwicklern geschrieben wurde.
Dieses Paket enthält eine Sammlung von Shellskripten, welche die Funktionalität von OpenSSL kapseln, um damit einen erleichterten Betrieb einer CA zu ermöglichen.
Die Skripte abstrahieren allgemeine Aufgaben für den Betrieb einer CA.
EasyRSA enthält Funktionen zur Erzeugung eines Wurzelzertifikats, zum Erzeugen von Zertifikatsanträgen, für das Ausstellen von Client- oder Serverzertifikaten auf Basis von Zertifikatsanträgen und für das Erzeugen einer \textit{Certificate Revocation List}(CRL).
Dabei ist es durch Anpassen von Konfigurationsdateien möglich, eine CA ganz nach den eigenen Bedürfnissen zu betreiben und Einfluss auf Parameter wie zum Beispiel Schlüssellängen, Laufzeiten von Zertifikaten oder verwendete kryptografische Algorithmen zu nehmen.

Aufgrund der Vorteile von EasyRSA in Bezug auf einfachere Konfiguration und erleichterte Bedienung für CA-Betreiber und Benutzer im Vergleich zur manuellen Umsetzung einer CA mit OpenSSL alleine, soll EasyRSA für den Aufbau der Zertifizierungsstelle verwendet werden.
Diese Entscheidung wird untermauert von der Tatsache, dass sowohl EasyRSA als auch OpenVPN von den selben Entwicklern weiterentwickelt wird, sodass Kompatibilität zwischen den beiden Softwareprojekten zu erwarten ist.
Die Notwendigkeit zum selbstständigen Entwickeln von Skripten zum Erreichen eines ähnlichen Funktionsumfangs ergibt sich somit nicht.

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.
\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.
Aufgrund des Installationsprozess und den in EasyRSA Version~3.0.5 enthaltenen Vorteilen wird entschieden, dass EasyRSA Version~3.0.5 zum Aufbau der CA für den VPN-Dienst eingesetzt wird.

Um die öffentlichen Daten der CA über HTTP zur Verfügung zu stellen, kommt der Apache httpd als Webserver zum Einsatz, weil dieser unter Debian~9 über das Paket \texttt{apache2} leicht installiert werden kann.


\chapter{Planung der Installation} \label{cpt:openvpn_concept}
Nach Abschluss der Konzeptphase kann die Installation des VPN-Dienstes und der dazugehörigen PKI konkret geplant werden.
Abbildung~\ref{fig:openvpn_full_deployment} zeigt eine Gesamtübersicht über die geplante Installation des VPN-Dienstes und der dazugehörigen CA.

\begin{figure}[h]
\centering
\frame{\includegraphics[width=\textwidth]{img/OpenVPN-Deployment.pdf}}
\caption{Gesamtübersicht der geplanten VPN-Dienst-Installation}
\label{fig:openvpn_full_deployment}
\end{figure}

Im Vergleich mit Abbildung~\ref{fig:vpn_service_concept} aus Kapitel~\ref{sct:whole_abstract_concept} wurde OpenVPN als Software für die Client- und Serverkomponente des VPN gewählt.

Die PKI wird mit Hilfe der Software EasyRSA eingerichtet werden.
Für die Bereitstellung der öffentlichen Daten der PKI wird ein Apache httpd als Webserver verwendet.
Damit die CRL der PKI aktualisiert wird, wird ein Cronjob auf dem CA-Server eingerichtet, der diese Aufgabe übernimmt, und die aktuelle CRL anschließend über den Webserver veröffentlicht.
Auf dem VPN-Server kommt ein weiterer Cronjob zum Einsatz, um die aktuelle CRL vom Webserver auf dem CA-Server zu beschaffen und in die Konfiguration des OpenVPN-Servers zu integrieren.


\section{OpenVPN-Server} \label{sct:plan_openvpn_server}
In diesem Abschnitt werden die in Kapitel~\ref{cpt:service_concept} bereits beschlossenen Konzepte für den VPN-Dienst auf die gewählte VPN-Software OpenVPN zugeschnitten.
Die durch OpenVPN gegebenen Funktionen und Einschränkungen werden hierbei berücksichtigt, um später eine funktionsfähige Konfiguration für OpenVPN aus dieser Planung abzuleiten.

\paragraph{Manuelles Failover:}
Um die Verfügbarkeit des VPN-Dienstes im Fall eines Hardwareausfalls zu erhöhen, soll ein manuelles Failover auf einen zweiten, identisch konfigurierten Server möglich sein.
Das IT-Team vergibt für diesen Zweck verschiedene IPv4- und IPv6-Adressen für den Dienst und den Host.
Dadurch kann ein manuelles Failover durch die Übertragung der IP-Adresse des Dienstes von dem defekten Server auf einen weiteren, identisch konfigurierten Server durchgeführt werden.
Im Beispiel sieht ein Failover von Server~A auf Server~B wie folgt aus:
Bei einem Defekt von Server~A werden zunächst die IP-Dienstadressen auf A deaktiviert.
Anschließend werden die IP-Dienstadressen auf B aktiviert.

Sollte dieses Verfügbarkeitsniveau nicht mehr ausreichen, so ist ein Parallelbetrieb von zwei VPN-Servern möglich.
Dafür muss lediglich ein weiteres IPv6-Netz für VPN-Clients bereitgestellt werden und neue IP-Dienstadressen für einen weiteren VPN-Dienst vergeben werden.
In der OpenVPN-Clientkonfiguration können beide VPN-Server eingetragen werden, sodass die Clients bei Ausfall eines Servers automatisch eine Sitzung mit dem zweiten Server aufbauen können.
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.

\paragraph{VPN-Transportprotokoll:}
OpenVPN bietet UDP und TCP als mögliche Transportprotokolle für den VPN-Datenverkehr an.
Für diesen VPN-Dienst wird das UDP-Protokoll gewählt, 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-Schicht des VPN-Tunnels:}
OpenVPN unterstützt den Aufbau eines VPN-Tunnels auf OSI-Schicht~2 und OSI-Schicht~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-Schicht~2 nicht benötigt.
Zusätzlich würde ein VPN-Tunnel auf OSI-Schicht~2 mehr Bandbreite benötigen: IP-Pakete würden inklusive der dazugehörigen Ethernet-Frames übermittelt.
Aus diesen Gründen fällt die Wahl auf VPN-Tunnel auf OSI-Schicht~3.

\paragraph{Kompression des VPN-Verkehrs:}
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.
Zusätzlich wird in der \enquote{Best Current Practice} RFC~7525 zur Deaktivierung der Kompression von TLS geraten \cite[Vergleich][Kapitel 3.3]{RFC7525}.

Auf der DEFCON~26 wurde mit \enquote{VORACLE} ein in diesem Kontext relevanter Angriff\footnote{Proof of Concept: \url{https://github.com/skepticfx/voracle}} 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{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.
Mit den in diesem Absatz definierten Parametern soll die Kommunikation zwischen Clients und Server unabhängig von den verwendeten Betriebssystemen einheitlich geschützt werden, da die Vertraulichkeit und Authentizität der übertragenen Daten nach Anforderung~\ref{req:traffic} eine Kernfunktion dieses VPN-Dienstes darstellt.

Die TLS-Kommunikation wird nach Empfehlung des BSI über TLS-Version~1.2 oder höher durchgeführt \cite[][Abschnitt 2.3]{bsi:tls-checkliste}.
Zur Absicherung des Kontrollkanals wird die TLS-Chiffre TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 ausgewählt.

Diese Chiffre verwendet \textit{Ephemeral Diffie Hellman} (DHE) für den Schlüsselaustausch \cite[][Abschnitt A.5]{RFC5246}, RSA als Signaturalgorithmus\footnote{RSA wird von der PKI des VPN-Dienstes für Zertifikate eingesetzt.} zur Authentisierung \cite[][Abschnitt A.5]{RFC5246}, AES-256-GCM für die Verschlüsselung und SHA384 als Funktion für Pseudozufallszahlen für den \textit{Keyed-Hash Message Authentication Code} (HMAC) \cite[][Kapitel 5]{RFC5246}.
Durch die Verwendung von DHE kann \textit{Perfect Forward Secrecy} (PFS) gewährleistet werden \cite[][Abschnitt F.1.1.2]{RFC5246}.

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}.
\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.
Grund dafür sind Kompatibilitätsprobleme zwischen OpenVPN und OpenSSL~1.1.x auf der Clientseite\footnote{Siehe \url{https://community.openvpn.net/openvpn/ticket/963}}.

OpenVPN verwendet einen HMAC mit einem zuvor ausgetauschtem, gemeinsamen Geheimnis, um für Daten- und Kontrollkanal eingehende Datenpakete vor ihrer Verarbeitung zu authentisieren.
Die im HMAC als Quelle für Pseudozufallszahlen verwendete Hashfunktion wird auf SHA-256 festgelegt, weil SHA-1, trotz seiner weiterhin bestehenden, theoretischen Eignung zur Verwendung in einem HMAC, laut BSI nicht mehr verwendet werden sollte \cite[][Abschnitt 1.4, Punkt 3]{bsi:tr-02102-1}.

Für die Verschlüsselung des Datenkanals wird auf Basis der zuvor gewählten TLS-Chiffre die Chiffre AES-256-GCM ausgewählt.
Diese Chiffre ist eine \textit{Authenticated Encryption with Associated Data} (AEAD)-Chiffre.
Deshalb wird die Authentisierungsfunktion der Chiffre anstelle der zuvor beschriebenen HMAC-Funktion für den Datenkanal benutzt \cite[][Option \texttt{--auth}]{man:openvpn}.

Durch die Verwendung der selben Chiffre zur Verschlüsselung von Daten- und Kontrollkanal muss ein Angreifer für einen erfolgreichen Angriff - egal auf welchen Kanal - diese Chiffre brechen.
Gelingt es einem Angreifer den Kontrollkanal zu dechiffrieren, so erhält er Kenntnis über die Schlüssel, mit denen der Datenkanal verschlüsselt wird.
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.
Die für den HMAC verwendete Pseudozufallsfunktion kann zum aktuellen Zeitpunkt (04.11.2018) jedoch nicht ausgehandelt werden.
Müssen die kryptografischen Parameter ausgetauscht werden, so besteht die Gefahr, dass die in der Clientkonfiguration festgelegte Funktion für den HMAC vergessen wird.

Die flexible Aushandlung der Chiffren kann unsichere VPN-Sitzungen durch Fehlkonfigurationen auf Client und Server begünstigen, weshalb auf die Aushandlung von Chiffren explizit verzichtet wird.
Eine sichere VPN-Sitzung kommt somit nur bei korrekter Konfiguration von Client und Server zustande.
Potentielle Konfigurationsfehler bei Client oder Server verhindern den Sitzungsaufbau und werden dadurch sichtbar.

Sollten die hier gewählten, kryptografischen Parameter (einzeln oder insgesamt) nicht mehr als sicher gelten, so sollen \textbf{alle} kryptografischen Parameter nach aktuellem Stand der Technik und unter Berücksichtigung der verschiedenen Clientbetriebssysteme neu ausgewählt werden.
Dabei müssen alle VPN-Benutzer über die Änderung der Parameter benachrichtigt werden.
Die Aktualisierung der Vorlage für die OpenVPN-Clientkonfiguration ist ebenfalls notwendig.
Der damit verbundene Arbeitsaufwand ist akzeptabel, weil alle kryptografischen Parameter für eine Laufzeit von 20 Jahren gewählt wurden, und die Wahrscheinlichkeit, dass die Parameter ausgetauscht werden müssen, als gering eingeschätzt wird.

Eine alternativ mögliche, kontinuierliche Aktualisierung der kryptografischen Parameter unter Vorgabe der zur Aushandlung verfügbaren Chiffren in der Serverkonfiguration erscheint zunächst trivial:
Eine neue, moderne Chiffre kann in der Serverkonfiguration zur Liste der erlaubten Chiffren hinzugefügt werden und wird nach einem Neustart des VPN-Servers von allen kompatiblen VPN-Clients sofort verwendet.

Es müssen jedoch auch nicht mehr als modern geltende Chiffren aus der Liste der erlaubten Chiffren entfernt werden.
Das kann dazu führen, dass einzelne VPN-Benutzer mit älterer VPN-Clientsoftware nach der Deaktivierung einer alten Chiffre plötzlich keine VPN-Sitzung mehr aufbauen können.

Da die Aktualisierung der VPN-Clientsoftware im Einzelfall nicht unmittelbar erfolgen kann, erfordert die Deaktivierung einer Chiffre vorher eine sorgfältige Koordination mit den VPN-Benutzern.
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.
\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.


\section{PKI-Server} \label{sct:plan_pki_server}
In diesem Abschnitt wird das Konzept zur Benutzerverwaltung aus Kapitel~\ref{sct:user_concept} unter Berücksichtigung der gewählten PKI-Software EasyRSA konkretisiert.

\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.
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) des Servers enthalten.

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

OpenVPN unterstützt die Verwendung von Zertifikaten mit Schlüsseln auf Basis der EKK ab Version~2.4.0\footnote{Vergleich \url{https://github.com/OpenVPN/openvpn/blob/v2.4.6/README.ec}} vom Dezember 2016\footnote{Siehe \url{https://github.com/OpenVPN/openvpn/releases/tag/v2.4.0}}.
Die Unterstützung von Zertifikaten mit RSA-Schlüsseln ist jedoch schon in Version~1.2.0 vorhanden gewesen\footnote{Vergleich \url{https://github.com/OpenVPN/openvpn/blob/v2.4.6/ChangeLog}}, und existiert somit spätestens seit Mai 2002.
Zertifikate auf Basis des RSA-Kryptosystems wurden im OpenVPN-Umfeld also mindestens 14 Jahre länger erprobt als Zertifikate auf Basis von EKK.
Die daraus resultierenden Erfahrungswerte sind für die Auswahl des Kryptosystems der VPN-CA ausschlaggebend, da die Zertifikate für den VPN-Dienst, abhängig von ihrem Verwendungszweck, für Zeiträume von 5 bis 20 Jahren gültig sein sollen.

Für das gewählte Kryptosystem müssen Parameter, wie die gewünschte Schlüssellänge und, im Fall von EKK, eine elliptische Kurve, gewählt werden.
Sollten die Parameter des Kryptosystems, oder das Kryptosystem selbst, während des Betriebszeitraums nicht mehr als sicher gelten, so muss eine neue CA aufgebaut werden und die unsichere CA ersetzt werden.
Tritt dieser Fall ein, so ist er mit einem hohen Arbeitsaufwand verbunden, da neue Betriebsparameter für die CA gewählt werden müssen und alle gültigen Zertifikate der alten CA entsprechend ersetzt werden müssen.
Deshalb ist es geboten, das Risiko für diesen Fall zu minimieren.

Aus diesem Grund fällt die Wahl auf RSA, da mit RSA im Vergleich zu EKK mehr Erfahrungswerte vorliegen, die für die langfristige Stabilität von RSA sprechen.
Ein weiterer Grund für die Wahl von RSA liegt darin, dass lediglich die Schlüssellänge als Parameter gewählt werden muss.
Mögliche Fehler bei der Wahl einer elliptischen Kurve, wie sie bei EKK notwendig ist, entfallen bei RSA.

Die Vorteile von EKK sind bei dem Anwendungsfall der CA hingegen nicht relevant:
Die im Vergleich zu RSA geringeren Schlüssellängen bei gleichem Sicherheitsniveau werden nicht zwingend benötigt, da die Schlüssel beider Kryptosysteme auf modernen Computern in mehr als ausreichender Anzahl abgespeichert werden können.
Auch auf die im Vergleich zu RSA effizienteren Verfahren in EKK zum Signieren und Verschlüsseln von Daten kann verzichtet werden, da alle diese Operationen auf modernen Computern in wenigen Sekunden berechnet werden können.

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:}
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 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}.
Damit die CA für 20 Jahre sicher betrieben werden kann, wird auf Basis dieser Empfehlungen die Schlüssellänge auf 4096 Bit festgelegt.

\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.
\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}.
Für Serverzertifikate wird festgelegt, dass der \textit{vollqualifizierte Domainname} (FQDN) im Feld \texttt{Common Name} abgelegt wird.
Das Feld \texttt{Email Address} wird mit der Hochschul-E-Mail-Adresse der für den Server zuständigen Administratoren gefüllt.
Für alle weiteren Felder werden folgende Vorgaben festgelegt:
\texttt{Country}: \enquote{DE},
\texttt{Province}: \enquote{Niedersachsen},
\texttt{City}: \enquote{Hannover},
\texttt{Org}: \enquote{Hochschule Hannover},
\texttt{OU}: \enquote{Abteilung Informatik}.

\paragraph{Gültigkeitsdauer der CRL:}
OpenVPN kann die von der CA ausgestellte \textit{Certificate Revocation List} (CRL) benutzen, 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. 

Die CRL enthält Informationen über alle von der CA zurückgerufenen Zertifikate und ist nur für einen begrenzten Zeitraum gültig, der anhand der Felder \enquote{Last Update} und \enquote{Next Update} begrenzt wird \cite[][Kapitel 5.1.2]{RFC5280}.
Dabei sollte eine aktualisierte CRL noch vor Erreichen des \enquote{Next Update}-Zeitpunkt der vorherigen CRL durch die CA veröffentlicht werden \cite[][Kapitel 5.1.2.5]{RFC5280}.

Für EasyRSA kann die Gültigkeitsdauer der CRL in Tagen konfiguriert werden.
Da OpenVPN bei einer abgelaufenen CRL den Dienst verweigert, ist für einen unterbrechungsfreien Betrieb wichtig, dass immer eine gültige CRL zur Verfügung steht.
Grundsätzlich stellt dies kein Problem dar: Sowohl das Ausstellen, als auch das Installieren der CRL auf dem OpenVPN-Server können automatisiert werden.
Um auch bei manueller Installation der CRL einen unterbrechungsfreien Betrieb des VPN-Dienst zu gewährleisten, wird für die CRL eine Gültigkeitsdauer von 180 Tagen festgelegt.


\chapter{Konfiguration des OpenVPN-Servers} \label{cpt:implement_vpn_server}
In diesem Kapitel wird gezeigt, wie der Server für den VPN-Dienst installiert und konfiguriert wird. Wie in Kapitel~\ref{par:requirements} bereits geklärt, wird laut Anforderung~\ref{req:serveros} Debian~9 als Betriebssystem verwendet.
Die Konfiguration des Betriebssystems erfolgt dabei nach den Vorgaben des IT-Teams, damit der Dienst ohne zusätzliche Arbeiten als Produktivsystem übernommen werden kann.


\section{Konfiguration des Serverbetriebssystems} \label{sct:config_server}

\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.
Über ein weiteres Paar von IP-Dienstadressen wird der eigentliche OpenVPN-Dienst zur Verfügung gestellt.

Um Datenverkehr zwischen den VPN-Clients und dem Netz der Abteilung Informatik routen zu können, wird für IPv4 und IPv6 jeweils ein IP-Adressbereich benötigt, aus dem die VPN-Clients ihre Clientadressen zugewiesen bekommen können.
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{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.

Zuerst werden allgemeine Regeln definiert:
Als Standardverhalten wird festgelegt, dass alle Pakete verworfen werden.
Datenverkehr aus oder in die lokale Loopback-Schnittstelle wird zugelassen.
Datenverkehr mit den Protokollen ICMP und ICMPv6 wird zugelassen.
SSH-Zugriffe auf den Server über TCP-Port~22 werden zugelassen.
UDP-Pakete an den OpenVPN-Dienst auf Port~1194 werden zugelassen.
Vom Server ausgehender Datenverkehr wird grundsätzlich zugelassen, um die Grundfunktionen (beispielsweise: Installieren von Updates, DNS, NTP, \dots) des Betriebssystems zu ermöglichen.

Im Anschluss werden Regeln für die Behandlung des VPN-Datenverkehrs definiert:
Bei IPv4-Verkehr vom VPN-Netz zum Netz der Abteilung Informatik wird via NAT die Absenderadresse auf die IPv4-Dienstadresse übersetzt.
Datenverkehr, der aus dem VPN-Netz wieder in das VPN-Netz geroutet wird, soll verworfen werden.
Datenverkehr aus dem VPN-Netz über TCP oder UDP auf Port~2049 (NFS) wird verworfen.
Jeglicher weiterer Datenverkehr aus dem VPN-Netz heraus ist gestattet.

Alle Details zu Installation und Betrieb des VPN-Servers sind in dem Dokument \enquote{IPv6-VPN Serverdokumentation} im Anhang dieser Arbeit zu finden.


\section{Konfiguration von OpenVPN} \label{sct:openvpn_config}
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:}
Der VPN-Server soll über IPv4 und IPv6 aus dem Internet erreichbar sein (\ref{req:dualstack}).
In der \textbf{Serverkonfiguration} reichen die ersten drei Zeilen aus, um über IPv4 und IPv6 auf UDP-Port~1194 den VPN-Dienst anzubieten:
\begin{lstlisting}
port 1194
proto udp
proto udp6
multihome
\end{lstlisting}
OpenVPN beantwortet damit Anfragen für alle auf dem Server konfigurierten IP-Adressen.
Da auf dem Server neben den Dienstadressen auch die Hostadressen existieren, wird OpenVPN mit \texttt{multihome} angewiesen, eingehende Pakete mit der IP-Adresse als Absender zu beantworten, an die diese Pakete gerichtet waren.

In der \textbf{Clientkonfiguration} wird OpenVPN mit \texttt{nobind} angewiesen, den Clientsocket nicht an eine lokale Adresse zu binden. Die Angaben \texttt{port} und \texttt{proto} legen fest, wie der VPN-Server zu erreichen ist.
Über \texttt{remote} wird dann der zu verwendende VPN-Server explizit genannt.
Die Erreichbarkeit über IPv4 und IPv6 ergibt sich aus den im DNS unter \texttt{vpn-test.inform.hs-hannover.de} eingetragenen IP-Adressen.
\begin{lstlisting}
nobind
port 1194
proto udp
remote vpn-test.inform.hs-hannover.de 1194
\end{lstlisting}

\paragraph{OSI-Schicht des VPN-Tunnels:}
In \textbf{Client- und Serverkonfiguration} wird mit angegeben, dass eine virtuelle Netzwerkkarte auf OSI-Schicht~3 als Endpunkt für das VPN verwendet wird:
\begin{lstlisting}
dev tun
\end{lstlisting}

\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 50-500 VPN-Clients problemlos mit IP-Adressen versorgt werden können, indem ein \texttt{/16}-Block vergeben wurde.
In der Konfiguration des Clients sind keine Anweisungen notwendig.
Die \textbf{Serverkonfiguration} enthält diese Anweisungen:
\begin{lstlisting}
topology subnet
server 10.2.0.0 255.255.0.0
server-ipv6 2001:638:614:1750::/64
\end{lstlisting}
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:}
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.

Damit die einzurichtenden Routen den OpenVPN-Datenverkehr nicht durch das VPN leiten, sodass der VPN-Client den VPN-Server nicht mehr direkt erreichen kann, wird eine IPv4-Route zum VPN-Server über das Standardgateway des VPN-Clients eingerichtet:
\begin{lstlisting}
push "route remote_host 255.255.255.255 net_gateway"
\end{lstlisting}
Für IPv6 ist dieser Schritt nicht notwendig, da OpenVPN diesen Fall für IPv6 automatisch erkennen kann, und der VPN-Client selbstständig eine direkte IPv6-Route zum VPN-Server einrichtet.

Dann werden alle IPv4-Routen bekanntgegeben:
\begin{lstlisting}
push "route 141.71.38.0 255.255.255.0 vpn_gateway"	# DMZ
push "route 141.71.30.0 255.255.254.0 vpn_gateway"	# Inform
push "route 192.168.99.0 255.255.255.0 vpn_gateway"	# Edu
push "route 192.168.90.0 255.255.255.0 vpn_gateway"	# NAO
push "route 192.168.70.0 255.255.255.0 vpn_gateway"	# iDrac
push "route 10.0.20.0 255.255.255.0 vpn_gateway"	# Cluster
push "route 10.0.30.0 255.255.255.0 vpn_gateway"	# educloud
push "route 10.0.40.0 255.255.255.0 vpn_gateway"	# experimental ipv6 network
push "route 141.71.2.0 255.255.255.0 vpn_gateway"	# server network from H-IT for KMS
\end{lstlisting}
Der Platzhalter \texttt{vpn\_gateway} wird bei IPv4-Routen durch die IPv4-Adresse des VPN-Servers im VPN ersetzt.
Anschließend werden alle IPv6-Routen an die VPN-Clients bekanntgegeben:
\begin{lstlisting}
push "route-ipv6 2001:638:614:1780::/64 2001:638:614:1750::1"	# DMZ
push "route-ipv6 2001:638:614:1720::/64 2001:638:614:1750::1"	# Inform
push "route-ipv6 2001:638:614:1721::/64 2001:638:614:1750::1"	# Edu
push "route-ipv6 2001:638:614:1722::/64 2001:638:614:1750::1"	# NAO
push "route-ipv6 2001:638:614:1743::/64 2001:638:614:1750::1"	# Cluster
push "route-ipv6 2001:638:614:1744::/64 2001:638:614:1750::1"	# experimental ipv6 network
\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.
Aufgrund dieser einfachen Konfiguration besteht jederzeit die Möglichkeit der Anpassung und Erweiterbarkeit.

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

Anschließend werden in der \textbf{Client- und Serverkonfiguration} über die Parameter \texttt{ca}, \texttt{cert} und \texttt{key} Dateipfade konfiguriert, unter denen das Wurzelzertifikat, das Client- beziehungsweise Serverzertifikat und der dazugehörige private Schlüssel abgelegt sind.
In der \textbf{Serverkonfiguration} werden zusätzlich über die Parameter \texttt{dh} und \texttt{crl-verify} Dateipfade angegeben, unter denen die im Voraus berechneten Parameter für den Diffie-Hellman-Schlüsselaustausch, und die aktuelle Kopie der von der CA herausgegebenen CRL, abgespeichert sind.
\begin{lstlisting}
ca inform/ca.crt
cert inform/aither.inform.hs-hannover.de.crt
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
\end{lstlisting}
Analog dazu wird in der \textbf{Serverkonfiguration} mit dem selben Parameter verlangt, dass VPN-Clients immer ein Zertifikat mit \enquote{Clientrolle} besitzen.
\begin{lstlisting}
remote-cert-tls client
\end{lstlisting}

\paragraph{Kryptografische Parameter:}
Wie in Kapitel~\ref{sct:plan_openvpn_server} bereits erläutert, werden die kryptografischen Parameter wie folgt in \textbf{Client- und Serverkonfiguration} eingetragen.

Die TLS-Kommunikation wird über TLS Version~1.2 oder höher durchgeführt:
\begin{lstlisting}
tls-version-min "1.2"
\end{lstlisting}

Die für den Kontrollkanal verwendete TLS-Chiffre wird konfiguriert:
\begin{lstlisting}
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
\end{lstlisting}

Als Quelle für Pseudozufallszahlen im HMAC für Kontroll- und Datenkanal kommt SHA-256 zum Einsatz:
\begin{lstlisting}
auth SHA256
\end{lstlisting}

Zur Verschlüsselung des Datenkanals kommt die Chiffre AES-256-GCM zum Einsatz.
\begin{lstlisting}
cipher AES-256-GCM
\end{lstlisting}

Um zu verhindern, dass fehlerhaft konfigurierte VPN-Clients eine weniger sichere Verschlüsselung des Datenkanals aushandeln, wird in der \textbf{Serverkonfiguration} die Aushandlung der Chiffre zur Verschlüsselung des Datenkanals abgeschaltet.
\begin{lstlisting}
ncp-disable
\end{lstlisting}

\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.
\begin{lstlisting}
keepalive 10 30
\end{lstlisting}
Diese Anweisung sorgt dafür, dass der Server alle 10 Sekunden eine Ping-Nachricht an den Client schickt, und nach einem Zeitlimit von 60 Sekunden ohne Erhalt einer Antwort die Sitzung beendet, und damit verbundene Ressourcen wieder freigibt.
Gleichzeitig wird die Anweisung über \texttt{push} an den Client übermittelt, sodass dieser ebenfalls alle 10 Sekunden eine Ping-Nachricht an den Server schickt.
Erhält der Client innerhalb von 30 Sekunden keine Antwort auf seine Ping-Nachricht, so startet er sich neu um einen erneuten Sitzungsaufbau zu versuchen.

Um Verbindungsprobleme auf dem Client frühzeitig erkennen zu können, wird die Option \texttt{connect-timeout} in der \textbf{Clientkonfiguration} verwendet, um nach einem Zeitlimit von 20 Sekunden den Sitzungsaufbau abzubrechen.
\begin{lstlisting}
connect-timeout 20
\end{lstlisting}

Damit Client und Server sich bei einem gewollten Sitzungsabbau gegenseitig benachrichtigen, wird die Option \texttt{explicit-exit-notify} verwendet.
In der \textbf{Clientkonfiguration} wird als zusätzlicher Parameter angegeben, wie oft der Versand der Benachrichtigung an den Server probiert werden soll.
\begin{lstlisting}
explicit-exit-notify 3
\end{lstlisting}
In der \textbf{Serverkonfiguration} gibt der zusätzliche Parameter an, ob der Client einen neuen Sitzungsaufbau bei dem selben VPN-Server oder einem anderen VPN-Server probieren soll.
In diesem Fall soll der selbe Server erneut kontaktiert werden.
\begin{lstlisting}
explicit-exit-notify 1
\end{lstlisting}

Zuletzt wird in der \textbf{Serverkonfiguration} eingestellt, dass ein Clientzertifikat für mehr als eine VPN-Sitzung gleichzeitig verwendet werden darf.
Dadurch kann ein Benutzer den VPN-Zugang auf mehreren Geräten gleichzeitig benutzen, falls das notwendig sein sollte.
\begin{lstlisting}
duplicate-cn
\end{lstlisting}

\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 auf bestimmte Ressourcen nicht erneut zugreifen.
Dazu gehören beispielsweise private Schlüssel für Zertifikate, oder die virtuelle Netzwerkkarte.
Damit ein Neustart von OpenVPN auch ohne Privilegien funktionieren kann, ist es möglich mit \texttt{persist-tun} und \texttt{persist-key} das Handle auf die virtuelle Netzwerkkarte, sowie bereits gelesene Schlüssel im Speicher zu behalten.
\begin{lstlisting}
persist-tun
persist-key
\end{lstlisting}
Dann kann über die Parameter \texttt{user} und \texttt{group} gesteuert werden, in welchem Kontext OpenVPN mit reduzierten Privilegien betrieben werden soll.
\begin{lstlisting}
user nobody
group nogroup
\end{lstlisting}

Für die \textbf{Clientkonfiguration} kann es sinnvoll sein, dass OpenVPN das Passwort, mit dem ein privater Schlüssel geschützt wurde, nicht im Speicher behält.
Mit der folgenden Option kann OpenVPN gezwungen werden, ein solches Passwort nicht im Speicher zu halten.
\begin{lstlisting}
auth-nocache
\end{lstlisting}

\paragraph{Protokollierung:}
Um den Detailgrad der Protokolle 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.
Der Bereich reicht 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).

Für DSGVO-konforme Protokolle wird der Wert~0 in der \textbf{Serverkonfiguration} verwendet; der Wert~3 wird für übersichtliche Protokolle mit mehr Informationen in der \textbf{Clientkonfiguration} empfohlen.
Der Parameter \texttt{mute} gibt an, wie viele aufeinander folgende Nachrichten aus der selben Kategorie protokolliert werden sollen.
Damit können aufeinander folgende, ähnliche Nachrichten unterdrückt werden, die sich wiederholen.
Um einen guten Überblick im Testbetrieb zu erhalten, werden vorerst die folgenden Parameter gewählt:
\begin{lstlisting}
verb 3
mute 5
\end{lstlisting}

In der \textbf{Serverkonfiguration} kann mit \texttt{status} dafür gesorgt werden, dass OpenVPN regelmäßig eine Liste aller aktiven Sitzungen in die als Parameter angegebene Datei schreibt.
Eine solche Liste ist nützlich, um die Auslastung des Servers zu überwachen.
\begin{lstlisting}
status inform/status.log
\end{lstlisting}

Damit ist die Erzeugung der OpenVPN-Konfiguration für Client und Server abgeschlossen.
Die resultierenden Konfigurationdateien befinden sich im Anhang dieser Arbeit.


\chapter{Implementieren der Benutzerverwaltung} \label{cpt:implement_ca}
Nachdem die Installation des OpenVPN-Servers in Kapitel~\ref{cpt:implement_vpn_server} beschrieben wurde, wird in diesem Kapitel die Einrichtung der Zertifizierungsstelle zur Verwaltung der VPN-Benutzer auf Basis von EasyRSA gezeigt.

\label{sct:running_ca}
Für den Betrieb der Zertifizierungsstelle wird eine virtuelle Maschine exklusiv für diesen Zweck erzeugt und im Mitarbeiter-Netz platziert.
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:}
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.

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 dadurch motiviert werden.

\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 über das Debian-Paket \texttt{apache2} installiert, welcher ausschließlich das für diesen Zweck erzeugte Verzeichnis \texttt{/public} über HTTP zur Verfügung stellen soll.

Alle in \texttt{/public} platzierten Dateien und Verzeichnisse gehören dem Benutzer \texttt{root} und der Gruppe \texttt{root}.
Alle Dateien werden mit den Dateirechten \texttt{444} versehen, Verzeichnisse erhalten die Dateirechte \texttt{555}.
Dadurch werden Manipulationen durch nicht privilegierte, lokale Benutzer verhindert.
Gleichzeitig signalisieren die Dateirechte, dass die Inhalte unter \texttt{/public} nur durch \texttt{root} verändert werden dürfen und für alle anderen lediglich lesbar zur Verfügung stehen sollen.

Die Veröffentlichung von Konfigurationsdateien und Anleitungen für VPN-Benutzer kann über diesen Webserver ebenfalls stattfinden.

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

Auf dem OpenVPN-Server wird ebenfalls ein Cronjob eingerichtet, der die aktuelle CRL von dem Webserver der CA herunterlädt und in das Konfigurationsverzeichnis von OpenVPN integriert.

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.


\chapter{Fazit} \label{cpt:conclusion}
In dieser Arbeit wurde ein IPv6-VPN-Dienst für die Abteilung Informatik anhand von gegebenen Anforderungen mit OpenVPN konzipiert und umgesetzt.
Alle für die Installation und den Betrieb notwendigen Anleitungen befinden sich im Anhang dieser Arbeit:
\begin{itemize}
\item Benutzeranleitung für das IPv6-VPN der Abteilung Informatik
\item Dokumentation der Zertifizierungsstelle für den IPv6-VPN-Dienst
\item IPv6-VPN Serverdokumentation
\end{itemize}

Während des Vergleichs und der Auswahl der VPN-Softwarekandidaten hat sich gezeigt, dass mit OpenVPN eine flexible und - im Vergleich zu IPsec - unkomplizierte und vollständig quelloffene IPv4- und IPv6-VPN-Lösung geboten wird, die auf allen gängigen Client-Betriebssystemen läuft.
Fortgeschrittene Anwender können zusätzlich die kryptografischen Parameter plattformunabhängig festlegen, mit denen die Kommunikation abgesichert wird.
Die Verwaltung von VPN-Benutzern kann dabei unter anderem über X.509-Public-Key-Zertifikate geschehen, und bietet somit einen Kompromiss aus Flexibilität und Sicherheit.

Die Installation und Konfiguration des VPN-Dienst konnte ohne Komplikationen durchgeführt werden, und erfüllt alle gegebenen Anforderungen.
Da die Konzeption in enger Absprache mit dem IT-Team der Abteilung Informatik stattgefunden hat, und alle im IT-Team gängigen Vorgehensweisen berücksichtigt wurden, steht dem langfristigen Betrieb des in dieser Arbeit erschaffenen VPN-Servers und der dazugehörigen VPN-CA nichts im Weg.

Mit der in dieser Arbeit erschaffenen VPN-Lösung ist der Bedarf der Abteilung Informatik an einem IPv6-fähigen VPN-Dienst gedeckt worden.
Allerdings bedeutet die erfolgreiche Inbetriebnahme dieses neuen Produktivsystems keinesfalls, dass nun nichts mehr zu tun sei.
Es lohnt sich jederzeit, die Aktualisierung und Weiterentwicklung dieses 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{Aktualisierung der kryptografischen Parameter}
Sollten die in dieser Arbeit gewählten, kryptografischen Parameter nicht mehr als sicher gelten, so sollen alle Parameter nach aktuellem Stand der Technik neu gewählt werden.
Dafür ist neben einer Anpassung der Serverkonfiguration auch die Anpassung sämtlicher Clientkonfiguration notwendig.
Dies kann beispielsweise über eine veröffentlichte Beispielkonfiguration angestoßen werden, und muss allen VPN-Benutzer mitgeteilt werden.
Die mit dieser Methode verbundenen Vor- und Nachteile wurden in Kapitel~\ref{sct:plan_openvpn_server} im Detail diskutiert.

\paragraph{Unterstützung von TLS~1.3}
Heute (04.11.2018) unterstützt OpenVPN in der aktuellen Version~2.4.6 TLS~1.3 noch nicht.
Laut einem Ticket im OpenVPN Issue-Tracker\footnote{Siehe \url{https://community.openvpn.net/openvpn/ticket/1080}} kann vermutet werden, dass OpenVPN ab Version~2.4.7 TLS~1.3 bereits unterstützen könnte.
Um TLS~1.3 benutzen zu können, müssen die auf dem VPN-Server installierten Pakete \texttt{openssl} und \texttt{openvpn} TLS~1.3 unterstützen - da diese aus Debian-Paketquellen installiert werden, ist denkbar, dass TLS~1.3 erst mit Debian~10 unterstützt werden könnte.
Besteht die Unterstützung für TLS~1.3 seitens des VPN-Servers, so können VPN-Clients die Verwendung von TLS~1.3 erproben, indem in der Clientkonfiguration der Parameter \texttt{tls-version-min} auf 1.3 gestellt wird.
Sobald hinreichende Unterstützung für TLS~1.3 für alle VPN-Clients besteht, kann die minimal erlaubte TLS-Version in die Serverkonfiguration auf TLS~1.3 gestellt werden, um alle VPN-Sitzungen nur über TLS~1.3 aufzubauen.
Die Anpassung aller Clientkonfigurationen ist in diesem Fall nicht zwingend.
Jedoch sollten alle VPN-Benutzer auf die Umstellung hingewiesen werden und die Vorlage für die Clientkonfiguration aktualisiert werden.

\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}}.
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.
Die bisherigen Angaben in Bezug auf Effizienz, Wahl der kryptografischen Parameter und Benutzerfreundlichkeit sprechen meiner Meinung nach stark dafür, dass ein Umstieg von OpenVPN auf Wireguard vorteilhaft ist.

Zusätzlich wäre ein weiteres Einsatzszenario denkbar, das durch die hohe Effizienz und die einfachen Konzepte von Wireguard möglich gemacht wird.
Studierenden der Abteilung Informatik ist es nur nach Genehmigung des IT-Teams erlaubt, ihre Privatgeräte - wie zum Beispiel mitgebrachte Laptops - über Ethernet mit dem Netz der Abteilung Informatik zu verbinden.
Bei erteilter Erlaubnis wird die MAC-Adresse des Privatgeräts auf dem DHCP-Server über eine Whitelist freigeschaltet, damit das Privatgerät über DHCP IP-Adressen beziehen kann, und sich dadurch mit dem Netz der Abteilung Informatik verbinden kann.

An dieser Stelle könnte eine Lösung auf Basis von Wireguard ansetzen: Anstatt Zugriffsfreigaben auf Basis von MAC-Adressen zu erteilen, könnte ein mit Wireguard ausgestattetes Gateway so konfiguriert werden, dass nur durch Wireguard authentisierter Datenverkehr in das Netz der Abteilung Informatik weitergeleitet wird.
Als positiver Nebeneffekt werden \enquote{Lauschangriffe} auf OSI-Schicht~2 durch andere Privatgeräte dank der Verschlüsselung des Netzwerkverkehrs durch Wireguard effektiv verhindert.
Da Wireguard-Teilnehmer durch ihren öffentlichen Schlüssel durch das Gateway eindeutig identifiziert werden können, könnte man zusätzlich untersuchen, ob die Umsetzung unterschiedlicher Zugriffsrechte für verschiedene Wireguard-Teilnehmer möglich und sinnvoll ist.

% End of content