오프라인 VPN 패키지: 대상에게 무엇이 필요한지 물어라

VPN 클라이언트가 필요한 이유는 보통 자신의 패키지를 공급해 줄 네트워크에 도달하기 위해서이며, 이것은 잘 정돈된 작은 순환입니다. 다른 기계에서 OpenVPN DEB 하나를 내려받으면 대개 두 번째 빠진 의존성으로 끝나고, 그다음 세 번째, 그다음 라이브러리 버전을 쫓으며 저녁 하나가 지나갑니다. 대안은 연결되지 않은 기계가 자기 언어로 자기 패키지 관리자에게 무엇이 필요한지 말하게 하는 것입니다. 아래의 모든 것은 누가 묻는가라는 이 뒤집기에서 나옵니다.

Debian 계열 시스템에서는 그 대화가 apt-offline을 통해 이루어지며, 요청과 반환의 작업 흐름입니다. 그것의 실행 환경은 먼저 대상에 있어야 하며, 승인된 매체나 관리자가 통제하는 다른 부트스트랩에서 설치되어야 합니다. 어떤 도구도 무에서 스스로를 부팅할 수 없기 때문입니다.

도우미의 상태가 아니라 대상의 패키지 상태에서 시작하십시오

무엇보다 먼저 대상의 배포판 릴리스, 사용자 공간 아키텍처, 구성된 패키지 소스를 기록하십시오. 이 세 가지 사실이 어떤 VPN 구현과 어떤 데스크톱 통합이 적절한지를 결정하며, 연결된 도우미가 제공할 수 없는 사실이기도 합니다.

도우미는 파일을 내려받을 뿐 의존성의 기준선이 되지 않습니다. OpenVPN이 이미 설치된 더 새로운 노트북은 대상과 전혀 다른 패키지 상태를 가지므로, 그 성공은 대상이 무엇을 받아들일 수 있는지 아무것도 증명하지 않습니다.

실제로 무엇을 원하는지도 정하십시오. VPN 엔진, NetworkManager 서비스 플러그인, 그래픽 편집기는 별개의 패키지이며, 올바른 선택은 릴리스와 사용자가 연결을 어떻게 관리할지에 달려 있습니다. 화면 없는 서버에는 엔진과 구성 파일이 필요하고, 데스크톱에는 네트워크 설정이 터널을 소유하도록 해 주는 플러그인이 필요합니다. 잘못된 집합을 요청하면 성공하는 설치와 아무도 시작할 수 없는 연결이 생깁니다.

두 번의 왕복, 이 순서로

설명서는 세 가지 작업을 구분합니다. 연결되지 않은 시스템에서 요청을 만들고, 연결된 도우미에서 내려받고, 대상으로 다시 가져오는 것입니다. 패키지를 요청하기 전에 대상의 저장소 메타데이터를 새로 고치십시오. 패키지 요청은 그 메타데이터로 만들어지며 오래된 인덱스는 도우미가 채울 수 없는 요청을 낳기 때문입니다.

대상에서 apt-offline set vpn-meta.sig --update 형태의 관리자 명령이 새로 고침 요청을 기록합니다. 그 파일을 연결된 기계로 가져가 apt-offline get vpn-meta.sig --bundle vpn-meta.zip로 묶음을 내려받으십시오. 묶음을 다시 가져와 apt-offline install vpn-meta.zip로 대상에 들여오십시오. 역시 관리자로서 수행합니다.

이제 새로 고친 메타데이터로 패키지 요청을 만드십시오. 예를 들어 apt-offline set vpn-deps.sig --install-packages openvpn이며, 새 묶음 이름으로 왕복을 반복합니다. 각 요청은 그것이 만든 묶음과 짝을 지어 보관하십시오. 더 오래된 메타데이터에 대해 만들어진 묶음은 파일 이름이 서로 바꿔 쓸 수 있어 보여도 같은 요청이 아닙니다.

통합 패키지는 설계가 필요로 할 때만 추가하십시오

데스크톱이 네트워크 설정을 통해 터널을 관리해야 한다면, 요청에는 엔진뿐 아니라 그에 맞는 플러그인도 필요합니다. 다른 배포판에서 기억한 목록 대신 해당 릴리스가 제공하는 구체적인 패키지 이름을 넣고, 목록이 바뀔 때마다 새 요청을 만드십시오. 버전 고정도 생각해 볼 일입니다. 더 새로운 릴리스용으로 빌드된 패키지는 이름을 만족시키면서도 실행 시점에 실패할 수 있습니다. 바로 여기에서 네 개 패키지의 고정된 집합이 부담이 됩니다. 올바른 목록은 대상의 속성이며 대상만이 그것을 계산할 수 있기 때문입니다.

여기에서도 네 개 패키지의 고정된 집합이 부담이 됩니다. 올바른 목록은 대상의 속성이고, 대상은 그것을 올바르게 계산할 수 있는 유일한 기계입니다.

묶음을 가져오는 것은 VPN을 설치하는 것이 아닙니다

이름과 달리 설치 작업은 APT 데이터를 패키지 관리 환경에 넣을 뿐입니다. 패키지 트랜잭션을 수행하지 않습니다. 로컬에서 제공된 데이터로 대상의 실제 APT 설치를 완료하고 검토하며, ZIP의 성공이 소프트웨어의 존재를 뜻한다고 가정하지 말고 출력을 읽으십시오.

그 트랜잭션이 여전히 사용할 수 없는 파일을 요구한다면, 구체적으로 빠진 의존성이나 저장소 오류를 남기고 그것으로 다음 요청을 만드십시오. 다른 릴리스의 DEB로 바꾸지 말고, 억지로 통과시키기 위해 체크섬이나 저장소 인증 검사를 끄지 마십시오. 설명서는 내려받은 파일의 검증을 건너뛰지 말라고 분명히 경고하며, 그럴 만합니다. 검증되지 않은 패키지는 실패한 설치보다 나쁜 결과입니다.

패키지는 첫 번째 절반일 뿐

소프트웨어 설치는 승인된 엔드포인트, 프로필, 신뢰 자료, 자격 증명을 확보하는 것과 별개이며, 각각은 자체적인 통제된 전달 절차를 가질 수 있습니다. 유효한 프로필이 없는 작동하는 패키지 집합은 어디에도 연결되지 않습니다.

그다음 향후 업데이트를 위해 오프라인 전송 경로를 살려 두십시오. 첫 성공적인 연결을 유지 보수의 끝으로 여기면 다음 보안 업데이트는 차를 가진 누군가가 올 때까지 기다리게 되며, 그렇게 오프라인 네트워크는 조용히 몇 년씩 뒤처집니다.