FIPS-kerneskift tog Wi-Fi- og VPN-modulerne med sig

Slå fips-updates til, genstart, og maskinen vender tilbage uden en trådløs grænseflade, mens VPN-klienten nægter at starte, fordi dens kernemodul mangler. Intet blev afinstalleret i almindelig pakkeforstånd, og derfor ændrer geninstallation af klienten absolut intet. Maskinen kører en kerne, som dens drivere aldrig blev bygget til. To symptomer, én årsag, og årsagen ses med én kommando.

Hvad genstarten faktisk skiftede

FIPS-opdateringerne i Ubuntu Pro installerer en certificeret kernevariant og gør den til standardstartindgang. Den variant er en rigtig kerne: den starter, den kører, og den starter de tjenester, du allerede havde. Det, den ikke indeholder, er hver modul bygget til den generiske kerne, inklusive en trådløs driver kompileret uden for træet og et tunnelmodul leveret via DKMS. Driversættet flytter med kernen, ikke med pakkehåndteringen. Så hardwaren er stadig der, og softwaren, der taler med den, er ikke.

Sammenlign den kørende kerne med de installerede pakker, før du åbner nogen netværksindstilling. Versionsstrengen bærer et mærke, som den generiske kerne ikke har, og den ene detalje forklarer begge de manglende dele.

Læs også startindgangen, fordi en maskine kan have den certificerede kerne installeret uden at køre den. I så fald er modulhistorien helt anderledes, og de porte og drivere, du var ved at geninstallere, er i orden.

Læs modultilstanden før klientkonfigurationen

Et modul, der ikke kan findes, og et modul, der findes, men nægter at indlæses, er to forskellige fejl med forskellige løsninger. modinfo fortæller, hvilken du har, og lsmod fortæller, hvad der er indlæst lige nu. Gør begge dele, før du rører VPN-klientens konfiguration, fordi klientens egen fejl sjældent skiller dem ad.

Det trådløse kræver samme opdeling. En grænseflade, der aldrig dukker op, peger på driveren, mens en, der findes, men forbliver blokeret, peger på rfkill eller på netværkshåndteringen. De to ser ens ud i et panel på skrivebordet og deler intet under overfladen.

Kør kontrollerne på maskinen selv, mens fejlen stadig kan genskabes. Output kopieret fra en anden vært 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 slet ikke kan finde modulet, hjælper det ikke at geninstallere brugerrumspakken, fordi brugerrummet aldrig var den manglende del. Den observation sparer en time med pakkerod og peger direkte på kernen.

Rul tilbage i en rækkefølge, der efterlader dig en kerne

Hvis FIPS blev slået til ved en fejl, deaktiverer den dokumenterede gendannelsesvej tjenesten, fjerner dens pakker og gendanner derefter den generiske kerne. Rækkefølgen er ikke kosmetisk. Fjernelsen nægter at fortsætte, når den ikke kan finde en anden Ubuntu-kerne, fordi fjernelse af den eneste ville efterlade en maskine, der ikke kan starte. Den kontrol er forskellen mellem en tilbagerulning og en genopbygning. Det er også grunden til, at sekvensen fejler, når den generiske kerne allerede er fjernet.

Kør det, mens den generiske kerne stadig er installeret, accepter advarslen om at fjerne en kerne, og genstart derefter. Bekræft så, at ingen FIPS-pakke er tilbage i installeret tilstand, og at den kørende kerne er den, du forventede.

På en fjernvært skal du først arrangere konsol- eller out-of-band-adgang. At fjerne en kerne over SSH er fint lige indtil den genstart, der ikke vender tilbage.

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

Når certificeringen er kravet

Tilbagerulning er det forkerte træk, når certificeringen er kontraktlig, fordi maskinen så forlader den konfiguration, som revisionen beskriver. I så fald er driverhullet et spørgsmål om hardwarevalg: vælg en trådløs adapter, hvis driver følger med den certificerede kerne, accepter en maskine med kun kabel, eller flyt tunnelen til en komponent, som den certificerede kerne allerede understøtter.

At bygge et modul uden for træet ind i den certificerede kerne er ikke en neutral løsning. Det ændrer, hvad kernen udfører, og det er netop den egenskab, certificeringen beskriver.

Skriv beslutningen ned med ejerens navn ved siden af, fordi anmodningen om bare at få Wi-Fi til at virke vender tilbage om et par måneder med mindre kontekst. En kort note nu forhindrer den samme diskussion senere.

Kontroller stakken lag for lag efter ændringen

Efter tilbagerulningen eller hardwareændringen skal du kontrollere nedefra og op i stedet for fra VPN-klienten og ned. Grænsefladen skal findes, forbindelsen skal være oppe, resolveren skal virke, og først derefter betyder tunnelen noget. Hvert lag fejler med sin egen besked, og at læse dem i rækkefølge holder diagnosen ærlig.

Rest-DNS-tilstand fra den forrige start er en almindelig falsk positiv, så læs resolveren, før du konkluderer, at tunnelen gik i stykker.

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

Hvis tunnelen stadig fejler, når kernen er tilbage, skal du læse det fejlende trin i stedet for klientens oversigtslinje. Et modul, der aldrig blev indlæst, et certifikat, som modparten afviste, og en legitimationsoplysning, som serveren afviste, er tre separate problemer, og en genstart skiller dem ikke ad for dig. Skriv trinnets navn i sagen, så begynder den næste ingeniør der, hvor du stoppede.