Укључите 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

Ако тунел и даље не ради када се језгро врати, читајте фазу која пада, а не резиме клијента. Модул који се никада није учитао, сертификат који је друга страна одбила и акредитив који је сервер одбио три су одвојена проблема, и рестарт их неће разликовати уместо вас. Запишите назив фазе у тикету, и следећи инжењер почиње тамо где сте ви стали.

Повезани чланци