A terminálban működnek a letöltések, de a VS Code-bővítmények elbuknak a VPN mögött

A curl működik a konténerben, a bővítmény mégsem települ. Hasonlítsa össze a helyi szerkesztőt és a távoli környezetet, mielőtt proxybeállításokat másol.

A konténer termináljában sikeres letöltések valódi bizonyítékok az adott terminál környezetéről. Semmit sem mondanak a szerkesztő folyamatáról, a bővítménytelepítőről vagy arról a bináris fájlról, amelyet a bővítmény később letölt. A proxyváltozók másolása e három között egyetlen sikertelen kérést egy egész délutánnyi, oda nem tartozó módosítássá alakít.

Két környezet általában pontosan egy dologban tér el. Ezt megtalálni gyorsabb, mint kétszer elolvasni a proxy dokumentációját.

Melyik folyamat indította a sikertelen kérést

Egyetlen telepítés alatt három kérés is elbukhat, és mindegyiknek saját hálózati identitása van. A szerkesztő metaadatokat és csomag-URL-t kér a Marketplace-től, majd letölti a csomagot. Csak ezután futtat a bővítménygazda olyan kódot, amely nyelvi szervert vagy saját bináris fájlt tölthet le. Hogy melyik szakasz tört el, eldönti, melyik folyamatnak kell proxy, és a hiba felülete ritkán nevezi meg a szakaszt.

A működő terminál azt bizonyítja, hogy a konténer eléri az internetet, nem azt, hogy a szerkesztő is. Olvassa ki a bővítmény naplójából az utolsó megkísérelt URL-t. Az ott megnevezett gazda azonosítja a folyamatot és a rá vonatkozó házirendet.

A helyi szerkesztő és a távoli konténer két környezet

Távoli munkaterületen a bővítmény azon az oldalon fut, amelyet a típusa deklarál. A felületi bővítmények a helyi szerkesztőnél maradnak, a munkaterületi bővítmények pedig a konténerben futnak. Az egyikben beállított proxy láthatatlan a másik számára, és az újraépítés a konténer környezetét a konfigurációs fájljából hozza létre, nem abból, amit egy shellben exportált. Ez a kettősség magyarázza, miért települ ugyanaz a bővítmény egy laptopra, és miért bukik el ugyanabban a projektben SSH-n keresztül.

Olvassa el a telepítési helyet, mielőtt bármit szerkesztene. Amikor a napló távoli telepítést jelez, a konténer környezete a mérvadó.

Oda tegye a proxyt, ahol a kérés elindul

Egy Dev Container esetében, amelynek valóban HTTP-proxyra van szüksége, a változó a konténer konfigurációjába tartozik, hogy az újraépítés újratermelje. Az alábbi részlet beállítja azt az adott környezethez. A helyőrző cím a saját átjáróját képviseli, a kivételek pedig nem választható kitöltőanyagok.

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

A változó neve a célprotokollt írja le, ezért egy HTTPS_PROXY-érték jogosan kezdődhet http-vel. Alkalmazza a módosítást a támogatott újraépítési úton, és tartsa meg a kivételeket, mert a belső gazdákat elfogó proxy elrontja a konténer által igényelt szolgáltatásokat.

Válassza szét a bizalmi hibákat az elérhetőségtől

Az a proxy, amely csatlakozik, majd tanúsítvány-ellenőrzési hibát ad vissza, későbbi szakaszig jutott, mint amelyik elutasítja a kapcsolatot. Az első hiba az szervezet jóváhagyott bizalmi anyagát kéri a kérést végrehajtó környezetbe telepítve. A második elérhető címet és portot kér. Ha egyetlen problémaként kezeljük őket, olyan javítás születik, amely egyiknek sem működik.

Az ellenőrzés kikapcsolása vagy a szerkesztő emelt jogosultságokkal való futtatása nem javítás hiányzó proxyra vagy hiányzó bizalmi láncra. Mindkettő látható hibát cserél csendesre. Ezután próbálja újra ugyanazt a bővítményt, és jegyezze fel a következő sikertelen URL-t.

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

Jegyezze fel, a munkaterület melyik oldala állította elő azt az URL-t. Egy rövid jegyzet a szakasszal, a gazdával és az oldallal többet ér, mint a valaki által módosított beállítások listája, mert éppen ezt a jegyzetet tudja a következő ember reprodukálni.

Kapcsolódó cikkek