FIPS-ի միջուկի փոխումը տարավ իր հետ Wi-Fi-ի և VPN-ի մոդուլները

Միացրեք fips-updates-ը, վերագործարկեք, և մեքենան վերադառնում է առանց անլար ինտերֆեյսի, մինչդեռ VPN հաճախորդը հրաժարվում է սկսել, որովհետև նրա միջուկային մոդուլը բացակայում է։ Սովորական փաթեթային իմաստով ոչինչ չի հեռացվել, և դրա համար հաճախորդի վերատեղադրումը բացարձակապես ոչինչ չի փոխում։ Մեքենան աշխատում է մի միջուկով, որի համար նրա դրայվերները երբեք չեն կառուցվել։ Երկու ախտանիշ, մեկ պատճառ, և պատճառը երևում է մեկ հրամանով։

Ինչ էր իրականում փոխել վերագործարկումը

Ubuntu Pro-ի FIPS թարմացումները տեղադրում են միջուկի հավաստագրված տարբերակ և այն դարձնում են լռելյայն բեռնման գրառում։ Այդ տարբերակը իսկական միջուկ է՝ այն բեռնվում է, աշխատում է և գործարկում է այն ծառայությունները, որոնք արդեն ունեիք։ Այն, ինչ չկա դրա մեջ, այն է՝ ընդհանուր միջուկի համար կառուցված ամեն մոդուլ, ներառյալ ծառից դուրս կոմպիլացված անլար դրայվեր և DKMS-ի միջոցով մատակարարվող թունելային մոդուլ։ Դրայվերների հավաքածուն շարժվում է միջուկի հետ, ոչ թե փաթեթների կառավարչի։ Այսպիսով՝ սարքավորումը դեռ այնտեղ է, իսկ նրա հետ խոսող ծրագրաշարը՝ ոչ։

Համեմատեք ընթացիկ միջուկը տեղադրված փաթեթների հետ, նախքան ցանկացած ցանցային կարգավորում բացելը։ Տարբերակի տողը կրում է նշան, որը ընդհանուր միջուկը չունի, և այդ մեկ մանրամասնը բացատրում է երկու բացակայող մասերը։

Կարդացեք նաև բեռնման գրառումը, որովհետև մեքենան կարող է ունենալ հավաստագրված միջուկը տեղադրված՝ առանց այն գործարկելու։ Այդ դեպքում մոդուլների պատմությունը բոլորովին այլ է, և այն պորտերը ու դրայվերները, որոնք պատրաստվում էիք վերատեղադրել, կարգին են։

Կարդացեք մոդուլների վիճակը հաճախորդի կարգավորումից առաջ

Չգտնվող մոդուլը և գոյություն ունեցող, բայց բեռնվելուց հրաժարվող մոդուլը երկու տարբեր խափանումներ են՝ տարբեր լուծումներով։ modinfo-ն հայտնում է, թե որն ունեք, իսկ lsmod-ը՝ թե ինչ է բեռնված հիմա։ Արեք երկուսն էլ, նախքան VPN հաճախորդի կարգավորումը ձեռք տալը, որովհետև հաճախորդի սեփական սխալը հազվադեպ է դրանք տարբերում։

Անլար մասը նույն բաժանումն է պահանջում։ Ինտերֆեյսը, որ երբեք չի հայտնվում, մատնանշում է դրայվերը, մինչդեռ գոյություն ունեցող, բայց արգելափակվածը մատնանշում է rfkill-ը կամ ցանցի կառավարիչը։ Երկուսը սեղանային փոքր հավելվածում նույնն են երևում և մակերևույթի տակ ոչինչ չեն կիսում։

Կատարեք ստուգումները հենց մեքենայի վրա, քանի դեռ խափանումը վերարտադրելի է։ Այլ հոսթից տեղադրված ելքը սրա փոխարինողը չէ։

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

Երբ modinfo-ն ընդհանրապես չի գտնում մոդուլը, օգտատիրոջ տարածության փաթեթի վերատեղադրումը չի օգնի, որովհետև օգտատիրոջ տարածությունը երբեք բացակայող մասը չի եղել։ Այդ դիտարկումը խնայում է մեկ ժամ փաթեթային քաշքշուկ և ուղիղ մատնանշում է միջուկը։

