Descărcările din terminal funcționează, dar extensiile VS Code eșuează prin VPN

curl funcționează în container, iar extensia tot nu se instalează. Comparați editorul local și mediul la distanță înainte de a copia setările proxy.

Descărcările care reușesc în terminalul containerului sunt o dovadă reală despre mediul acelui terminal. Ele nu spun nimic despre procesul editorului, despre instalatorul de extensii sau despre fișierul binar pe care o extensie îl descarcă ulterior. Copierea variabilelor proxy între aceste trei transformă o cerere eșuată într-o întreagă după-amiază de modificări fără legătură.

Două medii diferă de obicei exact într-un singur aspect. Găsirea acelui aspect este mai rapidă decât citirea documentației proxy de două ori.

Ce proces a făcut cererea eșuată

Trei cereri pot eșua în timpul unei singure instalări, iar fiecare are propria identitate de rețea. Editorul cere Marketplace-ului metadate și un URL al pachetului, apoi descarcă pachetul. Abia după aceea hostul extensiilor rulează cod care poate descărca un server de limbaj sau propriul fișier binar. Etapa care s-a rupt decide ce proces are nevoie de un proxy, iar suprafața erorii numește rareori etapa.

Un terminal funcțional dovedește că containerul poate ajunge la internet, nu că editorul poate. Citeste jurnalul extensiei pentru ultimul URL pe care l-a încercat. Hostul numit acolo identifică procesul și politica ce i se aplică.

Editorul local și containerul la distanță sunt două medii

Într-un spațiu de lucru la distanță, o extensie rulează pe partea pe care o declară tipul ei. Extensiile de interfață rămân la editorul local, iar extensiile de spațiu de lucru rulează în container. Un proxy setat într-unul este invizibil pentru celălalt, iar o reconstrucție recreează mediul containerului din fișierul său de configurare, nu din ce ați exportat într-un shell. Această separare explică de ce aceeași extensie se instalează pe un laptop și eșuează în același proiect prin SSH.

Citiți locația instalării înainte de a modifica ceva. Când jurnalul raportează o instalare la distanță, mediul containerului este cel care contează.

Puneți proxy-ul acolo unde începe cererea

Pentru un Dev Container care are într-adevăr nevoie de un proxy HTTP, variabila aparține configurației containerului, astfel încât o reconstrucție să o reproducă. Fragmentul de mai jos o setează pentru acel mediu. Adresa substituentă reprezintă propriul dumneavoastră gateway, iar excluderile nu sunt umplutură opțională.

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

Numele variabilei descrie protocolul de destinație, așa că o valoare HTTPS_PROXY poate începe legitim cu http. Aplicați modificarea prin calea de reconstrucție acceptată și păstrați excluderile, deoarece un proxy care interceptează hosturi interne strică serviciile de care containerul are nevoie.

Separați eșecurile de încredere de accesibilitate

Un proxy care se conectează și apoi returnează o eroare de verificare a certificatului a ajuns la o etapă mai târzie decât unul care refuză conexiunea. Primul eșec vrea materialul de încredere aprobat de organizație instalat în mediul care face cererea. Al doilea vrea o adresă și un port accesibile. Tratarea lor ca o singură problemă produce o remediere care nu funcționează pentru niciunul.

Dezactivarea verificării sau rularea editorului cu drepturi ridicate nu este o reparație pentru un proxy lipsă sau un lanț de încredere absent. Ambele schimbă o eroare vizibilă cu una silențioasă. Încercați din nou aceeași extensie după aceea și notați următorul URL care eșuează.

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

Notați care parte a spațiului de lucru a produs acel URL. O notă scurtă cu etapa, hostul și partea valorează mai mult decât o listă de setări modificate de cineva, pentru că exact acea notă o poate reproduce următoarea persoană.

Articole similare