WireGuard: Zugriff auf Heim-LAN einrichten

Warum Ihr Heim-LAN über WireGuard nicht antwortet

Damit Sie Ihr Heim-LAN über WireGuard erreichen, müssen vier separate Einstellungen zusammenpassen. Drei von vier Einstellungen ergeben weiterhin einen Tunnel, der vollkommen funktionsfähig aussieht. Genau das macht diesen Fehler so schwer verständlich. wg show meldet einen aktuellen Handshake, ping 10.8.0.1 antwortet innerhalb weniger Millisekunden, und ping 192.168.20.10 liefert überhaupt keine Antwort.

Hier ist die vollständige Liste in der Reihenfolge, in der ein Paket die Einstellungen durchläuft. LAN steht für Local Area Network, also das private Netzwerk hinter Ihrem Heimrouter.

1. AllowedIPs auf dem Client muss das entfernte Subnetz abdecken. Andernfalls gelangt das Paket nie in den Tunnel.
2. AllowedIPs auf dem Server muss die Tunneladresse des Clients abdecken. Andernfalls wird das Paket verworfen, sobald es entschlüsselt wurde.
3. net.ipv4.ip_forward muss auf dem Server auf 1 gesetzt sein, weil Linux jedes Paket verwirft, das nicht an den Rechner selbst adressiert ist.
4. Das LAN muss eine Rückroute zu 10.8.0.0/24 kennen. Dafür benötigen Sie entweder eine Masquerade-Regel auf dem Server oder eine statische Route auf dem Heimrouter.

Jede dieser Einstellungen kann ohne Fehlermeldung fehlschlagen. Es wird nichts protokolliert, und es erscheint keine Warnung. Der Handshake funktioniert währenddessen weiterhin. Prüfen Sie die Einstellungen in dieser Reihenfolge. Die fehlerhafte Einstellung lässt sich so meist innerhalb von etwa einer Minute ermitteln.

Das in dieser Anleitung verwendete Netzwerk

Alle folgenden Adressen sind Beispiele. Ersetzen Sie sie durch Ihre eigenen Adressen und verwenden Sie die Ersetzungen konsistent, da eine nur teilweise aktualisierte Konfiguration die zweithäufigste Ursache für dieses Problem ist.

• Das Heim-LAN ist 192.168.20.0/24. Der Heimrouter ist 192.168.20.1.
• Der WireGuard-Server ist ein Linux-Rechner in diesem LAN. Seine LAN-Schnittstelle enp1s0 hat die Adresse 192.168.20.5, und seine Tunnelschnittstelle wg0 hat die Adresse 10.8.0.1.
• Der Host, den Sie erreichen möchten, ist ein NAS (Network Attached Storage) unter 192.168.20.10.
• Der Client ist ein Laptop an einem anderen Standort, 10.8.0.2 innerhalb des Tunnels.

Der Server ist ein Rechner im LAN und nicht der Router selbst. Das ist der normale Fall, etwa bei einem Raspberry Pi oder einem älteren Mini-PC. Das ist für Regel 4 relevant: Ihr Router weiß nicht, dass der Tunnel existiert, solange Sie ihn nicht darüber informieren. Außerdem sendet jeder Host im LAN Datenverkehr zu Zielen außerhalb des eigenen Subnetzes an diesen Router.

Wenn Ihr Internetanschluss keine öffentliche IP-Adresse hat, funktioniert das allein nicht, weil kein Host im Internet einen Handshake zu Ihrem Heimnetz initiieren kann. Der Abschnitt zum Einsatz eines VPS als Vermittler behandelt diesen Fall. Dort gelten dieselben vier Regeln, allerdings müssen Sie einen zusätzlichen Peer berücksichtigen.

AllowedIPs hat zwei unterschiedliche Bedeutungen

Eine Einstellung erfüllt zwei Aufgaben. Sie auf beiden Seiten gleich zu interpretieren, ist der häufigste Grund für diese Supportfälle. WireGuard bezeichnet diesen Mechanismus als Cryptokey Routing. Eine ausführlichere Beschreibung finden Sie unter wie WireGuard öffentliche Schlüssel an IP-Bereiche bindet.

