WireGuard: sicherer Fernzugriff ins Heimnetz

Auf eigene Gefahr: Eine falsch gesetzte Firewall- oder Port-Forward-Regel kann ungewollt interne Dienste ins Internet stellen. Leite ausschließlich den WireGuard-UDP-Port (z. B. 51820) weiter und keinen anderen. Prüfe nach dem Einrichten zwingend von einem fremden Netz aus (Mobilfunk/externer Port-Scan), dass nur dieser eine UDP-Port reagiert. Behalte außerdem einen alternativen Zugang zu Router und Server (lokale Konsole bzw. LAN-Zugriff), falls eine geänderte Firewall-Regel dich aussperrt — teste neue WAN-Regeln nie ohne diesen Rückweg.

Warum WireGuard statt Port-Forwarding einzelner Dienste

Wenn du von unterwegs auf NAS, Proxmox oder Smart-Home zugreifen willst, ist die schlechteste Lösung, jeden Dienst einzeln per Port-Forwarding ins Internet zu hängen. Jeder offene Port ist eine Angriffsfläche. WireGuard dreht das um: Du öffnest genau einen UDP-Port nach außen, und nur wer den passenden privaten Schlüssel besitzt, kommt überhaupt durch. Alles andere bleibt unsichtbar. WireGuard antwortet auf Pakete ohne gültigen Schlüssel gar nicht erst — der Port wirkt von außen wie geschlossen.

Das Prinzip: Schlüsselpaare und Peers

WireGuard kennt kein Login mit Passwort. Jede Seite (Server und jedes Client-Gerät) hat ein Schlüsselpaar: einen privaten und einen öffentlichen Schlüssel. Der private Schlüssel bleibt immer auf dem Gerät, nur die öffentlichen Schlüssel werden ausgetauscht. Wichtig: Lege pro Gerät einen eigenen Peer an (Handy, Laptop, Tablet jeweils separat). So kannst du einen einzelnen verlorenen Schlüssel widerrufen, ohne alle neu ausrollen zu müssen.

Variante A: Router/Gateway mit eingebautem WireGuard

Am einfachsten ist es, wenn dein Gateway WireGuard schon mitbringt:

Bei FRITZ!Box und UniFi wird die Port-Freigabe automatisch gesetzt — du musst nichts von Hand am NAT öffnen. Bei OPNsense/pfSense legst du selbst eine WAN-Firewall-Regel an: Protokoll UDP, Ziel-Port 51820, Aktion „pass“. Nur diesen einen Port, sonst nichts.

Variante B: Linux/Raspberry Pi als WireGuard-Peer

Hast du kein WG-fähiges Gateway, läuft WireGuard hervorragend auf einem Pi oder einer kleinen VM. Installation und Schlüssel:

sudo apt update && sudo apt install -y wireguard
# Schlüsselpaar für den Server erzeugen (Rechte einschränken!)
umask 077
wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub

Server-Konfiguration unter /etc/wireguard/wg0.conf:

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <INHALT_VON_server.key>

# Ein Peer pro Gerät – hier das Handy
[Peer]
PublicKey = <PUBLIC_KEY_DES_HANDYS>
AllowedIPs = 10.10.0.2/32

Damit Geräte hinter dem Pi erreichbar sind, brauchst du IP-Forwarding und NAT. Aktiviere Forwarding dauerhaft und richte eine Masquerade-Regel auf dem LAN-Interface ein (Beispiel-Interface eth0):

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wg.conf
sudo sysctl --system
# In wg0.conf unter [Interface] ergänzen:
# PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
sudo systemctl enable --now wg-quick@wg0

Auf deinem Router brauchst du dann eine Port-Weiterleitung: UDP 51820 → interne IP des Pi. Kein weiterer Forward.

Client-Config und QR-Code fürs Handy

Die mobile WireGuard-App erzeugt das Schlüsselpaar selbst — du gibst nur deren öffentlichen Schlüssel in den Server-Peer ein. Eine vollständige Client-Config sieht so aus:

[Interface]
PrivateKey = <CLIENT_PRIVATE_KEY>
Address = 10.10.0.2/32
DNS = 10.10.0.1            # interner DNS, damit Heim-Hostnamen aufgelöst werden

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = deinanschluss.ddns.net:51820
AllowedIPs = 10.10.0.0/24, 192.168.1.0/24   # Split-Tunnel: nur Heimnetz
PersistentKeepalive = 25

Für den QR-Code auf dem Server (Variante B):

sudo apt install -y qrencode
qrencode -t ansiutf8 < handy.conf

In der Handy-App: „Hinzufügen → aus QR-Code scannen“. Fertig.

Split-Tunnel vs. Full-Tunnel

Split-Tunnel (oben gezeigt): Nur Verkehr ins Heimnetz geht durch den Tunnel, dein normaler Internet-Traffic läuft direkt — schneller, schont die Upload-Leitung daheim. Setze dafür in AllowedIPs nur deine internen Subnetze. Full-Tunnel: Setze AllowedIPs = 0.0.0.0/0, ::/0, dann läuft aller Traffic über dein Heimnetz — sinnvoll in fremden WLANs, kostet aber Bandbreite. Hinweis: das 0.0.0.0/0 steht hier nur in der Client-Config als Routing-Ziel, nicht in der Firewall — das ist unkritisch.