Изтеглянията в терминала работят, но разширенията на VS Code се провалят през VPN

curl работи в контейнера, а разширението все още не се инсталира. Сравнете локалния редактор и отдалечената среда, преди да копирате настройките за прокси.

Изтеглянията, които успяват в терминала на контейнера, са реално доказателство за средата на този терминал. Те не казват нищо за процеса на редактора, инсталатора на разширения или двоичния файл, който разширението изтегля след това. Копирането на прокси променливи между тези три превръща една неуспешна заявка в следобед на несвързани промени.

Две среди обикновено се различават точно в едно отношение. Намирането на това отношение е по-бързо от двукратното четене на документацията за прокси.

Кой процес изпрати неуспешната заявка

По време на една инсталация могат да се провалят три заявки и всяка има собствена мрежова идентичност. Редакторът пита Marketplace за метаданни и URL на пакета, след което изтегля пакета. Едва след това хостът на разширенията изпълнява код, който може да изтегли езиков сървър или собствен двоичен файл. Кой етап се е счупил, определя кой процес се нуждае от прокси, а интерфейсът за грешки рядко назовава етапа.

Работещият терминал доказва, че контейнерът може да достигне интернет, а не че редакторът може. Прочетете журнала на разширението за последния URL, който е опитало. Посоченият там хост идентифицира процеса и прилаганата към него политика.

Локалният редактор и отдалеченият контейнер са две среди

В отдалечено работно пространство разширението работи от страната, която типът му декларира. Интерфейсните разширения остават с локалния редактор, а разширенията за работното пространство работят в контейнера. Зададеното в едното прокси е невидимо за другото, а преизграждането създава средата на контейнера от конфигурационния му файл, а не от онова, което сте експортирали в обвивка. Това разделение обяснява защо едно и също разширение се инсталира на лаптоп и се проваля в същия проект през SSH.

Прочетете мястото на инсталация, преди да промените каквото и да е. Когато журналът съобщи за отдалечена инсталация, средата на контейнера е тази, която има значение.

Поставете проксито там, където започва заявката

За Dev Container, на който наистина му трябва HTTP прокси, променливата принадлежи в конфигурацията на контейнера, за да я възпроизвежда преизграждането. Фрагментът по-долу я задава за тази среда. Адресът-заместител замества вашия собствен шлюз, а изключенията не са незадължителен пълнеж.

"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. Кратка бележка с етапа, хоста и страната струва повече от списък с настройки, които някой е променил, защото точно тази бележка следващият човек може да възпроизведе.

Подобни статии