several fixups discussed on tuesday
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
|
||||
\chapter{Conclusion} % Main chapter title
|
||||
|
||||
\label{Conclusion}
|
||||
\label{Conclusion}
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
|
||||
\chapter{Discussion} % Main chapter title
|
||||
|
||||
\label{Discussion}
|
||||
\label{Discussion}
|
||||
|
||||
@@ -72,7 +72,6 @@ and reordering. These impairments are applied symmetrically on all
|
||||
machines, meaning effective round-trip impairment is approximately
|
||||
double the per-machine values.
|
||||
|
||||
|
||||
\subsection{Configuration Methodology}
|
||||
|
||||
Each VPN is built from source within the Nix flake, ensuring that all
|
||||
@@ -82,7 +81,7 @@ under \texttt{pkgs/} in the flake.
|
||||
|
||||
Cryptographic material (WireGuard keys, Nebula certificates, ZeroTier
|
||||
identities) is generated deterministically via Clan's vars generator
|
||||
system.
|
||||
system.
|
||||
|
||||
Generated keys are stored in version control under
|
||||
\texttt{vars/per-machine/\{name\}/} and read at NixOS evaluation time,
|
||||
@@ -101,7 +100,8 @@ Table~\ref{tab:benchmark_suite} summarises each benchmark.
|
||||
\label{tab:benchmark_suite}
|
||||
\begin{tabular}{llll}
|
||||
\hline
|
||||
\textbf{Benchmark} & \textbf{Protocol} & \textbf{Duration} & \textbf{Key Metrics} \\
|
||||
\textbf{Benchmark} & \textbf{Protocol} & \textbf{Duration} &
|
||||
\textbf{Key Metrics} \\
|
||||
\hline
|
||||
Ping & ICMP & 3 runs $\times$ 100 pkts & RTT, packet loss \\
|
||||
TCP iPerf3 & TCP & 30 s & Throughput, retransmits, CPU \\
|
||||
@@ -348,8 +348,6 @@ typical observations, while min and max capture outlier behavior.
|
||||
The nix-cache benchmark additionally reports standard deviation via
|
||||
hyperfine's built-in statistical output.
|
||||
|
||||
|
||||
|
||||
\section{Source Code Analysis}
|
||||
|
||||
To complement the performance benchmarks with architectural
|
||||
@@ -517,8 +515,6 @@ wall-clock duration, number of attempts, VPN restart count and
|
||||
duration, connectivity wait time, source and target machine names,
|
||||
and on failure, the relevant service logs.
|
||||
|
||||
|
||||
|
||||
\section{VPNs Under Test}
|
||||
|
||||
VPNs were selected based on:
|
||||
@@ -532,7 +528,6 @@ VPNs were selected based on:
|
||||
\bitem{Linux support:} All VPNs must run on Linux.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
Ten VPN implementations were selected for evaluation, spanning a range
|
||||
of architectures from centralized coordination to fully decentralized
|
||||
mesh topologies. Table~\ref{tab:vpn_selection} summarizes the selection.
|
||||
|
||||
@@ -12,8 +12,6 @@ The chapter concludes with findings from the source code analysis.
|
||||
|
||||
\section{Baseline Performance}
|
||||
|
||||
|
||||
|
||||
% Under the baseline impairment profile (no added latency, loss, or
|
||||
% reordering), the overhead introduced by each VPN relative to the
|
||||
% internal (no VPN) baseline and WireGuard can be measured in isolation.
|
||||
@@ -97,4 +95,4 @@ High impairment profiles defined in Chapter~\ref{Methodology}.
|
||||
\section{Summary of Findings}
|
||||
|
||||
% Brief summary table or ranking of VPNs by key metrics.
|
||||
% Save deeper interpretation for a Discussion chapter.
|
||||
% Save deeper interpretation for a Discussion chapter.
|
||||
|
||||
@@ -6,6 +6,7 @@ extend-exclude = [
|
||||
"**/facter-report.nix",
|
||||
"**/key.json",
|
||||
"pkgs/clan-cli/clan_lib/machines/test_suggestions.py",
|
||||
"Chapters/Zusammenfassung.tex",
|
||||
]
|
||||
|
||||
[default.extend-words]
|
||||
|
||||
33
main.tex
33
main.tex
@@ -95,7 +95,8 @@
|
||||
% THESIS INFORMATION
|
||||
%----------------------------------------------------------------------------------------
|
||||
|
||||
\thesistitle{An Analysis of P2P VPN Implementation} % Your thesis title, this is used in the title
|
||||
\thesistitle{An Analysis of P2P VPN Implementation} % Your thesis
|
||||
% title, this is used in the title
|
||||
% and abstract, print it elsewhere with \ttitle
|
||||
%\supervisor{\textsc{Ber Lorke}} % Your supervisor's name, this is
|
||||
% used in the title page, print it elsewhere with \supname
|
||||
@@ -248,35 +249,7 @@ and Management}} % Your department's name and URL, this is used in
|
||||
|
||||
\end{abstract}
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% GERMAN ABSTRACT PAGE
|
||||
%----------------------------------------------------------------------------------------
|
||||
|
||||
\begingroup
|
||||
\renewcommand{\abstractname}{Zusammenfassung}
|
||||
\begin{abstract}
|
||||
\addchaptertocentry{Zusammenfassung}
|
||||
|
||||
Diese Arbeit untersucht Peer-to-Peer-Mesh-VPNs mithilfe eines
|
||||
reproduzierbaren, Nix-basierten Frameworks, das auf einem
|
||||
Deployment-System namens Clan aufbaut. Wir evaluieren zehn
|
||||
VPN-Implementierungen, darunter Tailscale (über Headscale),
|
||||
Hyprspace, Nebula, Tinc und ZeroTier, unter vier
|
||||
Netzwerkbeeinträchtigungsprofilen mit variierendem Paketverlust,
|
||||
Paketumsortierung, Latenz und Jitter, was über 300 einzelne
|
||||
Messungen in sieben Benchmarks ergibt.
|
||||
|
||||
Unsere Analyse zeigt, dass Tailscale unter beeinträchtigten
|
||||
Bedingungen den Standard-Netzwerkstack des Linux-Kernels
|
||||
übertrifft, was auf seinen Userspace-IP-Stack mit optimierten
|
||||
Parametern zurückzuführen ist. Wir bestätigen dies, indem wir die
|
||||
Benchmarks mit entsprechend angepassten Kernel-Parametern erneut
|
||||
durchführen und vergleichbare Durchsatzgewinne beobachten. Die
|
||||
Untersuchung deckte zudem eine kritische Sicherheitslücke in einem
|
||||
der evaluierten VPNs auf.
|
||||
|
||||
\end{abstract}
|
||||
\endgroup
|
||||
\input{Chapters/Zusammenfassung}
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% ACKNOWLEDGEMENTS
|
||||
|
||||
Reference in New Issue
Block a user