Autosave

MA-Inhalt.tex

@@ -148,24 +148,26 @@ Dafür wird in diesem Kapitel das Konzept für den VPN-Dienst und das Konzept f
 
 
 \section{Konzeption des VPNs} \label{sct:vpn_concept}
-Aufgrund der Anforderungen ergibt sich, \dots
+viele Benutzer und ein Zugangspunkt zum Abteilungsnetz: Client-Server-Architektur
 
-viele Benutzer und ein Zugangspunkt, VPN-Clients sollen nicht untereinander kommunizieren: Client-Server-Architektur
+Erreichbarkeit über IPv4 und IPv6: VPN-Dienst muss auf beiden Protokollen Sitzungen annehmen
-
-Erreichbarkeit über IPv4 und IPv6
 
 Nur bestimmte Netzbereiche der Abteilung Informatik werden durch das VPN geroutet
-Wir werden aus Layer~3 tunneln und dafür müssen wir den VPN-Clients VPN-interne IPv4- und IPv6-Adressen vergeben.
-Für IPv4 wird aufgrund der angestrebten Benutzerzahl ein \texttt{/16}-Block vergeben.
-Wir müssen für IPv4 NAT machen, um zu verhindern, dass der private IPv4-Bereich (öffentliche IPv4-Netze dieser Größe sind ausverkauft) geroutet werden muss.
 
-Die Datenübertragung soll mit modernen Chiffren verschlüsselt werden und \textit{Perfect Forward Secrecy} (PFS) bieten.
+Wir werden auf Layer~3 tunneln und dafür müssen wir den VPN-Clients IPv4- und IPv6-Adressen innerhalb des VPNs vergeben.
 
-Nur autorisierte Benutzer sollen Zugang zum VPN erhalten.
+Für IPv4 wird aufgrund der 50-500 Benutzer gleich großzügig ein \texttt{/16}-Block eingeplant.
+
+- Wir müssen für IPv4 NAT machen, um zu verhindern, dass der private IPv4-Bereich (öffentliche IPv4-Netze dieser Größe sind ausverkauft) geroutet werden muss.
+- VPN-Clients sollen nicht untereinander kommunizieren
+Lokale Firewall schirmt VPN-Clients voneinander ab und macht NAT
+
+- Nur autorisierte Benutzer sollen Zugang zum VPN erhalten.
 Benutzer müssen sich authentisieren.
-
+Die Datenübertragung soll mit modernen Chiffren verschlüsselt werden und \textit{Perfect Forward Secrecy} (PFS) bieten.
 \todo{\dots}
 
+
 \section{Konzeption der Benutzerverwaltung} \label{sct:user_concept}
 Nachdem die VPN-Software für das Vorhaben dieser Arbeit ausgewählt wurde, wird ein Konzept zur Verwaltung der VPN-Benutzer benötigt.
 Zielgruppe des Dienstes sind Beschäftigte und Studierende der Abteilung Informatik in der Größenordnung von etwa 50-500~Benutzern.
@@ -225,7 +227,7 @@ In diesem Kapitel wird die Software ausgesucht, mit der der VPN-Dienst umgesetzt
 Dazu werden zunächst die Anforderungen ermittelt und analysiert.
 Im Anschluss werden dann passende Softwarekandidaten vorgestellt und für die Auswahl der in dieser Arbeit zu verwendenden Software gegenübergestellt.
 
-Anhand der Anforderungen~\ref{req:dualstack} bis \ref{req:finance} aus Abschnitt~\ref{par:requirements} werden vorhandene Programme ermittelt, die sich als Kandidat zur Umsetzung des VPN-Dienstes eignen.
+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}).
 
@@ -441,7 +443,7 @@ Die verschiedenen Konfigurationsdateien werden in ihren eigenen Manpages detaill
 \paragraph{Zusammenfassung und Auswahl}
 In diesem Abschnitt wurden OpenVPN und Strongswan als Lösungen für die Umsetzung eines VPN gegenübergestellt.
 Dabei hat sich gezeigt, dass OpenVPN in den Kategorien Plattformabhängigkeit, Verfügbarkeit des Quellcode, Komplexität und Benutzerfreundlichkeit im Vergleich zu Strongswan besser abschneidet.
-Dadurch ist OpenVPN besser für die Umsetzung eines VPN-Dienst geeignet, der die in Abschnitt~\ref{par:requirements} genannten Anforderungen erfüllt.
+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 gewählt.
 
 
@@ -547,7 +549,7 @@ Um auch bei manueller Installation der CRL einen unterbrechungsfreien Betrieb de
 
 \section{Betrieb der Zertifizierungsstelle} \label{sct:running_ca}
 Für den Betrieb der Zertifizierungsstelle wird in Absprache mit dem IT-Team eine virtuelle Maschine exklusiv für diesen Zweck erzeugt und im Mitarbeiter-Netz platziert.
