웹사이트는 VPN으로 열리는데 apt는 저장소에 닿지 않는다

VPN은 연결되고 내부 위키는 브라우저에서 열리는데 apt update 은 여전히 닿지 못하는 미러에서 멈춰 있다. 그 그림에서 터널은 아무것도 망가지지 않았다. 브라우저와 패키지 관리자는 서로 다른 두 가지 프록시 결정을 내렸고, 그중 하나만 설정되어 있었다.

어느 결정이 실패했는지가 가장 먼저 확정할 가치가 있는 유일한 것이다.

설정을 건드리기 전에 오류를 읽어라

단계마다 남는 메시지가 다르다. 끝내 해석되지 않는 이름은 DNS, 끝내 완료되지 않는 연결은 라우팅이나 방화벽, 즉시 돌아오는 407은 프록시 인증, 인증서에 대한 불평은 TLS 검증, 서명 경고는 저장소 메타데이터다. 이 다섯 가지 고장에는 다섯 가지 다른 처방이 필요하고, DNS 문제 위에 덧붙인 프록시 한 줄은 멈춤을 옮길 뿐이다.

무엇이든 바꾸기 전에 그 정확한 줄과 그것이 지목한 저장소를 복사해 둬라. „시간 초과가 났다“는 흐릿한 기억이 십 분짜리 진단을 반나절로 만든다.

APT는 자체 프록시 설정을 가진다

APT는 /etc/apt/apt.conf.d/, 기본 apt.conf, 그리고 APT_CONFIG 이 가리키는 모든 파일을 읽는다. 데스크톱 프록시 프로필이나 GNOME 네트워크 설정, 브라우저 확장은 읽지 않는다. 반면 전송 계층은 프록시 환경 변수를 존중한다. 그래서 셸에서 동작하는 export https_proxy=... 은 다른 환경에서 도는 타이머에 대해 아무것도 증명하지 못한다.

실패하는 프로세스가 실제로 보는 내용을 덤프하라: apt-config dump | grep -i proxy.

실패하는 작업이 도는 사용자로 실행하라. root가 다른 파일 집합을 읽거나 systemd 타이머가 다른 환경으로 시작하면 덤프가 달라지고, 그 차이가 답이다. 서로 어긋나는 두 프록시 값은 하나가 빠진 것보다 나쁘다. 전송 계층은 찾을 수 있는 가장 구체적인 일치를 따르기 때문이다.

구성의 주인이 기대하는 자리에 프록시를 두라

관리자가 승인한 명시적 프록시라면 새 파일에 작은 조각이면 충분하다:

Acquire::http::Proxy "http://proxy.corp.example:3128/";
Acquire::https::Proxy "http://proxy.corp.example:3128/";
Acquire::http::Proxy::archive.example.internal "DIRECT";

셋째 줄은 대부분의 예제가 빼먹는 부분이다. 호스트별 키가 일반 값을 덮어쓰므로, 터널로 닿는 내부 미러는 프록시를 건너뛸 수 있고 나머지는 여전히 프록시를 지난다. DIRECT 은 이를 위해 문서화된 값이며 빈 문자열이 아니다.

조각을 /etc/apt/apt.conf.d/95proxy 처럼 새 번호 파일로 추가하라. 배포판 파일을 덮어쓰면 다음 패키지 업데이트가 변경을 조용히 되돌린다.

자격 증명은 URI 밖에 둔다

APT 전송 계층 참조 문서는 인증에 대해 apt_auth.conf 을 가리키며, 사용자 이름과 비밀번호가 바로 거기 들어간다. 프록시 URI에 넣으면 프로세스 목록, 셸 기록, 티켓에 붙여 넣는 모든 구성 덤프에 남는다. 인증 파일은 엄격한 권한이 필요하다. 자격 증명 저장소이기 때문이다.

스킴도 확인하라. HTTPS 저장소도 HTTP 프록시를 통해 닿을 수 있다. 전송 계층은 미러의 URI 스킴과 별개 선택이다.

그래픽 소프트웨어 센터는 별도의 프런트엔드다. PackageKit이나 snap 백엔드를 쓴다면 APT 조각은 그것에 아무 영향이 없으니, 실패한 요청을 어느 프로세스가 보냈는지 확인하라.

경로를 확인하라, 종료 코드만이 아니라

조각이 자리 잡으면 초록 결과를 믿는 대신 요청을 관찰하라. apt-get -o Debug::Acquire::http=true update 은 연결 시도, 고른 프록시, 응답 코드를 출력하므로 잘못된 프록시와 너를 거부한 프록시를 갈라 준다.

다음으로 동작해서는 안 되는 경우를 시험하라. VPN을 끊고 내부 미러가 응답을 멈추는지 확인하라. 그래도 내려받는다면 무언가가 터널을 우회해 라우팅하거나 오래된 캐시가 응답하는 것이다. 허용된 경로가 여전히 TLS를 검증하고 여전히 저장소 서명을 확인하는지도 확인하라. 트래픽을 들여다보는 프록시는 둘 중 하나를 끌 이유가 아니다. 인증되지 않은 클라이언트가 조용한 시간 초과 대신 분명한 거부를 받는지도 확인하라.

동작하는 조각과 실패한 출력을 변경 기록에 함께 남겨라. 같은 멈춤을 만난 다음 사람은 어떤 설명보다 빨리 두 줄의 차이를 알아볼 것이다.