WireGuard: Route ins 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 die Ursache für die meisten dieser 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.

Bei ausgehendem Verkehr 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 angibt, der diese Adresse umfasst. Wenn Sie nur 10.8.0.0/24 eintragen, sendet Ihr Laptop den LAN-Verkehr stattdessen über das lokale WLAN. Dort wird er entweder verworfen oder erreicht ein völlig anderes 192.168.20.10.

Bei eingehendem Verkehr ist AllowedIPs eine Zugriffskontrollliste. Nachdem WireGuard ein Paket von einem Peer entschlüsselt hat, prüft es die interne Quelladresse gegen AllowedIPs dieses Peers. Stimmen die Adressen nicht überein, verwirft WireGuard das Paket. Für dieses Verwerfen gibt es weder einen Logeintrag noch einen Zähler. 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 Zugriff verhindert

Wählen Sie ein Heimnetz-Subnetz, das kaum jemand anderes 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 bei den meisten Consumer-Routern die Werkseinstellungen. Daher befindet sich Ihr Laptop früher oder später in einem Café- oder Hotelnetz mit genau diesem Adressbereich.

Die Überschneidung 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 WLAN-Schnittstelle bereits vorhanden ist. ip route add lehnt dies ab, und die Schnittstelle wird nicht aktiviert:

RTNETLINK answers: File exists

Bei einem Full-Tunnel installiert wg-quick Policy-Routing-Regeln, die spezifischere Routen aus der Main-Tabelle bewusst ausnehmen. Die lokale 192.168.1.0/24-Route hat Vorrang vor dem Tunnel. Daher wird jedes Paket für das entfernte LAN über die lokale Verbindung gesendet. Der Tunnel ist aktiv, der Handshake funktioniert, und das NAS ist nicht erreichbar. Die Umnummerierung des Heim-LANs ist die einzige wirkliche Lösung.

Den Server als Router verwenden

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, selten 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 alleinstehendes sudo sysctl -w setzt denselben Wert, aber die Einstellung geht beim nächsten Reboot verloren. Das ist der klassische Fall „bis Dienstag hat es funktioniert“.

Die Weiterleitung muss außerdem die Firewall passieren dürfen. Wenn ufw unter Ubuntu aktiv ist, werden weitergeleitete Pakete verworfen, sofern DEFAULT_FORWARD_POLICY="ACCEPT" nicht in /etc/default/ufw gesetzt ist. Docker setzt diese Richtlinie selbst. Wenn sudo iptables -S FORWARD | head -1 auf einem Server, auf dem Sie nie manuell eine Firewall konfiguriert haben, -P FORWARD DROP ausgibt, wurde die Einstellung von Docker gesetzt. Für Ihren Tunnel-Datenverkehr benötigen Sie daher eine explizite Accept-Regel.

Warum die Antworten nie zurückkommen

Wenn die Regeln 1 bis 3 korrekt sind, erreicht der Ping das NAS tatsächlich. Trotzdem sehen Sie keine Antwort, weil sie keinen Rückweg hat. 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 und leitet die Antwort an sein eigenes Standardgateway weiter, also an Ihren Internetanschluss. Dort wird sie verworfen. Die Anfrage kommt an, aber die Antwort wird verworfen.

Option A: Masquerading auf dem WireGuard-Server. Der Server ersetzt die Quelladresse jedes weitergeleiteten Pakets durch 192.168.20.5, also seine eigene LAN-Adresse. Das NAS sieht jetzt eine Anfrage von einem Nachbarn im eigenen Subnetz, antwortet direkt an den Server, und der Server macht die Adressänderung rückgängig und sendet das Paket durch den Tunnel zurück. Im restlichen LAN müssen Sie nichts ändern.

Tragen Sie die Regel in den [Interface]-Block des Servers ein, damit sie zusammen mit dem Interface erscheint und verschwindet:

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, tragen Sie sie stattdessen in /etc/nftables.conf ein:

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

