당신의 VPN 게이트웨이에는 여전히 업데이트를 설치할 길이 필요하다

터널은 그 뒤에 있는 모든 이에게 동작하고, 게이트웨이는 그들의 트래픽을 전달하는데도 정작 기계 자신은 보안 업데이트를 설치하지 못한다. 이것이 이 문제의 흔한 모습이다. 전달 권한은 클라이언트에 주어졌고, 게이트웨이 자신의 아웃바운드 연결은 계획에 포함되지 않았다. 패키지 관리자는 게이트웨이에서 자기 소켓을 열어, 방화벽 정책 어디에도 이름을 적지 않았을 법한 저장소로 향한다.

게이트웨이를 잠그는 것은 옳다. 패치를 받지 못할 만큼 빡빡하게 잠그는 것은 다른 결정이며, 대개 의도하지 않은 결정이다.

로컬 출력은 클라이언트 전달이 아니다

전달 규칙은 다른 곳에서 도착해 게이트웨이를 통해 나가는 패킷을 다룬다. 게이트웨이 자신의 업데이트 트래픽은 그 규칙에 결코 해당하지 않는다. 로컬에서 생성되어 출력 경로를 지나기 때문이다. 이 차이가 클라이언트 접근이 완벽하게 동작하는 동안 불가능해 보이는 장애를 설명한다.

시험을 통과해 버리는 정책상의 틈도 설명한다. 터널 뒤 노트북에서의 빠른 확인은 전달 체인이 동작한다는 것만 증명하고 호스트 자신의 연결에 대해서는 아무 말도 하지 않는다. 게이트웨이를 두 주체로 보라. 전달 체인을 가진 라우터와 출력 체인을 가진 호스트다. 둘 다 방침이 필요하지만 보통 하나만 적힌다.

실패한 단계를 지목하라

업데이트 오류는 서로 다른 경계를 가리킨다. 어느 것이 실패했는지 읽기도 전에 포트 규칙부터 움켜쥐면 오후 하나를 날린다. 풀리지 않는 저장소 이름은 리졸버의 문제이지 전송의 문제가 아니다.

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

성공적인 조회 뒤의 시간 초과는 질문을 전송으로 옮긴다. 패키지 관리자가 실제로 시도한 주소, 포트, 설정된 프록시가 무엇인지다. TLS 검증 실패는 세 번째로 전혀 다른 사안이며, 연결이 협상할 만큼은 동작했다는 뜻이다. 아카이브 인증에 대한 불만은 네 번째 단계다. 도달 가능성이 아니라 서명된 메타데이터에 관한 것이다. 네 단계, 네 가지 다른 수리, 그리고 ping은 어느 패키지 관리자도 쓰지 않는 한 가지 프로토콜만 설명한다.

규칙을 더하기 전에 소스 목록을 읽어라

기억나는 것이 아니라 실제 소스 URI와 유효한 프록시 설정을 나열하라. 소스가 HTTPS인데 평문 HTTP용 규칙을 써 봐야 소용없고, 셸이 아는 프록시는 다른 환경으로 부팅 시 시작된 서비스에는 보이지 않을 수 있다.

APT의 HTTP 전송 문서 는 환경 및 APT 고유의 프록시 설정을 다루며 호스트별 선택도 포함한다. 그 HTTPS 전송에는 자체 검증 설정이 있다. 브라우저가 지나는 길과 패키지 관리자가 지나는 길은 같은 기계에서도 서로 다른 길이다.

소스가 어느 주소 패밀리로 해석되는지 보라. IPv4만 허용하는 규칙은 소스가 AAAA 레코드를 선호하는 호스트에서 계속 실패하며, 어느 응답이 먼저 도착하느냐에 달려 있어 오류가 간헐적으로 보인다.

유지보수 경로를 하나 고르고 그것을 지켜라

변호할 수 있는 선택지는 셋이다. 터널을 통한 유지보수 트래픽, 관리되는 업데이트 프록시, 또는 좁은 직접 예외다. 의도적으로 하나를 고르고 리졸버를 그에 맞춰라. 이름은 한쪽으로 해석되고 연결은 다른 쪽으로 가는 분리는 아무도 설명할 수 없는 장애를 만든다.

무엇을 고르든 무제한의 대비책이 되어서는 안 된다. 터널이 내려갔을 때 직접 아웃바운드 트래픽이 금지되어 있다면, 조용히 모든 것을 허용하는 유지보수 예외는 수리를 가장한 정책 변경이다. 터널 자체의 종단점과 부트스트랩 요구는 저장소 접근과 다른 범주에 두어라. 목적지가 다르고 실패 방식도 다르므로 하나의 예외가 다른 하나를 덮을 수 없다.

검증을 약화시키지 않고 확인하라

이미 정책을 가진 방화벽을 통해 범위를 적용하라. 어떤 안내서가 썼다는 이유로 두 번째 관리자를 더하지 말라. 그다음 유지되는 정책 아래에서 메타데이터 새로 고침과 실제 패키지 거래를 한 번 실행하고, 종료 상태만이 아니라 출력을 읽어라.

성공한 전송은 검증을 느슨하게 할 허가가 아니다. 아카이브 인증과 TLS 서버의 신원은 별개의 보증이며, 오류를 잠재우려고 둘 중 하나를 끄는 것은 무엇을 신뢰하는지를 바꾸는 것이지 무엇에 닿을 수 있는지를 바꾸는 것이 아니다.

마지막으로 터널이 없는 경우를 의도적으로 시험하라. 터널 없이 게이트웨이가 어떻게 행동하는지 아는 것은 설계의 일부이고, 장애 중에 그것을 알아내는 것은 아니다. 터널을 내리고 메타데이터 새로 고침을 실행해, 호스트가 의도한 방식으로 실패하는지 확인하라. 조용히 열린 경로로 되돌아가서는 안 된다. 저장소와 프록시 자격 증명은 공유 진단에서 빼고, 업데이트 경로의 주인이 누구인지 적은 메모를 남겨라.