TODO: Fix hyphenation without T1 fontenc

This commit is contained in:
Jan Philipp Timme 2018-10-24 13:07:30 +02:00
parent 508ea9be8a
commit 4d65bff2c3
4 changed files with 20 additions and 16 deletions

View File

@ -5,6 +5,7 @@
\usepackage[hidelinks]{hyperref} % Hyperref (alles klickbar, Bookmarks)
\usepackage{amssymb} % Math. Symbole aus AmsTeX
% Custom packages
\usepackage[T1]{fontenc} % MAYBE FIX hyphenation?
\usepackage[autostyle=true,german=quotes]{csquotes} % Anführungszeichen mit \enquote{}
\usepackage{textcomp} % Zusätzliches Package für °C
\usepackage{listings} % Codesnippets

2
COMMON-Hyphenation.tex Normal file
View File

@ -0,0 +1,2 @@
\hyphenation{EasyRSA MacOS FreeBSD Strong-swan Adres-sen Ver-fü-gung be-rück-sich-tigt Prüf-sum-me Da-ten-ver-kehrs Schlüs-sel-aus-tausch Zer-ti-fi-ka-ten Schlüs-sel-paa-ren Schlüs-sel-län-ge Ab-tei-lung Grund-sätz-lich Dienst-adres-se Client-kon-fi-gu-ra-tion}

View File

