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 3 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 findet die Verwendung von IPv6 eine zunehmende Verbreitung als Nachfolger von IPv4:
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}.
Auch das Netz der Abteilung Informatik an der Hochschule Hannover ist Vorreiter in der Erprobung von IPv6: Seit Anfang 2015 ist das Netz schon über IPv6 an das Internet angebunden.
Mitarbeitern und Studenten der Abteilung Informatik steht ein VPN-Dienst zur Ver\-fü\-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
Im Rahmen dieser Masterarbeit soll ein neuer, IPv6-fähiger VPN-Dienst konzipiert werden, der die Idee des bisherigen IPv4-VPN-Dienst aufgreift.
Dafür wird zunächst die Netzarchitektur der Abteilung Informatik inklusive dem Firewallkonzept vorgestellt.
Anschließend werden alle Rahmenbedingungen und Anforderungen erfasst, die bei der Konzeption des neuen VPN-Dienst berücksichtigt werden sollen.
In der darauf folgenden Konzeptphase werden zunächst grundlegende, lösungsunabhängige Entscheidungen getroffen, auf Basis derer dann eine technischen Lösung ausgewählt wird.
\todo{Danach geht es weiter mit der Planung der konkreten Lösung, der Installation und der Dokumentation.}
\chapter{Netzarchitektur der Abteilung Informatik}\label{cpt:netarchitecture}
Das Netz der Abteilung Informatik wird durch eine Firewall vom Netz der Hochschule Hannover und dem Internet getrennt.
An der Firewall sind zwei lokale Netze angeschlossen: Die Demilitarisierte Zone (DMZ) und das interne Abteilungsnetz, welches durch einen zentralen Switch in mehrere 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 ist in Abbildung~\ref{fig:topology_simple} zu sehen.
\begin{figure}[ht]
\centering
% Trim, da diese Grafik als PDF auf DIN A4 vorliegt.
\caption{Skizze der Netztopologie der Abteilung Informatik}
\label{fig:topology_simple}
\end{figure}
\section{Firewallkonzept}\label{sct:firewall}
Die im Netz der Abteilung Informatik verwendeten LANs und VLANs werden im Firewallkonzept als verschiedene Sicherheitszonen betrachtet.
Im Rahmen dieser 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.
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}
Die Rechner aller Mitarbeiter der Abteilung Informatik 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.
Verbindungen aus dem Mitarbeiter-Netz sind in alle anderen Zonen erlaubt.
\paragraph{Pool-PC-Netz}
Enthält die Rechner aus allen Poolräumen.
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-Netz & Pool-PC-Netz & Labor-Netze \\
In diesem Abschnitt werden alle Anforderungen und Rahmenbedingungen vorgestellt, die bei der Konzeption des neuen VPN-Dienst berücksichtigt werden müssen.
\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.
\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 von autorisierten Mitarbeitern und Studenten aus der Abteilung Informatik benutzt werden können.
Die Benutzer des VPN-Dienst sollen durch die Administratoren des VPN-Dienst einfach verwaltet werden können.
\item\label{req:serveros}\textbf{Betrieb des VPN-Servers:} Die Serverkomponente des VPN-Dienst 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:} Während des Betrieb des VPN-Dienst sollen keine Daten protokolliert werden, die Rückschlüsse auf das Benutzerverhalten zulassen. Im Rahmen einer laufenden Fehlersuche soll es möglich sein, mehr Daten zu protokollieren.
\item\label{req:finance}\textbf{Finanzieller Rahmen:} Es stehen keine finanziellen Mittel für den Erwerb einer VPN-Lösung zur Verfügung.
\end{enumerate}
Anhand der Anforderungen~\ref{req:dualstack} bis \ref{req:finance} werden vorhandene Programme ermittelt, die sich als Kandidat zur Umsetzung des VPN-Dienstes eignen.
Aufgrund des finanziellen Rahmens (\ref{req:finance}) kommt nur kostenfreie Software in Frage, deren Serverkomponente mit aktuellem Debian (\ref{req:serveros}) kompatibel ist.
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.
Jedermann kann öffentlich lesbaren Quellcode auf mögliche Sicherheitslücken untersuchen; dadurch erhöht sich die Wahrscheinlichkeit bestehende Sicherheitslücken zu finden.
Außerdem werden gefundene und behobene Sicherheitslücken häufig besser kommuniziert, da alle Änderungen am Quellcode ohnehin 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{Suche nach 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 aktuellem Debian 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 Paketieren der Software werden von den Verwaltern der Debian-Pakete ausgeführt.
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.
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 lauffähig ist.
Sie kann verwendet werden, um in Kombination mit IPsec-fähigen Betriebssystem-Kerneln geschützte Verbindungen zwischen zwei oder mehr Computern einzurichten.
Strongswan wird unter der Lizenz GPLv2 verbreitet\footnote{\url{https://wiki.strongswan.org/projects/strongswan/wiki/Contributions},\\ zuletzt abgerufen am 04.09.2018}.
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}.
Das Protokoll \enquote{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üf\-sum\-me 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.
Das Protokoll \enquote{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}.
Da die Sender- und Empfängeradressen der IP-Pakete hierbei nicht verändert wird, kann dieser Modus nur für direkte Ende-zu-Ende-Kommunikation verwendet werden.
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.
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.
Diese Aufgabe übernimmt Strongswan als IKEv2-Dienst.
Strongswan implementiert das Protokoll IKEv2\footnote{Internet Key Exchange Protokoll Version 2, definiert in \cite[][]{RFC7296}} und kann darüber authentisiert und verschlüsselt mit 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 Da\-ten\-ver\-kehrs über die Protokolle AH oder ESP wird jedoch direkt im IPsec-Stack des Kernels abgewickelt.
OpenVPN ist eine quelloffene Software zur Einrichtung von VPNs in Peer-to-Peer oder Client-Server-Architektur\cite[][Abschnitt \enquote{Server Mode}]{man:openvpn}.
Des Weiteren läuft es vollständig im Benutzerkontext und unterstützt nach dem Programmstart den Wechsel in einen nicht-privilegierten Benutzerkontext\cite[Siehe][\texttt{--user}]{man:openvpn}, um im Fall eines erfolgreichen Angriffs den potentiellen Schaden zu begrenzen.
Für lokal ausgeführte Programme entspricht der Einsatz von OpenVPN der Installation einer zusätzlichen Netzwerkkarte im lokalen Rechner - gegebenenfalls müssen die neuen IP-Adressen der virtuellen Netzwerkkarte berücksichtigt werden.
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}.
Alle kryptografische Operationen zur Verarbeitung des VPN-Datenverkehrs, sowie zur Authentisierung werden nur in OpenVPN durchgeführt, welches diese zu großen Teilen an die quelloffene Bibliothek openssl auslagert\cite[][Abschnitt \enquote{Introduction}]{man:openvpn}.
Idee: Hier kommen Kategorien hinein: Lizenz, Komplett quelloffen/Abhängigkeiten?, Funktionsumfang, Firewallregeln, Trennung von Steuerdaten und Nutzdaten, Platformabhängigkeit, Komplexität der Konfiguration, Einheitliche Sicherheitsniveaus, Userspace vs Userspace+Kernel, Benutzerfreundlichkeit, Konfiguration bidirektional/unidirektional, Potential für Fehlkonfiguration, Flexibilität
Konfiguration der IPsec-Verbindungen findet im Kernel statt, es ist ein zusätzliches IKEv2-Dienstprogramm notwendig, um die Konfigurationsparameter auszuhandeln und Schlüssel auszutauschen.
Die im Kernel konfigurierten Verbindungen sind immer unidirektional, d.h. für den Schutz von Datenverkehr zwischen zwei Rechnern sind auf beiden Rechnern jeweils zwei konfigurierte Verbindungen notwendig.
Bei gegebenenfalls. entdeckten Sicherheitslücken ergeben sich je nach Betriebssystemkernel unterschiedliche Reaktionszeiten.
Je nach Betriebssystem werden im Kernel gegebenenfalls. nicht alle laut RFC empfohlenen Chiffren gleichermaßen angeboten, dadurch kann ein einheitliches Sicherheitsniveau nur schwer gewährleistet werden.
Strongswan ist zwar grundsätzlich auf allen in \ref{req:clientos} aufgeführten Betriebssystemen lauffähig, jedoch endet die Benutzerfreundlichkeit voraussichtlich dann, wenn man Strongswan unter Windows erst einmal kompilieren muss.
Verlässt man sich auf der Clientseite auf das gegebenenfalls. bereits im Betriebssystem enthaltene IKEv2-Dienstprogramm, so wird die Bedienung über alle Betriebssysteme unterschiedlich sein.
Hinzu kommt, dass durch den hohen Funktionsumfang und die Flexibilität von IPsec Konfigurationen möglich sind, die zwar eine durch IPsec gekapselte Kommunikation ermöglichen, jedoch nicht das gewünschte Sicherheitsniveau herstellen.
OpenVPN hat nur einen Kommunikationskanäle (udp/1194), während für IPsec IKEv2 (udp/500 beziehungsweise udp/4500) und die Protokolle AH beziehungsweise ESP freigegeben werden müssen.
Da jedoch der Datenverkehr bei IPsec durch den Betriebssystemkernel verarbeitet wird, und dessen Quellcode bei Betriebssystemen von Microsoft oder Apple nicht zur Verfügung steht, scheidet Strongswan als Kandidat aus.
Allerdings gibt es auch eine modernere Neuentwicklung in Version 3.0.5(Stand 17.09.2018, siehe github.com/openvpn/easyrsa), die langfristig vom OpenVPN-Team weiterentwickelt wird und einige Verbesserungen im Vergleich zur alten v2 mitbringt.
Viele Verbesserungen, wie z.B. Unterstützung für ECDSA (Siehe Changelog) oder UTF-8 ist jetzt standard, AES256 wird für die Verschlüsselung des CA-Keys verwendet, \dots
Da für die Anfertigung von Zertifikatsanträgen einige Details beachtet werden sollen und diverse Einstellungen durch die Zertifizierungsstelle vorgegeben bzw. vorausgesetzt werden, ist es sinnvoll, dass die CA durch das IT-Team auf Basis von EasyRSA3 kurz vorbereitet wird und dann als Paket für Benutzer bereitgestellt wird.
\item Die Wahl der Algorithmen wirkt sich höchstens auf die Dauer der Authentisierung beim Verbindungsaufbau aus, der reguläre Betrieb wird davon nicht berührt.
\item Da OpenVPN-Clients für alle Plattformen den selben Code verwenden, sollte bei gleichbleibenden Versionen von OpenSSL (bzw. kompatiblen mbed-TLS-Bibliotheken) die Wahl sich nicht auf die Kompatibilität auswirken.
\item RSA ist lange erprobt, bestehende Patente sind ausgelaufen. Schlüssel sind etwas größer (2-4Kbit), nicht gegen Angriffe durch Quantencomputer beständig (Primfaktorzerlegung)
\item Elliptic Curve-Verfahren sind noch relativ neu (10 Jahre?). Schlüssel sind kleiner, es gab schon einen Fall mit einer Backdoor in einer Curve\todo{Citation needed für Dual\_EC\_DRBG}, nicht gegen Angriffe durch Quantencomputer beständig (diskreter Logarithmus).
\end{itemize}
RSA wird gewählt.
Weil es deutlich länger auf dem Markt ist.
Weil in einer Elliptic Curve schon eine Backdoor gezeigt wurde.
Weil RSA immer noch funktioniert und in naher Zukunft nicht geknackt werden wird.
Das BSI hat in seinen technischen Richtlinien keine Bedenken gegen den Einsatz von RSA in Szenarien, die über 2023 hinausgehen\cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}.
\item OpenVPN empfiehlt RSA mit Schlüsseln länger als 2048 Bit: \enquote{OpenVPN will migrate to 'preferred' as default in the future. Please ensure that your keys already comply.}\cite[][Option \texttt{--tls-cert-profile}]{man:openvpn}
\item Das BSI empfiehlt den Betrieb mit Schlüsseln länger als 3000 Bit über das Jahr 2023 hinaus\cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}.
Volles Schema => Mehr Informationen darüber, wo der VPN-Dienst angesiedelt ist. Ändert nicht viel. Es spricht nichts gegen den Einsatz des vollen Schemas. Es gibt keine nennenswerten Vorteile oder Nachteile. Mehr Informationen können helfen, wenn man einen Eimer voller Zertifikate findet.
\item Falls es möglich sein soll, Zertifikate bei Missbrauch/Verlust/etc zu sperren, dann braucht man einen eindeutigen Identifier
\item Voller Name: Konflikte selten aber möglich, personenbezogene Daten
\item E-Mail-Adresse: Eindeutig, aber personenbezogene Daten
\item Benutzername/LUH-ID: Eindeutig, kein Konfliktpotential, personenbeziehbar. (Nur "alte" Studenten haben noch Benutzernamen mit Namen drin)
\item Matrikelnummer (bei Studenten): Eindeutig, ggf. hat ein Student mehrere, aber das ist kein Thema. personenbeziehbar. Nachteil: Gibt es für Mitarbeiter nicht.
\end{itemize}
Benutzername wäre eine eindeutige Angabe, ist garantiert eindeutig.
Gleichzeitig kann man argumentieren, dass diese häufig pseudonym sind und die Zuordnung von Benutzername zu Person nicht immer trivial ist.
Datenschutzrechtlich sollte das gerade so okay sein.
Gültigkeitsdauer der CRL - falls Zertifikate überhaupt zurückgezogen werden sollen: maximal 180 Tage, kann ja vorher jederzeit aktualisiert werden (Cronjob oder so)
Nachdem in den vorangegagenen Teilen der Arbeit alle für die Erstellung der OpenVPN-Konfiguration notwendigen Informationen ermittelt wurden, wird hier gezeigt und erklärt, wie sich die Client- und Serverkonfigurationen für OpenVPN ergeben.
Dabei werden alle vorgenommenen Entscheidungen beleuchtet.
Auf Kompression wird verzichtet, da es bereits am 03.06.2018 Hinweise in der Manpage hinzugefügt wurden\footnote{\url{https://github.com/OpenVPN/openvpn/commit/6795a5f3d55f658fc1a28eb9f3b11d1217e3329c}}, in denen vor der Verwendung von Kompression gewarnt wird.
Zum Vergleich: OpenVPN Version 2.4.6 wurde von den Entwicklern am 19.04.2018\footnote{\url{https://github.com/OpenVPN/openvpn/releases/tag/v2.4.6}} freigegeben.
Auf der DEFCON 26 wird mit \enquote{VORACLE} ein in dieser Richtung relevanter Angriff auf OpenVPN vorgestellt\footnote{\url{https://media.defcon.org/DEF\%20CON\%2026/DEF\%20CON\%2026\%20presentations/Nafeez/DEFCON-26-Nafeez-Compression-Oracle-attacks-on-VPN-Networks.pdf}}.
Der Einsatz von IPsec ist für die Umsetzung eines VPN in das Netzwerk einer Fakultätsabteilung ein Schuss mit einer Kanone auf Spatzen.
In großen Umgebungen eines Konzerns kann die Situation schon etwas anders aussehen: Sofern die IT-Landschaft in einem Konzern homogen aufgestellt ist, könnten auf IPsec spezialisierte Administratoren über Konfigurationsmanagement wie zum Beispiel das Active Directory von Microsoft eine Steigerung der Netzwerksicherheit erzielen oder Außendienstmitarbeitern einen nahtlosen Anschluss an das Firmennetzwerk bieten.
Es gibt da noch etwas mit dem schönen Namen Wireguard. Mit gewollt geringer Komplexität und einem aktuellen Umfang von ca. 4000 Zeilen Code ist es eine würdige Alternative zu IPsec.
