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

കേർണൽ തിരികെ വന്നതിന് ശേഷവും ടണൽ പരാജയപ്പെടുന്നുവെങ്കിൽ, ക്ലയന്റിന്റെ സംഗ്രഹ വരിയല്ല, പരാജയപ്പെടുന്ന ഘട്ടം വായിക്കുക. ഒരിക്കലും ലോഡ് ചെയ്യാത്ത മൊഡ്യൂൾ, എതിർവശം നിരസിച്ച സർട്ടിഫിക്കറ്റ്, സർവർ നിരസിച്ച ക്രെഡൻഷ്യൽ എന്നിവ മൂന്ന് വ്യത്യസ്ത പ്രശ്നങ്ങളാണ്, റീബൂട്ട് അവ നിങ്ങൾക്കുവേണ്ടി വേർതിരിക്കില്ല. ടിക്കറ്റിൽ ഘട്ടത്തിന്റെ പേര് എഴുതുക, അടുത്ത എൻജിനീയർ നിങ്ങൾ നിർത്തിയിടത്ത് നിന്ന് തുടങ്ങും.