JPT/masterthesis
0
0
Fork 0
Code Issues Pull Requests Activity

Autosave

Browse Source
This commit is contained in:
Jan Philipp Timme 2018-11-01 14:01:47 +01:00
parent 10eaac8db3
commit 22f00f183d
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
MA-Inhalt.tex
View File

@ -174,8 +174,8 @@ Diese Vorgehensweise ist jedoch nicht sinnvoll, da der VPN-Dienst für mindesten
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 VPN soll auf OSI-Layer~3 stattfinden, da lediglich IPv4- und IPv6-Datenverkehr durch das VPN übertragen werden soll (\ref{req:routing}).
Sonstige Protokolle auf Layer~3 oder Layer~2 werden nicht benötigt.
Die Kommunikation innerhalb des VPN 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 Bandbreite verschwenden.
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.
@ -386,7 +386,7 @@ Im Vergleich zu OpenVPN und IPsec arbeitet Wireguard als Kernel-Modul schneller
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-Layer~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}.
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.
@ -583,12 +583,12 @@ remote vpn-test.inform.hs-hannover.de 1194
Das UDP-Protokoll wird verwendet, weil das TCP-Protokoll in Kombination mit stark ausgelasteten Netzwerken oder beim Transport von TCP-Paketen durch den VPN-Tunnel Performanceeinbußen verursachen kann \cite[][Option \texttt{--proto}]{man:openvpn}.
Bei Interesse kann eine detaillierte Analyse der Probleme der TCP-in-TCP-Situation in \cite[][]{analysis:tcpintcp} nachgelesen werden.
\paragraph{OSI-Layer des VPN-Tunnels:}
OpenVPN unterstützt den Aufbau eines VPN-Tunnels auf OSI-Layer~2 und OSI-Layer~3.
\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-Layer~2 nicht benötigt.
Zusätzlich würde ein VPN-Tunnel auf OSI-Layer~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-Layer~3 und wird mit der folgenden Anweisung in \textbf{Client- und Serverkonfiguration} eingestellt.
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 und wird mit der folgenden Anweisung in \textbf{Client- und Serverkonfiguration} eingestellt.
\begin{lstlisting}
dev tun
\end{lstlisting}
@ -961,7 +961,7 @@ Nach Wissen des Autors ist es Studierenden der Abteilung Informatik nur mit Gene
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 Layer~2 durch andere Privatgeräte mit Wireguard durch die Verschlüsselung des Netzwerkverkehrs effektiv verhindert.
Als positiver Nebeneffekt werden \enquote{Lauschangriffe} auf Schicht~2 durch andere Privatgeräte mit Wireguard durch die Verschlüsselung des Netzwerkverkehrs 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 unterschiedliche Zugriffsrechte für verschiedene Wireguard-Teilnehmer möglich und sinnvoll ist.
% End of content