การสลับเคอร์เนล 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

ถ้าอุโมงค์ยังล้มเหลวหลังเคอร์เนลกลับมา ให้อ่านขั้นตอนที่ล้มเหลวแทนบรรทัดสรุปของไคลเอนต์ โมดูลที่ไม่เคยโหลด ใบรับรองที่อีกฝ่ายปฏิเสธ และข้อมูลรับรองที่เซิร์ฟเวอร์ปฏิเสธเป็นปัญหาสามอย่างแยกกัน และการรีบูตจะไม่แยกมันให้คุณ บันทึกชื่อขั้นตอนในตั๋ว แล้ววิศวกรคนถัดไปจะเริ่มจากที่คุณหยุดไว้