Ausgehend gelesen ist AllowedIPs eine Routingtabelle. wg-quick macht aus jedem Eintrag eine Route zu wg0. Ein Paket für 192.168.20.10 wird nur dann verschlüsselt und an einen Peer gesendet, wenn ein Peer einen Bereich beansprucht, der diese Adresse enthält. Wenn Sie nur 10.8.0.0/24 eintragen, sendet Ihr Laptop den LAN-Verkehr stattdessen über das lokale WLAN. Dort verwirft ihn das Netzwerk entweder, oder er erreicht ein vollständig anderes 192.168.20.10.

Eingehend gelesen ist AllowedIPs eine Zugriffskontrollliste. Nachdem WireGuard ein Paket von einem Peer entschlüsselt hat, prüft es die innere Quelladresse gegen AllowedIPs dieses Peers. Stimmen die Adressen nicht überein, verwirft WireGuard das Paket. Ohne aktivierte Kernel-Debugmeldungen wird nichts protokolliert. Die einzige Spur ist der Empfangsfehlerzähler unter wg0, den ip -s link show wg0 ausgibt. Das Paket verschwindet einfach.

Die beiden Konfigurationsdateien sind daher niemals spiegelbildlich. Der Client listet auf, welche Ziele er über den Server erreichen möchte. Der Server listet auf, welche Quelladressen dieser Client verwenden darf.

Das passende Paar von Konfigurationsdateien

Client, /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <laptop private key>
Address = 10.8.0.2/32

[Peer]
PublicKey = <server public key>
Endpoint = home.example.com:51820
AllowedIPs = 10.8.0.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Server, /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <server private key>
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <laptop public key>
AllowedIPs = 10.8.0.2/32

Der Heimrouter benötigt außerdem eine Portweiterleitung für UDP 51820 an 192.168.20.5. Andernfalls beginnt der Handshake nie, und der Client protokolliert Handshake for peer 1 did not complete after 5 seconds, retrying. Diese Anleitung setzt voraus, dass Sie diesen Schritt bereits erledigt haben.

Vier Zeilen unterscheiden sich von einer einfachen Full-Tunnel-Konfiguration. Jede Änderung ist beabsichtigt.

• AllowedIPs = 10.8.0.0/24, 192.168.20.0/24 auf dem Client statt 0.0.0.0/0, ::/0. Dies ist ein Split-Tunnel: Das Tunnel-Subnetz und das Heim-LAN laufen über wg0. Für alle anderen Ziele bleibt die lokale Route erhalten. Ihr Webverkehr läuft nicht über Ihre Heimverbindung. Das ist normalerweise sinnvoll, wenn Sie nur das NAS benötigen.
• AllowedIPs = 10.8.0.2/32 auf dem Server, also eine einzelne Adresse statt eines Bereichs. Tragen Sie dort 10.8.0.0/24 ein. Dieser einzelne Client darf dann jede Adresse innerhalb des Tunnels beanspruchen. Wenn Sie später einen zweiten Peer mit einem überlappenden Bereich hinzufügen, wird der Verkehr an den Peer gesendet, der zuletzt konfiguriert wurde. Es wird nirgendwo eine Fehlermeldung ausgegeben.
• PersistentKeepalive = 25 nur auf dem Client. Der Client befindet sich hinter NAT (Network Address Translation). Sein Router verwirft die UDP-Zuordnung nach ein oder zwei Minuten ohne Datenverkehr. Danach kann der Server den Client nicht mehr erreichen. Der Server hat eine öffentliche Adresse und benötigt kein Keepalive.
• Noch keine Zeile DNS =. Wenn Sie diese hinzufügen, ändert sich die Namensauflösung für den gesamten Client. Der folgende DNS-Abschnitt erklärt die Funktion, bevor Sie die Zeile aktivieren.

Ein Full-Tunnel erreicht ebenfalls das LAN, da 0.0.0.0/0 auf jede Adresse passt. Dabei läuft jedoch sämtlicher Verkehr über den Tunnel, und eine Subnetzkollision lässt sich vom Client aus nicht beheben.

Warum dasselbe Subnetz an beiden Enden den Tunnel unbrauchbar macht

Wählen Sie für Ihr Heimnetz ein Subnetz, das kaum jemand verwendet, beispielsweise 192.168.20.0/24 oder 10.44.7.0/24. 192.168.1.0/24 und 192.168.0.0/24 sind auf den meisten Routern für Privathaushalte die Werkseinstellungen. Früher oder später befindet sich Ihr Laptop in einem Café- oder Hotelnetz, das genau diesen Bereich verwendet.

