Việc đổi kernel FIPS mang theo cả mô-đun Wi-Fi và VPN

Bật fips-updates, khởi động lại, và máy quay về mà không có giao diện không dây trong khi ứng dụng VPN từ chối khởi chạy vì thiếu mô-đun kernel của nó. Không có gì bị gỡ theo nghĩa gói thông thường, và đó là lý do việc cài lại ứng dụng không thay đổi gì cả. Máy đang chạy một kernel mà các trình điều khiển của nó chưa bao giờ được biên dịch cho. Hai triệu chứng, một nguyên nhân, và nguyên nhân hiện ra trong một lệnh duy nhất.

Lần khởi động lại đã thực sự đổi thứ gì

Các bản cập nhật FIPS trong Ubuntu Pro cài một biến thể kernel đã chứng nhận và biến nó thành mục khởi động mặc định. Biến thể đó là kernel thật: nó khởi động, nó chạy và nó khởi động các dịch vụ bạn đã có. Thứ nó không chứa là mọi mô-đun được biên dịch cho kernel chung, kể cả trình điều khiển không dây được biên dịch ngoài cây và một mô-đun đường hầm được cung cấp qua DKMS. Bộ trình điều khiển di chuyển cùng kernel chứ không cùng trình quản lý gói. Vậy nên phần cứng vẫn còn đó còn phần mềm nói chuyện với nó thì không.

So sánh kernel đang chạy với các gói đã cài trước khi mở bất kỳ thiết lập mạng nào. Chuỗi phiên bản mang một dấu mà kernel chung không có, và riêng chi tiết đó giải thích cả hai phần bị thiếu.

Cũng hãy đọc mục khởi động, vì máy có thể đã cài kernel được chứng nhận mà không chạy nó. Trong trường hợp đó câu chuyện mô-đun hoàn toàn khác, và các cổng cùng trình điều khiển bạn định cài lại vẫn ổn.

Đọc trạng thái mô-đun trước cấu hình ứng dụng

Một mô-đun không tìm thấy và một mô-đun tồn tại nhưng từ chối nạp là hai lỗi khác nhau với hai cách sửa khác nhau. modinfo cho biết bạn thuộc trường hợp nào, và lsmod cho biết hiện đang nạp gì. Hãy làm cả hai trước khi chạm vào cấu hình ứng dụng VPN, vì lỗi của chính ứng dụng hiếm khi phân biệt được chúng.

Phần không dây cũng cần cách tách tương tự. Một giao diện không bao giờ xuất hiện chỉ về trình điều khiển, còn một giao diện tồn tại nhưng bị chặn chỉ về rfkill hoặc trình quản lý mạng. Hai thứ trông giống nhau trong một applet trên màn hình và không chia sẻ gì bên dưới.

Hãy chạy các kiểm tra trên chính máy trong khi lỗi còn tái hiện được. Kết quả dán từ một máy khác không thay thế được kết quả này.

uname -r
pro status --all | grep -E 'fips|kernel'
modinfo wireguard 2>&1 | head -3
rfkill list

Khi modinfo hoàn toàn không tìm thấy mô-đun, cài lại gói không gian người dùng sẽ không giúp gì, vì không gian người dùng chưa bao giờ là phần bị thiếu. Quan sát đó tiết kiệm một giờ loay hoay với gói và chỉ thẳng vào kernel.

Quay lại theo thứ tự còn để lại cho bạn một kernel

Nếu FIPS bị bật nhầm, đường khôi phục được ghi lại sẽ tắt dịch vụ, dọn các gói của nó rồi khôi phục kernel chung. Thứ tự không phải hình thức. Việc dọn dẹp từ chối tiếp tục khi không tìm được kernel Ubuntu khác, vì xóa cái duy nhất sẽ để lại một máy không khởi động được. Chính kiểm tra đó là khác biệt giữa quay lui và dựng lại. Đó cũng là lý do trình tự này thất bại khi kernel chung đã bị xóa trước đó.

Chạy nó khi kernel chung vẫn còn cài, chấp nhận cảnh báo về việc xóa kernel, rồi khởi động lại. Sau đó xác nhận không còn gói FIPS nào ở trạng thái đã cài và kernel đang chạy là bản bạn mong đợi.

Trên máy từ xa, hãy sắp xếp truy cập qua bảng điều khiển hoặc ngoài băng trước. Xóa kernel qua SSH thì ổn cho tới đúng lần khởi động lại không quay về.

dpkg -l | grep -E 'linux-image|fips'
sudo pro disable fips-updates --purge
sudo apt install --reinstall linux-generic
sudo reboot

Khi chứng nhận là yêu cầu

Quay lui là nước đi sai khi chứng nhận mang tính hợp đồng, vì khi đó máy rời khỏi cấu hình mà cuộc kiểm toán mô tả. Trong trường hợp đó khoảng trống trình điều khiển là câu hỏi chọn phần cứng: chọn bộ tiếp hợp không dây có trình điều khiển đi kèm kernel được chứng nhận, chấp nhận máy chỉ có cáp, hoặc chuyển đường hầm sang thành phần mà kernel được chứng nhận đã hỗ trợ.

Biên dịch một mô-đun ngoài cây vào kernel được chứng nhận không phải giải pháp trung tính. Nó thay đổi thứ kernel thực thi, và đó chính là thuộc tính mà chứng nhận mô tả.

Ghi lại quyết định kèm tên người sở hữu bên cạnh, vì yêu cầu chỉ cần Wi-Fi chạy được sẽ quay lại sau vài tháng với ít bối cảnh hơn. Một ghi chú ngắn bây giờ ngăn cuộc tranh luận y hệt về sau.

Kiểm tra ngăn xếp theo tầng sau thay đổi

Sau khi quay lui hoặc thay phần cứng, hãy xác minh từ dưới lên thay vì từ ứng dụng VPN xuống. Giao diện phải tồn tại, liên kết phải lên, trình phân giải phải chạy, và chỉ khi đó đường hầm mới quan trọng. Mỗi tầng hỏng với thông báo của riêng nó, và đọc chúng theo thứ tự giữ cho chẩn đoán trung thực.

Trạng thái DNS còn sót từ lần khởi động trước là dương tính giả phổ biến, nên hãy đọc trình phân giải trước khi kết luận đường hầm hỏng.

nmcli device status
ip -brief link
resolvectl status | head -12
systemctl --failed

Nếu đường hầm vẫn hỏng sau khi kernel quay về, hãy đọc giai đoạn bị hỏng thay vì dòng tóm tắt của ứng dụng. Mô-đun chưa bao giờ nạp, chứng chỉ bị phía bên kia từ chối và thông tin xác thực bị máy chủ từ chối là ba vấn đề riêng biệt, và một lần khởi động lại sẽ không phân biệt chúng thay bạn. Ghi tên giai đoạn vào phiếu, và kỹ sư tiếp theo bắt đầu từ chỗ bạn dừng.