FIPS kodola maiņa paņēma līdzi Wi-Fi un VPN moduļus

Ieslēdziet fips-updates, pārstartējiet, un iekārta atgriežas bez bezvadu saskarnes, bet VPN klients atsakās startēt, jo tam trūkst kodola moduļa. Parastā pakešu nozīmē nekas netika atinstalēts, un tāpēc klienta pārinstalēšana nemaina pilnīgi neko. Iekārta darbojas ar kodolu, kuram tās draiveri nekad nav būvēti. Divi simptomi, viens cēlonis, un cēlonis ir redzams vienā komandā.

Ko pārstartēšana patiešām nomainīja

Ubuntu Pro FIPS atjauninājumi instalē sertificētu kodola variantu un padara to par noklusējuma starta ierakstu. Šis variants ir īsts kodols: tas startē, darbojas un palaiž pakalpojumus, kas jums jau bija. Kas tajā nav, ir katrs modulis, kas būvēts vispārīgajam kodolam, tostarp ārpus koka kompilēts bezvadu draiveris un tuneļa modulis, kas piegādāts caur DKMS. Draiveru kopums pārvietojas kopā ar kodolu, nevis ar pakešu pārvaldnieku. Tātad aparatūra joprojām ir, bet programmatūra, kas ar to runā, nav.

Salīdziniet darbojošos kodolu ar instalētajām paketēm, pirms atverat jebkuru tīkla iestatījumu. Versijas virkne nes atzīmi, kuras vispārīgajam kodolam nav, un šī viena detaļa izskaidro abas trūkstošās daļas.

Izlasiet arī starta ierakstu, jo iekārtai var būt instalēts sertificētais kodols, bet tā var to nedarbināt. Tādā gadījumā moduļu stāsts ir pilnīgi citāds, un porti un draiveri, ko grasījāties pārinstalēt, ir kārtībā.

Izlasiet moduļu stāvokli pirms klienta konfigurācijas

Modulis, ko nevar atrast, un modulis, kas pastāv, bet atsakās ielādēties, ir divi dažādi bojājumi ar dažādiem risinājumiem. modinfo ziņo, kurš jums ir, un lsmod ziņo, kas šobrīd ir ielādēts. Veiciet abus, pirms aiztiecat VPN klienta konfigurāciju, jo paša klienta kļūda tos reti šķir.

Bezvadu daļai vajadzīga tā pati atdalīšana. Saskarne, kas nekad neparādās, norāda uz draiveri, bet tā, kas pastāv, taču paliek bloķēta, norāda uz rfkill vai tīkla pārvaldnieku. Darbvirsmas lietotnē abas izskatās vienādi un zem virsmas neko nedala.

Veiciet pārbaudes pašā iekārtā, kamēr bojājums vēl ir atkārtojams. No citas saimnieka ielīmēta izvade to neaizstāj.

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

Kad modinfo moduli nemaz neatroda, lietotāja telpas paketes pārinstalēšana nepalīdzēs, jo lietotāja telpa nekad nav bijusi trūkstošā daļa. Šis novērojums ietaupa stundu pakešu rosības un norāda tieši uz kodolu.

Atgriezieties tādā secībā, kas jums atstāj kodolu

Ja FIPS tika ieslēgts kļūdas dēļ, dokumentētais atkopšanas ceļš izslēdz pakalpojumu, notīra tā paketes un pēc tam atjauno vispārīgo kodolu. Secība nav kosmētiska. Notīrīšana atsakās turpināt, kad nevar atrast citu Ubuntu kodolu, jo vienīgā noņemšana atstātu iekārtu, kas neieslēdzas. Šī pārbaude ir atšķirība starp atgriešanos un pārbūvi. Tā arī ir pīķa, kāpēc secība neizdodas, ja vispārīgais kodols jau ir noņemts.

Izpildiet to, kamēr vispārīgais kodols vēl ir instalēts, pieņemiet brīdinājumu par kodola noņemšanu un pēc tam pārstartējiet. Pēc tam pārliecinieties, ka instalētajā stāvoklī nav palicis neviens FIPS pakete un ka darbojošais kodols ir tas, ko gaidījāt.

Attālā saimniekā vispirms nodrošiniet konsoles vai ārpusjoslas piekļuvi. Kodola noņemšana pa SSH ir kārtībā tieši līdz tam pārstartēšanas brīdim, kas neatgriežas.

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

Kad sertifikācija ir prasība

Atgriešanās ir nepareizs solis, kad sertifikācija ir līgumiska, jo tad iekārta pamet konfigurāciju, ko apraksta audits. Tādā gadījumā draivera plaisa ir aparatūras izvēles jautājums: izvēlieties bezvadu adapteri, kura draiveris nāk kopā ar sertificēto kodolu, pieņemiet iekārtu tikai ar kabeli vai pārvietojiet tuneli uz komponentu, ko sertificētais kodols jau atbalsta.

Ārpus koka esoša moduļa būvēšana sertificētajā kodolā nav neitrāls risinājums. Tas maina to, ko kodols izpilda, un tieši šo īpašību apraksta sertifikācija.

Pierakstiet lēmumu ar īpašnieka vārdu blakus, jo lūgums vienkārši likt Wi-Fi strādāt atgriezīsies pēc dažiem mēnešiem ar mazāk konteksta. Īsa piezīme tagad novērš to pašu strīdu vēlāk.

Pēc izmaiņām pārbaudiet steku slāņos

Pēc atgriešanās vai aparatūras maiņas pārbaudiet no apakšas uz augšu, nevis no VPN klienta uz leju. Saskarnei jābūt, saitei jābūt paceltai, atrisinātājam jāstrādā, un tikai tad tunelim ir nozīme. Katrs slānis neizdodas ar savu ziņojumu, un to lasīšana secībā uztur diagnostiku godīgu.

Atlikušais DNS stāvoklis no iepriekšējās startēšanas ir bieži sastopams maldinošs signāls, tāpēc izlasiet atrisinātāju, pirms secināt, ka tunelis ir salūzis.

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

Ja tunelis joprojām neizdodas, kad kodols ir atgriezies, lasiet neizdevušos posmu, nevis klienta kopsavilkuma rindu. Modulis, kas nekad netika ielādēts, sertifikāts, ko pretējā puse noraidīja, un akreditācijas dati, ko serveris atteica, ir trīs atsevišķas problēmas, un pārstartēšana tās jūsu vietā neizkārtos. Pierakstiet posma nosaukumu biļetē, un nākamais inženieris sāks tur, kur jūs apstājāties.