Raspberry Pi als gehärtetes WireGuard-VPN-Gateway mit Split-Tunneling

Architektur-Überblick: WireGuard-Kernel-Routing und Split-Tunneling

Klassische VPN-Protokolle wie OpenVPN oder IPsec erfordern rechenintensive Kontextwechsel im Userspace und komplexe kryptografische Handshakes, was auf Einplatinencomputern mit ARM-Architektur wie dem Raspberry Pi zu hohem CPU-Overhead und Latenzen führt. WireGuard operiert hingegen direkt im Linux-Kernel-Raum und nutzt moderne Kryptografie (ChaCha20, Poly1305, Curve25519), wodurch Datendurchsätze von über 800 MBit/s an Gigabit-Ethernet-Schnittstellen bei minimaler Prozessorlast erreicht werden.

In einer Split-Tunneling-Architektur fungiert der Raspberry Pi als gehärtetes Sicherheits-Gateway. Anstatt den gesamten Internetverkehr eines Clients durch das Heimnetzwerk zu leiten – was die Bandbreite mobiler Verbindungen drosselt –, leitet der Tunnel selektiv nur definierte Ziel-Subnetze (z. B. interne Home-Lab-Ressourcen unter 192.168.10.0/24) über die verschlüsselte WireGuard-Schnittstelle. Umgekehrt kann das Gateway auch konfiguriert werden, um bestimmte lokale LAN-Geräte gezielt über einen externen VPN-Anbieter zu verschlüsseln, während der restliche LAN-Verkehr unberührt bleibt.

Schritt-für-Schritt-Implementierungsanleitung

Schritt 1: Aktivierung des Linux-Kernel-IP-Forwardings

Um die Paketweiterleitung zwischen der physischen Netzwerkschnittstelle (eth0) und dem virtuellen WireGuard-Interface (wg0) zu ermöglichen, muss das IPv4- und IPv6-Forwarding dauerhaft im Linux-Kernel aktiviert werden:

# /etc/sysctl.d/99-wireguard-forwarding.conf
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

Übernahme der geänderten Kernel-Parameter im laufenden System ohne Neustart:

sysctl --system

Schritt 2: Kryptografische Schlüsselerzeugung und Paketinstallation

Installation der WireGuard-Kernel-Werkzeuge sowie Generierung der privaten und öffentlichen Schlüsselpaare mit restriktiven Dateirechten:

apt update && apt install -y wireguard wireguard-tools nftables
mkdir -p /etc/wireguard && cd /etc/wireguard
chmod 700 /etc/wireguard
wg genkey | tee server_private.key | wg pubkey > server_public.key
chmod 600 server_private.key

Schritt 3: Konfiguration der gehärteten Server-Schnittstelle (wg0.conf)

Die zentrale Konfigurationsdatei definiert den Server-Port, die Subnetz-Zuweisung und integrierte Firewall-Routingregeln. Der Standard-UDP-Port von WireGuard (51820) wird zusammen mit strikten nftables-Masquerading-Regeln konfiguriert:

# /etc/wireguard/wg0.conf
[Interface]
Address = 10.100.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>

# Automatisches Firewall-Masquerading via nftables
PostUp = nft add table ip wireguard; nft add chain ip wireguard nat { type nat hook postrouting priority 100\; policy accept\; }; nft add rule ip wireguard nat oifname "eth0" masquerade
PostDown = nft delete table ip wireguard

# Beispiel-Konfiguration für einen Split-Tunnel-Client
[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.100.0.2/32

Schritt 4: Client-seitiges Split-Tunnel-Routing konfigurieren

Auf dem externen Client-Gerät steuert die Direktive AllowedIPs, ob die Verbindung als Full-Tunnel oder Split-Tunnel arbeitet. Durch die Definition von AllowedIPs = 192.168.10.0/24, 10.100.0.0/24 werden ausschließlich Datenpakete für das Heimnetzwerk durch den verschlüsselten Tunnel geroutet, während allgemeiner Webverkehr auf dem Client direkt über die eigene Internetverbindung erfolgt:

# Client-seitige Konfiguration (Split-Tunneling-Modus)
[Interface]
PrivateKey = <CLIENT_PRIVATE_KEY>
Address = 10.100.0.2/24
DNS = 192.168.10.1

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = vpn.lukaswojcik.com:51820
AllowedIPs = 192.168.10.0/24, 10.100.0.0/24
PersistentKeepalive = 25

Schritt 5: Qualitätssicherung und Durchsatz-Validierung

Nach dem Start des systemd-Dienstes mittels systemctl enable --now wg-quick@wg0 muss eine Überprüfung der Infrastruktur anhand von drei Diagnose-Schritten erfolgen:

1. Audit des Handshakes und Schlüsselaustauschs: Ausführung von wg show wg0 im Terminal des Raspberry Pi, um zu bestätigen, dass aktive Peers aktuelle Handshake-Zeitstempel und bidirektionale Datentransfers aufweisen.
2. Verifikation der Routing-Tabelle: Kontrolle der Client-Routingtabellen (z. B. ip route show), um sicherzustellen, dass das Standard-Gateway unberührt bleibt, während statische Routen für 192.168.10.0/24 strikt auf das Interface wg0 verweisen.
3. Bandbreiten- und Latenz-Benchmark: Durchführung eines internen iperf3-Durchsatztests zwischen dem externen Client und einem Server im Heimnetzwerk zur Prüfung, ob die Übertragungsrate ohne Paketfragmentierung die Leitungskapazität ausschöpft.

Zusammenfassung und resultierender Mehrwert

Was sich damit erreichen lässt: Der Aufbau eines gehärteten, im Linux-Kernel operierenden WireGuard-VPN-Gateways auf einem Raspberry Pi mit selektivem Split-Tunneling und automatisiertem Firewall-Masquerading.

Resultierender Mehrwert:

• Verzögerungsfreier Fernzugriff: Interne Home-Lab-Dienste, Dashboards und Speicher-Knoten sind von unterwegs sicher erreichbar, ohne dass interne Ports am Router freigegeben werden müssen.
• Optimierte Bandbreiten-Nutzung: Split-Tunneling verhindert, dass externer Streaming- oder Webverkehr unnötig durch die Upload-Leitung des Heimanschlusses fließt, wodurch die maximale Download-Geschwindigkeit auf den Clients erhalten bleibt.
• Minimaler Hardware-Ressourcenverbrauch: Die Ausführung auf Kernel-Ebene benötigt je übertragenem Gigabyte deutlich weniger Rechenzeit als Userspace-Protokolle wie OpenVPN, sodass spürbar mehr Systemressourcen für containerisierte Anwendungen frei bleiben.