החלפת הקרנל של 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

אם המנהרה עדיין נכשלת כשהקרנל חזר, קראו את השלב שנכשל ולא את שורת הסיכום של הלקוח. מודול שמעולם לא נטען, תעודה שהצד השני דחה ואישור שהשרת סירב להם הם שלוש בעיות נפרדות, ואתחול לא יבדיל ביניהן בשבילכם. רשמו את שם השלב בכרטיס, והמהנדס הבא יתחיל במקום שבו עצרתם.