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

اگر کرنل واپس آنے کے بعد بھی ٹنل ناکام رہے، تو کلائنٹ کی خلاصہ لائن نہیں بلکہ ناکام ہونے والا مرحلہ پڑھیں۔ جو ماڈیول کبھی لوڈ نہیں ہوا، جو سرٹیفکیٹ سامنے والے سرے نے رد کیا اور جو اسناد سرور نے رد کیں وہ تین الگ مسائل ہیں، اور ری بوٹ آپ کی طرف سے انہیں الگ نہیں کرے گا۔ ٹکٹ میں مرحلے کا نام لکھیں، اور اگلا انجینئر وہیں سے شروع کرے گا جہاں آپ رکے تھے۔