تعویض هستهٔ FIPS ماژول‌های Wi-Fi و VPN را با خود برد

fips-updates را فعال کنید، راه‌اندازی مجدد کنید و ماشین بدون رابط بی‌سیم برمی‌گردد، در حالی که کلاینت VPN از شروع امتناع می‌کند چون ماژول هستهٔ آن غایب است. هیچ چیز به معنای معمول بسته‌ها حذف نشده است، و به همین دلیل نصب دوبارهٔ کلاینت هیچ چیزی را تغییر نمی‌دهد. ماشین با هسته‌ای کار می‌کند که درایورهایش هرگز برای آن ساخته نشده‌اند. دو نشانه، یک علت، و علت با یک فرمان دیده می‌شود.

راه‌اندازی مجدد واقعاً چه چیزی را عوض کرد

به‌روزرسانی‌های FIPS در Ubuntu Pro یک گونهٔ گواهی‌شده از هسته را نصب می‌کنند و آن را ورودی بوت پیش‌فرض می‌سازند. آن گونه هستهٔ واقعی است: بوت می‌شود، کار می‌کند و سرویس‌هایی را که از قبل داشتید راه می‌اندازد. چیزی که ندارد هر ماژولی است که برای هستهٔ عمومی ساخته شده، از جمله درایور بی‌سیمی که بیرون از درخت کامپایل شده و ماژول تونلی که از طریق 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

اگر تونل پس از بازگشت هسته هنوز شکست می‌خورد، مرحلهٔ شکست‌خورده را بخوانید نه خط خلاصهٔ کلاینت. ماژولی که هرگز بارگذاری نشد، گواهی‌ای که همتا رد کرد و اعتبارنامه‌ای که سرور رد کرد سه مسئلهٔ جدا هستند و راه‌اندازی مجدد آن‌ها را به‌جای شما از هم جدا نمی‌کند. نام مرحله را در تیکت ثبت کنید تا مهندس بعدی از جایی که شما متوقف شدید شروع کند.