Den FIPS-Kernelwiessel huet d'Wi-Fi- an d'VPN-Moduler matgeholl

Schalt fips-updates an, start nei, an de Rechner kënnt ouni drahtlos Interface zréck, wärend de VPN-Client refuséiert ze starten, well säi Kernelmodul feelt. Et gouf näischt am gewéinleche Paketsënn deinstalléiert, an dofir ännert d'Neiinstallatioun vum Client absolut näischt. De Rechner leeft op engem Kernel, fir deen seng Treiber ni gebaut goufen. Zwee Symptomer, eng Ursaach, an d'Ursaach ass an engem eenzege Kommando ze gesinn.

Wat den Neistart tatsächlech ëmgeschalt huet

D'FIPS-Aktualiséierunge vun Ubuntu Pro installéieren eng zertifizéiert Kernelvariant a maachen se zum Standardstartandrag. Déi Variant ass en echte Kernel: hie startet, hie leeft, an hie startet d'Servicer, déi Dir schonn hat. Wat net dran ass, ass all Modul, dee fir de generesche Kernel gebaut gouf, dorënner en drahtlosen Treiber, deen ausserhalb vum Bam kompiléiert gouf, an en Tunnelmodul, deen iwwer DKMS geliwwert gëtt. Den Treibersaz beweegt sech mam Kernel, net mam Pakemanager. Also ass d'Hardware nach do an d'Software, déi mat hir schwätzt, net.

Vergläicht de lafende Kernel mat den installéierte Paken, ier Dir eng Netzwierkastellung opmaacht. D'Versiounszeechen dréit eng Markéierung, déi de generesche Kernel net huet, an déi eng Detail erkläert déi zwee fehlend Deeler.

Liest och den Startandrag, well e Rechner de zertifizéierte Kernel installéiert ka hunn, ouni en ze lafen. An deem Fall ass d'Modulgeschicht komplett anescht, an d'Porten an Treiber, déi Dir wollt nei installéieren, si gutt.

Liest den Modulzoustand virun der Clientkonfiguratioun

En Modul, deen net fonnt gëtt, an en Modul, deen et gëtt awer refuséiert ze lueden, sinn zwee verschidden Feeler mat zwee verschiddene Léisungen. modinfo mellt, wéi en Deen Dir hutt, an lsmod mellt, wat just elo gelueden ass. Maacht béides, ier Dir d'Konfiguratioun vum VPN-Client beréiert, well de Feeler vum Client selwer se selten trennt.

Den drahtlosen Deel brauch déi selwecht Deelung. En Interface, deen ni erschéngt, weist op den Treiber, wärend een, deen et gëtt awer blockéiert bleift, op rfkill oder op de Netzwierkmanager weist. Déi zwee gesinn am Desktop-Applet d'selwecht aus a deelen ënner der Uewerfläch näischt.

Féiert d'Kontrollen um Rechner selwer aus, soulaang de Feeler nach reproduzéierbar ass. Eng Ausgab, déi vun engem aneren Host agebonne gouf, ersetzt dës net.

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

Wann modinfo de Modul guer net fënnt, hëlleft eng Neiinstallatioun vum Userspace-Pak net, well den Userspace ni den Deel war, deen gefeelt huet. Déi Observatioun spuert eng Stonn Pakegefläiss a weist riicht op de Kernel.

Gitt an enger Rei zréck, déi Iech e Kernel léisst

Wann FIPS falsch ageschalt gouf, deaktivéiert den dokumentéierte Wee fir Erhuelung de Service, läscht seng Paken an restauréiert dann de generesche Kernel. D'Rei ass net kosmetesch. D'Läschen refuséiert weiderzemaachen, wann et keen aneren Ubuntu-Kernel fënnt, well deen eenzegen ewechzehuelen engem Rechner hannerléisst, dee net ka starten. Dee Kontroll ass den Ënnerscheed tëscht engem Zréck an engem Neibau. Et ass och de Grond, firwat d'Reiefolleg feelt, wann de generesche Kernel scho virdru geläscht gouf.

Féiert en aus, soulaang de generesche Kernel nach installéiert ass, akzeptéiert d'Warnung iwwer d'Läschen vun engem Kernel a start nei. Bestätegt duerno, datt kee FIPS-Pak am installéierten Zoustand bleift an datt de lafende Kernel deen ass, deen Dir erwaart hutt.

Op engem Fernhost arrangéiert Dir als éischt Konsol- oder Out-of-Band-Zougang. E Kernel iwwer SSH ewechzehuelen ass gutt bis just zu deem Neistart, deen net zréckkënnt.

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

Wann d'Zertifizéierung d'Ufuerderung ass

Zréckzekréien ass de falsche Schrëtt, wann d'Zertifizéierung kontraktuell ass, well de Rechner dann d'Konfiguratioun verléisst, déi den Audit beschreift. An deem Fall ass den Treiberluechen eng Fro vun der Hardwareauswiel: hëlt en drahtlosen Adapter, deem säin Treiber mam zertifizéierte Kernel kënnt, akzeptéiert e Rechner nëmme mat Kabel, oder verréckelt den Tunnel op eng Komponent, déi den zertifizéierte Kernel schonn ënnerstëtzt.

En ausserhalb vum Bam gebaute Modul an den zertifizéierte Kernel ze bauen ass keng neutral Léisung. Et ännert, wat de Kernel ausféiert, an dat ass genee déi Eegenschaft, déi d'Zertifizéierung beschreift.

Schreift d'Entscheedung mat dem Numm vum Besëtzer niewendrun op, well d'Ufro, just d'Wi-Fi solle funktionéieren, an e puer Méint mat manner Kontext zréckkënnt. Eng kuerz Notiz elo verhënnert déi selwecht Diskussi méi spéit.

Kontrolléiert de Stack no der Ännerung a Schichten

No dem Zréck oder der Hardwareännerung iwwerpréift vun ënnen no uewen amplaz vum VPN-Client no ënnen. Den Interface muss existéieren, d'Verbindung muss uewe sinn, den Resolver muss funktionéieren, an eréischt dann zielt den Tunnel. All Schicht feelt mat hirer eegener Noriicht, an se an der Rei ze liesen hält d'Diagnos éierlech.

Reschter vum DNS-Zoustand vum virege Start sinn e geleefegen False Positive, also liest den Resolver, ier Dir schléisst, datt den Tunnel futti ass.

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

Wann den Tunnel nach ëmmer feelt, wann de Kernel zréck ass, liest déi feelend Etapp amplaz vun der Zesummefaassungszeil vum Client. En Modul, deen ni gelueden gouf, en Zertifikat, deen déi aner Säit verworf huet, an en Identifiant, deen de Server refuséiert huet, sinn dräi getrennte Problemer, an en Neistart ënnerscheet se net fir Iech. Schreift den Numm vun der Etapp an den Ticket, an den nächsten Ingenieur fänkt do un, wou Dir opgehalen hutt.