El mòdul WireGuard no es carrega després d'una actualització del nucli? Comproveu-ho

El vostre túnel funcionava ahir, la màquina es va reiniciar després d'una actualització i ara la interfície no s'aixeca. En un sistema on WireGuard es compila com a mòdul extern, la causa habitual és que el mòdul del disc pertany a una versió del nucli diferent de la que s'executa ara. Les capçaleres amb un nom similar a la mateixa màquina no demostren res sobre aquesta coincidència. Només la cadena de versió ho decideix.

Nucli en execució o nucli instal·lat

Una actualització instal·la un paquet de nucli nou i deixa el vell al disc fins que la màquina es reinicia. Després del reinici, la versió en execució canvia, i qualsevol mòdul compilat contra l'anterior queda inservible encara que els seus fitxers segueixin allà. Aquest buit explica l'informe habitual d'una màquina que anava bé abans d'un reinici i es va espatllar després, sense cap canvi de configuració entremig. També explica per què reinstal·lar les capçaleres de vegades sembla resoldre el problema i de vegades no.

El paquet de capçaleres que instal·leu pot correspondre al paquet de nucli més nou en lloc del nucli que realment s'ha iniciat, i res del nom del paquet no distingeix aquests casos; només ho fa la cadena de versió. Comproveu què s'executa abans de comprovar què està instal·lat.

Tres comprovacions abans de reconstruir

La primera comprovació és quin nucli s'executa. La segona és si existeix un mòdul per a aquesta versió i si es pot trobar. La tercera és si el nucli ja l'ha carregat. La quarta pregunta, si es pot crear la interfície, posa a prova els privilegis i no el mòdul, així que va després de la reconstrucció i no en aquesta llista.

Les ordres següents responen les tres primeres sense canviar res. Llegiu cada resultat abans de continuar, perquè cada resposta descarta una reparació diferent.

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

Si la segona línia informa que el camí no existeix, falta l'entorn de compilació del nucli en execució i res del que compileu hi coincidirà. Si modinfo falla mentre el camí existeix, potser el mòdul no està instal·lat, cosa normal en nuclis que inclouen la implementació a l'arbre. Si modinfo té èxit i lsmod no mostra res, el mòdul existeix però no està carregat, cosa que és un problema de càrrega i no de compilació. Cada resultat us porta a un lloc diferent, i per això llegir importa més que les ordres.

Compileu contra la versió en execució

Un mòdul extern es compila contra un arbre de nucli preparat, i la guia de mòduls externs del nucli descriu l'ús del directori de compilació que pertany al nucli en execució i no del directori que porti el número de versió més alt. Aquest directori de compilació és un enllaç simbòlic mantingut pel paquet del nucli, així que apunta a l'arbre de la versió que s'ha iniciat actualment. La indirecció és precisament el punt: elimina una tria que altrament faríeu malament. Anomenar-lo explícitament fa que l'objectiu sigui inequívoc.

Un detall importa quan l'arbre només s'ha preparat i no s'ha compilat del tot. L'objectiu de preparació no genera el fitxer de versionat de símbols que necessiten algunes compilacions externes, així que un arbre ple de capçaleres no és automàticament un entorn de compilació complet. Si una compilació falla per símbols que falten, aquest fitxer és el primer lloc on mirar.

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

Quan les capçaleres empaquetades van endarrerides

En distribucions i ordinadors d'una sola placa que empaqueten els seus propis nuclis, les capçaleres poden anar dies o setmanes per darrere de la versió. El paquet de capçaleres pot ser correcte de nom i més antic de contingut, cosa que produeix una compilació que compila i després falla en carregar-se en lloc de durant la compilació. Barrejar fonts ho empitjora: un nucli de distribució amb capçaleres d'un repositori de tercers, o un nucli de fabricant amb capçaleres genèriques, poden compilar netament i tot i així ser rebutjats pel nucli en execució perquè la configuració difereix. Els números de versió per si sols no ho resolen.

Si la màquina segueix un canal de nucli experimental, decidiu deliberadament si voleu quedar-vos-hi amb artefactes de compilació coincidents o tornar al conjunt de paquets suportat. Repetir l'actualització i esperar que les peces s'alineïn no és un pla, perquè la mateixa discrepància es reprodueix cada vegada.

Verifiqueu la interfície després de la reconstrucció

Després d'una instal·lació correcta, crear la interfície és la prova que importa, seguida de llegir què ha carregat realment el nucli i què diu el registre si s'ha negat. Un mòdul que es carrega i una interfície que no es pot crear són fallades diferents amb causes diferents. Les tres ordres següents les separen.

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

Si el mòdul es nega a carregar-se, el registre del nucli n'indica el motiu, i una discrepància de versió només és una de les possibilitats. Llegiu aquesta línia abans de reconstruir, perquè una segona compilació idèntica gasta els mateixos deu minuts i produeix la mateixa negativa. Després traieu la interfície temporal perquè la propera prova comenci des d'un estat net.