Il cambio di kernel FIPS si è portato via i moduli Wi-Fi e VPN

Attivate fips-updates, riavviate, e la macchina torna senza interfaccia wireless mentre il client VPN rifiuta di avviarsi perché manca il suo modulo del kernel. Non è stato disinstallato nulla nel senso consueto dei pacchetti, ed è per questo che reinstallare il client non cambia assolutamente nulla. La macchina esegue un kernel per il quale i suoi driver non sono mai stati compilati. Due sintomi, una causa, e la causa si vede in un solo comando.

Che cosa ha davvero cambiato il riavvio

Gli aggiornamenti FIPS di Ubuntu Pro installano una variante certificata del kernel e la rendono la voce di avvio predefinita. Quella variante è un kernel vero: si avvia, funziona e avvia i servizi che avevate già. Ciò che non contiene è ogni modulo compilato per il kernel generico, incluso un driver wireless compilato fuori dall'albero e un modulo tunnel fornito tramite DKMS. L'insieme dei driver si sposta con il kernel, non con il gestore dei pacchetti. Quindi l'hardware è ancora lì e il software che gli parla no.

Confrontate il kernel in esecuzione con i pacchetti installati prima di aprire qualsiasi impostazione di rete. La stringa di versione porta un contrassegno che il kernel generico non ha, e quel singolo dettaglio spiega entrambi i pezzi mancanti.

Leggete anche la voce di avvio, perché una macchina può avere il kernel certificato installato senza eseguirlo. In quel caso la storia dei moduli è del tutto diversa, e le porte e i driver che stavate per reinstallare sono a posto.

Leggete lo stato dei moduli prima della configurazione del client

Un modulo che non si trova e un modulo che esiste ma rifiuta di caricarsi sono due guasti diversi con due correzioni diverse. modinfo indica quale avete, e lsmod indica che cosa è caricato adesso. Fate entrambe le cose prima di toccare la configurazione del client VPN, perché l'errore del client stesso raramente li separa.

La parte wireless richiede la stessa separazione. Un'interfaccia che non compare mai punta al driver, mentre una che esiste ma resta bloccata punta a rfkill o al gestore di rete. Le due sembrano identiche in un'applet del desktop e non condividono nulla sotto.

Eseguite i controlli sulla macchina stessa finché il guasto è ancora riproducibile. Un output incollato da un altro host non sostituisce questo.

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

Quando modinfo non trova affatto il modulo, reinstallare il pacchetto dello spazio utente non aiuterà, perché lo spazio utente non è mai stato la parte mancante. Quell'osservazione risparmia un'ora di traffico con i pacchetti e punta dritto al kernel.

Tornate indietro in un ordine che vi lasci un kernel

Se FIPS è stato attivato per errore, il percorso di ripristino documentato disattiva il servizio, elimina i suoi pacchetti e poi ripristina il kernel generico. L'ordine non è cosmetico. L'eliminazione rifiuta di proseguire quando non trova un altro kernel Ubuntu, perché rimuovere l'unico lascerebbe una macchina che non si avvia. Quel controllo è la differenza tra un rollback e una ricostruzione. È anche il motivo per cui la sequenza fallisce quando il kernel generico è già stato rimosso.

Eseguitelo mentre il kernel generico è ancora installato, accettate l'avviso sulla rimozione di un kernel e riavviate dopo. Poi confermate che non resti alcun pacchetto FIPS nello stato installato e che il kernel in esecuzione sia quello che vi aspettavate.

Su un host remoto, predisponete prima l'accesso da console o fuori banda. Rimuovere un kernel via SSH va bene fino esattamente al riavvio che non torna.

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

Quando la certificazione è il requisito

Tornare indietro è la mossa sbagliata quando la certificazione è contrattuale, perché la macchina esce dalla configurazione che l'audit descrive. In quel caso il divario dei driver è una questione di scelta dell'hardware: scegliete un adattatore wireless il cui driver arriva con il kernel certificato, accettate una macchina solo via cavo, oppure spostate il tunnel su un componente che il kernel certificato già supporta.

Compilare un modulo fuori dall'albero dentro il kernel certificato non è una soluzione neutra. Cambia ciò che il kernel esegue, ed è precisamente la proprietà che la certificazione descrive.

Registrate la decisione con il nome del proprietario accanto, perché la richiesta di far funzionare solo il Wi-Fi tornerà tra qualche mese con meno contesto. Una nota breve adesso evita la stessa discussione più avanti.

Controllate lo stack a strati dopo il cambiamento

Dopo il rollback o il cambio di hardware, verificate dal basso verso l'alto invece che dal client VPN verso il basso. L'interfaccia deve esistere, il collegamento deve essere attivo, il resolver deve funzionare, e solo allora il tunnel conta. Ogni strato fallisce con il proprio messaggio, e leggerli in ordine mantiene la diagnosi onesta.

Uno stato DNS residuo dall'avvio precedente è un falso positivo comune, quindi leggete il resolver prima di concludere che il tunnel si è rotto.

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

Se il tunnel fallisce ancora una volta tornato il kernel, leggete la fase che fallisce invece della riga di riepilogo del client. Un modulo che non è mai stato caricato, un certificato che il peer ha rifiutato e una credenziale che il server ha rifiutato sono tre problemi separati, e un riavvio non li distinguerà per voi. Annotate il nome della fase nel ticket, e il prossimo ingegnere partirà da dove vi siete fermati.