FIPS-kernomruiling het die Wi-Fi- en VPN-modules saamgeneem

Aktiveer fips-updates, herbegin, en die masjien kom terug sonder 'n draadlose koppelvlak terwyl die VPN-kliënt weier om te begin omdat sy kernmodule ontbreek. Niks is in die gewone pakket-sin gedeïnstalleer nie, en daarom verander die herinstallasie van die kliënt heeltemal niks. Die masjien loop op 'n kern waarvoor sy drywers nooit gebou is nie. Twee simptome, een oorsaak, en die oorsaak wys in 'n enkele opdrag.

Wat die herbegin werklik omgeskakel het

Ubuntu Pro se FIPS-opdaterings installeer 'n gesertifiseerde kernvariant en maak dit die verstek-inskrywing vir die selflaai. Daardie variant is 'n regte kern: dit begin, dit loop, en dit begin die dienste wat jy reeds gehad het. Wat dit nie bevat nie, is elke module wat vir die generiese kern gebou is, insluitend 'n draadlose drywer wat buite die boom saamgestel is en 'n tonnelmodule wat deur DKMS gelewer word. Die drywerstel beweeg saam met die kern, nie saam met die pakketbestuurder nie. Die hardeware is dus steeds daar en die sagteware wat met hom praat, is nie.

Vergelyk die lopende kern met die geïnstalleerde pakkette voordat jy enige netwerkinstelling oopmaak. Die weergawe-string dra 'n merker wat die generiese kern nie het nie, en daardie een besonderheid verklaar albei ontbrekende stukke.

Lees ook die selflaai-inskrywing, want 'n masjien kan die gesertifiseerde kern geïnstalleer hê sonder om dit te laat loop. In daardie geval is die moduleverhaal heeltemal anders, en die poorte en drywers wat jy op die punt was om te herinstalleer, is heeltemal reg.

Lees die modulestatus voor die kliëntkonfigurasie

'n Module wat nie gevind kan word nie en 'n module wat bestaan maar weier om te laai, is verskillende foute met verskillende oplossings. modinfo rapporteer watter een jy het, en lsmod rapporteer wat nou gelaai is. Doen albei voordat jy aan die VPN-kliënt se konfigurasie raak, want die kliënt se eie fout skei hulle selde.

Draadloos het dieselfde verdeling nodig. 'n Koppelvlak wat nooit verskyn nie, wys na die drywer, terwyl een wat bestaan maar geblokkeer bly, na rfkill of na die netwerkbestuurder wys. Dié twee lyk identies in 'n applet op die lessenaar en deel niks onder die oppervlak nie.

Voer die kontroles op die masjien self uit terwyl die fout nog herhaal kan word. Uitset wat van 'n ander gasheer geplak is, is nie 'n plaasvervanger vir hierdie een nie.

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

Wanneer modinfo die module glad nie kan vind nie, sal die herinstallasie van die gebruikersruim-pakket nie help nie, want die gebruikersruim was nooit die ontbrekende deel nie. Daardie waarneming spaar 'n uur se pakket-geskarrel en wys reguit na die kern.

Rol terug in 'n volgorde wat vir jou 'n kern laat

As FIPS per ongeluk geaktiveer is, deaktiveer die gedokumenteerde herstelpad die diens, verwyder sy pakkette en herstel dan die generiese kern. Die volgorde is nie kosmeties nie. Die verwydering weier om voort te gaan wanneer dit nie 'n ander Ubuntu-kern kan vind nie, want om die enigste een te verwyder sou 'n masjien laat wat nie kan begin nie. Daardie kontrole is die verskil tussen 'n terugrol en 'n herbou. Dit is ook die rede waarom die volgorde misluk wanneer die generiese kern reeds verwyder is.

Voer dit uit terwyl die generiese kern nog geïnstalleer is, aanvaar die waarskuwing oor die verwydering van 'n kern, en herbegin daarna. Bevestig dan dat geen FIPS-pakket in die geïnstalleerde toestand oorbly nie en dat die lopende kern die een is wat jy verwag het.

Op 'n afgeleë gasheer, reël eers konsol- of buiteband-toegang. Om 'n kern oor SSH te verwyder is goed tot presies die herbegin wat nie terugkom nie.

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

Wanneer die sertifisering die vereiste is

Om terug te rol is die verkeerde skuif wanneer die sertifisering kontraktueel is, want die masjien verlaat dan die konfigurasie wat die oudit beskryf. In daardie geval is die drywer-gaping 'n vraag oor hardeware-keuse: kies 'n draadlose adapter wie se drywer saam met die gesertifiseerde kern verskaf word, aanvaar 'n masjien met net 'n kabel, of skuif die tonnel na 'n komponent wat die gesertifiseerde kern reeds ondersteun.

Om 'n module buite die boom in die gesertifiseerde kern in te bou, is nie 'n neutrale oplossing nie. Dit verander wat die kern uitvoer, en dit is juis die eienskap wat die sertifisering beskryf.

Teken die besluit aan met die eienaar se naam daarby, want die versoek om net die Wi-Fi te laat werk, sal oor 'n paar maande terugkom met minder konteks. 'n Kort nota nou voorkom dieselfde argument later.

Kontroleer die stapel in lae ná die verandering

Kontroleer ná die terugrol of die hardeware-verandering van onder af op, eerder as van die VPN-kliënt af ondertoe. Die koppelvlak moet bestaan, die skakel moet op wees, die resolver moet werk, en eers dan maak die tonnel saak. Elke laag faal met sy eie boodskap, en om hulle in volgorde te lees hou die diagnose eerlik.

Oorblywende DNS-toestand van die vorige selflaai is 'n algemene valspositief, so lees die resolver voordat jy tot die gevolgtrekking kom dat die tonnel gebreek het.

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

As die tonnel steeds faal sodra die kern terug is, lees die foutende stadium eerder as die kliënt se opsomming. 'n Module wat nooit gelaai is nie, 'n sertifikaat wat die eweknie verwerp het en 'n geloofsbrief wat die bediener geweier het, is drie afsonderlike probleme, en 'n herbegin sal hulle nie namens jou onderskei nie. Teken die stadium se naam in die kaartjie aan, en die volgende ingenieur begin waar jy opgehou het.