212 lines
8.4 KiB
TeX
212 lines
8.4 KiB
TeX
\chapter{Introduction} % Main chapter title
|
|
|
|
\label{Introduction}
|
|
|
|
Peer-to-peer overlay VPNs allow nodes to connect directly 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. We complement these performance benchmarks with a source
|
|
code analysis of each implementation, verified by the respective
|
|
maintainers. The entire
|
|
experimental framework is built on Nix, NixOS, and the Clan deployment
|
|
system, so every result is independently reproducible.
|
|
|
|
\section{Motivation}
|
|
|
|
Peer-to-peer architectures can provide censorship-resistant,
|
|
fault-tolerant infrastructure because they have no single point of
|
|
failure \cite{shukla_towards_2021}. Blockchain platforms like Ethereum
|
|
depend on this property, as do IoT edge networks and content delivery
|
|
systems. But these benefits only hold when nodes are spread across
|
|
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}), so nominally decentralized
|
|
infrastructure actually sits in 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}
|
|
|
|
This centralization persists because self-hosting is hard. Cloud
|
|
providers offer static IP addresses and publicly routable endpoints,
|
|
which avoids the networking problems that residential and small-office
|
|
deployments face.
|
|
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, stable peer
|
|
connectivity from self-hosted infrastructure has traditionally
|
|
required significant technical expertise.
|
|
|
|
Overlay VPNs solve this problem. They establish encrypted tunnels
|
|
that traverse NAT boundaries, so peers can connect directly without
|
|
static IP addresses or manual firewall configuration. Each node
|
|
receives a stable virtual address within the overlay network,
|
|
regardless of its physical network topology. A device behind
|
|
consumer-grade NAT can therefore participate as a first-class peer
|
|
in a distributed system.
|
|
|
|
The Clan deployment framework uses Nix and NixOS to eliminate
|
|
configuration drift and dependency conflicts, which makes it
|
|
practical for a single administrator to self-host distributed
|
|
services.
|
|
Overlay VPNs are central to Clan's architecture: they supply the
|
|
peer connectivity that lets nodes form a network regardless of
|
|
physical location or NAT situation.
|
|
As illustrated in Figure~\ref{fig:vision-stages}, Clan plans to offer
|
|
a web interface that lets users design and deploy private P2P networks
|
|
with minimal configuration, assisted by an integrated LLM.
|
|
|
|
During Clan's development, a recurring problem surfaced:
|
|
practitioners disagreed on which mesh VPN to use, each pointing to
|
|
different edge cases where their preferred VPN failed or lacked a
|
|
needed feature. These discussions relied on anecdotal evidence rather
|
|
than systematic evaluation, which motivated 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. They measure point-to-point
|
|
throughput, latency, and CPU overhead but do 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, looking at 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 work in several directions. It evaluates a
|
|
broader set of VPN implementations with emphasis on fully
|
|
decentralized architectures and tests them under application-level
|
|
workloads such as video streaming and package downloads. It also
|
|
applies multiple network impairment profiles and provides a
|
|
reproducible experimental framework built on Nix, NixOS, and Clan.
|
|
|
|
A secondary goal was to create an automated benchmarking framework
|
|
that generates a public leaderboard, similar in spirit to the
|
|
js-framework-benchmark (see Figure~\ref{fig:js-framework-benchmark}).
|
|
A web interface with regularly updated results gives VPN developers a
|
|
concrete baseline to measure against.
|
|
|
|
\section{Research Contribution}
|
|
|
|
This thesis makes the following contributions:
|
|
|
|
\begin{enumerate}
|
|
\item A benchmark of ten peer-to-peer VPN implementations across
|
|
seven workloads and four network impairment profiles. The workloads
|
|
include video streaming and package downloads alongside synthetic
|
|
throughput tests.
|
|
\item A source code analysis of all ten VPN implementations. Manual
|
|
code review was combined with LLM-assisted analysis and the results
|
|
were verified by the respective maintainers on GitHub.
|
|
\item A reproducible experimental framework built on Nix, NixOS,
|
|
and the Clan deployment system. Dependencies are pinned and system
|
|
configuration is declarative, down to deterministic cryptographic
|
|
material generation. Every result can be independently replicated.
|
|
\item A performance analysis showing 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 that produces a public
|
|
leaderboard, giving VPN developers a target to optimize
|
|
against.
|
|
\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}
|
|
|