WireGuard-Heimzugriff: Server, Peer, Firewall und Tunnelprüfung

Umfang

Diese Seite prüft:

das Erstellen einer WireGuard-Server-Schnittstelle wg0 unter OpenWrt;
das Hinzufügen eines Client-Peers;
das Einordnen von wg0 in die LAN-Firewall-Zone;
Handshake, Ping auf die Tunnel-IP und LuCI über den Tunnel.

Sie prüft nicht:

öffentliche UDP-Portweiterleitung/Firewall am WAN;
DDNS/Domain;
Roaming mit Smartphone-/Windows-Clients;
Weiterleitung/NAT in das gesamte LAN.

Diese Punkte hängen von der Einsatzumgebung ab; dieser LAN-Test ersetzt sie nicht.

Topologie

Client 192.168.1.251
   │  vmbr5 (Test-LAN)
   ▼
OpenWrt VM 200 192.168.1.2
   wg0 10.10.0.1/24, UDP 51820
   │
   └── Tunnel 10.10.0.0/24
       Client wg0 10.10.0.2/24

Beim echten Heimzugriff befindet sich der Client im Internet; am OpenWrt-WAN muss UDP 51820 weitergeleitet/erlaubt sein. Dieser Test findet nur auf der LAN-Seite statt.

Vorbereitung

Router-ShellKernel und Werkzeuge prüfen

apk add wireguard-tools kmod-wireguard
wg --version
cat /proc/modules | grep wireguard

Im Test: wireguard-tools v1.0.20260223; Modul wireguard geladen.

Erwartetwg ist vorhanden und das Modul wireguard ist geladen.

Router-ShellServer-Schlüssel erzeugen (niemals in Chat/Repository einfügen)

umask 077
wg genkey > /tmp/wg-server.key
wg pubkey < /tmp/wg-server.key > /tmp/wg-server.pub
cat /tmp/wg-server.pub   # only the public key goes to the client

Der Client erzeugt ebenfalls sein eigenes Schlüsselpaar; senden Sie dessen privaten Schlüssel niemals an den Server. Der Server benötigt nur den öffentlichen Schlüssel des Clients.

ErwartetDer private Schlüssel bleibt auf dem Gerät; der öffentliche Schlüssel geht an den Client.

Server konfigurieren

Router-Shellwg0 und den Peer erstellen

uci set network.wg0=interface
uci set network.wg0.proto='wireguard'
uci set network.wg0.private_key='<server-private-key>'
uci set network.wg0.listen_port='51820'
uci set network.wg0.addresses='10.10.0.1/24'
uci set network.wg0.auto='1'

uci set network.wg0_client=wireguard_wg0
uci set network.wg0_client.public_key='<client-public-key>'
uci set network.wg0_client.allowed_ips='10.10.0.2/32'
uci set network.wg0_client.persistent_keepalive='25'

uci commit network
/etc/init.d/network restart

Die Benennung ist wichtig:

Schnittstellenabschnitt wg0, Peer-Typ wireguard_wg0; die Suffixe müssen übereinstimmen;
im Test führte die Benennung der Schnittstelle als wg dazu, dass netifd proto: none meldete und das Gerät wg0 fehlte; nach der Umbenennung in wg0 funktionierte es. Verwenden Sie wg0.

Prüfen:

wg show
ip -4 addr show wg0
ubus call network.interface.wg0 status

Erwartetnetifd erkennt proto=wireguard und wg0 hat seine Adresse.

Router-ShellFirewall: wg0 in die LAN-Zone aufnehmen

uci show firewall | grep -E "zone.*name|zone.*network"
uci add_list firewall.@zone[0].network='wg0'
uci commit firewall
/etc/init.d/firewall reload

@zone[0] war im Test die LAN-Zone; Ihr Index kann abweichen – suchen Sie den Abschnitt mit name='lan'.

Nach dem Hinzufügen von wg0 zum LAN konnte der Client 10.10.0.1 pingen und LuCI erreichen.

