FIPS-kernela anstataŭigo forprenis la Wi-Fi- kaj VPN-modulojn

Ŝaltu fips-updates, restartigu, kaj la maŝino revenas sen sendrata interfaco, dum la VPN-kliento rifuzas ekfunkcii ĉar mankas ĝia kernmodulo. Nenio estis malinstalita laŭ la ordinara paka senco, kaj pro tio reinstalo de la kliento tute ne ŝanĝas ion. La maŝino uzas kernon por kiu ĝiaj peliloj neniam estis konstruitaj. Du simptomoj, unu kaŭzo, kaj la kaŭzo videblas per unu komando.

Kion la restartigo fakte ŝaltis

La FIPS-ĝisdatigoj de Ubuntu Pro instalas atestitan varianton de la kerno kaj faras ĝin la defaŭlta starta ero. Tiu varianto estas vera kerno: ĝi startas, ĝi funkcias, kaj ĝi lanĉas la servojn kiujn vi jam havis. Kion ĝi ne enhavas, estas ĉiu modulo konstruita por la ĝenerala kerno, inkluzive sendratan pelilon kompilitan ekster la arbo kaj tunelan modulon liveratan per DKMS. La pelilaro moviĝas kun la kerno, ne kun la pakadministrilo. Do la aparataro ankoraŭ ĉeestas kaj la programaro kiu parolas kun ĝi ne.

Komparu la kurantan kernon kun la instalitaj pakaĵoj antaŭ ol malfermi ajnan retan agordon. La versioĉeno portas markon kiun la ĝenerala kerno ne havas, kaj tiu unu detalo klarigas ambaŭ mankantajn pecojn.

Legu ankaŭ la startan eron, ĉar maŝino povas havi la atestitan kernon instalita sen uzi ĝin. Tiuokaze la modula historio estas tute alia, kaj la havenoj kaj peliloj kiujn vi volis reinstali estas en ordo.

Legu la modulan staton antaŭ la klienta agordo

Modulo kiu ne troveblas kaj modulo kiu ekzistas sed rifuzas ŝargiĝi estas malsamaj difektoj kun malsamaj solvoj. modinfo raportas kiun vi havas, kaj lsmod raportas kio estas ŝargita nun. Faru ambaŭ antaŭ ol tuŝi la agordon de la VPN-kliento, ĉar la propra eraro de la kliento malofte distingas ilin.

La sendrata parto bezonas la saman dividon. Interfaco kiu neniam aperas montras al la pelilo, dum unu kiu ekzistas sed restas blokita montras al rfkill aŭ al la retadministrilo. Ambaŭ aspektas idente en aplikaĵeto de la labortablo kaj dividas nenion sube.

Rulu la kontrolojn sur la maŝino mem dum la difekto ankoraŭ ripeteblas. Eligo algluita de alia gastiganto ne anstataŭas ĉi tiun.

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

Kiam modinfo tute ne trovas la modulon, reinstalo de la uzantspaca pakaĵo ne helpos, ĉar la uzantspaco neniam estis la mankanta parto. Tiu konstato ŝparas horon da pakaĵa ĥaoso kaj montras rekte al la kerno.

Retroiru laŭ ordo kiu lasas al vi kernon

Se FIPS estis ŝaltita erare, la dokumentita reakira vojo malŝaltas la servon, forigas ĝiajn pakaĵojn kaj poste restarigas la ĝeneralan kernon. La ordo ne estas kosmetika. La forigo rifuzas daŭrigi kiam ĝi ne trovas alian Ubuntu-kernon, ĉar forigi la solan lasus maŝinon kiu ne povas starti. Tiu kontrolo estas la diferenco inter retroiro kaj rekonstruo. Ĝi ankaŭ estas la kialo kial la sinsekvo malsukcesas kiam la ĝenerala kerno jam estis forigita.

Rulu ĝin dum la ĝenerala kerno ankoraŭ estas instalita, akceptu la averton pri forigo de kerno, kaj poste restartigu. Poste konfirmu ke neniu FIPS-pakaĵo restas en la instalita stato kaj ke la kuranta kerno estas tiu kiun vi atendis.

En fora gastiganto, unue aranĝu konzolan aŭ eksterkanalan aliron. Forigi kernon per SSH estas en orde ĝis precize la restartigo kiu ne revenas.

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

Kiam la atestado estas la postulo

Retroiri estas la malĝusta movo kiam la atestado estas kontrakta, ĉar tiam la maŝino forlasas la agordon kiun la revizio priskribas. Tiuokaze la pelilmanko estas demando pri aparatara elekto: prenu sendratan adaptilon kies pelilo venas kun la atestita kerno, akceptu maŝinon nur per kablo, aŭ translokigu la tunelon al komponanto kiun la atestita kerno jam subtenas.

Konstrui modulon ekster la arbo en la atestitan kernon ne estas neŭtrala solvo. Ĝi ŝanĝas kion la kerno plenumas, kaj precize tiun econ priskribas la atestado.

Registru la decidon kun la nomo de la posedanto apude, ĉar la peto simple igi la Wi-Fi funkcii revenos post kelkaj monatoj kun malpli da kunteksto. Mallonga noto nun malhelpas la saman diskuton poste.

Kontrolu la stakon laŭ tavoloj post la ŝanĝo

Post la retroiro aŭ la aparatara ŝanĝo, kontrolu de malsupre supren anstataŭ de la VPN-kliento malsupren. La interfaco devas ekzisti, la ligo devas esti supren, la resolvilo devas funkcii, kaj nur tiam la tunelo gravas. Ĉiu tavolo malsukcesas per sia propra mesaĝo, kaj legi ilin laŭ ordo tenas la diagnozon honesta.

Restinta DNS-stato el la antaŭa starto estas ofta falsa pozitivo, do legu la resolvilon antaŭ ol konkludi ke la tunelo rompiĝis.

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

Se la tunelo ankoraŭ malsukcesas kiam la kerno revenis, legu la malsukcesan etapon anstataŭ la resuman linion de la kliento. Modulo kiu neniam ŝargiĝis, atestilo kiun la partnero malakceptis kaj legitimilo kiun la servilo rifuzis estas tri apartaj problemoj, kaj restartigo ne distingos ilin por vi. Notu la nomon de la etapo en la bileto, kaj la sekva inĝeniero komencos tie kie vi haltis.