FIPS 커널 교체로 Wi-Fi와 VPN 모듈이 함께 사라졌다
fips-updates를 켜면 무선 또는 터널 모듈 없이 만들어진 인증 커널로 부팅됩니다. 무엇이든 다시 설치하기 전에 커널을 확인하십시오.
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 listmodinfo가 모듈을 전혀 찾지 못한다면 사용자 공간 패키지를 다시 설치해도 도움이 되지 않습니다. 사용자 공간이 없어진 부분이 아니었기 때문입니다. 이 관찰은 한 시간의 패키지 소동을 아끼고 커널을 곧바로 가리킵니다.
커널을 남겨 두는 순서로 되돌리십시오
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커널이 돌아온 뒤에도 터널이 실패한다면 클라이언트의 요약 줄이 아니라 실패한 단계를 읽으십시오. 로드되지 않은 모듈, 상대가 거부한 인증서, 서버가 거절한 자격 증명은 세 가지 별개 문제이며, 재부팅이 대신 구분해 주지 않습니다. 티켓에 단계 이름을 남기면 다음 엔지니어가 당신이 멈춘 곳에서 시작합니다.