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

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