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

अगर कर्नेल लौटने के बाद भी टनल विफल रहे, तो क्लाइंट की सारांश पंक्ति नहीं बल्कि विफल होने वाला चरण पढ़ें। जो मॉड्यूल कभी लोड नहीं हुआ, जो प्रमाणपत्र सामने वाले छोर ने अस्वीकार किया और जो क्रेडेंशियल सर्वर ने अस्वीकार किया, तीन अलग समस्याएँ हैं, और रीबूट आपकी ओर से उन्हें अलग नहीं करेगा। टिकट में चरण का नाम लिखें, और अगला इंजीनियर वहीं से शुरू करेगा जहाँ आप रुके थे।