Vklopite fips-updates, znova zaženite in stroj se vrne brez brezžičnega vmesnika, medtem ko odjemalec VPN noče začeti, ker mu manjka modul jedra. V običajnem pomenu paketov ni bilo nič odstranjeno, zato ponovna namestitev odjemalca ne spremeni prav ničesar. Stroj teče na jedru, za katero njegovi gonilniki nikoli niso bili zgrajeni. Dva simptoma, en vzrok, in vzrok je viden v enem samem ukazu.

Kaj je ponovni zagon v resnici preklopil

Posodobitve FIPS v Ubuntu Pro namestijo certificirano različico jedra in jo naredijo privzeti vnos za zagon. Ta različica je pravo jedro: zažene se, deluje in požene storitve, ki ste jih že imeli. Česar pa ne vsebuje, je vsak modul, zgrajen za splošno jedro, vključno z brezžičnim gonilnikom, prevedenim zunaj drevesa, in tunelskim modulom, dobavljenim prek DKMS. Nabor gonilnikov se premika z jedrom, ne z upraviteljem paketov. Strojna oprema je torej še vedno tam, programska oprema, ki govori z njo, pa ne.

Primerjajte delujoče jedro z nameščenimi paketi, preden odprete katero koli omrežno nastavitev. Niz različice nosi oznako, ki je splošno jedro nima, in ta podatek pojasni oba manjkajoča dela.

Preberite tudi vnos za zagon, ker ima lahko stroj certificirano jedro nameščeno, ne da bi ga izvajal. V tem primeru je zgodba z moduli povsem drugačna in vrata ter gonilniki, ki ste jih nameravali znova namestiti, so v redu.

Preberite stanje modulov pred konfiguracijo odjemalca

Modul, ki ga ni mogoče najti, in modul, ki obstaja, a se noče naložiti, sta dve različni napaki z različnima popravkoma. modinfo sporoči, katero imate, lsmod pa, kaj je trenutno naloženo. Naredite oboje, preden se dotaknete konfiguracije odjemalca VPN, ker lastna napaka odjemalca redko loči med njima.

Brezžični del potrebuje enako ločevanje. Vmesnik, ki se nikoli ne pojavi, kaže na gonilnik, medtem ko tisti, ki obstaja, a ostane blokiran, kaže na rfkill ali na upravitelja omrežja. Oba sta v programu na namizju videti enako in si pod površjem ne delita ničesar.

Preizkuse izvedite na samem stroju, dokler je napako še mogoče ponoviti. Izpis, prilepljen z drugega gostitelja, tega ne nadomesti.

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

Ko modinfo modula sploh ne najde, ponovna namestitev paketa uporabniškega prostora ne bo pomagala, ker uporabniški prostor ni bil nikoli manjkajoči del. To opažanje prihrani uro urejanja paketov in kaže naravnost na jedro.

Vrnite se v vrstnem redu, ki vam pusti jedro

Če je bil FIPS vklopljen pomotoma, dokumentirana pot za obnovitev izklopi storitev, odstrani njene pakete in nato obnovi splošno jedro. Vrstni red ni kozmetičen. Odstranitev noče nadaljevati, ko ne najde drugega jedra Ubuntu, ker bi odstranitev edinega pustila stroj, ki se ne zažene. Ta preveritev je razlika med vrnitvijo in ponovno gradnjo. Je tudi razlog, da zaporedje ne uspe, ko je bilo splošno jedro že prej odstranjeno.

Izvedite jo, dokler je splošno jedro še nameščeno, sprejmite opozorilo o odstranitvi jedra in nato znova zaženite. Nato potrdite, da v nameščenem stanju ni ostal noben paket FIPS in da je delujoče jedro tisto, ki ste ga pričakovali.

Na oddaljenem gostitelju najprej uredite konzolni ali zunajpasovni dostop. Odstranjevanje jedra po SSH je v redu vse do tistega ponovnega zagona, ki se ne vrne.

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

Ko je certifikacija zahteva

Vrnitev nazaj je napačna poteza, ko je certifikacija pogodbena, ker stroj takrat zapusti konfiguracijo, ki jo opisuje revizija. V tem primeru je vrzel v gonilnikih vprašanje izbire strojne opreme: izberite brezžični vmesnik, katerega gonilnik se dobavi s certificiranim jedrom, sprejmite stroj samo s kablom ali prestavite tunel na komponento, ki jo certificirano jedro že podpira.

Zgraditi modul zunaj drevesa v certificirano jedro ni nevtralna rešitev. Spremeni, kaj jedro izvaja, in prav to lastnost certifikacija opisuje.

Zapišite odločitev z imenom lastnika ob njej, ker se bo zahteva, naj preprosto dela Wi-Fi, čez nekaj mesecev vrnila z manj konteksta. Kratka zabeležka zdaj prepreči enako razpravo pozneje.

Po spremembi preglejte sklad po plasteh

Po vrnitvi ali zamenjavi strojne opreme preverjajte od spodaj navzgor, ne od odjemalca VPN navzdol. Vmesnik mora obstajati, povezava mora biti dvignjena, razreševalnik mora delovati, in šele nato je tunel pomemben. Vsaka plast odpove s svojim sporočilom, branje po vrsti pa ohranja diagnozo pošteno.

Preostalo stanje DNS iz prejšnjega zagona je pogost lažni alarm, zato preberite razreševalnik, preden sklepate, da se je tunel pokvaril.

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

Če tunel po vrnitvi jedra še vedno odpove, berite stopnjo, ki odpove, ne vrstice s povzetkom odjemalca. Modul, ki se ni nikoli naložil, potrdilo, ki ga je nasprotna stran zavrnila, in poverilnice, ki jih je strežnik zavrnil, so tri ločene težave in ponovni zagon jih ne bo ločil namesto vas. Zapišite ime stopnje v zahtevek in naslednji inženir bo začel tam, kjer ste vi končali.

Sorodni članki