Die Kollision verhindert die Verbindung vollständig und zeigt sich in den beiden Fällen unterschiedlich. Bei einem Split-Tunnel versucht wg-quick, eine Route für ein Präfix hinzuzufügen, das auf der Wi-Fi-Schnittstelle bereits vorhanden ist. Wenn die vorhandene Route dieselbe Metrik hat, lehnt ip route add den Vorgang ab, und die Schnittstelle wird nicht aktiviert:

RTNETLINK answers: File exists

Auf einem Laptop, den NetworkManager verwaltet, hat die Wi-Fi-Route normalerweise eine Metrik wie 600. Das Hinzufügen gelingt daher stattdessen, und die Tunnelroute mit der Metrik 0 wird bevorzugt. Das NAS antwortet. Jeder Host im Café-Netz, der zu diesem Bereich gehört, befindet sich nun jedoch hinter dem Tunnel. Das betrifft häufig auch den DNS-Server.

Bei einem Full-Tunnel installiert wg-quick Regeln für das Policy Routing, die spezifischere Routen aus der Haupttabelle absichtlich umgehen. Die lokale 192.168.1.0/24-Route wird gegenüber dem Tunnel bevorzugt. Daher verlässt jedes Paket für das entfernte LAN die Verbindung über den lokalen Link. Der Tunnel ist aktiv, der Handshake funktioniert, aber das NAS ist nicht erreichbar. Die einzige zuverlässige Lösung besteht darin, das Heimnetz neu zu nummerieren.

Den Server als Router einrichten

ip route show default
printf 'net.ipv4.ip_forward = 1\n' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

Der erste Befehl liefert den tatsächlichen Namen der LAN-Schnittstelle. Aktuelle Images verwenden Namen wie enp1s0 oder ens3, seltener eth0. Eine Masquerade-Regel, die die falsche Schnittstelle angibt, trifft auf keinen Datenverkehr zu. Der letzte Befehl sollte net.ipv4.ip_forward = 1 ausgeben. Ein einfaches sudo sysctl -w setzt denselben Wert, aber nur bis zum nächsten Reboot. Danach ist die Einstellung verloren. Das führt typischerweise zu der Meldung: „Bis Dienstag hat es funktioniert.“

Die Weiterleitung muss außerdem die Firewall passieren können. Wenn ufw unter Ubuntu aktiv ist, werden weitergeleitete Pakete verworfen, sofern DEFAULT_FORWARD_POLICY="ACCEPT" nicht in /etc/default/ufw gesetzt ist. Docker setzt mit seinem standardmäßigen iptables-Backend dieselbe Richtlinie automatisch, wenn es die Weiterleitung beim Start aktivieren muss, sofern ip-forward-no-drop nicht in /etc/docker/daemon.json gesetzt ist. Wenn sudo iptables -S FORWARD | head -1 auf einem Server, dessen Firewall Sie nie manuell konfiguriert haben, -P FORWARD DROP ausgibt, wurde die Einstellung daher meist von Docker vorgenommen. Sie kann aber auch von einem Provisioning-Skript oder einem anderen Firewall-Manager stammen. In jedem Fall benötigt der Tunnelverkehr eine explizite Accept-Regel.

Warum die Antworten nie zurückkommen

Wenn die Regeln 1 bis 3 stimmen, erreicht der Ping das NAS tatsächlich. Trotzdem sehen Sie keine Antwort, weil der Rückweg fehlt. Das NAS antwortet an 10.8.0.2, eine Adresse außerhalb seines eigenen Subnetzes. Deshalb übergibt es das Paket an sein Standardgateway, den Heimrouter unter 192.168.20.1. Dieser Router kennt 10.8.0.0/24 nicht. Er leitet die Antwort daher an sein eigenes Standardgateway, Ihren Internetanschluss, weiter. Dort wird sie verworfen. Die Anfrage kommt an, aber die Antwort geht verloren.

Option A: Masquerading auf dem WireGuard-Server. Der Server ersetzt die Quelladresse jedes Tunnelpakets, das er über enp1s0 weiterleitet, durch 192.168.20.5, die eigene LAN-Adresse dieses Interfaces. Das NAS sieht die Anfrage nun als Anfrage von einem Nachbarn im eigenen Subnetz. Es antwortet direkt an den Server. Der Server macht die Adressumsetzung rückgängig und sendet die Antwort durch den Tunnel zurück. An den anderen Geräten im LAN muss nichts geändert werden.

