Nedladdningar i terminalen fungerar, men VS Code-tillägg misslyckas på VPN

curl fungerar i containern och tillägget installeras fortfarande inte. Jämför den lokala editorn och fjärrmiljön innan du kopierar proxyinställningar.

Nedladdningar som lyckas i containerns terminal är ett verkligt bevis om den terminalens miljö. De säger ingenting om editorprocessen, tilläggsinstalleraren eller den binärfil som ett tillägg hämtar efteråt. Att kopiera proxyvariabler mellan dessa tre förvandlar en misslyckad begäran till en hel eftermiddag av orelaterade ändringar.

Två miljöer skiljer sig vanligtvis i exakt en aspekt. Att hitta den aspekten går snabbare än att läsa proxydokumentationen två gånger.

Vilken process gjorde den misslyckade begäran

Tre begäranden kan misslyckas under en enda installation, och var och en har sin egen nätverksidentitet. Editorn begär metadata och en paket-URL från Marketplace och laddar sedan ner paketet. Först efter det kör tilläggsvärden kod som kan hämta en språkserver eller sin egen binärfil. Vilket steg som bröts avgör vilken process som behöver en proxy, och felytan namnger sällan steget.

En fungerande terminal bevisar att containern kan nå internet, inte att editorn kan. Läs tilläggets logg för den senaste URL den försökte. Värden som nämns där identifierar processen och den policy som gäller för den.

Lokal editor och fjärrcontainer är två miljöer

I en fjärransluten arbetsyta körs ett tillägg på den sida som dess typ deklarerar. Gränssnittstillägg stannar hos den lokala editorn, och arbetsytetillägg körs i containern. En proxy som angetts i den ena är osynlig för den andra, och en ombyggnad återskapar containerns miljö från dess konfigurationsfil i stället för från det du exporterade i ett skal. Den uppdelningen förklarar varför samma tillägg installeras på en bärbar dator och misslyckas i samma projekt via SSH.

Läs installationsplatsen innan du ändrar något. När loggen rapporterar en fjärrinstallation är det containerns miljö som spelar roll.

Placera proxyn där begäran börjar

För en Dev Container som verkligen behöver en HTTP-proxy hör variabeln hemma i containerkonfigurationen så att en ombyggnad återskapar den. Utdraget nedan anger den för den miljön. Platshållaradressen står för din egen gateway, och undantagen är inte valfri utfyllnad.

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

Variabelnamnet beskriver målprotokollet, så ett HTTPS_PROXY-värde får legitimt börja med http. Tillämpa ändringen via den stödda ombyggnadsvägen, och behåll undantagen, eftersom en proxy som fångar interna värdar bryter tjänster som containern behöver.

Separera tillitsfel från nåbarhet

En proxy som ansluter och sedan returnerar ett certifikatverifieringsfel har nått ett senare steg än en som avvisar anslutningen. Det första felet vill ha organisationens godkända tillitsmaterial installerat i miljön som utför begäran. Det andra vill ha en nåbar adress och port. Behandlas de som ett problem blir resultatet en åtgärd som inte fungerar för någon av dem.

Att stänga av verifieringen, eller köra editorn med förhöjda rättigheter, är inte en reparation för en saknad proxy eller en saknad tillitskedja. Båda byter ett synligt fel mot ett tyst. Försök igen med samma tillägg efteråt och notera nästa URL som misslyckas.

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

Notera vilken sida av arbetsytan som producerade den URL:en. En kort anteckning med steget, värden och sidan är värd mer än en lista över inställningar som någon ändrat, eftersom just den anteckningen kan nästa person återskapa.

Relaterade artiklar