WireGuard funktioniert über Mobilfunk, aber nicht im selben WLAN

Der Tunnel baut sich über Mobilfunk auf und bleibt zu Hause dann bei „Verbinden“ stehen, mit demselben Profil, demselben Peer-Schlüssel und ohne jede Änderung der Konfiguration dazwischen. Der Unterschied liegt in der Route: Eine Anfrage aus dem LAN an die öffentliche Adresse des Routers ist nicht dieselbe Reise wie eine Anfrage, die aus dem Internet eintrifft. Die meisten Heim-Gateways implementieren den Rückweg entweder gar nicht oder nur für bestimmte Protokolle. Dadurch sieht das Symptom nach einem defekten Schlüssel aus, obwohl sich am Schlüssel nichts geändert hat. Klären Sie zuerst, welcher Pfad versagt hat, bevor Sie einen Schlüssel, eine Portweiterleitung oder ein Client-Profil anfassen.

Eine Adresse, zwei verschiedene Wege

Von außen erreicht ein Paket die öffentliche Adresse des Routers, und eine Portweiterleitungsregel reicht es an den WireGuard-Listener auf dem internen Host weiter. Von innen wählt der Client dieselbe öffentliche Adresse, sodass das Paket den Client verlässt, am Router ankommt und wieder in Richtung LAN zurückgedreht werden muss. Genau an dieser Rückdrehung trennen sich die beiden Wege, weil der Router einen Datenfluss übersetzen muss, der dieselbe Schnittstelle zugleich verlässt und wieder betritt. Viele Implementierungen verwerfen ihn, statt ihn zu übersetzen, und der Client wartet dann auf einen Handshake, der nie gesendet wurde.

Die Verhaltensweise heißt üblicherweise NAT-Loopback oder Hairpinning und gehört zum Router, nicht zu WireGuard; RFC 4787 beschreibt die Übersetzungsfälle, in denen ein Gateway es unterstützen darf oder nicht. WireGuard selbst hat keine Meinung zum Pfad, weil es nur Pakete sieht, die seine Schnittstelle erreichen. Wenn der Router den Datenfluss verwirft, erhält der Daemon nie etwas, der Client meldet einen Handshake-Timeout, und das Server-Log bleibt leer. Ein leeres Log ist daher ein Hinweis darauf, wo das Paket stehen blieb, kein Beweis dafür, dass der Server ausgefallen ist. Es ist auch der Grund, warum eine Neuinstallation nichts ändert.

Auch die Umkehrung zählt: Ein Server-Log, das einen Handshake-Versuch von der LAN-Adresse zeigt, beweist, dass das Paket angekommen ist und der Pfad in Ordnung ist, was die Untersuchung auf Schlüssel und erlaubte Adressen verlagert. Lesen Sie das Log danach, was es beweist, und nicht danach, was Sie zu sehen gehofft hatten.

Erst reproduzieren, dann ändern

Testen Sie aus einem autorisierten externen Netz mit demselben Gerät und demselben Profil und wiederholen Sie den Test anschließend im LAN, ohne etwas zu bearbeiten. Ein abgeschlossener Handshake draußen und ein Client, der drinnen das Gerät nie verlässt, reproduzieren den Zustand, statt ihn zu erraten. Beide Versuche müssen dasselbe Profil verwenden, sonst beweist der Vergleich nichts.

Schauen Sie dann nach, worauf der Endpunktname für dieses Gerät auflöst. Die folgenden drei Befehle zeigen außerdem, welche Adresse der Client tatsächlich angewählt hat:

wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.net

Der erste Befehl meldet den Endpunkt, den die Schnittstelle gerade verwendet, und die anderen beiden zeigen, worauf der Name auf dieser Maschine auflöst. Ein Client, der eine öffentliche Adresse anwählt, während er im selben Netz wie der Server sitzt, nutzt den Hairpin-Pfad. Ein Client, der die LAN-Adresse anwählt, tut das nicht, und ein Fehler dort gehört zu einer anderen Untersuchung. Diese Unterscheidung entscheidet, ob der nächste Abschnitt überhaupt gilt.

Zulässige Wege zu einem nahen Server

Die sauberste Lösung ist eine Split-Horizon-Antwort: Der öffentliche Name löst für das Internet auf die öffentliche Adresse auf und für Clients im Inneren auf die LAN-Adresse des Servers. Das Profil behält einen Endpunktnamen, und der Resolver wählt den Pfad. Dafür braucht man die Kontrolle über die interne DNS-Antwort, die ein Heimrouter meist bietet und eine Organisation bewusst einrichten kann. Ohne diese Kontrolle bleiben nur eine Router-Funktion oder ein zweites Profil.

Die Router-Funktion ist die Reflexion: Das Gateway übersetzt den Datenfluss von innen nach außen und schickt ihn wieder nach innen. Wo sie funktioniert, braucht sie keine Client-Änderung, und wo sie nicht funktioniert, rettet keine Client-Einstellung sie. Testen Sie sie, indem Sie während eines internen Versuchs das Server-Log beobachten, statt die Funktionsliste des Routers zu lesen.

Das Profil auf eine private Adresse umzuschreiben ist eine Diagnose, kein Entwurf. Es beweist, dass der Server im LAN antwortet, und es zerstört dasselbe Profil in dem Moment, in dem der Laptop das Haus verlässt.

Das Profil unterwegs brauchbar halten

Welchen Weg Sie auch wählen, lassen Sie die Identitätsprüfung in Ruhe. Die Endpunktadresse ist nicht die Peer-Identität, und ein Adresswechsel rechtfertigt niemals, einen fremden öffentlichen Schlüssel zu akzeptieren, der zufällig antwortet. WireGuard authentifiziert über den Schlüssel, ein falscher Host scheitert also am Handshake, statt Zugriff auf etwas Unerwartetes zu gewähren.

Wenn sich die öffentliche Adresse ändert, hält dynamisches DNS den Namen brauchbar, und das Aktualisierungsverhalten des Clients entscheidet, wie schnell die Änderung ankommt. Testen Sie das nach einem Adresswechsel von außen, denn der LAN-Fall kann es nicht bestätigen. Achten Sie auf einen Resolver, der die alte Antwort über die Lebensdauer des Records hinaus zwischenspeichert. Ein Name, der noch auf die vorherige Adresse zeigt, sieht genauso aus wie ein Server, der ausgefallen ist.

Notieren Sie, welchen Namen das Profil verwendet und worauf er auf beiden Seiten der Grenze auflöst. Ein Profil, das von einer Router-Funktion abhängt, die niemand festgehalten hat, ist ein Support-Anruf, der auf das nächste Firmware-Update wartet. Die Notiz sagt auch der nächsten Person, ob ein interner Fehler der bekannte Hairpin-Fall ist oder etwas Neues.