Lassen Sie das Schlüsselwort counter stehen. 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 einen weiteren, leicht zu übersehenden Vorteil. Viele Hosts verwenden eine Firewall, die nur Verbindungen aus dem eigenen Subnetz akzeptiert. Die Windows-Dateifreigabe verhält sich standardmäßig so. Das gilt auch für mehrere NAS-Administrationsoberflächen. Ein Paket von 10.8.0.2 wird vom Zielhost 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 wie 192.168.20.5 aussieht. Sie können die Clients daher nicht unterscheiden, und Regeln pro Client auf LAN-Geräten funktionieren 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 namens 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 Regeln pro Client in Ihrem LAN bleiben aussagekräftig. Dafür benötigen Sie einen Router, der statische Routen unterstützt. Außerdem hilft diese Lösung nur Hosts, die diesen Router als Standardgateway verwenden. Jeder Host mit einer lokalen, auf das Subnetz begrenzten 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 kontrollierten Systems erforderlich ist. Wechseln Sie zur statischen Route, wenn Sie die tatsächlichen Clientadressen benötigen.

Welche der vier Regeln fehlschlägt

Gehen Sie vom Client aus nach außen vor. 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. Wird stattdessen Ihre WLAN-Schnittstelle genannt, ist Regel 1 falsch und der AllowedIPs des Clients deckt das LAN-Subnetz nicht ab. Ein ping: connect: Network is unreachable verweist auf dieselbe Zeile.

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

sudo tcpdump -ni wg0 icmp

Ein funktionierender Pfad zeigt IP 10.8.0.2 > 192.168.20.10: ICMP echo request. ICMP steht für Internet Control Message Protocol und ist das Protokoll, das ping verwendet. Wenn bei einem funktionierenden Handshake hier nichts angezeigt wird, greift Regel 2: Der AllowedIPs des Servers für diesen Peer umfasst 10.8.0.2 nicht. Das Paket wurde bei der Entschlüsselung verworfen, bevor es wg0 erreichen konnte.

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

sudo tcpdump -ni enp1s0 icmp

Sind Anfragen auf wg0 sichtbar, hier jedoch nicht, greift Regel 3. Die Weiterleitung ist deaktiviert oder eine FORWARD-Regel hat das Paket verworfen. Sind hier Anfragen mit der Quelladresse 10.8.0.2 sichtbar, aber keine Antworten, greift Regel 4. Für die Antwort fehlt eine Route zurück. Sind hier Anfragen mit der Quelladresse 192.168.20.5 sichtbar, aber keine Antworten, funktioniert Ihre Masquerading-Regel. Der Zielhost selbst lehnt die Anfrage ab. Prüfen Sie daher die Firewall auf dem NAS. Dieselbe Prüfung funktioniert auch für andere Dienste, wenn Sie icmp durch port 445 oder den gewünschten Port ersetzen.

IP-Adresse erreichbar, aber der Name nicht

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 läuft über einen separaten Pfad, und Ihr Laptop fragt weiterhin den Resolver ab, den er vom lokalen WLAN erhalten hat. Dieser Resolver kennt die Namen in Ihrem Heimnetz nicht.

Damit die Namen im Heimnetz funktionieren, müssen zwei Bedingungen erfüllt sein. Die Adresse des Resolvers muss auf dem Client innerhalb von AllowedIPs liegen, sonst gelangt die DNS-Abfrage (Domain Name System) nicht durch den Tunnel. Außerdem muss der Resolver bereit sein, eine Abfrage zu beantworten, deren Quelladresse 10.8.0.2 lautet. Viele Resolver im Heimnetz lehnen solche Abfragen standardmäßig ab: dnsmasq mit aktiviertem local-service beantwortet nur Abfragen 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, weil die Abfrage nach der Umschreibung von 192.168.20.5 kommt.

Auf der Client-Seite ist eine Zeile erforderlich:

DNS = 192.168.20.1

