Заміна ядра FIPS забрала модулі Wi-Fi і VPN

Увімкніть fips-updates, перезавантажтеся, і машина повертається без бездротового інтерфейсу, а клієнт VPN відмовляється запускатися, бо немає його модуля ядра. Нічого не було видалено у звичайному сенсі пакетів, і саме тому перевстановлення клієнта не змінює геть нічого. Машина працює на ядрі, для якого її драйвери ніколи не збиралися. Два симптоми, одна причина, і причину видно в одній команді.

Що насправді перемкнуло перезавантаження

Оновлення FIPS в Ubuntu Pro встановлюють сертифікований варіант ядра і роблять його типовим записом завантаження. Цей варіант — справжнє ядро: воно завантажується, працює і запускає служби, які у вас уже були. Чого в ньому немає, то це всіх модулів, зібраних для звичайного ядра, зокрема бездротового драйвера, скомпільованого поза деревом, і модуля тунелю, що постачається через DKMS. Набір драйверів рухається разом із ядром, а не з менеджером пакетів. Тож обладнання ще є, а програмного забезпечення, яке з ним говорить, немає.

Порівняйте робоче ядро зі встановленими пакетами, перш ніж відкривати будь-яке мережеве налаштування. Рядок версії несе позначку, якої звичайне ядро не має, і ця одна деталь пояснює обидві відсутні частини.

Прочитайте й запис завантаження, бо машина може мати сертифіковане ядро встановленим, але не запускати його. У такому разі історія з модулями зовсім інша, і порти та драйвери, які ви збиралися перевстановити, у порядку.

Прочитайте стан модулів до налаштування клієнта

Модуль, який не вдається знайти, і модуль, який існує, але відмовляється завантажуватися, — дві різні несправності з різними виправленнями. modinfo повідомляє, яка з них у вас, а lsmod повідомляє, що завантажено просто зараз. Зробіть і те, і те, перш ніж чіпати налаштування клієнта VPN, бо власна помилка клієнта рідко їх розрізняє.

Бездротовій частині потрібен той самий поділ. Інтерфейс, який ніколи не з'являється, вказує на драйвер, а той, що існує, але лишається заблокованим, вказує на rfkill або на менеджер мережі. Обидва виглядають однаково в аплеті на робочому столі і не мають під собою нічого спільного.

Виконуйте перевірки на самій машині, поки несправність ще відтворюється. Вивід, вставлений з іншого хоста, не замінює цей.

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

Коли modinfo взагалі не знаходить модуль, перевстановлення пакета простору користувача не допоможе, бо простір користувача ніколи не був відсутньою частиною. Це спостереження економить годину вовтузіння з пакетами і вказує прямо на ядро.

Відкочуйтеся в порядку, який лишає вам ядро

Якщо FIPS було ввімкнено помилково, задокументований шлях відновлення вимикає службу, видаляє її пакети і потім відновлює звичайне ядро. Порядок не косметичний. Видалення відмовляється продовжувати, коли не знаходить іншого ядра Ubuntu, бо видалення єдиного лишило б машину, яка не завантажиться. Ця перевірка і є різниця між відкатом і перезбиранням. Вона ж причина, чому послідовність не спрацьовує, коли звичайне ядро вже було видалено.

Виконайте це, поки звичайне ядро ще встановлене, прийміть попередження про видалення ядра і потім перезавантажтеся. Після цього переконайтеся, що у встановленому стані не лишилося жодного пакета FIPS і що робоче ядро — те, якого ви чекали.

На віддаленому хості спершу організуйте консольний або позасмуговий доступ. Видаляти ядро через SSH нормально рівно до того перезавантаження, яке не повертається.

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

Коли сертифікація і є вимогою

Відкат — неправильний крок, коли сертифікація договірна, бо тоді машина виходить із конфігурації, яку описує аудит. У такому разі розрив у драйверах — питання вибору обладнання: візьміть бездротовий адаптер, драйвер якого постачається із сертифікованим ядром, прийміть машину лише з кабелем або перенесіть тунель на компонент, який сертифіковане ядро вже підтримує.

Збирання модуля поза деревом у сертифіковане ядро — не нейтральне обхідне рішення. Воно змінює те, що виконує ядро, і саме цю властивість описує сертифікація.

Запишіть рішення разом з ім'ям власника поруч, бо прохання просто змусити Wi-Fi працювати повернеться за кілька місяців із меншим контекстом. Коротка нотатка зараз запобігає тій самій суперечці пізніше.

Перевірте стек по шарах після зміни

Після відкату або заміни обладнання перевіряйте знизу вгору, а не від клієнта VPN вниз. Інтерфейс має існувати, канал має бути піднятий, резолвер має працювати, і лише тоді тунель має значення. Кожен шар падає зі своїм повідомленням, і читання їх по порядку тримає діагностику чесною.

Залишковий стан DNS від попереднього завантаження — часта хибна тривога, тому прочитайте резолвер, перш ніж робити висновок, що тунель зламався.

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

Якщо тунель усе ще не працює після повернення ядра, читайте етап, який падає, а не рядок підсумку клієнта. Модуль, який так і не завантажився, сертифікат, який відкинула інша сторона, і облікові дані, які відхилив сервер, — три окремі проблеми, і перезавантаження не розрізнить їх за вас. Запишіть назву етапу в заявці, і наступний інженер почне там, де ви зупинилися.