터미널 다운로드는 되는데 VPN에서는 VS Code 확장이 실패한다

컨테이너 터미널에서 성공하는 다운로드는 그 터미널의 환경에 대한 실제 증거입니다. 편집기 프로세스, 확장 설치 프로그램, 확장이 나중에 가져오는 바이너리에 대해서는 아무것도 말하지 않습니다. 그 세 가지 사이에서 프록시 변수를 복사하는 것은 실패한 요청 하나를 무관한 편집으로 가득한 오후로 바꿉니다.

두 환경은 보통 정확히 한 가지 점에서 다릅니다. 그 점을 찾는 것이 프록시 문서를 두 번 읽는 것보다 빠릅니다.

실패한 요청을 보낸 프로세스

한 번의 설치에서 세 개의 요청이 실패할 수 있고, 각각 고유한 네트워크 정체성을 가집니다. 편집기는 Marketplace에 메타데이터와 패키지 URL을 요청한 뒤 패키지를 내려받습니다. 그 다음에야 확장 호스트가 언어 서버나 자체 바이너리를 가져올 수 있는 코드를 실행합니다. 어느 단계가 깨졌는지가 어느 프로세스에 프록시가 필요한지를 결정하며, 오류 표면은 그 단계를 거의 지목하지 않습니다.

작동하는 터미널은 컨테이너가 인터넷에 닿을 수 있음을 증명할 뿐, 편집기가 그럴 수 있음을 증명하지 않습니다. 확장 로그에서 마지막으로 시도한 URL을 읽으십시오. 거기에 적힌 호스트가 프로세스와 그에 적용되는 정책을 식별합니다.

로컬 편집기와 원격 컨테이너는 두 개의 환경이다

원격 작업 공간에서 확장은 그 유형이 선언하는 쪽에서 실행됩니다. 인터페이스 확장은 로컬 편집기에 남고, 작업 공간 확장은 컨테이너에서 실행됩니다. 한쪽에 설정한 프록시는 다른 쪽에 보이지 않으며, 재빌드는 컨테이너 환경을 구성 파일에서 다시 만들지, 셸에서 내보낸 것에서 만들지 않습니다. 이 분리가 같은 확장이 노트북에서는 설치되고 같은 프로젝트에서 SSH를 거치면 실패하는 이유를 설명합니다.

무엇이든 편집하기 전에 설치 위치를 읽으십시오. 로그가 원격 설치를 보고하면 컨테이너 환경이 중요한 쪽입니다.

요청이 시작되는 곳에 프록시를 두라

정말로 HTTP 프록시가 필요한 Dev Container라면 변수는 컨테이너 구성에 있어야 재빌드에서도 재현됩니다. 아래 조각은 그 환경에 대해 설정합니다. 자리 표시자 주소는 여러분의 게이트웨이를 대신하며, 제외 항목은 선택적 채우기가 아닙니다.

"containerEnv": {
  "HTTP_PROXY": "http://proxy.corp.example:8080",
  "HTTPS_PROXY": "http://proxy.corp.example:8080",
  "NO_PROXY": "localhost,127.0.0.1,.internal.example"
}

변수 이름은 목적지 프로토콜을 설명하므로 HTTPS_PROXY 값이 http로 시작하는 것도 정당하며, 지원되는 재빌드 경로로 변경을 적용하고 제외 항목을 유지하십시오. 내부 호스트를 가로채는 프록시는 컨테이너에 필요한 서비스를 깨뜨립니다.

신뢰 실패와 도달 가능성을 분리하라

연결한 뒤 인증서 검증 오류를 반환하는 프록시는 연결을 거부하는 프록시보다 더 뒤 단계에 도달한 것입니다. 첫 번째 실패에는 요청을 수행하는 환경에 조직의 승인된 신뢰 자료가 설치되어 있어야 합니다. 두 번째에는 도달 가능한 주소와 포트가 필요합니다. 둘을 하나의 문제로 다루면 어느 쪽에도 통하지 않는 수정이 나옵니다.

검증을 끄거나 편집기를 높은 권한으로 실행하는 것은 프록시 부재나 신뢰 체인 부재에 대한 수리가 아닙니다. 둘 다 보이는 오류를 조용한 오류로 바꿉니다. 그런 다음 같은 확장을 다시 시도하고 다음으로 실패하는 URL을 기록하십시오.

env | grep -iE '^(http|https|no)_proxy='
code --install-extension ms-python.python --force

작업 공간의 어느 쪽이 그 URL을 만들었는지 기록하십시오: 단계, 호스트, 쪽을 적은 짧은 메모는 누군가 바꾼 설정 목록보다 값어치가 있습니다. 다음 사람이 재현할 수 있는 것은 바로 그 메모이기 때문입니다.