Mit WireGuard auf das Heimnetz zugreifen: Raspberry Pi als VPN-Zugang einrichten

Ein Raspberry Pi kann einen WireGuard-Zugang zum Heimnetz bereitstellen. Beim Split-Tunneling laufen nur festgelegte Zielnetze durch den Tunnel; der übrige Internetverkehr nutzt weiterhin den lokalen Anschluss des Clients. Diese Anleitung beschränkt den VPN-Zugang auf ein IPv4-Heimnetz und ergänzt echte Filterregeln. Masquerading ersetzt beim Weiterleiten die Quelladresse des Clients durch die Adresse des Pi. Das erleichtert den Rückweg für Antworten, begrenzt aber allein noch keinen Zugriff.

WireGuard ist unter Linux im Kernel integriert. Daraus folgt kein fester Durchsatz: Pi-Modell, CPU, Netzwerk, Gegenstelle und Anschluss beeinflussen das Ergebnis. Auch IPsec verarbeitet den Datenverkehr unter Linux üblicherweise im Kernel; OpenVPN kann dafür Data Channel Offload verwenden. Pauschale Aussagen über mehr als 800 MBit/s, minimale CPU-Last oder verzögerungsfreien Zugriff wären deshalb ohne Messung nicht belastbar.

1. Beispielnetz und Grenzen festlegen

• Heimnetz: 192.168.10.0/24, Pi mit fester Adresse 192.168.10.2 an eth0.
• WireGuard-Server: 10.100.0.1; ein Client mit eigener Identität und 10.100.0.2.
• Erlaubt: Verbindungen des Clients zu IPv4-Zielen im Heimnetz und zugehörige Antworten.
• Gesperrt: Weiterleitung zu anderen Netzen, neue Verbindungen aus dem LAN zum Client und Zugriff aus wg0 auf Dienste des Pi selbst.

Die Netze sind Beispiele und dürfen sich weder untereinander noch mit dem aktuellen Clientnetz überschneiden. eth0 muss dem tatsächlichen LAN-Interface entsprechen. Der Router benötigt bei einem IPv4-Anschluss eine UDP-Weiterleitung des gewählten Ports 51820 auf den Pi; die bestehende Host-Firewall muss diesen äußeren UDP-Verkehr ebenfalls zulassen. Einzelne Web- oder Speicherports im LAN werden dafür nicht öffentlich freigegeben. Bei Carrier-Grade NAT teilt der Internetanbieter eine öffentliche IPv4-Adresse auf mehrere Anschlüsse auf. Eine lokale Portweiterleitung reicht dann häufig nicht aus; ein anderer erreichbarer Zugang ist nötig.

2. Werkzeuge und Schlüssel vorbereiten

Auf einem aktuellen Raspberry Pi OS werden die Werkzeuge mit sudo apt update und sudo apt install wireguard-tools nftables installiert. Die folgende Schlüsselerzeugung läuft in einer Root-Bash-Shell. Die Einstellung umask 077 verhindert bereits beim Erstellen Lese- und Schreibrechte für andere Benutzerkonten; set -C verhindert das Überschreiben vorhandener Schlüsseldateien.

# In a root Bash shell, on the server:
set -euo pipefail
umask 077
install -d -m 700 /etc/wireguard
cd /etc/wireguard
set -C
wg genkey > server_private.key
wg pubkey < server_private.key > server_public.key

Das Schlüsselpaar des Clients wird getrennt auf dem Client erzeugt. Nur öffentliche Schlüssel werden zwischen den Geräten ausgetauscht. Private Schlüssel gehören weder in gemeinsam genutzte Notizen noch in Bildschirmaufnahmen. Die späteren Konfigurationsdateien enthalten private Schlüssel und benötigen ebenfalls Modus 600: Lesen und Schreiben sind nur für das Dateieigentümerkonto erlaubt; Gruppe und andere Konten erhalten keine Rechte.

3. Weiterleitung durch Filter begrenzen

Der folgende Inhalt gehört in /etc/nftables.d/wireguard.nft. Die Tabellennamen wg_guard und wg_nat müssen für diese Konfiguration reserviert sein. Die Datei ersetzt bei erneutem Laden nur diese eigenen Tabellen, nicht das komplette Regelwerk. Eine Syntaxprüfung mit sudo nft -c -f /etc/nftables.d/wireguard.nft erfolgt vor der Aktivierung.

# Owned tables only; repeated loads replace these rules atomically.
add table inet wg_guard
flush table inet wg_guard
table inet wg_guard {
  chain input {
    type filter hook input priority -10; policy accept;
    iifname "wg0" counter drop
  }
  chain forward {
    type filter hook forward priority -10; policy accept;
    iifname "wg0" ct state invalid counter drop
    iifname "wg0" oifname "eth0" ip saddr 10.100.0.2 ip daddr 192.168.10.0/24 ct state { new, established, related } counter accept
    iifname "eth0" oifname "wg0" ip saddr 192.168.10.0/24 ip daddr 10.100.0.2 ct state { established, related } counter accept
    iifname "wg0" counter drop
    oifname "wg0" counter drop
  }
}
add table ip wg_nat
flush table ip wg_nat
table ip wg_nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    iifname "wg0" oifname "eth0" ip saddr 10.100.0.2 ip daddr 192.168.10.0/24 counter masquerade
  }
}

Die Filterregeln erlauben nur die festgelegte Tunnelquelle und das Heimnetz als Ziel. Die NAT-Regel ersetzt bei genau diesem Verkehr die Quelladresse durch die LAN-Adresse des Pi. Dadurch können LAN-Geräte direkt an den Pi antworten; eine zusätzliche Rückroute zum Tunnelnetz entfällt in diesem Beispiel. Als Nachteil erscheint in LAN-Protokollen die Adresse des Pi statt der ursprünglichen Clientadresse.

