FIPS-kjerneswapet tok Wi-Fi- og VPN-modulane med seg

Slå på fips-updates, start på nytt, og maskinen kjem tilbake utan trådlaust grensesnitt medan VPN-klienten nektar å starte fordi kjernemodulen manglar. Ingenting vart avinstallert i vanleg pakkeforståing, og difor endrar nyinstallering av klienten absolutt ingenting. Maskinen køyrer ein kjerne som drivarane aldri vart bygde for. To symptom, éin årsak, og årsaka viser seg i éin einaste kommando.

Kva omstarten faktisk bytte

FIPS-oppdateringane i Ubuntu Pro installerar ein sertifisert kjernevariant og gjer han til standard oppstartsval. Den varianten er ein ekte kjerne: han startar, han køyrer, og han startar tenestene du allereie hadde. Det han ikkje inneheld, er kvar modul bygd for den generiske kjernen, inkludert ein trådlaus drivar kompilert utanfor treet og ein tunnelmodul levert via DKMS. Drivarsettet flyttar seg med kjernen, ikkje med pakkehandsamaren. Så maskinvara er framleis der, og programvara som snakkar med henne er det ikkje.

Samanlikn kjernen som køyrer med dei installerte pakkane før du opnar noka nettverksinnstilling. Versjonsstrengen ber eit merke den generiske kjernen ikkje har, og den eine detaljen forklarer båe dei manglande delane.

Les òg oppstartsvalet, fordi ein maskin kan ha den sertifiserte kjernen installert utan å køyre han. I så fall er modulhistorien heilt annleis, og portane og drivarane du var i ferd med å installere på nytt, er i orden.

Les modultilstanden før klientkonfigurasjonen

Ein modul som ikkje kan finnast, og ein modul som finst men nektar å lastast, er to ulike feil med ulike løysingar. modinfo melder kva for ein du har, og lsmod melder kva som er lasta akkurat no. Gjer båe delar før du rører konfigurasjonen til VPN-klienten, fordi feilen til klienten sjølv sjeldan skil dei.

Det trådlause treng same oppdelinga. Eit grensesnitt som aldri dukkar opp, peikar på drivaren, medan eit som finst men blir blokkert, peikar på rfkill eller på nettverkshandsamaren. Dei to ser like ut i eit skrivebordsminiprogram og deler ingenting under overflata.

Køyr kontrollane på maskinen sjølv medan feilen framleis kan gjerast om. Utdata lima inn frå ein annan vert er ikkje ei erstatning for denne.

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

Når modinfo ikkje finn modulen i det heile, hjelper det ikkje å installere brukarromspakken på nytt, fordi brukarrommet aldri var den manglande delen. Den observasjonen sparar ein time med pakkestyr og peikar rett på kjernen.

Rull tilbake i ei rekkjefølgje som lèt deg sitje att med ein kjerne

Vart FIPS slått på ved ein feil, deaktiverer den dokumenterte gjenopprettingsvegen tenesta, fjernar pakkane og gjenopprettar deretter den generiske kjernen. Rekkjefølgja er ikkje kosmetisk. Fjerninga nektar å halde fram når ho ikkje finn ein annan Ubuntu-kjerne, fordi å fjerne den einaste ville late att ein maskin som ikkje startar. Den kontrollen er skilnaden mellom ein tilbakerulling og ein gjenoppbygging. Det er òg grunnen til at sekvensen feilar når den generiske kjernen allereie er fjerna.

Køyr han medan den generiske kjernen framleis er installert, godta åtvaringa om å fjerne ein kjerne, og start på nytt etterpå. Stadfest deretter at ingen FIPS-pakke er att i installert tilstand, og at kjernen som køyrer er den du venta.

På ein ekstern vert må du først ordne konsoll- eller bandutantilgang. Å fjerne ein kjerne over SSH er greitt heilt fram til omstarten som ikkje kjem tilbake.

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

Når sertifiseringa er kravet

Tilbakerulling er feil trekk når sertifiseringa er kontraktsfesta, fordi maskinen då forlèt konfigurasjonen revisjonen skildrar. I så fall er drivargapet eit spørsmål om maskinvareval: vel ein trådlaus adapter der drivaren følgjer med den sertifiserte kjernen, godta ein maskin med berre kabel, eller flytt tunnelen til ein komponent den sertifiserte kjernen allereie støttar.

Å byggje ein modul utanfor treet inn i den sertifiserte kjernen er ikkje ei nøytral løysing. Det endrar kva kjernen utfører, og det er nettopp den eigenskapen sertifiseringa skildrar.

Skriv ned avgjerda med namnet til eigaren ved sida, fordi førespurnaden om berre å få Wi-Fi til å verke kjem tilbake om nokre månader med mindre kontekst. Eit kort notat no hindrar den same diskusjonen seinare.

Sjekk stakken lag for lag etter endringa

Etter tilbakerullinga eller maskinvareendringa, verifiser nedanfrå og opp i staden for frå VPN-klienten og ned. Grensesnittet må finnast, sambandet må vere oppe, resolvaren må verke, og først då betyr tunnelen noko. Kvart lag feilar med si eiga melding, og å lese dei i rekkjefølgje held diagnosen ærleg.

Rest-DNS-tilstand frå førre oppstart er ein vanleg falsk positiv, så les resolvaren før du konkluderer med at tunnelen er øydelagd.

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

Om tunnelen framleis feilar når kjernen er tilbake, les det feilande trinnet i staden for oppsummeringslinja til klienten. Ein modul som aldri vart lasta, eit sertifikat motparten avviste, og ei innlogging serveren nekta, er tre separate problem, og ein omstart skil dei ikkje for deg. Skriv trinnnamnet i saka, og neste ingeniør byrjar der du stoppa.