Download i terminalen virker, men VS Code-udvidelser fejler på VPN

curl virker i containeren, og udvidelsen installeres stadig ikke. Sammenlign editoren lokalt og det eksterne miljø, før du kopierer proxyindstillinger.

Downloads, der lykkes i containerens terminal, er reelt bevis om den terminals miljø. De siger intet om editorprocessen, installationsprogrammet for udvidelser eller den binære fil, som en udvidelse henter bagefter. At kopiere proxyvariabler mellem de tre gør én mislykket anmodning til en hel eftermiddag med uvedkommende ændringer.

To miljøer adskiller sig normalt i præcis én henseende. At finde den henseende er hurtigere end at læse proxydokumentationen to gange.

Hvilken proces sendte den mislykkede anmodning

Tre anmodninger kan fejle under én installation, og hver har sin egen netværksidentitet. Editoren beder Marketplace om metadata og en pakke-URL og henter derefter pakken. Først bagefter kører udvidelsesværten kode, der kan hente en sprogserver eller sin egen binære fil. Det trin, der brød sammen, afgør, hvilken proces der har brug for en proxy, og fejlfladen nævner sjældent trinnet.

En fungerende terminal beviser, at containeren kan nå internettet, ikke at editoren kan. Læs udvidelsesloggen for den sidste URL, den forsøgte. Den vært, der nævnes der, identificerer processen og den politik, der gælder for den.

Lokal editor og ekstern container er to miljøer

I et eksternt arbejdsområde kører en udvidelse på den side, som dens type erklærer. Grænsefladeudvidelser bliver hos den lokale editor, og arbejdsområdeudvidelser kører i containeren. En proxy, der er sat i den ene, er usynlig for den anden, og en genopbygning genskaber containerens miljø ud fra dens konfigurationsfil i stedet for ud fra det, du eksporterede i en shell. Den opdeling forklarer, hvorfor den samme udvidelse installeres på en bærbar computer og fejler i det samme projekt over SSH.

Læs installationsplaceringen, før du ændrer noget. Når loggen rapporterer en ekstern installation, er det containerens miljø, der er afgørende.

Sæt proxyen, hvor anmodningen starter

For en Dev Container, der faktisk har brug for en HTTP-proxy, hører variablen i containerkonfigurationen, så en genopbygning genskaber den. Uddraget nedenfor sætter den for det miljø. Pladsholderadressen står for din egen gateway, og undtagelserne er ikke valgfri polstring.

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

Variablens navn beskriver destinationsprotokollen, så en HTTPS_PROXY-værdi kan med rette begynde med http. Anvend ændringen via den understøttede genopbygningsvej, og behold undtagelserne, fordi en proxy, der opsnapper interne værter, ødelægger tjenester, som containeren har brug for.

Adskil tillidsfejl fra tilgængelighed

En proxy, der opretter forbindelse og derefter returnerer en certifikatverifikationsfejl, har nået et senere trin end en, der afviser forbindelsen. Den første fejl kræver organisationens godkendte tillidsmateriale installeret i det miljø, der udfører anmodningen. Den anden kræver en tilgængelig adresse og port. Behandles de som ét problem, giver det en løsning, der ikke virker for nogen af dem.

At deaktivere verifikation eller køre editoren med forhøjede rettigheder er ikke en reparation for en manglende proxy eller en manglende tillidskæde. Begge bytter en synlig fejl for en tavs. Prøv den samme udvidelse igen bagefter, og noter den næste URL, der fejler.

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

Noter, hvilken side af arbejdsområdet der frembragte den URL. En kort note med trinnet, værten og siden er mere værd end en liste over indstillinger, nogen har ændret, fordi netop den note kan den næste person genskabe.

Relaterede artikler