El canvi de nucli FIPS s'endugué els mòduls de Wi-Fi i VPN

Activeu fips-updates, reinicieu i la màquina torna sense interfície sense fil, mentre el client VPN es nega a arrencar perquè li falta el mòdul del nucli. No s'ha desinstal·lat res en el sentit habitual dels paquets, i per això reinstal·lar el client no canvia absolutament res. La màquina funciona amb un nucli per al qual els seus controladors no es van compilar mai. Dos símptomes, una causa, i la causa es veu en una sola ordre.

Què va canviar realment el reinici

Les actualitzacions FIPS d'Ubuntu Pro instal·len una variant certificada del nucli i la fan l'entrada d'arrencada per defecte. Aquesta variant és un nucli de veritat: arrenca, funciona i inicia els serveis que ja teníeu. El que no conté és cada mòdul compilat per al nucli genèric, inclòs un controlador sense fil compilat fora de l'arbre i un mòdul de túnel lliurat mitjançant DKMS. El conjunt de controladors es mou amb el nucli, no amb el gestor de paquets. Per tant, el maquinari encara hi és i el programari que hi parla no.

Compareu el nucli en execució amb els paquets instal·lats abans d'obrir cap paràmetre de xarxa. La cadena de versió porta una marca que el nucli genèric no té, i aquest sol detall explica les dues peces que falten.

Llegiu també l'entrada d'arrencada, perquè una màquina pot tenir el nucli certificat instal·lat sense executar-lo. En aquest cas la història dels mòduls és completament diferent, i els ports i controladors que estàveu a punt de reinstal·lar estan bé.

Llegiu l'estat dels mòduls abans de la configuració del client

Un mòdul que no es pot trobar i un mòdul que existeix però es nega a carregar-se són avaries diferents amb solucions diferents. modinfo indica quin dels dos teniu, i lsmod indica què hi ha carregat ara mateix. Feu les dues coses abans de tocar la configuració del client VPN, perquè l'error propi del client rares vegades els separa.

La part sense fil necessita la mateixa divisió. Una interfície que no apareix mai apunta al controlador, mentre que una que existeix però queda bloquejada apunta a rfkill o al gestor de xarxa. Totes dues es veuen igual en una miniaplicació d'escriptori i no comparteixen res per sota.

Feu les comprovacions a la mateixa màquina mentre l'avaria encara es pot reproduir. Una sortida enganxada d'un altre equip no substitueix aquesta.

uname -r
pro status --all | grep -E 'fips|kernel'
modinfo wireguard 2>&1 | head -3
rfkill list

Quan modinfo no troba el mòdul de cap manera, reinstal·lar el paquet d'espai d'usuari no ajudarà, perquè l'espai d'usuari mai no era la part que faltava. Aquesta observació estalvia una hora de tràfec de paquets i assenyala directament el nucli.

Torneu enrere en un ordre que us deixi un nucli

Si FIPS es va activar per error, el camí de recuperació documentat desactiva el servei, purga els seus paquets i després restaura el nucli genèric. L'ordre no és cosmètic. La purga es nega a continuar quan no troba cap altre nucli d'Ubuntu, perquè eliminar l'únic deixaria una màquina que no pot arrencar. Aquesta comprovació és la diferència entre una reversió i una reconstrucció. També és la raó per la qual la seqüència falla quan el nucli genèric ja s'havia eliminat.

Executeu-ho mentre el nucli genèric encara és instal·lat, accepteu l'avís sobre eliminar un nucli i reinicieu després. Després confirmeu que no queda cap paquet FIPS en estat instal·lat i que el nucli en execució és el que esperàveu.

En un equip remot, organitzeu primer accés per consola o fora de banda. Eliminar un nucli per SSH va bé fins exactament al reinici que no torna.

dpkg -l | grep -E 'linux-image|fips'
sudo pro disable fips-updates --purge
sudo apt install --reinstall linux-generic
sudo reboot

Quan la certificació és el requisit

Tornar enrere és el moviment equivocat quan la certificació és contractual, perquè llavors la màquina surt de la configuració que descriu l'auditoria. En aquest cas el buit de controladors és una qüestió de selecció de maquinari: trieu un adaptador sense fil el controlador del qual ve amb el nucli certificat, accepteu una màquina només amb cable o moveu el túnel a un component que el nucli certificat ja admeti.

Compilar un mòdul fora de l'arbre dins del nucli certificat no és una solució neutra. Canvia què executa el nucli, i aquesta és precisament la propietat que descriu la certificació.

Registreu la decisió amb el nom del propietari al costat, perquè la petició de fer funcionar el Wi-Fi i prou tornarà d'aquí a uns quants mesos amb menys context. Una nota curta ara evita la mateixa discussió més endavant.

Reviseu la pila per capes després del canvi

Després de la reversió o del canvi de maquinari, verifiqueu de baix a dalt en lloc de des del client VPN cap avall. La interfície ha d'existir, l'enllaç ha d'estar aixecat, el resolutor ha de funcionar i només llavors importa el túnel. Cada capa falla amb el seu propi missatge, i llegir-los en ordre manté el diagnòstic honest.

L'estat de DNS que sobra de l'arrencada anterior és un fals positiu habitual, així que llegiu el resolutor abans de concloure que el túnel s'ha trencat.

nmcli device status
ip -brief link
resolvectl status | head -12
systemctl --failed

Si el túnel encara falla un cop el nucli ha tornat, llegiu l'etapa que falla i no la línia de resum del client. Un mòdul que no es va carregar mai, un certificat que l'igual va rebutjar i una credencial que el servidor va rebutjar són tres problemes separats, i un reinici no els distingirà per vosaltres. Anoteu el nom de l'etapa al tiquet, i el següent enginyer començarà on vosaltres ho vau deixar.