FIPS-kernelswitch nam de wifi- en VPN-modules mee

Schakel fips-updates in, herstart, en de machine komt terug zonder draadloze interface terwijl de VPN-client weigert te starten omdat de kernelmodule ontbreekt. Er is niets gedeïnstalleerd in de gewone pakketbetekenis, en daarom verandert het opnieuw installeren van de client helemaal niets. De machine draait op een kernel waarvoor de stuurprogramma's nooit zijn gebouwd. Twee symptomen, één oorzaak, en de oorzaak is in één commando te zien.

Wat de herstart werkelijk omzette

De FIPS-updates van Ubuntu Pro installeren een gecertificeerde kernelvariant en maken die de standaard opstartvermelding. Die variant is een echte kernel: hij start, hij draait en hij start de diensten die u al had. Wat er niet in zit, is elke module die voor de generieke kernel is gebouwd, inclusief een draadloos stuurprogramma dat buiten de boom is gecompileerd en een tunnelmodule die via DKMS wordt geleverd. De set stuurprogramma's beweegt mee met de kernel, niet met de pakketbeheerder. De hardware is er dus nog wel en de software die ermee praat niet.

Vergelijk de draaiende kernel met de geïnstalleerde pakketten voordat u welke netwerkinstelling dan ook opent. De versiereeks draagt een markering die de generieke kernel niet heeft, en dat ene detail verklaart beide ontbrekende onderdelen.

Lees ook de opstartvermelding, want een machine kan de gecertificeerde kernel geïnstalleerd hebben zonder hem te draaien. In dat geval is het moduleverhaal heel anders, en de poorten en stuurprogramma's die u op het punt stond opnieuw te installeren zijn in orde.

Lees de modulestatus vóór de clientconfiguratie

Een module die niet gevonden kan worden en een module die bestaat maar weigert te laden zijn twee verschillende storingen met twee verschillende oplossingen. modinfo meldt welke u hebt, en lsmod meldt wat er nu geladen is. Doe beide voordat u de configuratie van de VPN-client aanraakt, want de fout van de client zelf scheidt ze zelden.

Het draadloze deel heeft dezelfde splitsing nodig. Een interface die nooit verschijnt wijst op het stuurprogramma, terwijl een die bestaat maar geblokkeerd blijft op rfkill of op de netwerkbeheerder wijst. Die twee zien er in een bureaublad-applet hetzelfde uit en delen niets onder de oppervlakte.

Voer de controles op de machine zelf uit zolang de storing nog reproduceerbaar is. Uitvoer die van een andere host is geplakt is geen vervanging hiervoor.

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

Wanneer modinfo de module helemaal niet vindt, helpt het opnieuw installeren van het userspace-pakket niet, want de userspace was nooit het ontbrekende deel. Die observatie bespaart een uur pakketgedoe en wijst recht op de kernel.

Ga terug in een volgorde die u een kernel laat

Als FIPS per ongeluk is ingeschakeld, schakelt het gedocumenteerde herstelpad de dienst uit, verwijdert de pakketten en herstelt daarna de generieke kernel. De volgorde is niet cosmetisch. De verwijdering weigert door te gaan wanneer er geen andere Ubuntu-kernel is, want het verwijderen van de enige zou een machine achterlaten die niet opstart. Die controle is het verschil tussen een terugdraaiing en een herbouw. Het is ook de reden dat de reeks mislukt wanneer de generieke kernel al eerder is verwijderd.

Voer het uit terwijl de generieke kernel nog is geïnstalleerd, accepteer de waarschuwing over het verwijderen van een kernel en herstart daarna. Bevestig vervolgens dat er geen FIPS-pakket in geïnstalleerde staat overblijft en dat de draaiende kernel degene is die u verwachtte.

Op een externe host regelt u eerst console- of out-of-band-toegang. Een kernel via SSH verwijderen is prima tot precies de herstart die niet terugkomt.

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

Wanneer de certificering de eis is

Terugdraaien is de verkeerde zet wanneer de certificering contractueel is, want dan verlaat de machine de configuratie die de audit beschrijft. In dat geval is het gat in de stuurprogramma's een kwestie van hardwarekeuze: kies een draadloze adapter waarvan het stuurprogramma met de gecertificeerde kernel meekomt, accepteer een machine met alleen een kabel, of verplaats de tunnel naar een onderdeel dat de gecertificeerde kernel al ondersteunt.

Een module buiten de boom in de gecertificeerde kernel bouwen is geen neutrale oplossing. Het verandert wat de kernel uitvoert, en dat is precies de eigenschap die de certificering beschrijft.

Leg de beslissing vast met de naam van de eigenaar ernaast, want het verzoek om alleen de wifi te laten werken komt over een paar maanden terug met minder context. Een korte notitie nu voorkomt dezelfde discussie later.

Controleer de stack na de wijziging laag voor laag

Controleer na de terugdraaiing of de hardwarewijziging van onder naar boven in plaats van vanaf de VPN-client naar beneden. De interface moet bestaan, de verbinding moet up zijn, de resolver moet werken, en pas dan doet de tunnel ertoe. Elke laag faalt met zijn eigen melding, en ze in volgorde lezen houdt de diagnose eerlijk.

Achtergebleven DNS-status van de vorige start is een veelvoorkomende valse positief, dus lees de resolver voordat u concludeert dat de tunnel kapot is.

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

Als de tunnel nog steeds faalt zodra de kernel terug is, lees dan de falende fase in plaats van de samenvattingsregel van de client. Een module die nooit is geladen, een certificaat dat de tegenpartij weigerde en een inloggegeven dat de server weigerde zijn drie aparte problemen, en een herstart scheidt ze niet voor u. Noteer de naam van de fase in het ticket, en de volgende engineer begint waar u stopte.