Inalis ng FIPS Kernel Swap ang Wi-Fi at VPN Modules

I-on ang fips-updates, i-reboot, at bumabalik ang makina na walang wireless interface habang tumatanggi ang VPN client na magsimula dahil wala ang kernel module nito. Walang na-uninstall sa karaniwang kahulugan ng package, at iyon ang dahilan kung bakit walang binabago ang muling pag-install ng client. Gumagana ang makina sa kernel na hindi kailanman binuo para sa mga driver nito. Dalawang sintomas, isang sanhi, at makikita ang sanhi sa isang utos.

Ano ang aktwal na pinalitan ng reboot

Ang mga update ng FIPS sa Ubuntu Pro ay nag-i-install ng sertipikadong variant ng kernel at ginagawa itong default na boot entry. Ang variant na iyon ay tunay na kernel: nagbo-boot ito, gumagana, at sinisimulan ang mga serbisyong mayroon ka na. Ang wala rito ay bawat module na binuo para sa generic na kernel, kasama ang wireless driver na na-compile sa labas ng tree at isang tunnel module na inihahatid sa pamamagitan ng DKMS. Gumagalaw ang set ng driver kasama ng kernel, hindi kasama ng package manager. Kaya nandiyan pa rin ang hardware at wala ang software na kumakausap dito.

Ihambing ang tumatakbong kernel sa mga naka-install na package bago buksan ang anumang setting ng network. May marka ang version string na wala sa generic na kernel, at iyon lang ang nagpapaliwanag sa dalawang nawawalang piraso.

Basahin din ang boot entry, dahil maaaring naka-install ang sertipikadong kernel sa isang makina nang hindi ito ginagamit. Sa ganoong kaso, ganap na iba ang kuwento ng mga module, at maayos ang mga port at driver na babaguhin mo sana.

Basahin ang estado ng module bago ang configuration ng client

Ang module na hindi mahanap at ang module na mayroon ngunit tumatangging mag-load ay dalawang magkaibang sira na may magkaibang lunas. Sinasabi ng modinfo kung alin ang mayroon ka, at sinasabi ng lsmod kung ano ang naka-load ngayon. Gawin ang dalawa bago hawakan ang configuration ng VPN client, dahil bihirang paghiwalayin ng sariling error ng client ang mga ito.

Kailangan ng wireless ang parehong paghahati. Ang interface na hindi kailanman lumilitaw ay tumutukoy sa driver, habang ang mayroon ngunit nananatiling naka-block ay tumutukoy sa rfkill o sa network manager. Magkamukha ang dalawa sa applet ng desktop at walang pinagsasaluhan sa ilalim.

Patakbuhin ang mga pagsusuri sa makina mismo habang naaayos pang muli ang sira. Ang output na nakadikit mula sa ibang host ay hindi kapalit nito.

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

Kapag hindi talaga mahanap ng modinfo ang module, walang maitutulong ang muling pag-install ng userspace package, dahil hindi kailanman ang userspace ang nawawalang bahagi. Ang obserbasyong iyon ay nakakatipid ng isang oras ng paghihirap sa package at direktang tumuturo sa kernel.

Bumalik sa pagkakasunod-sunod na nag-iiwan sa iyo ng kernel

Kung na-on ang FIPS nang mali, hindi pinapagana ng dokumentadong recovery path ang serbisyo, nililinis ang mga package nito, at pagkatapos ay ibinabalik ang generic na kernel. Hindi kosmetiko ang pagkakasunod-sunod. Tumatanggi ang paglilinis na magpatuloy kapag wala itong mahanap na ibang Ubuntu kernel, dahil ang pag-alis sa nag-iisa ay mag-iiwan ng makina na hindi makakaboot. Ang pagsusuring iyon ang pagkakaiba ng rollback at rebuild. Ito rin ang dahilan kung bakit nabigo ang sequence kapag naalis na ang generic na kernel.

Patakbuhin ito habang naka-install pa ang generic na kernel, tanggapin ang babala tungkol sa pag-alis ng kernel, at pagkatapos ay i-reboot. Pagkatapos, kumpirmahin na walang natirang package ng FIPS sa naka-install na estado at ang tumatakbong kernel ay ang inaasahan mo.

Sa malayong host, ayusin muna ang console o out-of-band na access. Maayos ang pag-alis ng kernel sa SSH hanggang sa mismong reboot na hindi na bumabalik.

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

Kapag ang sertipikasyon ang pangangailangan

Mali ang pag-urong kapag kontraktwal ang sertipikasyon, dahil lumalabas ang makina sa configuration na inilalarawan ng audit. Sa ganoong kaso, ang agwat ng driver ay tanong ng pagpili ng hardware: pumili ng wireless adapter na ang driver ay kasama ng sertipikadong kernel, tanggapin ang makinang may cable lamang, o ilipat ang tunnel sa component na sinusuportahan na ng sertipikadong kernel.

Ang pagbuo ng module sa labas ng tree papasok sa sertipikadong kernel ay hindi neutral na solusyon. Binabago nito ang ginagawa ng kernel, at iyon mismo ang katangiang inilalarawan ng sertipikasyon.

Itala ang desisyon kasama ang pangalan ng may-ari sa tabi, dahil babalik ang kahilingang gawin lang na gumana ang Wi-Fi pagkalipas ng ilang buwan na may mas kaunting konteksto. Ang maikling tala ngayon ay pumipigil sa parehong pagtatalo mamaya.

Suriin ang stack nang pa-layer pagkatapos ng pagbabago

Pagkatapos ng pag-urong o pagbabago ng hardware, i-verify mula sa ibaba pataas sa halip na mula sa VPN client pababa. Dapat mayroon ang interface, dapat nakataas ang link, dapat gumana ang resolver, at saka lang mahalaga ang tunnel. Bawat layer ay nabigo sa sarili nitong mensahe, at ang pagbasa sa kanila nang sunod-sunod ay nagpapanatiling tapat ng diagnosis.

Ang natirang estado ng DNS mula sa nakaraang boot ay karaniwang false positive, kaya basahin ang resolver bago magpasya na nasira ang tunnel.

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

Kung nabigo pa rin ang tunnel kapag bumalik ang kernel, basahin ang yugtong nabigo sa halip na ang summary line ng client. Module na hindi kailanman na-load, certificate na tinanggihan ng kabilang dulo, at credential na tinanggihan ng server ay tatlong magkaibang problema, at hindi ito paghihiwalayin ng reboot para sa iyo. Itala ang pangalan ng yugto sa ticket, at magsisimula ang susunod na inhinyero sa kinahantungan mo.