Die Policy accept lässt nicht beteiligten Verkehr dieser zusätzlichen Tabellen unverändert. Andere vorhandene Basisketten können erlaubte Pakete weiterhin verwerfen. Deshalb ist die Einbindung in die bestehende Firewall erforderlich. UFW, firewalld oder Docker dürfen die Regeln nicht unbemerkt ersetzen oder umgehen; beschleunigte Flowtables müssen den VPN-Verkehr von einem möglichen Filter-Bypass ausnehmen. Für einen ausschließlich mit nftables verwalteten Pi kann die Datei über include "/etc/nftables.d/wireguard.nft" in das gepflegte persistente Regelwerk aufgenommen werden. Ein späterer Firewall-Reload muss diese Regeln erhalten.

4. IPv4-Forwarding und Server aktivieren

Dieses Beispiel transportiert IPv4-Ziele. IPv6-Forwarding ist dafür nicht erforderlich und wird nicht pauschal eingeschaltet. Der zusätzliche inet-Filter verwirft auch IPv6-Weiterleitung über wg0, falls IPv6 bereits anderweitig aktiv ist.

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

Die gezielte Übernahme erfolgt mit sudo sysctl -p /etc/sysctl.d/99-wireguard-forwarding.conf. Das Beispiel erzwingt keinen globalen Reverse-Path-Filterwert. Eine Änderung von ip_forward kann IPv4-Parameter auf Router-Standardwerte zurücksetzen; bestehende Härtungseinstellungen sind anschließend zu prüfen. Striktes rp_filter=1 kann erlaubten Verkehr verwerfen, wenn Hin- und Rückweg verschiedene Schnittstellen verwenden oder zusätzliche Regeln die Routen bestimmen. Die Einstellung muss deshalb zu den tatsächlich verwendeten Netzwerkwegen passen.

# /etc/wireguard/wg0.conf
[Interface]
Address = 10.100.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>
PreUp = /usr/sbin/nft -f /etc/nftables.d/wireguard.nft

[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.100.0.2/32

Die Platzhalter werden durch die tatsächlichen Schlüssel ersetzt. PreUp lädt die Filter vor dem Aufbau der Schnittstelle. Ein Fehler beim Laden bricht den Start ab. Die Regeln bleiben beim Herunterfahren bestehen und werden beim nächsten Start gezielt ersetzt. Damit entfällt eine Folge ungeschützter, nur teilweise ausgeführter PostUp-NAT-Befehle. UDP 51820 ist hier bewusst gewählt; ohne gesetzten Listen-Port kann WireGuard einen zufälligen Port wählen.

Nach Prüfung der Firewall-Einbindung und der Dateirechte startet sudo systemctl enable --now wg-quick@wg0 den Dienst. Die Härtung betrifft den beschriebenen VPN-Pfad. Betriebssystemupdates, SSH-Zugang, andere Hostdienste und LAN-Berechtigungen müssen unabhängig davon gepflegt werden.

5. Client für Split-Tunneling konfigurieren

[Interface]
PrivateKey = <CLIENT_PRIVATE_KEY>
Address = 10.100.0.2/32

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = vpn.example.net:51820
AllowedIPs = 192.168.10.0/24
# Optional for a client behind NAT:
PersistentKeepalive = 25

vpn.example.net ist ein Platzhalter für den erreichbaren eigenen Endpunkt. Die Client-Anwendung beziehungsweise wg-quick erzeugt aus AllowedIPs die passende Route. WireGuard selbst ordnet über diese Präfixe ausgehende Ziele einem Peer zu und prüft bei eingehenden Paketen die erlaubten Quelladressen. Auf dem Server ersetzt AllowedIPs = 10.100.0.2/32 deshalb keine Ziel- oder Portfilter.

Eine Änderung des Clients auf 0.0.0.0/0 öffnet mit den gezeigten Filterregeln keinen Internetzugang über den Pi. Für zusätzliche Peers sind eigene Schlüssel und eindeutige Tunneladressen sowie passende Filterregeln nötig. PersistentKeepalive = 25 kann NAT-Zuordnungen offenhalten; ohne diesen Bedarf kann die Zeile entfallen.

6. Funktion und Sperren getrennt prüfen

1. Während aktiven Testverkehrs zeigt sudo wg show wg0 Handshake und Transferzähler. Ein alter Zeitstempel bei einem ruhenden Peer beweist noch keinen Fehler. wg show ... dump und showconf können private Informationen ausgeben und gehören nicht in öffentliche Diagnoseprotokolle.
2. Auf einem Linux-Client prüft ip route get 192.168.10.10 die Heimnetzroute; ip route get 1.1.1.1 muss bei dieser Clientkonfiguration weiterhin den lokalen Internetweg zeigen. Andere Betriebssysteme benötigen die entsprechende Routingdiagnose.
3. Ein erlaubter LAN-Dienst muss erreichbar sein. Internetziele über einen absichtlich zum Volltunnel geänderten Testclient sowie Dienste des Pi über die Tunneladresse müssen gesperrt bleiben. Die Zähler in sudo nft list table inet wg_guard helfen bei der Zuordnung.
4. Ein autorisierter iperf3-Test misst den tatsächlichen Durchsatz. CPU-Last, Heim-Upload, Gegenstelle und MTU begrenzen das Ergebnis; Leitungssättigung oder fehlende Fragmentierung werden nicht allein durch einen hohen Messwert bewiesen.