WireGuard-Modul lädt nach einem Kernel-Update nicht? Prüfen Sie das

Ihr Tunnel lief gestern, die Maschine startete nach einem Update neu, und jetzt kommt die Schnittstelle nicht hoch. Auf einem System, auf dem WireGuard als externes Modul gebaut wird, ist die übliche Ursache, dass das Modul auf der Platte zu einer anderen Kernelversion gehört als der, die jetzt läuft. Header mit ähnlichem Namen auf derselben Maschine beweisen nichts über diese Übereinstimmung. Nur die Versionszeichenkette entscheidet darüber.

Laufender oder installierter Kernel

Ein Update installiert ein neues Kernelpaket und lässt das alte auf der Platte, bis die Maschine neu startet. Nach dem Neustart ändert sich die laufende Version, und jedes gegen die vorherige gebaute Modul wird unbrauchbar, obwohl seine Dateien noch da sind. Diese Lücke erklärt den vertrauten Bericht von einer Maschine, die vor einem Neustart in Ordnung war und danach kaputt, ohne Konfigurationsänderung dazwischen. Sie erklärt auch, warum eine Neuinstallation der Header das Problem manchmal zu beheben scheint und manchmal nicht.

Das Header-Paket, das Sie installieren, kann zum neuesten Kernelpaket passen statt zu dem Kernel, der tatsächlich gebootet wurde, und nichts im Paketnamen unterscheidet diese Fälle; nur die Versionszeichenkette tut das. Prüfen Sie, was läuft, bevor Sie prüfen, was installiert ist.

Drei Prüfungen vor dem Neubau

Die erste Prüfung ist, welcher Kernel läuft. Die zweite ist, ob ein Modul für diese Version existiert und gefunden werden kann. Die dritte ist, ob der Kernel es bereits geladen hat. Die vierte Frage, ob die Schnittstelle erstellt werden kann, prüft Rechte statt das Modul, gehört also nach den Neubau und nicht in diese Liste.

Die folgenden Befehle beantworten die ersten drei, ohne etwas zu ändern. Lesen Sie jedes Ergebnis, bevor Sie weitergehen, denn jede Antwort schließt eine andere Reparatur aus.

uname -r
ls -l /lib/modules/$(uname -r)/build
modinfo wireguard
lsmod | grep wireguard

Wenn die zweite Zeile meldet, dass der Pfad nicht existiert, fehlt die Build-Umgebung für den laufenden Kernel, und nichts, was Sie kompilieren, wird dazu passen. Wenn modinfo fehlschlägt, während der Pfad existiert, ist das Modul möglicherweise gar nicht installiert, was bei Kerneln normal ist, die die Implementierung im Baum mitliefern. Wenn modinfo gelingt und lsmod nichts zeigt, existiert das Modul, ist aber nicht geladen, was ein Ladeproblem und kein Build-Problem ist. Jedes Ergebnis führt Sie woanders hin, deshalb ist das Lesen wichtiger als die Befehle.

Bauen Sie gegen die laufende Version

Ein externes Modul wird gegen einen vorbereiteten Kernelbaum kompiliert, und die Anleitung des Kernels für externe Module beschreibt die Verwendung des Build-Verzeichnisses, das zum laufenden Kernel gehört, statt des Verzeichnisses mit der höchsten Versionsnummer. Dieses Build-Verzeichnis ist ein symbolischer Link, den das Kernelpaket pflegt, also zeigt es auf den Baum der aktuell gebooteten Version. Die Umleitung ist genau der Punkt: Sie beseitigt eine Wahl, die Sie sonst falsch treffen würden. Wenn Sie es ausdrücklich benennen, wird das Ziel eindeutig.

Ein Detail zählt, wenn der Baum nur vorbereitet und nicht vollständig gebaut wurde. Das Vorbereitungsziel erzeugt nicht die Symbolversionsdatei, die manche externen Builds brauchen, also ist ein Baum voller Header nicht automatisch eine vollständige Build-Umgebung. Wenn ein Build an fehlenden Symbolen scheitert, ist diese Datei die erste Stelle zum Nachsehen.

sudo make -C /lib/modules/$(uname -r)/build M=$(pwd) modules
sudo make -C /lib/modules/$(uname -r)/build M=$(pwd) modules_install
sudo depmod -a

Wenn paketierte Header hinterherhinken

Bei Distributionen und Einplatinencomputern, die ihre eigenen Kernel paketieren, können Header Tage oder Wochen hinter der Version zurückliegen. Das Header-Paket kann im Namen korrekt und im Inhalt älter sein, was einen Build ergibt, der kompiliert und dann beim Laden scheitert statt während der Kompilierung. Das Mischen von Quellen verschlimmert es: ein Distributionskernel mit Headern aus einem Drittanbieter-Repository oder ein Herstellerkernel mit generischen Headern kann sauber kompilieren und trotzdem vom laufenden Kernel abgelehnt werden, weil die Konfiguration abweicht. Versionsnummern allein klären das nicht.

Wenn die Maschine einem experimentellen Kernelkanal folgt, entscheiden Sie bewusst, ob Sie dort mit passenden Build-Artefakten bleiben oder zum unterstützten Paketsatz zurückkehren. Das Update zu wiederholen und zu hoffen, dass die Teile zusammenpassen, ist kein Plan, weil sich dieselbe Abweichung jedes Mal wiederholt.

Prüfen Sie die Schnittstelle nach dem Neubau

Nach einer erfolgreichen Installation ist das Erstellen der Schnittstelle der entscheidende Test, gefolgt vom Lesen, was der Kernel tatsächlich geladen hat und was das Protokoll sagt, wenn er es abgelehnt hat. Ein Modul, das lädt, und eine Schnittstelle, die nicht erstellt werden kann, sind verschiedene Fehler mit verschiedenen Ursachen. Die drei folgenden Befehle trennen sie.

sudo ip link add wg9 type wireguard
lsmod | grep wireguard
sudo dmesg | tail -5

Wenn das Modul das Laden verweigert, nennt das Kernelprotokoll den Grund, und eine Versionsabweichung ist nur eine der Möglichkeiten. Lesen Sie diese Zeile, bevor Sie erneut bauen, denn ein zweiter identischer Build kostet dieselben zehn Minuten und liefert dieselbe Ablehnung. Entfernen Sie danach die Wegwerf-Schnittstelle, damit der nächste Test von einem sauberen Zustand aus startet.