Tragen Sie die Regel in den [Interface]-Block des Servers ein. Dadurch wird sie zusammen mit dem Interface aktiviert und entfernt:

PostUp = iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE

Auf einem System, das bereits von nftables verwaltet wird, schreiben Sie die Regel stattdessen in /etc/nftables.conf:

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.8.0.0/24 oifname "enp1s0" counter masquerade
  }
}

Behalten Sie das Schlüsselwort counter bei. Ohne dieses Schlüsselwort zeigt sudo nft list ruleset die Regel ohne Paketanzahl an. Genau diese Anzahl zeigt, ob die Regel verwendet wird.

Masquerading hat außerdem einen leicht zu übersehenden Vorteil. Viele Hosts verwenden eine Firewall, die nur Verbindungen aus dem eigenen Subnetz akzeptiert. Die Windows-Dateifreigabe arbeitet standardmäßig so. Das gilt auch für mehrere NAS-Verwaltungsoberflächen. Auf einem solchen Host wird ein Paket von 10.8.0.2 verworfen, selbst wenn das Routing korrekt ist. Nach dem Masquerading ist die Quelladresse eine LAN-Adresse, sodass diese Regeln greifen. Der Nachteil ist, dass jeder Tunnelclient in den Logs aller LAN-Hosts als 192.168.20.5 erscheint. Sie können die Clients dadurch nicht unterscheiden. Außerdem funktionieren clientbezogene Regeln auf LAN-Geräten nicht.

Option B: eine statische Route auf dem Heimrouter. Teilen Sie dem Router mit, dass 10.8.0.0/24 hinter 192.168.20.5 liegt. Auf einem Linux-Router genügt ein Befehl:

sudo ip route add 10.8.0.0/24 via 192.168.20.5

Consumer-Router enthalten in den erweiterten Einstellungen meist eine Seite mit der Bezeichnung Static Routes oder Routing: Ziel 10.8.0.0, Maske 255.255.255.0, Gateway 192.168.20.5. Speichern Sie die Route in der gespeicherten Routerkonfiguration. Ein ip route add, das Sie auf einem Linux-System eingeben, ist nach dem nächsten Reboot nicht mehr vorhanden.

Damit bleibt die tatsächliche Clientadresse erhalten. Logs und clientbezogene Regeln in Ihrem LAN bleiben dadurch aussagekräftig. Dafür benötigen Sie einen Router, der statische Routen unterstützt. Außerdem hilft die Route nur Hosts, die diesen Router als Standardgateway verwenden. Ein Host mit einer subnetzbezogenen lokalen Firewall benötigt weiterhin eine eigene Regel für 10.8.0.0/24. Beginnen Sie mit Masquerading, weil dafür nichts außerhalb des bereits von Ihnen kontrollierten Systems geändert werden muss. Wechseln Sie zur statischen Route, wenn Sie die tatsächlichen Clientadressen benötigen.

So ermitteln Sie, welche der vier Regeln fehlerhaft ist

Arbeiten Sie vom Client aus nach außen. Jeder Schritt zeigt, ob das Paket diese Stelle erreicht hat.

Gelangt das Paket in den Tunnel? Auf dem Client:

ip route get 192.168.20.10

Die Ausgabe sollte dev wg0 nennen. Wenn sie Ihre Wi-Fi-Schnittstelle nennt, ist entweder Regel 1 fehlerhaft und der AllowedIPs des Clients deckt das LAN-Subnetz nicht ab, oder eine lokale Route für denselben Bereich hat Vorrang. Das ist die oben beschriebene Subnetzkollision. Ein ping: connect: Network is unreachable weist auf dieselbe Ursache hin.

Kommen Pakete am Server an? Führen Sie diesen Befehl auf dem Server aus und pingen Sie anschließend das NAS vom Client aus:

sudo tcpdump -ni wg0 icmp

Bei einem funktionierenden Pfad wird IP 10.8.0.2 > 192.168.20.10: ICMP echo request angezeigt. Dabei steht ICMP für Internet Control Message Protocol, das Protokoll, das ping verwendet. Wenn bei einem funktionierenden Handshake nichts angezeigt wird, liegt fast immer Regel 2 vor: Der AllowedIPs des Servers für diesen Peer enthält 10.8.0.2 nicht. Das Paket wurde daher bei der Entschlüsselung verworfen, bevor es wg0 erreicht hat. Steigt der RX-Fehlerzähler in ip -s link show wg0 auf dem Server mit jedem Ping, bestätigt das die Ursache. Bleibt der Zähler unverändert, prüfen Sie, ob eine Firewall auf dem Client ausgehenden Datenverkehr zum Tunnel blockiert.

