Výměna jádra kvůli FIPS si vzala moduly Wi-Fi i VPN

Zapněte fips-updates, restartujte a stroj se vrátí bez bezdrátového rozhraní, zatímco klient VPN odmítá nastartovat, protože mu chybí modul jádra. V běžném smyslu balíčků se nic neodinstalovalo, a proto přeinstalace klienta nezmění vůbec nic. Stroj běží na jádru, pro které se jeho ovladače nikdy nesestavovaly. Dva příznaky, jedna příčina a příčina je vidět jediným příkazem.

Co restart vlastně přepnul

Aktualizace FIPS v Ubuntu Pro nainstalují certifikovanou variantu jádra a udělají z ní výchozí položku pro start. Ta varianta je skutečné jádro: naběhne, běží a spouští služby, které jste už měli. Co v něm není, je každý modul sestavený pro generické jádro, včetně bezdrátového ovladače zkompilovaného mimo strom a tunelového modulu dodávaného přes DKMS. Sada ovladačů se posouvá s jádrem, ne se správcem balíčků. Hardware je tedy pořád přítomný a software, který s ním mluví, ne.

Porovnejte běžící jádro s nainstalovanými balíčky, než otevřete jakékoli síťové nastavení. Řetězec verze nese značku, kterou generické jádro nemá, a ten jediný detail vysvětluje oba chybějící díly.

Přečtěte si i položku pro start, protože stroj může mít certifikované jádro nainstalované, a přesto ho nespouštět. V takovém případě je příběh modulů úplně jiný a porty i ovladače, které jste se chystali přeinstalovat, jsou v pořádku.

Přečtěte stav modulů dřív než konfiguraci klienta

Modul, který nelze najít, a modul, který existuje, ale odmítá se načíst, jsou dvě různé závady s různými řešeními. modinfo hlásí, kterou z nich máte, a lsmod hlásí, co je právě načtené. Udělejte obojí, než sáhnete na konfiguraci klienta VPN, protože vlastní chyba klienta je málokdy rozliší.

Bezdrátová část potřebuje stejné rozdělení. Rozhraní, které se nikdy neobjeví, ukazuje na ovladač, kdežto to, které existuje, ale zůstává zablokované, ukazuje na rfkill nebo na správce sítě. V panelu na ploše vypadají obě stejně a pod povrchem nemají nic společného.

Spusťte kontroly na samotném stroji, dokud se závada ještě dá reprodukovat. Výstup vložený z jiného hostitele tohle nenahradí.

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

Když modinfo modul vůbec nenajde, přeinstalace balíčku v uživatelském prostoru nepomůže, protože uživatelský prostor nikdy nebyl tou chybějící částí. To pozorování ušetří hodinu handrkování s balíčky a míří přímo na jádro.

Vracejte se v pořadí, které vám nechá jádro

Jestliže bylo FIPS zapnuto omylem, dokumentovaná cesta obnovy vypne službu, odstraní její balíčky a potom obnoví generické jádro. Pořadí není kosmetické. Odstranění odmítne pokračovat, když nenajde jiné jádro Ubuntu, protože odebrání toho jediného by nechalo stroj, který nenaběhne. Právě tato kontrola je rozdíl mezi návratem a přestavbou. Je to také důvod, proč sled kroků selže, když už bylo generické jádro dřív odstraněno.

Proveďte to, dokud je generické jádro ještě nainstalované, přijměte varování o odstranění jádra a potom restartujte. Pak potvrďte, že ve stavu nainstalováno nezůstal žádný balíček FIPS a že běžící jádro je to, které jste čekali.

Na vzdáleném hostiteli si nejdřív zajistěte konzolový nebo mimosměrový přístup. Odebírat jádro přes SSH je v pořádku přesně do restartu, který se nevrátí.

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

Když je certifikace požadavkem

Vracet se zpět je špatný krok, když je certifikace smluvní, protože stroj tím opustí konfiguraci, kterou popisuje audit. V takovém případě je mezera v ovladačích otázkou volby hardwaru: vyberte bezdrátový adaptér, jehož ovladač se dodává s certifikovaným jádrem, přijměte stroj jen s kabelem, nebo přesuňte tunel na komponentu, kterou certifikované jádro už podporuje.

Sestavit modul mimo strom do certifikovaného jádra není neutrální řešení. Mění to, co jádro vykonává, a to je přesně ta vlastnost, kterou certifikace popisuje.

Zapište rozhodnutí s jménem vlastníka vedle něj, protože žádost, ať Wi-Fi prostě funguje, se za pár měsíců vrátí s menším kontextem. Krátká poznámka teď zabrání stejné hádce později.

Po změně projděte stack po vrstvách

Po návratu nebo výměně hardwaru ověřujte zdola nahoru, ne od klienta VPN dolů. Rozhraní musí existovat, spoj musí být nahoře, resolver musí fungovat, a teprve pak záleží na tunelu. Každá vrstva selhává vlastní zprávou a čtení v pořadí udrží diagnózu poctivou.

Zbytkový stav DNS z předchozího startu je častý falešný poplach, proto si přečtěte resolver, než uzavřete, že se tunel rozbil.

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

Jestliže tunel po návratu jádra pořád selhává, čtěte selhávající fázi, ne souhrnný řádek klienta. Modul, který se nikdy nenačetl, certifikát, který protějšek odmítl, a přihlašovací údaj, který server odmítl, jsou tři oddělené problémy a restart je za vás nerozliší. Zapište název fáze do tiketu a další inženýr začne tam, kde jste vy skončili.