WireGuard AllowedIPs: die Route, die NetworkManager nie hinzufügte

Der Handshake-Zähler aktualisiert sich, das Interface behält seine Adresse, und ein Ping auf die Gegenseite kommt nirgendwo an. Diese Kombination verwirrt Leute, weil ein funktionierender Handshake wie ein Beweis wirkt, dass der Tunnel bereit ist. Ist er nicht: Ein Tunnel kann vollständig ausgehandelt sein und trotzdem keine Route haben, die Verkehr hineinleitet, und das sind zwei getrennte Aufgaben, die von zwei getrennten Stücken Zustand erledigt werden. Die Korrektur hängt ganz davon ab, welches der beiden fehlt, also besteht der erste Schritt darin, das herauszufinden.

wg-quick erledigt beides, ohne gefragt zu werden. Die eingebaute WireGuard-Unterstützung von NetworkManager installiert außerdem standardmäßig Peer-Routen, was die Verdächtigen auf eine deaktivierte Option, eine andere Routing-Tabelle oder eine über etwas anderes importierte Konfiguration eingrenzt.

Bestätigen Sie den Tunnel, bevor Sie die Route jagen

wg show zeigt Interface, Peer, Endpunkt und Alter des letzten Handshakes, und ip addr show bestätigt, dass die Adresse vorhanden ist. Ein frischer Handshake bedeutet, dass Schlüssel, Endpunkt und UDP-Pfad funktionieren. Was auch immer kaputt ist, sitzt stromabwärts davon: Routing, Filterung oder Namensauflösung.

Fragen Sie dann den Kernel, was er mit einem echten Ziel statt einem hypothetischen täte: ip route get 10.42.7.9. Die Antwort nennt das ausgehende Interface und die Quelladresse, die das Paket tragen würde. Wenn sie den physischen Adapter nennt, betritt das Paket den Tunnel nie, so gesund der Handshake auch aussieht.

AllowedIPs ist ein Filter und eine Routenliste

Die Präfixe in AllowedIPs erledigen zwei Aufgaben. Sie wählen, welcher Peer ein ausgehendes Ziel trägt, und sie prüfen die Quelladresse eingehender Pakete, was die Grenze des Cryptokey-Routings ist. In wg-quick treiben sie zusätzlich die automatische Routeninstallation, und genau dieses Zusatzverhalten ist der Grund, warum dieselbe Konfiguration vom Terminal aus funktioniert und nicht von einem Desktop-Client.

Im Fall hinter diesem Artikel wurde das Profil über ein Drittanbieter-Plugin importiert statt über die eingebaute Unterstützung, und das Interface kam ohne die Präfixroute hoch. Ein Blick in die Tabelle zeigt es sofort: ip route show enthält nur die verbundene Route für die Interface-Adresse und nichts für den entfernten Bereich.

Fragen Sie, ob Peer-Routen überhaupt aktiviert sind

Lesen Sie die Einstellung, bevor Sie etwas ändern: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. Wenn peer-routes no anzeigt, ist die unterstützte Reparatur nmcli connection modify work-wg wireguard.peer-routes yes, gefolgt von einem Neuverbinden. Eine statische Route stattdessen hinzuzufügen funktioniert bis zur nächsten Aktivierung und verschwindet dann still. Dieses Verschwinden ist der Hinweis: Eine Route, die jeden Morgen als Rätsel zurückkommt, wird nicht vom Profil installiert.

Wenn die Option bereits aktiviert ist, prüfen Sie mit ip route show table all | grep 10, ob das Präfix in einer anderen Tabelle lebt. Eine Route in einer Nicht-Haupttabelle fehlt nicht, sie ist nur unsichtbar für eine Suche, die ausschließlich die Haupttabelle konsultiert. Reparieren Sie das Policy-Routing, statt einen doppelten Eintrag oben draufzustapeln.

Fügen Sie das Präfix der Verbindung hinzu, nicht dem laufenden System

Im Verbindungseditor hält die WireGuard-Seite den Peer und seine AllowedIPs, und die IPv4-Seite hält zusätzliche Routen. Eine dort hinzugefügte Route überlebt Neuverbindungen, weil sie zum Profil gehört. Auf der Kommandozeile ist das Gegenstück, der Verbindung eine Route in der Form mit leerem Gateway anzuhängen und die Verbindung dann herunter- und wieder hochzufahren, damit die Änderung greift.

Wählen Sie das engste Präfix, das die benötigten Hosts abdeckt. Das Beispiel /8 des Anbieters zu kopieren kann lokale Bereiche verschlucken, die zufällig darin liegen, und die resultierenden Ausfälle sehen wie ein kaputter Tunnel aus statt wie eine zu breite Route.

Split-Tunneling entscheidet die Präfixliste

Es gibt keinen Split-Tunnel-Schalter; die Präfixliste ist die Entscheidung. Ein Peer mit einem Bereich für das Büro-LAN und einem für ein Labornetz schickt genau diese Ziele durch den Tunnel und lässt alles andere in Ruhe. Ein einzelner Host braucht ein /32, und überlappende Bereiche an zwei Standorten brauchen Host-Präfixe, bis jemand ein Subnetz umnummeriert.

Die Entscheidung, nichts durch den Tunnel zu schicken, treibt dieselbe Entscheidung an ihre Grenze: Eine minimale Liste lässt die Verbindung oben, während gewöhnlicher Verkehr auf seinem üblichen Weg bleibt. Schreiben Sie die Absicht auf, weil der nächste Leser die kurze Liste sonst für ein Versehen hält und sie hilfreich erweitert.

Ein Eigentümer für die Routentabelle

wg-quick und NetworkManager glauben beide, sie besäßen die Routen des Interfaces. Importieren Sie eine für wg-quick geschriebene Konfiguration und starten Sie dann auch noch den wg-quick-Dienst, und Sie bekommen doppelte oder widersprüchliche Einträge, deren Verhalten davon abhängt, wer zuletzt lief. Wählen Sie einen einzigen Eigentümer und entfernen Sie den anderen: Wenn NetworkManager die Verbindung verwaltet, deaktivieren Sie die wg-quick-Unit für dieses Interface, und fügen Sie nie ein zweites Profil für dasselbe Gerät hinzu.

Wenn die Aufteilung einem physischen Adapter statt einem Ziel folgen muss, sind Sie ins Policy-Routing übergewechselt, und Policy-Routing braucht ebenfalls einen einzigen Autor. Prüfen Sie es, indem Sie ip route get wiederholen und dann mit etwas, das die gewählte Quelladresse ausgibt, einen Host innerhalb des entfernten Präfixes erreichen. Prüfen Sie IPv6 und DNS getrennt, wenn das Profil eines von beidem trägt.