{"id":534,"date":"2026-10-07T12:45:00","date_gmt":"2026-10-07T10:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?page_id=534"},"modified":"2026-09-25T10:49:13","modified_gmt":"2026-09-25T08:49:13","slug":"raspberry-pi-als-gehartetes-wireguard-vpn-gateway-mit-split-tunneling","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/raspberry-pi-de\/tutorials-de-raspberry-pi-de\/raspberry-pi-als-gehartetes-wireguard-vpn-gateway-mit-split-tunneling\/","title":{"rendered":"Raspberry Pi als geh\u00e4rtetes WireGuard-VPN-Gateway mit Split-Tunneling"},"content":{"rendered":"

Architektur-\u00dcberblick: WireGuard-Kernel-Routing und Split-Tunneling<\/h2>\n

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\u00fchrt. WireGuard<\/strong> operiert hingegen direkt im Linux-Kernel-Raum und nutzt moderne Kryptografie (ChaCha20, Poly1305, Curve25519), wodurch Datendurchs\u00e4tze von \u00fcber 800 MBit\/s an Gigabit-Ethernet-Schnittstellen bei minimaler Prozessorlast erreicht werden.<\/p>\n

In einer Split-Tunneling-Architektur<\/strong> fungiert der Raspberry Pi als geh\u00e4rtetes Sicherheits-Gateway. Anstatt den gesamten Internetverkehr eines Clients durch das Heimnetzwerk zu leiten \u2013 was die Bandbreite mobiler Verbindungen drosselt \u2013, leitet der Tunnel selektiv nur definierte Ziel-Subnetze (z. B. interne Home-Lab-Ressourcen unter 192.168.10.0\/24<\/code>) \u00fcber die verschl\u00fcsselte WireGuard-Schnittstelle. Umgekehrt kann das Gateway auch konfiguriert werden, um bestimmte lokale LAN-Ger\u00e4te gezielt \u00fcber einen externen VPN-Anbieter zu verschl\u00fcsseln, w\u00e4hrend der restliche LAN-Verkehr unber\u00fchrt bleibt.<\/p>\n

\n\"Split-Tunnel-Routing
Split-Tunneling in der Routing-Tabelle: Nur die beiden unter AllowedIPs<\/code> genannten Netze laufen \u00fcber wg0<\/code>. Das Gateway leitet sie auf Kernel-Ebene weiter und maskiert sie auf eth0<\/code>; der \u00fcbrige Verkehr verl\u00e4sst den Client direkt.<\/figcaption><\/figure>\n

Schritt-f\u00fcr-Schritt-Implementierungsanleitung<\/h2>\n

Schritt 1: Aktivierung des Linux-Kernel-IP-Forwardings<\/h3>\n

Um die Paketweiterleitung zwischen der physischen Netzwerkschnittstelle (eth0<\/code>) und dem virtuellen WireGuard-Interface (wg0<\/code>) zu erm\u00f6glichen, muss das IPv4- und IPv6-Forwarding dauerhaft im Linux-Kernel aktiviert werden:<\/p>\n

# \/etc\/sysctl.d\/99-wireguard-forwarding.conf\nnet.ipv4.ip_forward = 1\nnet.ipv6.conf.all.forwarding = 1\nnet.ipv4.conf.all.rp_filter = 1\nnet.ipv4.conf.default.rp_filter = 1<\/code><\/pre>\n
\u00dcbernahme der ge\u00e4nderten Kernel-Parameter im laufenden System ohne Neustart:<\/p>\n
sysctl --system<\/code><\/pre>\n
Schritt 2: Kryptografische Schl\u00fcsselerzeugung und Paketinstallation<\/h3>\n
Installation der WireGuard-Kernel-Werkzeuge sowie Generierung der privaten und \u00f6ffentlichen Schl\u00fcsselpaare mit restriktiven Dateirechten:<\/p>\n
apt update && apt install -y wireguard wireguard-tools nftables\nmkdir -p \/etc\/wireguard && cd \/etc\/wireguard\nchmod 700 \/etc\/wireguard\nwg genkey | tee server_private.key | wg pubkey > server_public.key\nchmod 600 server_private.key<\/code><\/pre>\n
Schritt 3: Konfiguration der geh\u00e4rteten Server-Schnittstelle (wg0.conf)<\/h3>\n
Die zentrale Konfigurationsdatei definiert den Server-Port, die Subnetz-Zuweisung und integrierte Firewall-Routingregeln. Der Standard-UDP-Port von WireGuard (51820<\/code>) wird zusammen mit strikten nftables<\/code>-Masquerading-Regeln konfiguriert:<\/p>\n
# \/etc\/wireguard\/wg0.conf\n[Interface]\nAddress = 10.100.0.1\/24\nListenPort = 51820\nPrivateKey = <SERVER_PRIVATE_KEY>\n\n# Automatisches Firewall-Masquerading via nftables\nPostUp = 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\nPostDown = nft delete table ip wireguard\n\n# Beispiel-Konfiguration f\u00fcr einen Split-Tunnel-Client\n[Peer]\nPublicKey = <CLIENT_PUBLIC_KEY>\nAllowedIPs = 10.100.0.2\/32<\/code><\/pre>\n
Schritt 4: Client-seitiges Split-Tunnel-Routing konfigurieren<\/h3>\n
Auf dem externen Client-Ger\u00e4t steuert die Direktive AllowedIPs<\/code>, 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<\/code> werden ausschlie\u00dflich Datenpakete f\u00fcr das Heimnetzwerk durch den verschl\u00fcsselten Tunnel geroutet, w\u00e4hrend allgemeiner Webverkehr auf dem Client direkt \u00fcber die eigene Internetverbindung erfolgt:<\/p>\n
# Client-seitige Konfiguration (Split-Tunneling-Modus)\n[Interface]\nPrivateKey = <CLIENT_PRIVATE_KEY>\nAddress = 10.100.0.2\/24\nDNS = 192.168.10.1\n\n[Peer]\nPublicKey = <SERVER_PUBLIC_KEY>\nEndpoint = vpn.lukaswojcik.com:51820\nAllowedIPs = 192.168.10.0\/24, 10.100.0.0\/24\nPersistentKeepalive = 25<\/code><\/pre>\n
Schritt 5: Qualit\u00e4tssicherung und Durchsatz-Validierung<\/h3>\n
Nach dem Start des systemd-Dienstes mittels systemctl enable --now wg-quick@wg0<\/code> muss eine \u00dcberpr\u00fcfung der Infrastruktur anhand von drei Diagnose-Schritten erfolgen:<\/p>\n
    \n
  1. Audit des Handshakes und Schl\u00fcsselaustauschs:<\/strong> Ausf\u00fchrung von wg show wg0<\/code> im Terminal des Raspberry Pi, um zu best\u00e4tigen, dass aktive Peers aktuelle Handshake-Zeitstempel und bidirektionale Datentransfers aufweisen.<\/li>\n
  2. Verifikation der Routing-Tabelle:<\/strong> Kontrolle der Client-Routingtabellen (z. B. ip route show<\/code>), um sicherzustellen, dass das Standard-Gateway unber\u00fchrt bleibt, w\u00e4hrend statische Routen f\u00fcr 192.168.10.0\/24<\/code> strikt auf das Interface wg0<\/code> verweisen.<\/li>\n
  3. Bandbreiten- und Latenz-Benchmark:<\/strong> Durchf\u00fchrung eines internen iperf3<\/code>-Durchsatztests zwischen dem externen Client und einem Server im Heimnetzwerk zur Pr\u00fcfung, ob die \u00dcbertragungsrate ohne Paketfragmentierung die Leitungskapazit\u00e4t aussch\u00f6pft.<\/li>\n<\/ol>\n
    Zusammenfassung und resultierender Mehrwert<\/h2>\n
    Was sich damit erreichen l\u00e4sst:<\/strong> Der Aufbau eines geh\u00e4rteten, im Linux-Kernel operierenden WireGuard-VPN-Gateways auf einem Raspberry Pi mit selektivem Split-Tunneling und automatisiertem Firewall-Masquerading.<\/p>\n
    Resultierender Mehrwert:<\/strong><\/p>\n