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

कर्नेल परत आल्यावरही टनेल अयशस्वी होत असेल, तर क्लायंटची सारांश ओळ नाही तर अयशस्वी होणारा टप्पा वाचा. कधीही लोड न झालेले मॉड्यूल, समोरच्या टोकाने नाकारलेले प्रमाणपत्र आणि सर्व्हरने नाकारलेले क्रेडेन्शियल या तीन वेगळ्या समस्या आहेत, आणि रीबूट तुमच्यावतीने त्या वेगळ्या करणार नाही. तिकिटात टप्प्याचे नाव लिहा, आणि पुढचा अभियंता तुम्ही थांबलात तिथून सुरुवात करेल.