Downloads in de terminal werken, maar VS Code-extensies falen op de VPN

Downloads die in de terminal van de container slagen, zijn echt bewijs over de omgeving van die terminal. Ze zeggen niets over het editorproces, de extensie-installatieprogramma of het binaire bestand dat een extensie daarna ophaalt. Proxyvariabelen tussen die drie kopiëren verandert één mislukte aanvraag in een hele middag ongerelateerde bewerkingen.

Twee omgevingen verschillen meestal op precies één punt. Dat punt vinden is sneller dan de proxydocumentatie twee keer lezen.

Welk proces deed de mislukte aanvraag

Tijdens één installatie kunnen drie aanvragen mislukken, en elk heeft zijn eigen netwerkidentiteit. De editor vraagt de Marketplace om metadata en een pakket-URL en downloadt dan het pakket. Pas daarna voert de extensiehost code uit die een taalserver of een eigen binair bestand kan ophalen. Welke fase brak, bepaalt welk proces een proxy nodig heeft, en het foutoppervlak noemt de fase zelden.

Een werkende terminal bewijst dat de container het internet kan bereiken, niet dat de editor dat kan. Lees het extensielog voor de laatste URL die het probeerde. De daar genoemde host identificeert het proces en het beleid dat ervoor geldt.

Lokale editor en externe container zijn twee omgevingen

In een externe werkruimte draait een extensie aan de kant die zijn type verklaart. Interface-extensies blijven bij de lokale editor, en werkruimte-extensies draaien in de container. Een proxy die in de ene is ingesteld, is onzichtbaar voor de andere, en een herbouw maakt de containeromgeving opnieuw uit zijn configuratiebestand in plaats van uit wat u in een shell hebt geëxporteerd. Die splitsing verklaart waarom dezelfde extensie op een laptop installeert en in hetzelfde project via SSH faalt.

Lees de installatielocatie voordat u iets bewerkt. Wanneer het log een externe installatie meldt, is de omgeving van de container degene die ertoe doet.

Zet de proxy waar de aanvraag begint

Voor een Dev Container die echt een HTTP-proxy nodig heeft, hoort de variabele in de containerconfiguratie zodat een herbouw hem reproduceert. Het fragment hieronder stelt hem voor die omgeving in. Het plaatsvervangende adres staat voor uw eigen gateway, en de uitsluitingen zijn geen optionele opvulling.

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

De naam van de variabele beschrijft het bestemmingsprotocol, dus een HTTPS_PROXY-waarde mag legitiem met http beginnen. Pas de wijziging toe via het ondersteunde herbouwpad, en behoud de uitsluitingen, want een proxy die interne hosts onderschept breekt diensten die de container nodig heeft.

Scheid vertrouwensfouten van bereikbaarheid

Een proxy die verbinding maakt en daarna een certificaatverificatiefout teruggeeft, heeft een latere fase bereikt dan een die de verbinding weigert. De eerste fout wil het door de organisatie goedgekeurde vertrouwensmateriaal, geïnstalleerd in de omgeving die de aanvraag doet. De tweede wil een bereikbaar adres en poort. Ze als één probleem behandelen levert een oplossing op die voor geen van beide werkt.

Verificatie uitschakelen, of de editor met verhoogde rechten draaien, is geen reparatie voor een ontbrekende proxy of een ontbrekende vertrouwensketen. Beide ruilen een zichtbare fout voor een stille. Probeer daarna dezelfde extensie opnieuw en noteer de volgende URL die faalt.

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

Noteer welke kant van de werkruimte die URL heeft opgeleverd. Een korte notitie met de fase, de host en de kant is meer waard dan een lijst met instellingen die iemand heeft gewijzigd, want juist die notitie kan de volgende persoon reproduceren.