Nedlastinger i terminalen virker, men VS Code-utvidelser feiler på VPN

curl virker i containeren, og utvidelsen installeres fortsatt ikke. Sammenlign den lokale editoren og fjernmiljøet før du kopierer proxyinnstillinger.

Nedlastinger som lykkes i containerens terminal, er reelt bevis om den terminalens miljø. De sier ingenting om editorprosessen, utvidelsesinstallasjonen eller binærfilen en utvidelse henter etterpå. Å kopiere proxyvariabler mellom disse tre gjør én mislykket forespørsel til en hel ettermiddag med urelaterte endringer.

To miljøer skiller seg vanligvis ut i nøyaktig én henseende. Å finne den henseenden er raskere enn å lese proxydokumentasjonen to ganger.

Hvilken prosess sendte den mislykkede forespørselen

Tre forespørsler kan feile under én installasjon, og hver har sin egen nettverksidentitet. Editoren ber Marketplace om metadata og en pakke-URL og laster deretter ned pakken. Først etterpå kjører utvidelsesverten kode som kan hente en språkserver eller sin egen binærfil. Hvilket trinn som brøt, avgjør hvilken prosess som trenger en proxy, og feilflaten navngir sjelden trinnet.

En fungerende terminal beviser at containeren kan nå internett, ikke at editoren kan. Les utvidelsesloggen for den siste URL-en den forsøkte. Verten som nevnes der, identifiserer prosessen og policyen som gjelder for den.

Lokal editor og ekstern container er to miljøer

I et eksternt arbeidsområde kjører en utvidelse på siden dens type erklærer. Grensesnittutvidelser blir hos den lokale editoren, og arbeidsområdeutvidelser kjører i containeren. En proxy satt i den ene er usynlig for den andre, og en gjenoppbygging gjenskaper containerens miljø fra konfigurasjonsfilen i stedet for fra det du eksporterte i et skall. Denne delingen forklarer hvorfor den samme utvidelsen installeres på en bærbar PC og feiler i det samme prosjektet over SSH.

Les installasjonsstedet før du endrer noe. Når loggen rapporterer en ekstern installasjon, er det containerens miljø som betyr noe.

Sett proxyen der forespørselen starter

For en Dev Container som virkelig trenger en HTTP-proxy, hører variabelen hjemme i containerkonfigurasjonen slik at en gjenoppbygging gjenskaper den. Utdraget nedenfor setter den for det miljøet. Plassholderadressen står for din egen gateway, og unntakene er ikke valgfri utfylling.

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

Variabelnavnet beskriver destinasjonsprotokollen, så en HTTPS_PROXY-verdi kan lovlig begynne med http. Bruk endringen gjennom den støttede gjenoppbyggingsveien, og behold unntakene, fordi en proxy som fanger interne verter, ødelegger tjenester containeren trenger.

Skill tillitsfeil fra tilgjengelighet

En proxy som kobler til og deretter returnerer en sertifikatverifiseringsfeil, har nådd et senere trinn enn en som avviser tilkoblingen. Den første feilen vil ha organisasjonens godkjente tillitsmateriale installert i miljøet som utfører forespørselen. Den andre vil ha en tilgjengelig adresse og port. Behandles de som ett problem, gir det en løsning som ikke virker for noen av dem.

Å deaktivere verifisering eller kjøre editoren med forhøyede rettigheter er ikke en reparasjon for en manglende proxy eller en manglende tillitskjede. Begge bytter en synlig feil mot en stille. Prøv den samme utvidelsen igjen etterpå og noter den neste URL-en som feiler.

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

Noter hvilken side av arbeidsområdet som produserte den URL-en. Et kort notat som navngir trinnet, verten og siden er mer verdt enn en liste over innstillinger noen har endret, fordi nettopp det notatet kan den neste personen gjenskape.

Relaterte artikler