Schimbarea nucleului FIPS a luat cu ea modulele Wi-Fi și VPN

Activați fips-updates, reporniți, iar mașina revine fără interfață wireless în timp ce clientul VPN refuză să pornească pentru că îi lipsește modulul de nucleu. Nimic nu a fost dezinstalat în sensul obișnuit al pachetelor, și de aceea reinstalarea clientului nu schimbă absolut nimic. Mașina rulează un nucleu pentru care driverele ei nu au fost niciodată construite. Două simptome, o cauză, iar cauza se vede într-o singură comandă.

Ce a schimbat de fapt repornirea

Actualizările FIPS din Ubuntu Pro instalează o variantă certificată a nucleului și o fac intrarea de pornire implicită. Acea variantă este un nucleu real: pornește, rulează și pornește serviciile pe care le aveați deja. Ce nu conține este fiecare modul construit pentru nucleul generic, inclusiv un driver wireless compilat în afara arborelui și un modul de tunel livrat prin DKMS. Setul de drivere se mută împreună cu nucleul, nu cu managerul de pachete. Așadar hardware-ul este încă acolo, iar software-ul care vorbește cu el nu.

Comparați nucleul care rulează cu pachetele instalate înainte de a deschide orice setare de rețea. Șirul versiunii poartă un marcaj pe care nucleul generic nu îl are, iar acel singur detaliu explică ambele piese lipsă.

Citiți și intrarea de pornire, pentru că o mașină poate avea nucleul certificat instalat fără să îl ruleze. În acest caz povestea modulelor este complet diferită, iar porturile și driverele pe care urma să le reinstalați sunt în regulă.

Citiți starea modulelor înainte de configurarea clientului

Un modul care nu poate fi găsit și un modul care există dar refuză să se încarce sunt două defecte diferite, cu remedii diferite. modinfo raportează care dintre ele este, iar lsmod raportează ce este încărcat acum. Faceți ambele înainte de a atinge configurația clientului VPN, pentru că eroarea clientului însuși le desparte rar.

Partea wireless are nevoie de aceeași separare. O interfață care nu apare niciodată indică driverul, în timp ce una care există dar rămâne blocată indică rfkill sau managerul de rețea. Cele două arată identic într-o aplicație de birou și nu împart nimic dedesubt.

Rulați verificările pe mașina respectivă cât timp defectul este încă reproductibil. O ieșire lipită de pe alt host nu înlocuiește aceasta.

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

Când modinfo nu găsește deloc modulul, reinstalarea pachetului din spațiul utilizator nu va ajuta, pentru că spațiul utilizator nu a fost niciodată partea lipsă. Acea observație economisește o oră de învârtire printre pachete și indică direct nucleul.

Reveniți în ordinea care vă lasă un nucleu

Dacă FIPS a fost activat din greșeală, calea de recuperare documentată dezactivează serviciul, elimină pachetele lui și apoi restaurează nucleul generic. Ordinea nu este cosmetică. Eliminarea refuză să continue când nu găsește un alt nucleu Ubuntu, pentru că eliminarea singurului ar lăsa o mașină care nu pornește. Acea verificare este diferența dintre o revenire și o reconstrucție. Este și motivul pentru care secvența eșuează când nucleul generic a fost deja eliminat.

Rulați-o cât timp nucleul generic este încă instalat, acceptați avertismentul privind eliminarea unui nucleu și reporniți după aceea. Apoi confirmați că nu a rămas niciun pachet FIPS în starea instalat și că nucleul care rulează este cel pe care îl așteptați.

Pe un host de la distanță, asigurați mai întâi acces prin consolă sau din afara benzii. Eliminarea unui nucleu prin SSH este în regulă până exact la repornirea care nu mai revine.

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

Când certificarea este cerința

Revenirea este mișcarea greșită când certificarea este contractuală, pentru că mașina părăsește astfel configurația pe care o descrie auditul. În acest caz lipsa driverului este o chestiune de alegere a hardware-ului: alegeți un adaptor wireless al cărui driver vine cu nucleul certificat, acceptați o mașină doar cu cablu, sau mutați tunelul pe o componentă pe care nucleul certificat o suportă deja.

Construirea unui modul din afara arborelui în nucleul certificat nu este o soluție neutră. Schimbă ceea ce execută nucleul, iar aceasta este exact proprietatea pe care o descrie certificarea.

Consemnați decizia cu numele proprietarului alături, pentru că cererea de a face pur și simplu Wi-Fi-ul să funcționeze va reveni peste câteva luni cu mai puțin context. O notă scurtă acum împiedică aceeași dezbatere mai târziu.

Verificați stiva pe straturi după schimbare

După revenire sau după schimbarea hardware-ului, verificați de jos în sus, nu de la clientul VPN în jos. Interfața trebuie să existe, legătura trebuie să fie activă, resolverul trebuie să funcționeze, și abia apoi contează tunelul. Fiecare strat eșuează cu propriul mesaj, iar citirea lor în ordine ține diagnosticul onest.

Starea DNS rămasă de la pornirea anterioară este un fals pozitiv obișnuit, așa că citiți resolverul înainte de a concluziona că tunelul s-a stricat.

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

Dacă tunelul tot eșuează după ce nucleul a revenit, citiți etapa care eșuează, nu linia de rezumat a clientului. Un modul care nu s-a încărcat niciodată, un certificat pe care partenerul l-a respins și o acreditare pe care serverul a refuzat-o sunt trei probleme separate, iar o repornire nu le va distinge în locul dumneavoastră. Notați numele etapei în tichet, iar următorul inginer începe de unde v-ați oprit.