-Unter Berücksichtigung der Anforderung \ref{req:serveros} aus Abschnitt~\ref{par:requirements} wird Debian~9 nach den Vorgaben des IT-Teams auf der virtuellen Maschine installiert.
+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}
@@ -577,7 +579,7 @@ Details zur Benutzung der CA sind in dem Dokument \enquote{Dokumentation der Zer
 
 
 \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 Abschnitt~\ref{par:requirements} bereits geklärt, wird laut Anforderung \ref{req:serveros} Debian~9 als Betriebssystem verwendet.
+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.
 
 
@@ -629,7 +631,7 @@ Nach Einrichtung des Servers wird in diesem Schritt die Konfiguration des OpenVP
 Nähere Informationen zu den verwendeten Optionen können in \cite[][]{man:openvpn} nachgeschlagen werden.
 
 \paragraph{Erreichbarkeit des Dienstes}
-Laut Anforderung~\ref{req:dualstack} aus Abschnitt~\ref{par:requirements} soll der VPN-Dienst über IPv4 und IPv6 aus dem Internet erreichbar sein.
+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.
 
 In der \textbf{Serverkonfiguration} reichen die ersten drei Zeilen aus, um über IPv4 und IPv6 auf UDP-Port~1194 den VPN-Dienst anzubieten:
@@ -714,7 +716,7 @@ Zusätzlich wird in der \enquote{Best Current Practice} RFC~7525 zur Deaktivieru
 Auf der DEFCON~26 wurde mit \enquote{VORACLE} ein in diesem Kontext relevanter Angriff auf OpenVPN vorgestellt\footnote{\url{https://media.defcon.org/DEF\%20CON\%2026/DEF\%20CON\%2026\%20presentations/Nafeez/DEFCON-26-Nafeez-Compression-Oracle-attacks-on-VPN-Networks.pdf}}, der auf aktivierter Kompression aufbaut.
 
 \paragraph{Zertifikatgestützte Authentisierung}
-Um die in Kapitel~\ref{sct:user_concept} beschriebene Zertifizierungsstelle zur Benutzerauthentisierung zu verwenden und die VPN-Kommunikation nach Anforderung~\ref{req:traffic} aus Abschnitt~\ref{par:requirements} abzusichern, wird OpenVPN im TLS-Modus betrieben.
+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.
 
@@ -738,7 +740,7 @@ remote-cert-tls client
 \end{lstlisting}
 
 \paragraph{Kryptografische Parameter}
-Wie in Abschnitt~\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.
+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 diese Absatz definierten Parametern soll die Kommunikation zwischen Clients und Server unabhängig von den verwendeten Betriebssystemen einheitlich geschützt werden.
@@ -890,7 +892,7 @@ Zum aktuellen Zeitpunkt (13.10.2018) ist OpenVPN~3 noch nicht bereit für den pr
 Sollte sich das jedoch ändern, könnte im Rahmen einer neuen Arbeit untersucht werden, welche Verbesserungen OpenVPN~3 mit sich bringt, und ob ein Umstieg von OpenVPN~2.4.0 auf OpenVPN~3 lohnenswert ist.
 
 \paragraph{Alternative Wireguard}
-Wie in Abschnitt~\ref{ssct:wireguard} aus Kapitel~\ref{cpt:choosing_vpn_software} dieser Arbeit bereits erwähnt wurde, ist Wireguard zum aktuellen Zeitpunkt (13.10.2018) noch in einem experimentellen Zustand.
+Wie in Kapitel~\ref{ssct:wireguard} dieser Arbeit bereits erwähnt wurde, ist Wireguard zum aktuellen Zeitpunkt (13.10.2018) noch in einem experimentellen Zustand.
 Sobald Wireguard für den produktiven Einsatz geeignet ist und Clientsoftware für alle benötigten Betriebssysteme zur Verfügung steht, kann in einer neuen Arbeit untersucht werden, ob die sich die Ablösung des VPN-Dienstes aus dieser Arbeit mit einer neuen Lösung auf Basis von Wireguard lohnt.
 Die bisherigen Angaben in Bezug auf Effizienz, Wahl der kryptografischen Parameter und Benutzerfreundlichkeit sprechen nach Meinung des Autors stark dafür, dass ein Umstieg von OpenVPN auf Wireguard vorteilhaft sei.