FIPS branduolio keitimas pasiėmė Wi-Fi ir VPN modulius

Įjunkite fips-updates, paleiskite iš naujo, ir kompiuteris grįžta be belaidės sąsajos, o VPN klientas atsisako startuoti, nes trūksta jo branduolio modulio. Įprasta paketų prasme nieko nebuvo pašalinta, todėl kliento diegimas iš naujo nieko nekeičia. Kompiuteris veikia branduoliu, kuriam jo tvarkyklės niekada nebuvo sukurtos. Du simptomai, viena priežastis, ir priežastis matoma vienoje komandoje.

Ką iš tikrųjų pakeitė paleidimas iš naujo

Ubuntu Pro FIPS atnaujinimai įdiegia sertifikuotą branduolio variantą ir padaro jį numatytuoju paleidimo įrašu. Tas variantas yra tikras branduolys: jis paleidžiamas, veikia ir paleidžia paslaugas, kurias jau turėjote. Ko jame nėra, tai kiekvieno modulio, sukurto bendrajam branduoliui, įskaitant už medžio ribų sukompiliuotą belaidę tvarkyklę ir tunelio modulį, tiekiamą per DKMS. Tvarkyklių rinkinys juda kartu su branduoliu, o ne su paketų tvarkykle. Taigi aparatinė įranga vis dar yra, o programinė įranga, kuri su ja kalba, ne.

Palyginkite veikiantį branduolį su įdiegtais paketais prieš atidarydami bet kokį tinklo nustatymą. Versijos eilutė turi žymę, kurios bendrasis branduolys neturi, ir ši viena detalė paaiškina abi trūkstamas dalis.

Perskaitykite ir paleidimo įrašą, nes kompiuteryje gali būti įdiegtas sertifikuotas branduolys, bet jis neveikti. Tokiu atveju modulių istorija visiškai kitokia, o prievadai ir tvarkyklės, kuriuos ketinote diegti iš naujo, yra tvarkingi.

Perskaitykite modulių būseną prieš kliento konfigūraciją

Nerandamas modulis ir egzistuojantis, bet įkelti atsisakantis modulis yra dvi skirtingos gedimų rūšys su skirtingais sprendimais. modinfo praneša, kurį turite, o lsmod – kas įkelta dabar. Atlikite abu prieš liesdami VPN kliento konfigūraciją, nes paties kliento klaida juos retai atskiria.

Belaidei daliai reikia to paties atskyrimo. Sąsaja, kuri niekada nepasirodo, rodo į tvarkyklę, o ta, kuri yra, bet lieka užblokuota, rodo į rfkill arba tinklo tvarkyklę. Abi darbalaukio programėlėje atrodo vienodai ir po paviršiumi nieko bendro neturi.

Atlikite patikras pačiame kompiuteryje, kol gedimas dar atkuriamas. Iš kitos mašinos įklijuota išvestis to nepakeičia.

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

Kai modinfo visai neranda modulio, naudotojo erdvės paketo diegimas iš naujo nepadės, nes naudotojo erdvė niekada nebuvo trūkstama dalis. Šis pastebėjimas sutaupo valandą paketų vargų ir nukreipia tiesiai į branduolį.

Grįžkite tokia tvarka, kuri palieka branduolį

Jei FIPS buvo įjungtas per klaidą, dokumentuotas atkūrimo kelias išjungia paslaugą, pašalina jos paketus ir tada atkuria bendrąjį branduolį. Tvarka nėra kosmetinė. Šalinimas atsisako tęsti, kai neranda kito Ubuntu branduolio, nes pašalinus vienintelį liktų kompiuteris, kuris nepaleidžiamas. Ši patikra yra skirtumas tarp grąžinimo ir perstatymo. Tai taip pat priežastis, kodėl seka nepavyksta, kai bendrasis branduolys jau buvo pašalintas.

Vykdykite tai, kol bendrasis branduolys dar įdiegtas, priimkite įspėjimą apie branduolio šalinimą ir tada paleiskite iš naujo. Po to patvirtinkite, kad įdiegtoje būsenoje neliko nė vieno FIPS paketo ir kad veikiantis branduolys yra tas, kurio tikėjotės.

Nuotoliniame kompiuteryje pirmiausia susitvarkykite konsolės arba už juostos ribų prieigą. Šalinti branduolį per SSH gerai iki pat to paleidimo iš naujo, kuris negrįžta.

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

Kai sertifikavimas yra reikalavimas

Grįžimas atgal yra neteisingas žingsnis, kai sertifikavimas yra sutartinis, nes tada kompiuteris palieka konfigūraciją, kurią aprašo auditas. Tokiu atveju tvarkyklės spraga yra aparatinės įrangos pasirinkimo klausimas: pasirinkite belaidį adapterį, kurio tvarkyklė tiekiama su sertifikuotu branduoliu, sutikite su kompiuteriu tik su kabeliu arba perkelkite tunelį į komponentą, kurį sertifikuotas branduolys jau palaiko.

Modulio už medžio ribų įkėlimas į sertifikuotą branduolį nėra neutralus sprendimas. Jis keičia tai, ką branduolys vykdo, ir būtent šią savybę aprašo sertifikavimas.

Užrašykite sprendimą su savininko vardu šalia, nes prašymas tiesiog paleisti Wi-Fi grįš po kelių mėnesių su mažiau konteksto. Trumpa pastaba dabar užkerta kelią tam pačiam ginčui vėliau.

Po pakeitimo patikrinkite steką sluoksniais

Po grąžinimo ar aparatinės įrangos pakeitimo tikrinkite iš apačios į viršų, o ne nuo VPN kliento žemyn. Sąsaja turi egzistuoti, ryšys turi būti pakeltas, resolveris turi veikti, ir tik tada tunelis turi reikšmę. Kiekvienas sluoksnis nepavyksta su savo pranešimu, o jų skaitymas iš eilės išlaiko diagnozę sąžiningą.

Likusi DNS būsena nuo ankstesnio paleidimo yra dažnas klaidingas signalas, todėl perskaitykite resolverį prieš darydami išvadą, kad tunelis sugedo.

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

Jei tunelis vis tiek nepavyksta, kai branduolys grįžo, skaitykite nepavykusį etapą, o ne kliento suvestinę eilutę. Niekada neįkeltas modulis, sertifikatas, kurį atmetė kita pusė, ir prisijungimo duomenys, kurių serveris atsisakė, yra trys atskiros problemos, ir paleidimas iš naujo jų už jus neatskirs. Užrašykite etapo pavadinimą biliete, ir kitas inžinierius pradės ten, kur jūs sustojote.