“SOCKS를 통한 APT”에 관한 오래된 답변은 종종 래퍼나 HTTP-to-SOCKS 릴레이를 권합니다. 그런 답변은 구버전의 실제 한계를 설명할 수 있습니다. 그러나 socks5h 지원을 문서화한 APT 버전에서는 그것이 유일한 선택지가 아닙니다.

구성 조각은 기존 acquisition transport 키를 사용할 수 있습니다:

Acquire::http::Proxy "socks5h://127.0.0.1:1080/";
Acquire::https::Proxy "socks5h://127.0.0.1:1080/";

이 예제는 같은 머신에 이미 승인된 SOCKS5 리스너가 있다고 가정합니다. 리스너를 시작하지는 않습니다. SSH 동적 포워딩은 그러한 로컬 리스너를 만드는 한 가지 방법입니다. 프록시가 원격이라면 대신 실제로 도달 가능한 엔드포인트를 사용하세요. SOCKS5 프록시 목록의 후보는 저장소 요청에 공용 프록시가 허용되는 경우에만 적용됩니다.

스킴은 지시의 일부입니다

APT 전송 매뉴얼은 원격 DNS 확인을 사용하는 SOCKS5에 대해 socks5h를 나열합니다. 설치된 버전에 대해서는 문서화된 스킴을 사용하고, 다른 프로그램이 우연히 받아들이는 레이블로 줄이지 마세요.

마찬가지로 오래된 포럼 스니펫의 Acquire::socks::Proxy는 HTTP acquisition 방식이 그 설정을 읽는다는 증거가 아닙니다. 구성 파서는 키를 받아들여도 다운로드 방식이 그것을 사용하지 않을 수 있습니다.

로컬 주소에는 경계가 있습니다

APT가 컨테이너나 가상 머신 안에서 실행될 때 127.0.0.1는 그 환경을 가리킵니다. 호스트의 SOCKS 리스너는 다른 엔드포인트입니다. 거부된 로컬 연결을 진단하기 전에 APT가 어디서 실행되는지 확인하세요.

SOCKS 지원은 저장소 서명이나 HTTPS 인증서 검사도 제거하지 않습니다. 그 보호를 활성 상태로 유지하세요. 설치된 APT에 문서화된 기능이 없다면 알 수 없는 URI 스킴을 비밀번호 문제로 다루지 말고 승인된 대안이나 업데이트 경로를 선택하세요.

관련 글