Pobieranie w terminalu działa, ale rozszerzenia VS Code zawodzą przez VPN

curl działa w kontenerze, a rozszerzenie nadal się nie instaluje. Porównaj lokalny edytor i środowisko zdalne, zanim skopiujesz ustawienia serwera proxy.

Pobrania, które kończą się sukcesem w terminalu kontenera, są realnym dowodem na temat środowiska tego terminala. Nie mówią nic o procesie edytora, instalatorze rozszerzeń ani pliku binarnego, który rozszerzenie pobiera później. Kopiowanie zmiennych proxy między tymi trzema zamienia jedno nieudane żądanie w całe popołudnie niepowiązanych zmian.

Dwa środowiska zwykle różnią się dokładnie w jednym aspekcie. Znalezienie tego aspektu jest szybsze niż dwukrotne czytanie dokumentacji proxy.

Który proces wysłał nieudane żądanie

Podczas jednej instalacji mogą zawieść trzy żądania, a każde ma własną tożsamość sieciową. Edytor pyta Marketplace o metadane i URL pakietu, a następnie pobiera pakiet. Dopiero potem host rozszerzeń uruchamia kod, który może pobrać serwer języka lub własny plik binarny. To, który etap się zepsuł, decyduje o tym, który proces potrzebuje proxy, a interfejs błędu rzadko nazywa ten etap.

Działający terminal dowodzi, że kontener może dotrzeć do internetu, a nie że edytor może. Przeczytaj w dzienniku rozszerzenia ostatni URL, którego próbowało. Nazwany tam host wskazuje proces i politykę, która go dotyczy.

Lokalny edytor i zdalny kontener to dwa środowiska

W zdalnym obszarze roboczym rozszerzenie działa po stronie deklarowanej przez swój typ. Rozszerzenia interfejsu pozostają przy lokalnym edytorze, a rozszerzenia obszaru roboczego działają w kontenerze. Proxy ustawione w jednym jest niewidoczne dla drugiego, a przebudowa odtwarza środowisko kontenera z jego pliku konfiguracyjnego, a nie z tego, co wyeksportowano w powłoce. Ten podział wyjaśnia, dlaczego to samo rozszerzenie instaluje się na laptopie i zawodzi w tym samym projekcie przez SSH.

Przeczytaj lokalizację instalacji, zanim cokolwiek zmienisz. Gdy dziennik zgłasza instalację zdalną, liczy się środowisko kontenera.

Umieść proxy tam, gdzie zaczyna się żądanie

Dla Dev Container, który naprawdę potrzebuje proxy HTTP, zmienna należy do konfiguracji kontenera, aby przebudowa ją odtworzyła. Poniższy fragment ustawia ją dla tego środowiska. Adres zastępczy oznacza Twoją własną bramę, a wyjątki nie są opcjonalnym wypełnieniem.

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

Nazwa zmiennej opisuje protokół docelowy, więc wartość HTTPS_PROXY może legalnie zaczynać się od http. Zastosuj zmianę obsługiwaną ścieżką przebudowy i zachowaj wyjątki, ponieważ proxy przechwytujące wewnętrzne hosty psuje usługi potrzebne kontenerowi.

Oddziel błędy zaufania od osiągalności

Proxy, które łączy się i zwraca błąd weryfikacji certyfikatu, osiągnęło późniejszy etap niż to, które odrzuca połączenie. Pierwszy błąd wymaga zatwierdzonego przez organizację materiału zaufania zainstalowanego w środowisku wykonującym żądanie. Drugi wymaga osiągalnego adresu i portu. Traktowanie ich jako jednego problemu daje poprawkę, która nie działa dla żadnego z nich.

Wyłączenie weryfikacji albo uruchomienie edytora z podwyższonymi uprawnieniami nie jest naprawą brakującego proxy ani brakującego łańcucha zaufania. Oba zamieniają widoczny błąd na cichy. Następnie ponów próbę z tym samym rozszerzeniem i zanotuj kolejny URL, który zawiedzie.

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

Zanotuj, która strona obszaru roboczego wytworzyła ten URL. Krótka notatka z etapem, hostem i stroną jest warta więcej niż lista ustawień zmienionych przez kogoś, ponieważ właśnie tę notatkę następna osoba może odtworzyć.

Powiązane artykuły