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

કર્નલ પાછું આવ્યા પછી પણ ટનલ નિષ્ફળ જાય તો ક્લાયન્ટની સારાંશ લાઇન નહીં, નિષ્ફળ થતું સ્ટેજ વાંચો. ક્યારેય લોડ ન થયેલું મોડ્યુલ, સામેના છેડાએ નકારેલું પ્રમાણપત્ર અને સર્વરે નકારેલી ઓળખ ત્રણ અલગ સમસ્યાઓ છે, અને રીબૂટ તમારા વતી તેમને અલગ નહીં કરે. ટિકિટમાં સ્ટેજનું નામ લખો, અને આગલો ઇજનેર તમે જ્યાં થોભ્યા ત્યાંથી શરૂ કરશે.