Завантаження в терміналі працюють, але розширення 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. Коротка нотатка з етапом, хостом і боком варта більше за список змінених кимось налаштувань, бо саме цю нотатку зможе відтворити наступна людина.

Схожі статті