Հետ գնացեք այնպիսի հերթականությամբ, որ ձեզ միջուկ թողնի

Եթե FIPS-ը միացվել է սխալմամբ, փաստաթղթավորված վերականգնման ուղին անջատում է ծառայությունը, մաքրում է դրա փաթեթները և ապա վերականգնում ընդհանուր միջուկը։ Հերթականությունը զարդարանք չէ։ Մաքրումը հրաժարվում է շարունակել, երբ չի գտնում Ubuntu-ի մեկ այլ միջուկ, որովհետև միակը հեռացնելը կթողնի մեքենա, որը չի բեռնվի։ Այդ ստուգումն է տարբերությունը հետ գնալու և վերակառուցելու միջև։ Դա նաև այն պատճառն է, թե ինչու հաջորդականությունը ձախողվում է, երբ ընդհանուր միջուկն արդեն հեռացվել է։

Կատարեք այն, քանի դեռ ընդհանուր միջուկը տեղադրված է, ընդունեք միջուկը հեռացնելու մասին նախազգուշացումը և ապա վերագործարկեք։ Հետո հաստատեք, որ ոչ մի FIPS փաթեթ չի մնացել տեղադրված վիճակում և որ ընթացիկ միջուկը ձեր սպասածն է։

Հեռավոր հոսթի վրա նախ կազմակերպեք կոնսոլի կամ գոտուց դուրս հասանելիություն։ SSH-ով միջուկ հեռացնելը նորմալ է մինչև այն վերագործարկումը, որը չի վերադառնում։

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

Երբ հավաստագրումը պահանջն է

Հետ գնալը սխալ քայլ է, երբ հավաստագրումը պայմանագրային է, որովհետև այդ ժամանակ մեքենան դուրս է գալիս այն կարգավորումից, որը նկարագրում է աուդիտը։ Այդ դեպքում դրայվերի բացը սարքավորում ընտրելու հարց է՝ ընտրեք անլար ադապտեր, որի դրայվերը գալիս է հավաստագրված միջուկի հետ, ընդունեք միայն մալուխով մեքենա, կամ տեղափոխեք թունելը այն բաղադրիչ, որը հավաստագրված միջուկն արդեն աջակցում է։

Ծառից դուրս մոդուլը հավաստագրված միջուկի մեջ կառուցելը չեզոք լուծում չէ։ Այն փոխում է, թե ինչ է կատարում միջուկը, և հենց այդ հատկությունն է նկարագրում հավաստագրումը։

Գրանցեք որոշումը՝ կողքին սեփականատիրոջ անունով, որովհետև ուղղակի Wi-Fi-ը աշխատացնելու խնդրանքը մի քանի ամիս անց կվերադառնա ավելի քիչ համատեքստով։ Կարճ նշումը հիմա կկանխի նույն վեճը հետո։

Փոփոխությունից հետո ստուգեք կույտը շերտերով

Հետ գնալուց կամ սարքավորումը փոխելուց հետո ստուգեք ներքևից վերև, ոչ թե VPN հաճախորդից ներքև։ Ինտերֆեյսը պետք է գոյություն ունենա, կապը պետք է բարձրացված լինի, լուծիչը պետք է աշխատի, և միայն դրանից հետո է թունելը կարևոր։ Յուրաքանչյուր շերտ ձախողվում է իր հաղորդագրությամբ, և դրանք հերթով կարդալը ախտորոշումը պահում է ազնիվ։

Նախորդ բեռնումից մնացած DNS վիճակը սովորական կեղծ ահազանգ է, ուստի կարդացեք լուծիչը, նախքան եզրակացնելը, որ թունելը կոտրվել է։

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

Եթե թունելը դեռ ձախողվում է միջուկի վերադարձից հետո, կարդացեք ձախողվող փուլը, ոչ թե հաճախորդի ամփոփ տողը։ Երբեք չբեռնված մոդուլը, հակառակորդի մերժած վկայականը և սերվերի մերժած հավատարմագրերը երեք առանձին խնդիրներ են, և վերագործարկումը ձեր փոխարեն չի տարբերի դրանք։ Գրանցեք փուլի անվանումը տոմսում, և հաջորդ ինժեները կսկսի այնտեղ, որտեղ դուք կանգ առաք։