Verlassen die Pakete den Server in Richtung LAN? Beobachten Sie auf dem Server die LAN-Seite:

sudo tcpdump -ni enp1s0 icmp

Wenn Anfragen auf wg0 sichtbar sind, aber hier nichts erscheint, liegt Regel 3 vor. Die Weiterleitung ist deaktiviert oder eine FORWARD-Regel hat das Paket verworfen. Seltener verwirft das strikte Reverse-Path-Filtering (rp_filter) das Paket. Das geschieht, wenn die Route des Servers zurück zur Quelle über eine andere Schnittstelle führt. Anfragen mit der Quelle 10.8.0.2, aber ohne Antworten, weisen normalerweise auf Regel 4 hin. Für die Antwort fehlt dann die Rückroute. Ein Host, der Pings ignoriert oder nur auf Anfragen aus dem eigenen Subnetz antwortet, sieht jedoch genauso aus. Anfragen mit der Quelle 192.168.20.5, aber ohne Antworten bedeuten, dass Ihre Masquerade-Regel funktioniert und der Zielhost selbst nicht antwortet. Prüfen Sie daher die Firewall auf dem NAS. Bei einem Linux-Host prüfen Sie außerdem, ob net.ipv4.icmp_echo_ignore_all so gesetzt ist, dass Pings ignoriert werden. Dieselbe Prüfkette funktioniert auch für andere Dienste, sobald Sie icmp durch port 445 oder den jeweils gewünschten Port ersetzen.

Ich erreiche die IP, aber nicht den Namen

ssh 192.168.20.10 funktioniert und ssh nas.home.arpa schlägt fehl:

ssh: Could not resolve hostname nas.home.arpa: Name or service not known

Mit dem Tunnel ist alles in Ordnung. Die Namensauflösung ist ein separater Pfad, und Ihr Laptop fragt weiterhin den Resolver ab, den er über das lokale WLAN gelernt hat. Dieser Resolver weiß nichts über die Namen in Ihrem Heimnetzwerk.

Zwei Bedingungen müssen erfüllt sein, damit Heimnetzwerknamen funktionieren. Die Adresse des Resolvers muss innerhalb von AllowedIPs auf dem Client liegen, sonst gelangt die DNS-Anfrage (Domain Name System) niemals in den Tunnel. Zudem muss der Resolver bereit sein, eine Anfrage zu beantworten, deren Quelladresse 10.8.0.2 lautet. Viele Heim-Resolver verweigern dies standardmäßig: dnsmasq, das mit local-service läuft, beantwortet nur Anfragen aus einem direkt angeschlossenen Subnetz, und Pi-hole wird mit einem Listening-Modus ausgeliefert, der nur lokale Anfragen zulässt. Eine Masquerade-Regel verbirgt dieses Problem, da die Anfrage nach dem Rewrite von 192.168.20.5 aus eintrifft.

Die Client-Seite besteht aus einer Zeile:

DNS = 192.168.20.1

Auf einem Linux-Client benötigen Sie openresolv oder eine entsprechende Implementierung von resolvconf, da wg-quick andernfalls mit resolvconf: command not found abbricht. Prüfen Sie, was dies auf einem systemd-resolved-System bewirkt, bevor Sie es einrichten: wg-quick registriert diese Server exklusiv. Während der Tunnel aktiv ist, gehen Suchanfragen des Laptops daher an Ihren Heim-Resolver, nicht nur für Heimnetzwerknamen. Nur Namen unter einer spezifischeren Domain, die eine andere Schnittstelle beansprucht, werden weiterhin anderswo aufgelöst. Überprüfen Sie das Ergebnis mit resolvectl status wg0. Wenn Sie möchten, dass Heimnetzwerknamen zu Hause und alles andere lokal aufgelöst wird, handelt es sich um Split-DNS, und DNS über einen WireGuard-Tunnel korrigieren behandelt die Konfiguration vollständig.

Keine öffentliche IP-Adresse zu Hause? Schalten Sie einen VPS dazwischen

