Zmiana jądra FIPS zabrała moduły Wi-Fi i VPN

Włącz fips-updates, uruchom ponownie, a maszyna wraca bez interfejsu bezprzewodowego, podczas gdy klient VPN odmawia startu, bo brakuje jego modułu jądra. Nic nie zostało odinstalowane w zwykłym sensie pakietów, i dlatego ponowna instalacja klienta nie zmienia zupełnie niczego. Maszyna działa na jądrze, dla którego jej sterowniki nigdy nie zostały zbudowane. Dwa objawy, jedna przyczyna, a przyczynę widać w jednym poleceniu.

Co restart naprawdę przełączył

Aktualizacje FIPS w Ubuntu Pro instalują certyfikowany wariant jądra i czynią go domyślnym wpisem rozruchowym. Ten wariant to prawdziwe jądro: uruchamia się, działa i startuje usługi, które już miałeś. Czego w nim nie ma, to każdego modułu zbudowanego dla jądra ogólnego, w tym sterownika bezprzewodowego skompilowanego poza drzewem i modułu tunelowego dostarczanego przez DKMS. Zestaw sterowników przenosi się z jądrem, a nie z menedżerem pakietów. Sprzęt więc nadal jest, a oprogramowanie, które z nim rozmawia, nie.

Porównaj działające jądro z zainstalowanymi pakietami, zanim otworzysz jakiekolwiek ustawienie sieci. Ciąg wersji niesie znacznik, którego jądro ogólne nie ma, i ten jeden szczegół wyjaśnia oba brakujące elementy.

Przeczytaj też wpis rozruchowy, bo maszyna może mieć certyfikowane jądro zainstalowane, ale go nie uruchamiać. W takim przypadku historia modułów jest zupełnie inna, a porty i sterowniki, które miałeś przeinstalować, są w porządku.

Przeczytaj stan modułów przed konfiguracją klienta

Moduł, którego nie można znaleźć, i moduł, który istnieje, ale odmawia załadowania, to dwie różne usterki z różnymi naprawami. modinfo informuje, który masz, a lsmod informuje, co jest teraz załadowane. Zrób jedno i drugie, zanim dotkniesz konfiguracji klienta VPN, bo błąd samego klienta rzadko je rozdziela.

Część bezprzewodowa potrzebuje tego samego podziału. Interfejs, który nigdy się nie pojawia, wskazuje na sterownik, a ten, który istnieje, ale pozostaje zablokowany, wskazuje na rfkill albo na menedżera sieci. Oba wyglądają identycznie w aplecie na pulpicie i nie mają pod spodem nic wspólnego.

Uruchom testy na samej maszynie, dopóki usterkę można jeszcze odtworzyć. Wynik wklejony z innego hosta nie zastępuje tego.

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

Kiedy modinfo w ogóle nie znajduje modułu, ponowna instalacja pakietu przestrzeni użytkownika nie pomoże, bo przestrzeń użytkownika nigdy nie była brakującym elementem. Ta obserwacja oszczędza godzinę szarpaniny z pakietami i wskazuje prosto na jądro.

Wycofaj się w kolejności, która zostawia jądro

Jeśli FIPS został włączony przez pomyłkę, udokumentowana ścieżka odzyskiwania wyłącza usługę, usuwa jej pakiety i przywraca jądro ogólne. Kolejność nie jest kosmetyczna. Usuwanie odmawia kontynuacji, gdy nie znajdzie innego jądra Ubuntu, bo usunięcie jedynego zostawiłoby maszynę, która nie wystartuje. To sprawdzenie jest różnicą między wycofaniem a przebudową. Jest też powodem, dla którego sekwencja zawodzi, gdy jądro ogólne zostało już wcześniej usunięte.

Wykonaj to, dopóki jądro ogólne jest jeszcze zainstalowane, zaakceptuj ostrzeżenie o usunięciu jądra i uruchom ponownie. Potem potwierdź, że w stanie zainstalowanym nie został żaden pakiet FIPS i że działające jądro jest tym, którego oczekiwałeś.

Na zdalnym hoście najpierw załatw dostęp przez konsolę lub poza pasmem. Usuwanie jądra przez SSH jest w porządku aż do restartu, który nie wraca.

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

Gdy certyfikacja jest wymogiem

Wycofanie to zły ruch, gdy certyfikacja jest umowna, bo maszyna wychodzi wtedy z konfiguracji opisanej w audycie. W takim przypadku luka w sterownikach to kwestia wyboru sprzętu: wybierz adapter bezprzewodowy, którego sterownik jest dostarczany z certyfikowanym jądrem, zaakceptuj maszynę tylko z kablem albo przenieś tunel na komponent, który certyfikowane jądro już obsługuje.

Zbudowanie modułu poza drzewem w certyfikowane jądro nie jest neutralnym obejściem. Zmienia to, co wykonuje jądro, i właśnie tę właściwość opisuje certyfikacja.

Zapisz decyzję razem z nazwiskiem właściciela obok, bo prośba, żeby po prostu działało Wi-Fi, wróci za kilka miesięcy z mniejszym kontekstem. Krótka notatka teraz zapobiega tej samej dyskusji później.

Sprawdź stos warstwami po zmianie

Po wycofaniu lub zmianie sprzętu sprawdzaj od dołu do góry, a nie od klienta VPN w dół. Interfejs musi istnieć, łącze musi być podniesione, resolver musi działać, i dopiero wtedy tunel ma znaczenie. Każda warstwa zawodzi z własnym komunikatem, a czytanie ich po kolei utrzymuje diagnozę uczciwą.

Pozostały stan DNS z poprzedniego rozruchu to częsty fałszywy alarm, więc przeczytaj resolver, zanim uznasz, że tunel się zepsuł.

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

Jeśli tunel nadal zawodzi po powrocie jądra, czytaj etap, który zawodzi, a nie wiersz podsumowania klienta. Nigdy niezaładowany moduł, certyfikat odrzucony przez drugą stronę i dane logowania odrzucone przez serwer to trzy osobne problemy, a restart ich za ciebie nie rozdzieli. Zapisz nazwę etapu w zgłoszeniu, a następny inżynier zacznie tam, gdzie ty skończyłeś.