Ndryshimi i kernelit FIPS mori me vete modulet Wi-Fi dhe VPN

Aktivizoni fips-updates, rinisni, dhe makina kthehet pa ndërfaqe me valë ndërsa klienti VPN refuzon të niset sepse i mungon moduli i kernelit. Asgjë nuk u çinstalua në kuptimin e zakonshëm të paketave, dhe prandaj riinstalimi i klientit nuk ndryshon absolutisht asgjë. Makina punon me një kernel për të cilin drejtuesit e saj nuk u ndërtuan kurrë. Dy simptoma, një shkak, dhe shkaku duket në një komandë të vetme.

Çfarë ndryshoi në të vërtetë rinisja

Përditësimet FIPS të Ubuntu Pro instalojnë një variant të certifikuar të kernelit dhe e bëjnë atë hyrjen e parazgjedhur të nisjes. Ai variant është kernel i vërtetë: niset, punon dhe nis shërbimet që kishit tashmë. Ajo që nuk përmban është çdo modul i ndërtuar për kernelin e përgjithshëm, përfshirë një drejtues me valë të përpiluar jashtë pemës dhe një modul tuneli të ofruar përmes DKMS. Grupi i drejtuesve lëviz me kernelin, jo me menaxherin e paketave. Pra hardueri është ende aty dhe softueri që flet me të nuk është.

Krahasoni kernelin që punon me paketat e instaluara përpara se të hapni çdo rregullim rrjeti. Vargu i versionit mban një shenjë që kernelit të përgjithshëm i mungon, dhe ai detaj i vetëm shpjegon të dy pjesët që mungojnë.

Lexoni edhe hyrjen e nisjes, sepse një makinë mund ta ketë kernelin e certifikuar të instaluar pa e ekzekutuar. Në atë rast historia e moduleve është krejt tjetër, dhe portat e drejtuesit që po riinstaloni janë në rregull.

Lexoni gjendjen e moduleve përpara konfigurimit të klientit

Një modul që nuk gjendet dhe një modul që ekziston por refuzon të ngarkohet janë dy defekte të ndryshme me zgjidhje të ndryshme. modinfo raporton cilin keni, dhe lsmod raporton çfarë është ngarkuar tani. Bëjini të dyja përpara se të prekni konfigurimin e klientit VPN, sepse gabimi i vetë klientit rrallë i ndan ata.

Pjesa me valë ka nevojë për të njëjtën ndarje. Një ndërfaqe që nuk shfaqet kurrë tregon drejtuesin, ndërsa një që ekziston por mbetet e bllokuar tregon rfkill ose menaxherin e rrjetit. Të dyja duken njësoj në një applet desktopi dhe nuk ndajnë asgjë nën sipërfaqe.

Kryeni kontrollet në vetë makinën ndërsa defekti është ende i riprodhueshëm. Një dalje e ngjitur nga një host tjetër nuk e zëvendëson këtë.

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

Kur modinfo nuk e gjen fare modulin, riinstalimi i paketës së hapësirës së përdoruesit nuk do të ndihmojë, sepse hapësira e përdoruesit nuk ishte kurrë pjesa që mungonte. Ai vëzhgim kursen një orë mundime me paketat dhe tregon drejt kernelit.

Kthehuni mbrapsht në një rend që ju lë një kernel

Nëse FIPS u aktivizua gabimisht, rruga e dokumentuar e rikuperimit çaktivizon shërbimin, heq paketat e tij dhe më pas rikthen kernelin e përgjithshëm. Rendi nuk është kozmetik. Heqja refuzon të vazhdojë kur nuk gjen një kernel tjetër Ubuntu, sepse heqja e të vetmit do të linte një makinë që nuk niset. Ai kontroll është dallimi midis një kthimi mbrapsht dhe një rindërtimi. Është gjithashtu arsyeja pse sekuenca dështon kur kerneli i përgjithshëm është hequr tashmë.

Kryeni atë ndërsa kerneli i përgjithshëm është ende i instaluar, pranoni paralajmërimin për heqjen e një kerneli dhe më pas rinisni. Pastaj konfirmoni se nuk ka mbetur asnjë paketë FIPS në gjendje të instaluar dhe se kerneli që punon është ai që prisnit.

Në një host të largët, para së gjithash siguroni akses konsol ose jashtë brezit. Heqja e një kerneli përmes SSH është në rregull deri pikërisht në rinisjen që nuk kthehet.

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

Kur certifikimi është kërkesa

Kthimi mbrapsht është lëvizja e gabuar kur certifikimi është kontraktor, sepse atëherë makina del nga konfigurimi që përshkruan auditimi. Në atë rast boshllëku i drejtuesve është çështje zgjedhjeje hardueri: zgjidhni një përshtatës me valë drejtuesi i të cilit vjen me kernelin e certifikuar, pranoni një makinë vetëm me kabllo, ose zhvendosni tunelin në një komponent që kerneli i certifikuar tashmë e mbështet.

Ndërtimi i një moduli jashtë pemës në kernelin e certifikuar nuk është zgjidhje neutrale. Ndryshon atë që ekzekuton kerneli, dhe pikërisht atë veti përshkruan certifikimi.

Regjistroni vendimin me emrin e pronarit pranë, sepse kërkesa për të bërë thjesht që Wi-Fi të punojë do të kthehet pas disa muajsh me më pak kontekst. Një shënim i shkurtër tani parandalon të njëjtin debat më vonë.

Kontrolloni stivën me shtresa pas ndryshimit

Pas kthimit mbrapsht ose ndryshimit të harduerit, verifikoni nga poshtë lart në vend që nga klienti VPN poshtë. Ndërfaqja duhet të ekzistojë, lidhja duhet të jetë lart, zgjidhësi duhet të punojë, dhe vetëm atëherë tuneli ka rëndësi. Çdo shtresë dështon me mesazhin e vet, dhe leximi i tyre me radhë e mban diagnozën të ndershme.

Gjendja e mbetur e DNS nga nisja e mëparshme është një pozitiv i rremë i zakonshëm, prandaj lexoni zgjidhësin përpara se të përfundoni se tuneli u prish.

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

Nëse tuneli vazhdon të dështojë pasi kerneli është kthyer, lexoni fazën që dështon në vend të rreshtit përmbledhës të klientit. Një modul që nuk u ngarkua kurrë, një certifikatë që pala tjetër e refuzoi dhe një kredencial që serveri e refuzoi janë tre probleme të ndara, dhe një rinisje nuk do t'i dallojë ato në vendin tuaj. Shënoni emrin e fazës në njoftim, dhe inxhinieri i radhës fillon aty ku ju u ndalët.