Wenn die Statusseite Ihres Routers eine WAN-Adresse innerhalb von 100.64.0.0/10 anzeigt, befinden Sie sich hinter CGNAT (Carrier-Grade Network Address Translation). Dann kann kein Handshake aus dem Internet Ihr Heimnetz erreichen. Eine private 192.168.x.x-Adresse an dieser Stelle weist normalerweise auf einen zweiten Router vor Ihrem Router hin, also auf doppeltes NAT. Versetzen Sie den Modemrouter des ISP in den Bridge-Modus oder leiten Sie UDP 51820 auch auf diesem Gerät weiter. Wenn Sie dieses Gerät nicht ändern können oder seine eigene WAN-Adresse ebenfalls nicht öffentlich ist, behandeln Sie die Situation wie CGNAT. Ein ausgehender Handshake funktioniert weiterhin normal. Die Lösung ist daher ein dritter Knoten mit öffentlicher Adresse. Ein kleiner VPS stellt den Hub bereit, und der Rechner zu Hause baut die Verbindung zu ihm auf.

Die vier Regeln ändern sich nicht. Sie gelten jetzt über zwei Hops hinweg, daher verdoppelt sich der Verwaltungsaufwand.

• Auf dem VPS erhält der Peer-Eintrag des Rechners zu Hause AllowedIPs = 10.8.0.3/32, 192.168.20.0/24: seine eigene Tunneladresse sowie das Subnetz, für das er Datenverkehr weiterleiten darf.
• Auf dem VPS bleibt der Peer-Eintrag des Laptops AllowedIPs = 10.8.0.2/32.
• Auf dem Laptop erhält der Peer des VPS AllowedIPs = 10.8.0.0/24, 192.168.20.0/24, weil jetzt sämtlicher Datenverkehr zum Hub geleitet wird.
• Auf dem Rechner zu Hause erhält der Peer des VPS AllowedIPs = 10.8.0.0/24, und der Rechner zu Hause führt PersistentKeepalive = 25, weil er sich nun hinter NAT befindet.
• Der VPS benötigt außerdem net.ipv4.ip_forward = 1. Seine Forwarding-Kette muss wg0 nach wg0 zulassen, weil der Datenverkehr des Laptops über dieselbe Schnittstelle ein- und ausgeht. Eine Firewall-Konfiguration für einen einfachen Full-Tunnel-VPS blockiert genau diesen Datenverkehr.

Wenn Sie die VPS-Seite noch nicht eingerichtet haben, behandelt WireGuard auf einem VPS einrichten die Schlüsselerzeugung, die Firewall und die systemd-Unit. Das allgemeine Vorgehen, um eine Maschine zu erreichen, die keine eingehenden Verbindungen akzeptieren kann, wird unter einen Reverse-Tunnel hinter CGNAT öffnen beschrieben. Wenn die manuelle Verwaltung von Peer-Adressen zu aufwendig wird, übernimmt einen Tailscale-Subnet-Router betreiben dieselbe Routing-Aufgabe und automatisiert die Adressverwaltung.

Nach einem Reboot automatisch starten

sudo systemctl enable --now wg-quick@wg0
sudo systemctl enable --now nftables
sudo wg show

enable --now ist der Schritt, den viele überspringen. Ein manuell gestartetes wg-quick up wg0 ist nach dem nächsten Kernel-Upgrade und Reboot nicht mehr aktiv. wg show sollte den Peer mit einer aktuellen latest handshake-Zeile sowie Transferzählern ungleich 0 in beide Richtungen anzeigen.

Ein später hinzugefügter zweiter Client erfordert keinen Neustart, bei dem alle derzeit verbundenen Clients getrennt würden:

sudo bash -c 'wg syncconf wg0 <(wg-quick strip wg0)'

wg-quick strip gibt die Konfiguration ohne die Schlüssel aus, die nur wg-quick versteht, und syncconf übernimmt die Änderungen, während laufende Sitzungen bestehen bleiben. Der Befehl aktualisiert nur die Peers. Ein geändertes Address oder eine neue PostUp-Zeile erfordert weiterhin ein vollständiges Down und Up.

FAQ

Warum kann ich den WireGuard-Server anpingen, aber nichts anderes im Heimnetz?