Auf einem Linux-Client, der openresolv oder ein entsprechendes Verfahren benötigt, beendet sich wg-quick andernfalls mit resolvconf: command not found. Machen Sie sich mit der Wirkung auf einem systemd-resolved-System vertraut, bevor Sie die Einstellung setzen: wg-quick registriert diese Server ausschließlich. Solange der Tunnel aktiv ist, wird daher jede Namensauflösung auf dem Laptop an den Resolver im Heimnetz gesendet, nicht nur die Namen des Heimnetzes. Prüfen Sie das Ergebnis mit resolvectl status wg0. Wenn Namen im Heimnetz zu Hause und alle anderen Namen lokal aufgelöst werden sollen, handelt es sich um Split DNS. DNS über einen WireGuard-Tunnel korrigieren beschreibt die Konfiguration vollständig.

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

Wenn die Statusseite Ihres Routers eine WAN-Adresse aus 100.64.0.0/10 oder eine private 192.168.x.x-Adresse anzeigt, befinden Sie sich hinter CGNAT (Carrier-Grade Network Address Translation). Dann kann kein Handshake aus dem Internet Ihr Heimnetz erreichen. Ein ausgehender Handshake funktioniert weiterhin normal. Die Lösung ist ein dritter Knoten mit einer öffentlichen Adresse. Ein kleiner VPS übernimmt die Hub-Funktion, und der Rechner zu Hause baut die Verbindung zu ihm auf.

Die vier Regeln ändern sich nicht. Sie gelten jetzt über zwei Hops hinweg. Deshalb 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 übertragen 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 der gesamte Datenverkehr zum Hub geht.
• Auf dem Rechner zu Hause erhält der Peer des VPS AllowedIPs = 10.8.0.0/24. Außerdem führt der Rechner zu Hause PersistentKeepalive = 25, weil er sich jetzt hinter NAT befindet.
• Der VPS benötigt ebenfalls net.ipv4.ip_forward = 1. Seine Forwarding-Kette muss wg0 zu wg0 erlauben, 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 den VPS noch nicht eingerichtet haben, beschreibt WireGuard auf einem VPS einrichten die Schlüsselerzeugung, die Firewall und die systemd-Unit. Das allgemeine Vorgehen, um einen Rechner zu erreichen, der keine eingehenden Verbindungen annehmen 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 Heim-LAN erreichen?

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

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 Nachbarn, den sie bereits erreichen können, 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 ist sinnvoll, wenn die tatsächlichen Client-Adressen in den Logs Ihrer LAN-Hosts erscheinen sollen oder wenn Sie dort Firewall-Regeln pro Client benötigen.

Warum funktioniert dasselbe Subnetz an beiden Enden des Tunnels nicht?

Ihr Laptop kann nicht zwei Routen für dasselbe Präfix verwalten. Wenn das lokale Netzwerk 192.168.1.0/24 verteilt und Ihr Heim-LAN ebenfalls 192.168.1.0/24 verwendet, schlägt ein Split-Tunnel mit wg-quick up fehl, wenn ip route add mit RTNETLINK answers: File exists ablehnt. Ein Full-Tunnel wird stattdessen aufgebaut. Dabei installiert wg-quick Policy-Regeln, die verhindern, dass spezifischere Routen aus der Haupttabelle verwendet werden. Dadurch hat das lokale Netzwerk Vorrang und das entfernte LAN bleibt nicht erreichbar. Nummerieren Sie das Heim-LAN auf einen selten verwendeten Bereich wie 192.168.20.0/24 um. Eine clientseitige Lösung gibt es nicht.

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

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

Mein Heimanschluss hat keine öffentliche IP-Adresse. Kann ich trotzdem auf mein LAN zugreifen?

Ja, mit einem dritten Knoten. Hinter CGNAT ist die WAN-Adresse Ihres Routers privat. Daher kann kein Peer aus dem Internet einen Handshake mit ihm starten. Ein ausgehender Handshake funktioniert dagegen normal. Betreiben Sie WireGuard auf einem VPS mit öffentlicher Adresse und lassen Sie den Rechner zu Hause mit PersistentKeepalive = 25 eine ausgehende Verbindung dorthin herstellen. Der Peer-Eintrag des Heimrechners auf dem VPS benötigt ein AllowedIPs, das seine Tunneladresse sowie 192.168.20.0/24 enthält. Auf dem VPS müssen anschließend IP-Forwarding aktiviert und eine Forward-Regel eingerichtet werden, die wg0 zu wg0 erlaubt.