several fixups discussed on tuesday

This commit is contained in:
2026-03-06 17:34:31 +01:00
parent ec32331bae
commit c168a1b441
5 changed files with 102 additions and 129 deletions

View File

@@ -72,53 +72,6 @@ and reordering. These impairments are applied symmetrically on all
machines, meaning effective round-trip impairment is approximately
double the per-machine values.
\section{VPNs Under Test}
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.
\begin{table}[H]
\centering
\caption{VPN implementations included in the benchmark}
\label{tab:vpn_selection}
\begin{tabular}{lll}
\hline
\textbf{VPN} & \textbf{Architecture} & \textbf{Notes} \\
\hline
Tailscale (Headscale) & Coordinated mesh & Open-source
coordination server \\
ZeroTier & Coordinated mesh & Global virtual Ethernet \\
Nebula & Coordinated mesh & Slack's overlay network \\
Tinc & Fully decentralized & Established since 1998 \\
Yggdrasil & Fully decentralized & Spanning-tree routing \\
Mycelium & Fully decentralized & End-to-end encrypted IPv6 overlay \\
Hyprspace & Fully decentralized & libp2p-based, IPFS-compatible \\
EasyTier & Fully decentralized & Rust-based, multi-protocol \\
VpnCloud & Fully decentralized & Lightweight, kernel bypass option \\
WireGuard & Point-to-point & Reference baseline (not a mesh VPN) \\
\hline
Internal (no VPN) & N/A & Baseline for raw network performance \\
\hline
\end{tabular}
\end{table}
WireGuard is included as a reference point despite not being a mesh VPN.
Its minimal overhead and widespread adoption make it a useful comparison
for understanding the cost of mesh coordination and NAT traversal logic.
\subsection{Selection Criteria}
VPNs were selected based on:
\begin{itemize}
\bitem{NAT traversal capability:} All selected VPNs can establish
connections between peers behind NAT without manual port forwarding.
\bitem{Decentralization:} Preference for solutions without mandatory
central servers, though coordinated-mesh VPNs were included for comparison.
\bitem{Active development:} Only VPNs with recent commits and
maintained releases were considered.
\bitem{Linux support:} All VPNs must run on Linux.
\end{itemize}
\subsection{Configuration Methodology}
@@ -129,12 +82,7 @@ under \texttt{pkgs/} in the flake.
Cryptographic material (WireGuard keys, Nebula certificates, ZeroTier
identities) is generated deterministically via Clan's vars generator
system. For example, WireGuard keys are generated as:
\begin{verbatim}
wg genkey > "$out/private-key"
wg pubkey < "$out/private-key" > "$out/public-key"
\end{verbatim}
system.
Generated keys are stored in version control under
\texttt{vars/per-machine/\{name\}/} and read at NixOS evaluation time,
@@ -273,11 +221,6 @@ bursts, because a packet that was lost or reordered increases the
probability that the next packet suffers the same fate. This produces
realistic bursty degradation rather than uniformly distributed drops.
The ``Low'' profile approximates a well-provisioned continental
connection, ``Medium'' represents intercontinental links or congested
networks, and ``High'' simulates severely degraded conditions such as
satellite links or highly congested mobile networks.
A 30-second stabilization period follows TC application before
measurements begin, allowing queuing disciplines to settle.
@@ -405,6 +348,8 @@ 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
@@ -571,3 +516,53 @@ test-specific payload, and a \texttt{meta} object recording
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:
\begin{itemize}
\bitem{NAT traversal capability:} All selected VPNs can establish
connections between peers behind NAT without manual port forwarding.
\bitem{Decentralization:} Preference for solutions without mandatory
central servers, though coordinated-mesh VPNs were included for comparison.
\bitem{Active development:} Only VPNs with recent commits and
maintained releases were considered (with the exception of VPN Cloud).
\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.
\begin{table}[H]
\centering
\caption{VPN implementations included in the benchmark}
\label{tab:vpn_selection}
\begin{tabular}{lll}
\hline
\textbf{VPN} & \textbf{Architecture} & \textbf{Notes} \\
\hline
Tailscale (Headscale) & Coordinated mesh & Open-source
coordination server \\
ZeroTier & Coordinated mesh & Global virtual Ethernet \\
Nebula & Coordinated mesh & Slack's overlay network \\
Tinc & Fully decentralized & Established since 1998 \\
Yggdrasil & Fully decentralized & Spanning-tree routing \\
Mycelium & Fully decentralized & End-to-end encrypted IPv6 overlay \\
Hyprspace & Fully decentralized & libp2p-based, IPFS-compatible \\
EasyTier & Fully decentralized & Rust-based, multi-protocol \\
VpnCloud & Fully decentralized & Lightweight, kernel bypass option \\
WireGuard & Point-to-point & Reference baseline (not a mesh VPN) \\
\hline
Internal (no VPN) & N/A & Baseline for raw network performance \\
\hline
\end{tabular}
\end{table}
WireGuard is included as a reference point despite not being a mesh VPN.
Its minimal overhead and widespread adoption make it a useful comparison
for understanding the cost of mesh coordination and NAT traversal logic.