@ -13,7 +13,7 @@ Auch das Netz der Abteilung Informatik an der Hochschule Hannover ist Vorreiter
Seit Anfang 2017 ist das Netz schon über IPv6 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 Ver\-\-gung, um Zugang in das Netz der Abteilung aus dem Internet heraus zu erhalten.
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
@ -58,7 +58,7 @@ Teil des Auftrags ist die Erstellung eine Konzepts für die Verwaltung der VPN-B
Die für die Umsetzung verwendete Software ist nicht vorgegeben und soll anhand der aufgestellten Konzepte und Anforderungen 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ücksich\-tigt werden müssen.
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*]
@ -248,7 +248,7 @@ Im Anschluss werden dann passende Softwarekandidaten vorgestellt und für die Au
Anhand der Anforderungen~\ref{req:dualstack} bis \ref{req:finance} aus Kapitel~\ref{par:requirements} 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 Clientkomponenten der gesuchten Software müssen unter den aktuellen Betriebssystemen lauffähig sein (\ref{req:clientos}).
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.
Deshalb soll Kerckhoffs' Prinzip bei der Wahl der VPN-Software angewendet werden, indem ausschließlich quelloffene Software berücksichtigt wird.
@ -283,7 +283,7 @@ Mit IPsec können Richtlinien definiert werden, ob und wie Datenverkehr von eine
Zum Schutz des Datenverkehrs können die Protokolle AH und ESP benutzt werden, die in den folgenden Absätzen kurz vorgestellt werden.
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üf\-sum\-me gebildet.
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.
@ -311,7 +311,7 @@ An dieser Stelle kommt Strongswan als IKEv2-Dienst zum Einsatz.
Strongswan implementiert (neben weiteren Protokollen) das Protokoll IKEv2\footnote{Internet Key Exchange Protokoll Version~2, definiert in \cite[][]{RFC7296}} und kann darüber 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 Da\-ten\-ver\-kehrs über die Protokolle AH oder ESP wird jedoch direkt im IPsec-Stack des Kernels abgewickelt.
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.
@ -377,7 +377,7 @@ Mehr Details zur Benutzung von Wireguard unter Linux können anhand eines Beispi
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üs\-sel\-austausch-Protokoll und der ersten Nachricht des darauf folgenden Datentransport-Protokolls, welche den Sitzungsinitiator gegenüber dem anderen Sitzungsteilnehmer authentisiert, würden die Autoren die Sicherheit des Schlüsselaustauschs nicht beweisen können.
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, würden die Autoren die Sicherheit des Schlüsselaustauschs nicht beweisen können.
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}.
Im weiteren Verlauf wählen die Autoren eine Analysemethode, die eine Trennung von Handshake-Protokoll und Datentransport-Protokolls verlangt, welche die Autoren durch minimale Veränderungen am Wireguard-Protokoll herbeiführen \cite[][Abschnitt 1, \enquote{Our Contributions}]{wireguard:analysis}.
@ -411,7 +411,7 @@ Für die Freigabe von IPsec-Datenverkehr in einer Firewall sind somit mehrere Re
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-Zer\-ti\-fi\-ka\-ten verwendet, so reicht es aus, diese als Datei im PEM-Format bereitzustellen.
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 genutzt werden, und unter Mac OS steht Tunnelblick 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}.
@ -452,7 +452,7 @@ Im Betrieb besteht OpenVPN aus einem laufenden Programm, das über eine Konfigur
Eine Konfigurationsdatei für OpenVPN besteht aus einer zeilenweisen Auflistung von Optionen, die das OpenVPN-Programm als Argumente akzeptiert.
Alle Optionen werden in der Manpage von OpenVPN (nach Meinung des Autors) ausführlich und leicht verständlich erklärt und sollten für Einsteiger mit Grundkenntnissen in Bezug auf Netzwerke und Linux kein Hindernis darstellen.
Strong\-swan 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.
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 zeilenweisen Auflistungen aus Name-Wert-Paaren.
Zusätzlich enthalten die Konfigurationsdateien durch Schweifklammern abgegrenzte Abschnitte, in denen Konfigurationen für bestimmte Kontexte hinterlegt werden.
@ -468,7 +468,7 @@ Somit wird OpenVPN als VPN-Software zur Umsetzung des VPN-Dienst gewählt.
\chapter{Implementieren der Benutzerverwaltung} \label{cpt:implement_ca}
Die VPN-Software OpenVPN bringt OpenSSL als Abhängigkeit mit.
OpenSSL stellt eine Menge von Funktionen als Kommandozeilenwerkzeug zur Verfügung, mit denen alle Basisfunktionen einer Zertifizierungsstelle wie zum Beispiel die Erzeugung von Schlüssel\-paaren und Zertifikatsanträgen, sowie das Ausstellen von Zertifikaten auf Basis von Zertifikatsanträgen möglich ist.
OpenSSL stellt eine Menge von Funktionen 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.
Im Prinzip ist es möglich, durch manuelle Bedienung von OpenSSL eine \textit{Zertifizierungsstelle} (CA) zu 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.
@ -489,7 +489,7 @@ Die zum aktuellen Zeitpunkt (01.10.2018) über GitHub\footnote{\url{https://gith
EasyRSA wurde in Version~3 von Grund auf neu geschrieben und verfügt über ein im Vergleich zu EasyRSA Version~2 vereinfachtem Benutzerinterface, welches nun von einem einzigen Kommandozeilenbefehl zur Verfügung gestellt wird.
Zusätzlich hinzugekommen sind neue Features wie etwa die Unterstützung des \textit{Elliptische-Kurven-Kryptosystems} (EKK), Unterstützung von UTF-8 oder die Verwendung von AES256 zum Verschlüsseln 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.
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.
@ -515,7 +515,7 @@ Die Unterstützung von Zertifikaten mit RSA-Schlüsseln ist jedoch schon in Vers
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üs\-sel\-län\-ge und, im Fall von EKK, eine elliptische Kurve gewählt werden.
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 ersetzen.
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.
@ -562,7 +562,7 @@ Dabei sollte eine aktualisierte CRL noch vor Erreichen des \enquote{Next Update}
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 eine gültige CRL immer zur Verfügung steht.
Grund\-sätz\-lich stellt dies kein Problem dar: Sowohl das Ausstellen, als auch das Installieren der CRL auf dem OpenVPN-Server können automatisiert werden.
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.
@ -621,8 +621,8 @@ Um bei einem Defekt von Server~A ein Failover auf den Server~B durchzuführen, w
Anschließend werden die IP-Dienstadressen auf B aktiviert.
Sollte dieses Verfügbarkeitsniveau nicht mehr ausreichen, so muss lediglich ein weiteres IPv6-Netz für VPN-Clients bereitgestellt werden und neue IP-Dienstadressen für einen weiteren VPN-Dienst vergeben werden.
Damit ist ein Parallelbetrieb von zwei OpenVPN-Diensten möglich, die sich in der Konfiguration nur durch ihre IP-Dienst\-adresse und das verwendete IPv6-Netz für VPN-Clients unterscheiden.
In der OpenVPN-Client\-kon\-fi\-gu\-ra\-tion können beide VPN-Dienste 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.
In der OpenVPN-Clientkonfiguration können beide VPN-Dienste eingetragen werden, sodass die Clients bei Ausfall eines Servers automatisch eine Sitzung mit dem zweiten Server aufbauen können.
\paragraph{Lokale Firewall}
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.
@ -651,7 +651,7 @@ Nähere Informationen zu den verwendeten Optionen können in \cite[][]{man:openv
\paragraph{Erreichbarkeit des Dienstes}
Laut Anforderung~\ref{req:dualstack} aus Kapitel~\ref{par:requirements} soll der VPN-Dienst über IPv4 und IPv6 aus dem Internet erreichbar sein.
Als Ausgangspunkt dafür wird der DNS-Name des VPN-Dienst verwendet, der auf die IPv4- und IPv6-Dienst\-adresse zeigt.
Als Ausgangspunkt dafür wird der DNS-Name des VPN-Dienst verwendet, der auf die IPv4- und IPv6-Dienstadresse zeigt.
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}
@ -660,7 +660,7 @@ proto udp
proto udp6
multihome
\end{lstlisting}
OpenVPN beantwortet damit Anfragen für alle auf dem Server konfigurierten IP-Adres\-sen.
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 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.

View File

@ -2,6 +2,7 @@
\input{COMMON-Config.tex}
\input{COMMON-Style.tex}
\input{COMMON-Hyphenation.tex}
\author{Jan Philipp Timme}
\title{Konzeption und Umsetzung eines IPv6-VPN für die Abteilung Informatik}