A WireGuard modul nem töltődik be a kernel frissítése után? Ellenőrizze ezt

Az alagút tegnap működött, a gép újraindult egy frissítés után, és most az interfész nem jön fel. Olyan rendszeren, ahol a WireGuardot külső modulként fordítják, a szokásos ok az, hogy a lemezen lévő modul más kernelkiadáshoz tartozik, mint amelyik most fut. Az azonos nevű fejlécek ugyanazon a gépen semmit nem bizonyítanak erről az egyezésről. Csak a kiadási karakterlánc dönt erről.

Futó vagy telepített kernel

A frissítés telepít egy új kernelcsomagot, és a régit a lemezen hagyja, amíg a gép újra nem indul. Az újraindítás után a futó kiadás megváltozik, és minden, az előzőhöz fordított modul használhatatlanná válik, pedig a fájljai még ott vannak. Ez a hézag magyarázza a jól ismert beszámolót egy gépről, amely újraindítás előtt rendben volt, utána pedig elromlott, anélkül hogy bármi változott volna a konfigurációban. Azt is megmagyarázza, miért tűnik úgy, hogy a fejlécek újratelepítése néha megoldja a problémát, néha pedig nem.

A telepített fejléc-csomag a legújabb kernelcsomaghoz illeszkedhet, nem ahhoz a kernelhez, amelyik valóban elindult, és a csomag nevében semmi nem különbözteti meg ezeket az eseteket; csak a kiadási karakterlánc teszi ezt. Előbb ellenőrizze, mi fut, aztán azt, mi van telepítve.

Három ellenőrzés az újraépítés előtt

Az első ellenőrzés az, melyik kernel fut. A második az, hogy létezik-e modul ehhez a kiadáshoz, és megtalálható-e. A harmadik az, hogy a kernel már betöltötte-e. A negyedik kérdés, hogy létrehozható-e az interfész, jogosultságokat vizsgál, nem a modult, ezért az újraépítés után van a helye, nem ebben a listában.

Az alábbi parancsok az első háromra válaszolnak anélkül, hogy bármit változtatnának. Minden eredményt olvasson el, mielőtt továbblép, mert minden válasz más javítást zár ki.

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

Ha a második sor azt jelenti, hogy az útvonal nem létezik, hiányzik a futó kernel fordítási környezete, és semmi, amit lefordít, nem fog illeszkedni hozzá. Ha a modinfo sikertelen, miközben az útvonal létezik, a modul talán egyáltalán nincs telepítve, ami normális azoknál a kerneleknél, amelyek a megvalósítást a fán belül szállítják. Ha a modinfo sikeres, és a lsmod semmit nem mutat, a modul létezik, de nincs betöltve, ami betöltési, nem pedig fordítási probléma. Minden eredmény máshová küldi önt, ezért az olvasás fontosabb, mint a parancsok.

A futó kiadáshoz fordítson

Egy külső modult egy előkészített kernelfa ellen fordítanak, és a kernel külső modulokról szóló útmutatója a futó kernelhez tartozó fordítási könyvtár használatát írja le, nem azt, amelyik a legmagasabb verziószámot viseli. Ez a fordítási könyvtár a kernelcsomag által karbantartott szimbolikus hivatkozás, ezért arra a fára mutat, amely az éppen elindított kiadáshoz tartozik. A közvetettség a lényeg: eltávolít egy választást, amelyet különben rosszul hozna meg. Ha kifejezetten megnevezi, a cél egyértelművé válik.

Egy részlet számít, amikor a fát csak előkészítették, nem fordították le teljesen. Az előkészítési cél nem állítja elő azt a szimbólum-verziózási fájlt, amelyre egyes külső fordításoknak szükségük van, ezért a fejlécekkel teli fa nem automatikusan teljes fordítási környezet. Ha egy fordítás hiányzó szimbólumok miatt hiúsul meg, ez a fájl az első hely, ahol érdemes megnézni.

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

Amikor a csomagolt fejlécek lemaradnak

Azokon a disztribúciókon és egykártyás számítógépeken, amelyek saját kerneleket csomagolnak, a fejlécek napokkal vagy hetekkel elmaradhatnak a kiadástól. A fejléc-csomag lehet név szerint helyes és tartalmilag régebbi, ami olyan buildet ad, amely lefordul, majd betöltéskor hiúsul meg, nem pedig fordítás közben. A források keverése ront a helyzeten: egy harmadik féltől származó tárolóból származó fejlécekkel rendelkező disztribúciós kernel vagy egy általános fejlécekkel rendelkező gyártói kernel tisztán lefordulhat, és mégis elutasíthatja a futó kernel, mert a konfiguráció eltér. A verziószámok önmagukban nem döntenek erről.

Ha a gép kísérleti kernelcsatornát követ, tudatosan döntse el, hogy ott marad-e megfelelő fordítási termékekkel, vagy visszatér a támogatott csomagkészlethez. A frissítés ismételgetése és annak remélése, hogy az alkatrészek összeállnak, nem terv, mert ugyanaz az eltérés minden alkalommal megismétlődik.

Ellenőrizze az interfészt az újraépítés után

Sikeres telepítés után az interfész létrehozása az a próba, amely számít, utána pedig annak olvasása, mit töltött be valójában a kernel, és mit mond a napló, ha megtagadta. A betöltődő modul és a létre nem hozható interfész különböző hibák, különböző okokkal. Az alábbi három parancs elválasztja őket.

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

Ha a modul megtagadja a betöltést, a kernel naplója megnevezi az okot, és a verzióeltérés csak az egyik lehetőség. Olvassa el azt a sort az újraépítés előtt, mert egy második azonos build ugyanazt a tíz percet tölti el, és ugyanazt az elutasítást adja. Utána távolítsa el az ideiglenes interfészt, hogy a következő próba tiszta állapotból induljon.