커널 업데이트 후 WireGuard 모듈이 로드되지 않습니까? 이 점을 확인하세요
외부 모듈은 그것을 로드할 커널에 맞춰 빌드해야 하며, 디스크에 있는 최신 헤더 패키지에 맞춰 빌드하면 안 됩니다. 다시 빌드하기 전에 실행 중인 릴리스를 확인하세요.
어제는 터널이 동작했는데 업데이트 후 재부팅한 뒤 지금은 인터페이스가 올라오지 않습니다. WireGuard를 외부 모듈로 빌드하는 시스템에서 흔한 원인은 디스크의 모듈이 현재 실행 중인 커널 릴리스와 다른 릴리스에 속해 있다는 점입니다. 같은 머신에 비슷한 이름의 헤더가 있다고 해서 그 일치가 증명되지는 않습니다. 그것을 결정하는 것은 릴리스 문자열뿐입니다.
실행 중인 커널인가 설치된 커널인가
업데이트는 새 커널 패키지를 설치하고 머신이 재부팅될 때까지 이전 패키지를 디스크에 남겨 둡니다. 재부팅 후 실행 중인 릴리스가 바뀌고, 이전 릴리스에 맞춰 빌드된 모듈은 파일이 남아 있어도 사용할 수 없게 됩니다. 이 간극이, 그 사이에 설정 변경도 없이 재부팅 전에는 정상이었고 후에는 깨졌다는 흔한 보고를 설명합니다. 헤더를 다시 설치하면 어떤 때는 문제가 해결된 것처럼 보이고 어떤 때는 그렇지 않은 이유도 여기서 설명됩니다.
설치하는 헤더 패키지는 실제로 부팅된 커널이 아니라 최신 커널 패키지에 대응할 수 있으며, 패키지 이름만으로는 그 경우를 구분할 수 없고, 구분하는 것은 릴리스 문자열뿐입니다. 무엇이 설치되어 있는지 확인하기 전에 무엇이 실행 중인지 확인하세요.
다시 빌드하기 전 세 가지 확인
첫 번째 확인은 어떤 커널이 실행 중인지입니다. 두 번째는 그 릴리스용 모듈이 존재하고 찾을 수 있는지입니다. 세 번째는 커널이 이미 그것을 로드했는지입니다. 네 번째 질문, 즉 인터페이스를 만들 수 있는지는 모듈이 아니라 권한을 시험하므로 이 목록이 아니라 다시 빌드한 뒤에 다룹니다.
아래 명령은 아무것도 바꾸지 않고 처음 세 가지에 답합니다. 답마다 배제되는 수리가 다르므로 계속하기 전에 각 결과를 읽으세요.
uname -r
ls -l /lib/modules/$(uname -r)/build
modinfo wireguard
lsmod | grep wireguard
두 번째 줄이 경로가 없다고 보고하면 실행 중인 커널의 빌드 환경이 없고, 컴파일한 무엇도 그것과 맞지 않습니다. 경로가 있는데 modinfo 이 실패하면 모듈이 아예 설치되지 않았을 수 있으며, 이는 구현을 트리 안에 제공하는 커널에서는 정상입니다. modinfo 이 성공하고 lsmod 이 아무것도 표시하지 않으면 모듈은 있지만 로드되지 않은 것이며, 이는 빌드가 아니라 로드 시점의 문제입니다. 각 결과가 서로 다른 곳으로 안내하므로 명령보다 읽기가 더 중요합니다.
실행 중인 릴리스에 맞춰 빌드하세요
외부 모듈은 준비된 커널 트리에 맞춰 컴파일되며, 커널의 외부 모듈 안내서는 가장 높은 버전 번호를 가진 디렉터리가 아니라 실행 중인 커널에 속한 빌드 디렉터리를 사용하라고 설명합니다. 그 빌드 디렉터리는 커널 패키지가 관리하는 심볼릭 링크이므로 현재 부팅된 릴리스의 트리를 가리킵니다. 이 간접성이 바로 핵심이며, 그렇지 않으면 잘못하게 될 선택을 없애 줍니다. 그것을 명시적으로 지정하면 대상이 모호하지 않게 됩니다.
트리가 완전히 빌드되지 않고 준비만 된 경우 한 가지 세부 사항이 중요합니다. 준비 대상은 일부 외부 빌드에 필요한 심볼 버전 파일을 만들지 않으므로, 헤더로 가득한 트리가 자동으로 완전한 빌드 환경이 되지는 않습니다. 심볼 부족으로 빌드가 실패하면 그 파일이 가장 먼저 볼 곳입니다.
sudo make -C /lib/modules/$(uname -r)/build M=$(pwd) modules
sudo make -C /lib/modules/$(uname -r)/build M=$(pwd) modules_install
sudo depmod -a
패키징된 헤더가 뒤처질 때
자체 커널을 패키징하는 배포판과 단일 보드 컴퓨터에서는 헤더가 릴리스보다 며칠이나 몇 주 늦을 수 있습니다. 헤더 패키지는 이름은 맞지만 내용은 더 오래된 것일 수 있으며, 그러면 빌드는 컴파일된 뒤 컴파일 중이 아니라 로드 시점에 실패합니다. 출처를 섞으면 더 나빠지며, 서드파티 저장소의 헤더를 가진 배포판 커널이나 일반 헤더를 가진 벤더 커널은 깨끗하게 컴파일되고도 설정이 다르기 때문에 실행 중인 커널에 거부될 수 있습니다. 버전 번호만으로는 그것이 해결되지 않습니다.
머신이 실험적 커널 채널을 따른다면, 대응하는 빌드 산출물을 가지고 그대로 머물지 아니면 지원되는 패키지 집합으로 돌아갈지를 의식적으로 결정하세요. 업데이트를 반복하면서 조각들이 맞아떨어지기를 바라는 것은, 같은 불일치가 매번 재현되므로 계획이 아닙니다.
다시 빌드한 뒤 인터페이스를 확인하세요
설치가 성공한 뒤에는 인터페이스를 만드는 것이 중요한 시험이고, 그다음에 커널이 실제로 무엇을 로드했는지, 거부했다면 로그가 무엇을 말하는지 읽습니다. 로드되는 모듈과 만들 수 없는 인터페이스는 원인이 다른 서로 다른 실패입니다. 아래 세 명령이 그것을 구분합니다.
sudo ip link add wg9 type wireguard
lsmod | grep wireguard
sudo dmesg | tail -5
모듈이 로드를 거부하면 커널 로그가 이유를 밝히며, 버전 불일치는 가능한 원인 중 하나일 뿐입니다. 두 번째로 동일하게 빌드해도 같은 십 분을 쓰고 같은 거부가 나오므로, 다시 빌드하기 전에 그 줄을 읽으세요. 그런 다음 임시 인터페이스를 제거해 다음 시험이 깨끗한 상태에서 시작되게 하세요.