그 오래된 openfortivpn .deb 파일이 당신의 Raspberry Pi에 맞을까요?

포럼 답변이 완전한 파일 이름을 건네고, 그 이름은 해결책처럼 보입니다. .deb 하나, 명령 하나, 끝입니다. 그 문자열이 실제로 인코딩하는 것은 패키지 버전, CPU 아키텍처, 그리고 누군가 글을 쓴 날 그것을 빌드한 배포판 스위트입니다. 이 세 가지 중 어느 것도 당신 책상 위의 보드를 자동으로 설명하지 않습니다. 오래된 다운로드는 한 기기의 상황을 찍은 스냅숏이지, 당신을 위한 설치 계획이 아닙니다.

파일 이름이 조용히 고정하는 것

openfortivpn_1.17.0-1_armhf.deb 같은 이름을 오른쪽에서 왼쪽으로 읽어 보세요. 접미사는 바이너리가 컴파일된 아키텍처이고, 가운데 필드는 업스트림과 패키징 리비전이며, 암묵적인 네 번째 필드는 그것이 빌드된 스위트의 라이브러리 집합입니다.

64비트 Raspberry Pi OS 설치에서 시스템 아키텍처는 arm64이므로 dpkg -i는 아키텍처 불일치로 armhf 패키지를 거부합니다. multiarch가 설치를 가능하게 하는 경우에도 바이너리는 빌드 당시 릴리스의 라이브러리 버전을 기대하며, 더 새로운 기본 시스템은 그것을 더 이상 제공하지 않을 수 있습니다. 결과는 실행 파일이 시작되지 않는 설치된 패키지이고, 이것이 사람들이 보통 클라이언트 자체가 고장 났다고 잘못 해석하는 실패입니다.

보드가 ARM 기기라고 해서 ARM 패키지가 적절해지는 것은 아닙니다. 아키텍처는 하나의 축이고, 릴리스와 ABI는 나머지 두 축이며, 그것들은 각각 독립적으로 실패합니다.

다운로드 링크를 묻기 전에 배포판에 물으세요

유지되는 모든 채널은 지금 무엇을 설치할지 알려 줄 수 있습니다. 어떤 파일 전송도 고려하기 전에 대상 기기에서 실제로 사용하는 저장소로 질의를 실행하세요.

cat /etc/os-release
dpkg --print-architecture
apt-cache policy openfortivpn

버전과 저장소 이름이 있는 후보 줄은 배포판이 이 시스템을 위한 빌드를 이미 가지고 있다는 뜻입니다. 후보가 없거나, 사용할 생각이 없던 스위트의 후보라면, 소프트웨어가 어딘가에 존재하는지가 아니라 당신의 소스에 관한 정보입니다.

메타데이터 새로 고침이 실패하면 그 실패를 패키지 문제와 분리해 두세요. 이름 해석, 저장소 전송, 빠진 Release 서명, 수명이 끝난 스위트는 모두 클라이언트가 관여하기 전에 apt update를 깨뜨립니다. 소스를 고치는 것은 VPN 클라이언트를 고르는 것과 다른 작업이고, 둘을 섞는 것이 사람들이 현재 시스템을 낡은 릴리스로 향하게 되는 방식입니다.

apt가 검증하는 것과 내려받은 파일이 얻지 못하는 것

정상적인 설치는 서명 사슬을 따릅니다. 아카이브가 자신의 인덱스에 서명하고, 인덱스는 각 패키지의 해시를 담고, 패키지는 일치해야 합니다. 아카이브 인증 참조는 그 사슬을 각 개별 파일에 첨부된 서명을 확인한다는 발상과 분리합니다.

오래된 HTTP 링크에서 저장한 파일에는 그중 아무것도 없습니다. 저장소 신원 없이 도착하고, 배포판이 클라이언트를 패치해도 업데이트되지 않으며, 누가 그것을 교체할 책임이 있는지 기록하는 것도 없습니다. 고정된 산출물을 가진 관리자에게는 여전히 정당한 선택일 수 있지만, 그 선택에는 소유자, 어딘가에 기록된 체크섬, 다음 보안 업데이트를 위한 계획이 따라와야 합니다.

오래된 지침이 계속 돌아가게 하려고 서명 오류를 억제하거나 TLS 검증을 끄는 것은 무언가를 검사하던 유일한 부분을 없애는 일입니다. 대신 실패하는 검사를 복원하세요.

클라이언트를 설치한 다음 연결은 따로 디버그하세요

유지되는 후보가 있으면 정상적인 검토된 트랜잭션으로 설치하고 패키지 관리자가 무엇을 했는지 기록하게 두세요.

배포가 정말로 업스트림 빌드를 필요로 한다면 프로젝트의 현재 빌드 지침을 따르고, 이제 당신이 유지하는 소프트웨어로 다루세요. 개발 패키지, pkg-config, TLS 라이브러리 헤더, PPP 데몬은 실제 의존성이고, 나중에 필요할 제거 절차도 마찬가지입니다.

설치는 로컬 소프트웨어 단계일 뿐입니다. 게이트웨이는 클라이언트의 프로토콜과 인증 흐름을 받아들여야 하고, 클라이언트는 게이트웨이가 제시하는 인증서를 신뢰해야 하며, 터널에는 동작하는 PPP 계층과 경로, 리졸버 소유자가 필요합니다. 완료된 패키지 트랜잭션은 게이트웨이가 계정을 받아들이는지, 사설 범위에 도달할 수 있는지를 아무것도 증명하지 않습니다. 설치 프로그램을 다시 실행하는 대신 깨지는 지점에서 각 계층을 시험하세요.

오래된 파일 이름을 대신할 계획

먼저 플랫폼 정체성을 적으세요. OS 릴리스, 아키텍처, 사용 중인 소스 목록입니다. 그다음 패키지가 오는 승인된 위치를 지목하세요. 배포판 저장소든, 키가 고정된 공급업체 저장소든, 직접 컴파일하고 패키징하는 빌드든 마찬가지입니다.

마지막으로 유지 관리자와 업데이트 경로를 지목하세요. 아무도 소유하지 않는 클라이언트를 돌리는 Pi는 첫 라이브러리 업데이트까지 계속 동작하고, 그다음 같은 문제를 가진 누군가가 같은 포럼 스레드를 다시 찾게 될 것입니다.

바로잡은 믿음은 한 줄로 말할 만큼 단순합니다. 오래된 패키지는 클라이언트가 언젠가 빌드되어 동작했다는 증거이지, 오늘 밤 당신의 보드에 설치된다는 증거가 아닙니다. 세 축을 확인하고, 그다음 계속 업데이트할 수 있는 채널을 고르세요.