FIPS-kjerneswap tok med seg Wi-Fi- og VPN-modulene

Slå på fips-updates, start på nytt, og maskinen kommer tilbake uten trådløst grensesnitt mens VPN-klienten nekter å starte fordi kjernemodulen mangler. Ingenting ble avinstallert i vanlig pakkeforståelse, og derfor endrer nyinstallering av klienten absolutt ingenting. Maskinen kjører en kjerne som driverne aldri ble bygget for. To symptomer, én årsak, og årsaken vises i én enkelt kommando.

Hva omstarten faktisk byttet

FIPS-oppdateringene i Ubuntu Pro installerer en sertifisert kjernevariant og gjør den til standard oppstartsvalg. Den varianten er en ekte kjerne: den starter, den kjører, og den starter tjenestene du allerede hadde. Det den ikke inneholder, er hver modul bygget for den generiske kjernen, inkludert en trådløs driver kompilert utenfor treet og en tunnelmodul levert via DKMS. Driversettet flytter seg med kjernen, ikke med pakkebehandleren. Så maskinvaren er fortsatt der, og programvaren som snakker med den er det ikke.

Sammenlign kjernen som kjører med de installerte pakkene før du åpner noen nettverksinnstilling. Versjonsstrengen bærer et merke den generiske kjernen ikke har, og den ene detaljen forklarer begge de manglende delene.

Les også oppstartsvalget, fordi en maskin kan ha den sertifiserte kjernen installert uten å kjøre den. I så fall er modulhistorien helt annerledes, og portene og driverne du var i ferd med å installere på nytt, er i orden.

Les modultilstanden før klientkonfigurasjonen

En modul som ikke kan finnes, og en modul som finnes men nekter å lastes, er to forskjellige feil med forskjellige løsninger. modinfo melder hvilken du har, og lsmod melder hva som er lastet akkurat nå. Gjør begge deler før du rører konfigurasjonen til VPN-klienten, fordi klientens egen feil sjelden skiller dem.

Det trådløse trenger samme oppdeling. Et grensesnitt som aldri dukker opp, peker på driveren, mens et som finnes men blir blokkert, peker på rfkill eller på nettverksbehandleren. De to ser like ut i et skrivebordsminiprogram og deler ingenting under overflaten.

Kjør kontrollene på maskinen selv mens feilen fortsatt kan gjenskapes. Utdata limt inn fra en annen vert er ikke en erstatning for denne.

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

Når modinfo ikke finner modulen i det hele tatt, hjelper det ikke å installere brukerromspakken på nytt, fordi brukerrommet aldri var den manglende delen. Den observasjonen sparer en time med pakkestyr og peker rett på kjernen.

Rull tilbake i en rekkefølge som etterlater deg en kjerne

Hvis FIPS ble slått på ved en feil, deaktiverer den dokumenterte gjenopprettingsveien tjenesten, fjerner pakkene og gjenoppretter deretter den generiske kjernen. Rekkefølgen er ikke kosmetisk. Fjerningen nekter å fortsette når den ikke finner en annen Ubuntu-kjerne, fordi å fjerne den eneste ville etterlate en maskin som ikke starter. Den kontrollen er forskjellen mellom en tilbakerulling og en gjenoppbygging. Det er også grunnen til at sekvensen feiler når den generiske kjernen allerede er fjernet.

Kjør den mens den generiske kjernen fortsatt er installert, godta advarselen om å fjerne en kjerne, og start på nytt etterpå. Bekreft deretter at ingen FIPS-pakke er igjen i installert tilstand, og at kjernen som kjører er den du forventet.

På en ekstern vert må du først ordne konsoll- eller båndutentilgang. Å fjerne en kjerne over SSH er greit helt fram til omstarten som ikke kommer tilbake.

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

Når sertifiseringen er kravet

Tilbakerulling er feil trekk når sertifiseringen er kontraktsfestet, fordi maskinen da forlater konfigurasjonen revisjonen beskriver. I så fall er driverhullet et spørsmål om maskinvarevalg: velg en trådløs adapter hvis driver følger med den sertifiserte kjernen, godta en maskin med bare kabel, eller flytt tunnelen til en komponent den sertifiserte kjernen allerede støtter.

Å bygge en modul utenfor treet inn i den sertifiserte kjernen er ikke en nøytral løsning. Det endrer hva kjernen utfører, og det er nettopp den egenskapen sertifiseringen beskriver.

Skriv ned beslutningen med eierens navn ved siden av, fordi forespørselen om bare å få Wi-Fi til å virke kommer tilbake om noen måneder med mindre kontekst. Et kort notat nå hindrer den samme diskusjonen senere.

Sjekk stakken lag for lag etter endringen

Etter tilbakerullingen eller maskinvareendringen, verifiser nedenfra og opp i stedet for fra VPN-klienten og ned. Grensesnittet må finnes, forbindelsen må være oppe, resolveren må virke, og først da betyr tunnelen noe. Hvert lag feiler med sin egen melding, og å lese dem i rekkefølge holder diagnosen ærlig.

Rest-DNS-tilstand fra forrige oppstart er en vanlig falsk positiv, så les resolveren før du konkluderer med at tunnelen er ødelagt.

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

Hvis tunnelen fortsatt feiler når kjernen er tilbake, les det feilende trinnet i stedet for oppsummeringslinjen til klienten. En modul som aldri ble lastet, et sertifikat motparten avviste, og en innlogging serveren nektet, er tre separate problemer, og en omstart skiller dem ikke for deg. Skriv trinnets navn i saken, og neste ingeniør begynner der du stoppet.