Спампоўкі ў тэрмінале працуюць, але пашырэнні 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. Кароткая нататка з назвай стадыі, хаста і боку каштоўнейшая за спіс налад, якія хтосьці змяніў, бо менавіта гэтую нататку зможа ўзнавіць наступны чалавек.

Падобныя артыкулы