229 lines
9.1 KiB
TeX
229 lines
9.1 KiB
TeX
\chapter{Introduction} % Main chapter title
|
|
|
|
\label{Introduction}
|
|
|
|
Peer-to-peer overlay VPNs promise to restore genuine decentralization
|
|
by enabling direct connectivity between nodes regardless of NAT or
|
|
firewall restrictions. Yet practitioners choosing among the growing
|
|
number of mesh VPN implementations must rely largely on anecdotal
|
|
evidence: systematic, reproducible comparisons under realistic
|
|
conditions are scarce.
|
|
|
|
This thesis addresses that gap. We benchmark ten peer-to-peer VPN
|
|
implementations across seven workloads and four network impairment
|
|
profiles, yielding over 300 unique measurements. We complement these
|
|
performance benchmarks with a source code analysis of each
|
|
implementation, verified through direct engagement with the respective
|
|
maintainers. The entire experimental framework is built on Nix, NixOS,
|
|
and the Clan deployment system, making every result independently
|
|
reproducible.
|
|
|
|
\section{Motivation}
|
|
|
|
Peer-to-peer architectures promise censorship-resistant, fault-tolerant
|
|
infrastructure by eliminating single points of failure
|
|
\cite{shukla_towards_2021}.
|
|
These architectures underpin a growing range of systems, from IoT
|
|
edge computing and content delivery networks to blockchain platforms
|
|
like Ethereum.
|
|
Yet realizing these benefits requires distributing nodes across
|
|
genuinely diverse hosting entities.
|
|
|
|
In practice, this diversity remains illusory.
|
|
Amazon, Hetzner, and OVH collectively host 70\% of all Ethereum nodes
|
|
(see Figure~\ref{fig:ethernodes_hosting}),
|
|
concentrating nominally decentralized infrastructure
|
|
within a handful of cloud providers.
|
|
More concerning, these providers operate under overlapping regulatory
|
|
jurisdictions,
|
|
predominantly the United States and the European Union.
|
|
This concentration undermines technical sovereignty:
|
|
a single governmental action could compel service termination,
|
|
data disclosure, or traffic manipulation across a majority of the network.
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[width=1\textwidth]{Figures/ethernodes_hosting.png}
|
|
\caption{Distribution of Ethereum nodes hosted by various providers
|
|
\cite{noauthor_isps_nodate}}
|
|
\label{fig:ethernodes_hosting}
|
|
\end{figure}
|
|
|
|
Why does this centralization persist despite the explicit goals of
|
|
decentralization?
|
|
The answer lies in the practical barriers to self-hosting.
|
|
Cloud providers offer static IP addresses and publicly routable endpoints,
|
|
eliminating the networking complexity that plagues residential and
|
|
small-office deployments.
|
|
Most internet-connected devices sit behind Network Address Translation (NAT),
|
|
which prevents incoming connections without explicit port forwarding
|
|
or relay infrastructure.
|
|
Combined with dynamic IP assignments from ISPs, maintaining stable
|
|
peer connectivity
|
|
from self-hosted infrastructure traditionally required significant
|
|
technical expertise.
|
|
|
|
Overlay VPNs offer a solution to this fundamental barrier.
|
|
By establishing encrypted tunnels that traverse NAT boundaries,
|
|
mesh VPNs enable direct peer-to-peer connectivity without requiring
|
|
static IP addresses or manual firewall configuration.
|
|
Each node receives a stable virtual address within the overlay network,
|
|
regardless of its underlying network topology.
|
|
In practice, this means a device behind consumer-grade NAT can
|
|
participate as a first-class peer in a distributed system,
|
|
removing the primary technical advantage that cloud providers hold.
|
|
|
|
The Clan deployment framework builds on this foundation.
|
|
Clan uses Nix and NixOS to eliminate configuration drift and
|
|
dependency conflicts, reducing operational overhead enough for a
|
|
single administrator to reliably self-host complex distributed
|
|
services.
|
|
Overlay VPNs are central to Clan's architecture,
|
|
providing the secure peer connectivity that enables nodes
|
|
to form cohesive networks regardless of their physical location or
|
|
NAT situation.
|
|
As illustrated in Figure~\ref{fig:vision-stages}, Clan envisions
|
|
a web interface that enables users to design and deploy private P2P networks
|
|
with minimal configuration, assisted by an integrated LLM
|
|
for contextual guidance and troubleshooting.
|
|
|
|
During the development of Clan, a recurring challenge became apparent:
|
|
practitioners held divergent preferences for mesh VPN solutions,
|
|
each citing different edge cases where their chosen VPN
|
|
proved unreliable or lacked essential features.
|
|
These discussions were grounded in anecdotal evidence rather than
|
|
systematic evaluation, motivating the present work.
|
|
|
|
\subsection{Related Work}
|
|
|
|
Existing research offers only partial coverage of this space.
|
|
Lackorzynski et al.\ \cite{lackorzynski_comparative_2019} benchmark
|
|
OpenVPN, IPSec, Tinc, Freelan, MACsec, and WireGuard in the context
|
|
of industrial communication systems, measuring point-to-point
|
|
throughput, latency, and CPU overhead. Their work does not address
|
|
overlay network behavior such as NAT traversal or dynamic peer discovery.
|
|
The most closely related study by Kjorveziroski et al.\
|
|
\cite{kjorveziroski_full-mesh_2024} evaluates full-mesh VPN solutions
|
|
for distributed systems, analyzing throughput, reliability under packet
|
|
loss, and relay behavior for VPNs including ZeroTier. However, it
|
|
focuses primarily on solutions with a central point of failure and
|
|
limits its workloads to synthetic iperf3 tests. This thesis extends
|
|
that foundation by evaluating a broader set of VPN implementations
|
|
with emphasis on fully decentralized architectures, exercising them
|
|
under real-world workloads such as video streaming and package
|
|
downloads, applying multiple network impairment profiles, and
|
|
providing a fully reproducible experimental framework built on
|
|
Nix, NixOS, and Clan.
|
|
|
|
Beyond filling this research gap, a further goal was to create a fully
|
|
automated benchmarking framework capable of generating a public
|
|
leaderboard, similar in spirit to the js-framework-benchmark
|
|
(see Figure~\ref{fig:js-framework-benchmark}). By providing an
|
|
accessible web interface with regularly updated
|
|
results, the framework gives VPN developers a concrete, public
|
|
baseline to measure against.
|
|
|
|
\section{Research Contribution}
|
|
|
|
This thesis makes the following contributions:
|
|
|
|
\begin{enumerate}
|
|
\item A comprehensive benchmark of ten peer-to-peer VPN
|
|
implementations across seven workloads (including real-world
|
|
video streaming and package downloads) and four network
|
|
impairment profiles, producing over 300 unique measurements.
|
|
\item A source code analysis of all ten VPN implementations,
|
|
combining manual code review with LLM-assisted analysis,
|
|
followed by verification through direct engagement with the
|
|
respective maintainers on GitHub.
|
|
\item A fully reproducible experimental framework built on
|
|
Nix, NixOS, and the Clan deployment system, with pinned
|
|
dependencies, declarative system configuration, and
|
|
deterministic cryptographic material generation, enabling
|
|
independent replication of all results.
|
|
\item A performance analysis demonstrating that Tailscale
|
|
outperforms the Linux kernel's default networking stack under
|
|
degraded conditions, and that kernel parameter tuning (Reno
|
|
congestion control in place of CUBIC, with RACK
|
|
disabled) yields measurable throughput improvements.
|
|
\item The discovery of several security vulnerabilities across
|
|
the evaluated VPN implementations.
|
|
\item An automated benchmarking framework designed for public
|
|
leaderboard generation, intended to encourage ongoing
|
|
optimization by VPN developers.
|
|
\end{enumerate}
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[width=1\textwidth]{Figures/krause-js-framework.png}
|
|
\caption{js-framework-benchmark results for Chrome 144.0
|
|
\cite{krause_krausestjs-framework-benchmark_2026}}
|
|
\label{fig:js-framework-benchmark}
|
|
\end{figure}
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
|
|
% Row 1
|
|
\begin{subfigure}{0.45\textwidth}
|
|
\centering
|
|
\includegraphics[width=\linewidth]{Figures/vision/stage1.png}
|
|
\caption{Stage 1}
|
|
\end{subfigure}
|
|
\hfill
|
|
\begin{subfigure}{0.45\textwidth}
|
|
\centering
|
|
\includegraphics[width=\linewidth]{Figures/vision/stage2.png}
|
|
\caption{Stage 2}
|
|
\end{subfigure}
|
|
|
|
\vspace{1em} % Add spacing between rows
|
|
|
|
% Row 2
|
|
\begin{subfigure}{0.45\textwidth}
|
|
\centering
|
|
\includegraphics[width=\linewidth]{Figures/vision/stage3.png}
|
|
\caption{Stage 3}
|
|
\end{subfigure}
|
|
\hfill
|
|
\begin{subfigure}{0.45\textwidth}
|
|
\centering
|
|
\includegraphics[width=\linewidth]{Figures/vision/stage4.png}
|
|
\caption{Stage 4}
|
|
\end{subfigure}
|
|
|
|
\vspace{1em} % Add spacing between rows
|
|
|
|
% Row 3
|
|
\begin{subfigure}{0.45\textwidth}
|
|
\centering
|
|
\includegraphics[width=\linewidth]{Figures/vision/stage5.png}
|
|
\caption{Stage 5}
|
|
\end{subfigure}
|
|
\hfill
|
|
\begin{subfigure}{0.45\textwidth}
|
|
\centering
|
|
\includegraphics[width=\linewidth]{Figures/vision/stage6.png}
|
|
\caption{Stage 6}
|
|
\end{subfigure}
|
|
|
|
\vspace{1em} % Add spacing between rows
|
|
|
|
% Row 4
|
|
\begin{subfigure}{0.45\textwidth}
|
|
\centering
|
|
\includegraphics[width=\linewidth]{Figures/vision/stage7.png}
|
|
\caption{Stage 7}
|
|
\end{subfigure}
|
|
\hfill
|
|
\begin{subfigure}{0.45\textwidth}
|
|
\centering
|
|
\includegraphics[width=\linewidth]{Figures/vision/stage8.png}
|
|
\caption{Stage 8}
|
|
\end{subfigure}
|
|
|
|
\caption{Planned web interface for setting up a Clan family network}
|
|
\label{fig:vision-stages}
|
|
\end{figure}
|
|
|