ErwartetUDP 51820 ist erreichbar und Tunnel-IPs können kommunizieren.

Minimale Client-Prüfung

Die Client-Konfiguration steht in 022. Auf dem Server:

wg show

Nachdem der Client den Handshake durchgeführt hat, sollte der Server Folgendes anzeigen:

peer: <client-public-key>
  endpoint: 192.168.1.251:44421
  allowed ips: 10.10.0.2/32
  latest handshake: ...
  transfer: ...

Dieser Test-Client:

Handshake vor 3 Sekunden;
transfer 124 B received, 180 B sent;
Ping auf 10.10.0.1 4/4;
HTTP http://10.10.0.1/ lieferte LuCI.

Was für ein echtes WAN noch fehlt

Öffentliche IP/Portweiterleitung: WAN-UDP 51820 → OpenWrt;
die WAN-Eingangs-Firewall erlaubt dieses UDP;
DDNS/fester Hostname;
der Endpoint des Clients verwendet die öffentliche Adresse, nicht 192.168.1.2;
für den Zugriff auf das gesamte LAN müssen allowed_ips des Server-Peers und AllowedIPs des Clients das LAN-Präfix enthalten, dazu Rückrouting/NAT;
machen Sie aus „Tunnel-IP antwortet auf Ping“ nicht „das gesamte Heim-LAN ist erreichbar“.

Häufige Fehler

wg0 fehlt / proto none

Name des Schnittstellenabschnitts und Suffix des Peer-Typs stimmen nicht überein;
wireguard-tools/kmod-wireguard fehlen;
das Netzwerk wurde nicht neu gestartet;
prüfen Sie wg show, ubus status, logread.

Kein Handshake

öffentliche Schlüssel von Client und Server vertauscht;
falscher Endpoint/Port;
die Firewall erlaubt UDP nicht;
Berechtigungen/Inhalt des privaten Schlüssels falsch;
WireGuard benötigt für Handshakes keine Zeitsynchronisation, aber ein falscher Schlüssel schlägt trotzdem fehl.

Tunnel-Ping schlägt fehl

allowed_ips enthält die Tunnel-IP des Peers nicht;
die Schnittstelle hat keine Adresse / ist down;
Firewall-Zone;
die Client-Route leitet den Endpoint selbst in den Tunnel (Schleife).

Tunnel-IP antwortet, LAN nicht erreichbar

dem Client-AllowedIPs fehlt das LAN-Präfix;
dem Server fehlen Weiterleitung/NAT/Rückroute;
Firewall-Weiterleitung nicht erlaubt;
setzen Sie einen funktionierenden Tunnel nicht mit einem funktionierenden LAN gleich.

E2-Testlauf (2026-10-20)

Umgebung: OpenWrt 25.12.6 x86 VM 200; wg0 10.10.0.1/24, UDP 51820; PVE-netns-Client 10.10.0.2/24.
Server: wg show listete den Peer auf, der Handshake gelang, Transfer 1,47 KiB/1,90 KiB; wg0 aktiv.
Client: Handshake, Tunnel-Ping 4/4, HTTP 200 (LuCI).
Nicht getestet: WAN-Portweiterleitung/-Firewall, DDNS, Smartphone/Windows, LAN-Weiterleitung, NAT/Rückroute.
Rezept: tests/recipes/wireguard-server-25.12.md.

Quellen und Review

Dies ist E2 partiell: LAN-seitiger Server und Tunnel wurden getestet; echtes WAN, mobile Clients und LAN-Weiterleitung nicht.
Private Schlüssel bleiben auf den Geräten; legen Sie sie niemals im Repository, in Screenshots oder im Chat ab.
Es gab keinen unabhängigen Reviewer; die Schlussfolgerungen gelten nur für diese VM-/netns-Umgebung.

Quellen

Router.Homes

Unabhängige OpenWrt-Notizen. Jede Seite nennt Firmware, Gerät, Paketmanager und den Rückweg.

Symbole: Solar by 480 Design, CC BY 4.0