이 CPU용으로 빌드된 VPN 바이너리인가요? ELF 헤더를 읽어 보세요

두 파일 모두 32비트이며 그중 하나만 보드에서 실행됩니다. Intel용 ELF32 빌드와 ARM용 ELF32 빌드는 클래스 필드에서는 일치하지만 중요한 모든 것에서 다릅니다. 32비트 옵션을 제공하는 다운로드 페이지는 실제로 내려받은 파일의 헤더를 읽기 전까지 거의 아무것도 알려 주지 않습니다. 이름을 바꿔도 명령어 하나 바뀌지 않습니다.

클래스와 머신은 서로 다른 질문에 답한다

클래스 필드는 파일이 32비트 구조를 쓰는지 64비트 구조를 쓰는지 알려 줍니다. 머신 필드는 파일이 컴파일된 명령어 집합을 지칭합니다. 첫 번째만 읽는 것이 바로 그럴듯해 보이는 파일 이름을 가진 x86 빌드가 ARM 보드에 설치되는 경로입니다. 두 값 모두 같은 명령에서 나오므로 하나를 건너뛰기 너무 쉽습니다.

같은 혼동은 64비트 표기에도 적용됩니다. aarch64와 x86-64는 워드 크기만 공유하고 명령어는 하나도 공유하지 않습니다. 64비트 다운로드 하나를 나열한 벤더 페이지는 벤더 자신의 빌드를 설명할 뿐, 당신의 머신을 설명하지 않습니다. 페이지의 열 제목이 아니라 파일의 헤더를 확인하세요.

readelf -h ./vendor-vpn
readelf -l ./vendor-vpn | head -20
file ./vendor-vpn

첫 번째 명령은 클래스와 머신을 포함한 헤더를 출력합니다. 두 번째는 인터프리터 요청이 들어 있는 프로그램 헤더를 보여 줍니다. 세 번째는 표가 필요 이상으로 많을 때 한 줄로 정리해 줍니다.

실행 권한을 추가하거나 배포판 검사를 패치해도 아무것도 변환되지 않습니다. 에뮬레이션은 플랫폼이 지원하는 경우 배포 결정이며, 나름의 성능과 의존성 비용이 따릅니다.

설치 프로그램을 실행하기 전에 헤더를 읽으세요

신뢰할 수 있는 산출물에서 무엇이든 실행하기 전에 먼저 검사하세요. 중간에 실패한 설치 프로그램은 라이브러리를 바꿔 놓고 아무것도 동작하지 않는 상태를 남길 수 있으며, 처음 받은 아카이브보다 더 나쁜 출발점입니다. 헤더 검사는 읽기 전용이며 시스템에서 아무것도 바뀌지 않는다는 점에서 되돌릴 수 있습니다.

머신 필드는 보드의 마케팅 이름이 아니라 실행 중인 시스템의 패키지 아키텍처와 비교하세요. 32비트 사용자 공간을 돌리는 64비트 CPU에는 32비트 빌드가 필요하며, 이 세부 사항이 어느 다운로드가 네이티브인지 결정합니다. 제약은 보드 성능이 아니라 설치된 사용자 공간입니다.

dpkg --print-architecture
uname -m
getconf LONG_BIT

첫 번째 명령은 시스템이 어느 아키텍처용으로 패키지를 설치하는지 알려 주며, 바로 이 값이 일치해야 합니다. 나머지 두 명령은 커널과 워드 크기를 설명하며, 멀티아키텍처 설치에서는 사용자 공간과 어긋날 수 있습니다.

그 답이 어긋나면 다른 아카이브를 내려받기 전에 벤더가 어느 쪽을 지원하는지 결정하세요. 추측은 각기 다른 지점에서 실패하는 설치의 반복을 낳고, 모든 실패가 새로운 문제처럼 보입니다.

아키텍처만이 아니라 인터프리터를 확인하세요

동적 실행 파일은 기대하는 로더를 프로그램 헤더에 기록합니다. 로더 경로가 다른 시스템에서는 머신 필드가 정확히 일치해도 커널이 파일 실행을 거부합니다. 바로 이 실패 때문에 사람들이 없는 라이브러리를 찾아 나섭니다.

오류 메시지는 어느 경우인지 알려 주지만 두 경우는 혼동하기 쉽습니다. 형식이나 아키텍처 거부는 파일이나 인터프리터가 없는 것과 다릅니다, 그리고 다른 패키지를 설치해서 고쳐지는 것은 둘 중 하나뿐입니다.

readelf -l ./vendor-vpn | grep -A1 INTERP
ls -l /lib64/ld-linux-x86-64.so.2

첫 번째 명령은 바이너리가 요구하는 인터프리터 경로를 보여 줍니다. 두 번째는 그 경로가 존재하는지 확인하며, 잘못된 빌드와 없는 로더를 구분합니다.

신뢰할 수 없는 바이너리에 의존성 목록 도구를 실행하지 마세요. 일부 구현은 검사하는 파일을 실행할 수 있습니다. 검사는 읽기 전용으로 유지하고, 지원되지 않는 빌드를 실행하려고 로더 심볼릭 링크를 추가하는 유혹을 참으세요.

사실을 손에 쥐고 빌드를 요청하세요

벤더에게 OS 릴리스, 패키지 아키텍처, 클래스와 머신 값, 첫 오류 메시지를 보내세요. 그 조합은 쓸모 있는 답을 얻지만, 일반적인 실패의 스크린샷은 지원 템플릿만 받습니다.

바이너리 질문은 구성 질문과 분리하세요. 올바른 빌드가 실행된 뒤에도 프로필, 자격 증명, 경로는 여전히 각자의 문제이며, 프로필을 아무리 편집해도 아키텍처가 잘못된 바이너리는 실행되지 않습니다.