Ein Ping an 10.8.0.1 bestätigt nur, dass der Tunnel aktiv ist. Der Zugriff auf den Rest des LANs ist ein Routing-Problem. AllowedIPs des Clients muss 192.168.20.0/24 enthalten. Andernfalls gelangt das Paket nicht in den Tunnel. Auf dem Server muss net.ipv4.ip_forward auf 1 gesetzt sein. Andernfalls verwirft der Server Pakete, die nicht an ihn selbst adressiert sind. Außerdem benötigt das LAN eine Route zurück zu 10.8.0.0/24. Führen Sie auf dem Server sudo tcpdump -ni enp1s0 icmp aus, während Sie einen Ping senden. Anfragen mit der Quelladresse 10.8.0.2, auf die keine Antworten zurückkommen, weisen normalerweise auf einen fehlenden Rückweg hin.

Benötige ich eine statische Route auf meinem Heimrouter?

Nur wenn Sie auf die Masquerade-Regel verzichten. Eine Masquerade-Regel auf dem WireGuard-Server ersetzt die Quelladresse des Tunnelverkehrs durch die eigene LAN-Adresse des Servers. Dadurch antworten die LAN-Hosts an einen bereits bekannten Nachbarn, und der Router wird nicht benötigt. Eine statische Route für 10.8.0.0/24 über die LAN-Adresse des Servers ist die Alternative. Das lohnt sich, wenn in den Logs der LAN-Hosts die echten Client-Adressen erscheinen sollen oder wenn Sie dort Firewall-Regeln pro Client benötigen.

Warum führt dasselbe Subnetz an beiden Enden zum Ausfall des Tunnels?

Ihr Laptop kann nicht gleichzeitig zwei Routen für dasselbe Präfix verwenden. Wenn das lokale Netzwerk 192.168.1.0/24 verteilt und Ihr Heimnetz ebenfalls 192.168.1.0/24 verwendet, schlägt ein Split-Tunnel mit wg-quick up entweder fehl, wenn ip route add mit RTNETLINK answers: File exists ablehnt, oder er wird bei einer höheren Metrik der WLAN-Route aktiv und verbirgt die lokalen Hosts dieses Bereichs hinter dem Tunnel. Ein Full-Tunnel wird dagegen aktiv. Dabei installiert wg-quick Policy-Regeln, die spezifischere Routen aus der Haupttabelle zurückhalten. Dadurch gewinnt das lokale Netzwerk, und das entfernte LAN bleibt nicht erreichbar. Nummerieren Sie das Heimnetz auf einen selten verwendeten Bereich wie 192.168.20.0/24 um. Es gibt keine Lösung auf der Client-Seite.

Ich kann das NAS per IP-Adresse erreichen, aber nicht per Namen. Was fehlt?

Die Namensauflösung folgt dem Tunnel nicht automatisch. Fügen Sie DNS = 192.168.20.1, Ihren Resolver zu Hause, in den [Interface]-Block des Clients ein. Stellen Sie außerdem sicher, dass diese Adresse innerhalb von AllowedIPs des Peers liegt. Andernfalls gelangt die Anfrage nicht in den Tunnel. Prüfen Sie anschließend, ob der Resolver Anfragen außerhalb seines eigenen Subnetzes beantwortet. Sowohl dnsmasq mit local-service als auch der Local-only-Modus von Pi-hole lehnen solche Anfragen ab. Eine Masquerade-Regel auf dem WireGuard-Server umgeht dieses Problem, indem sie die Quelladresse der Anfrage ersetzt.

Meine Heimverbindung hat keine öffentliche IP-Adresse. Kann ich mein LAN trotzdem erreichen?

Ja, mit einem dritten Knoten. Hinter CGNAT ist die WAN-Adresse Ihres Routers nicht öffentlich erreichbar. Daher kann kein Peer aus dem Internet den Handshake mit dem Router starten. Ein ausgehender Handshake funktioniert dagegen normal. Richten Sie WireGuard auf einem VPS mit öffentlicher Adresse ein. Lassen Sie den Rechner zu Hause mit PersistentKeepalive = 25 eine ausgehende Verbindung dorthin herstellen. Der Peer-Eintrag des Rechners zu Hause auf dem VPS benötigt ein AllowedIPs, das dessen Tunnel-Adresse sowie 192.168.20.0/24 enthält. Auf dem VPS müssen Sie anschließend die Weiterleitung aktivieren und eine Forward-Regel einrichten, die wg0 zu wg0 erlaubt.