Prenosi v terminalu delujejo, a razširitve VS Code prek VPN spodletijo

curl deluje v vsebniku in razširitev se še vedno ne namesti. Primerjajte lokalni urejevalnik in oddaljeno okolje, preden kopirate nastavitve posredniškega strežnika.

Prenosi, ki uspejo v terminalu vsebnika, so resničen dokaz o okolju tega terminala. Ne povedo ničesar o procesu urejevalnika, namestitvenem programu razširitev ali binarni datoteki, ki jo razširitev pozneje prenese. Kopiranje spremenljivk posredniškega strežnika med temi tremi spremeni eno neuspešno zahtevo v celo popoldne nepovezanih sprememb.

Dve okolji se običajno razlikujeta natanko v enem pogledu. Iskanje tega pogleda je hitrejše od dvakratnega branja dokumentacije o posredniškem strežniku.

Kateri proces je poslal neuspešno zahtevo

Med enim nameščanjem lahko spodletijo tri zahteve in vsaka ima svojo omrežno identiteto. Urejevalnik zaprosi Marketplace za metapodatke in URL paketa, nato prenese paket. Šele zatem gostitelj razširitev izvede kodo, ki lahko prenese jezikovni strežnik ali lastno binarno datoteko. Katera stopnja se je zlomila, odloča, kateri proces potrebuje posredniški strežnik, in površina napake stopnjo redko imenuje.

Delujoč terminal dokazuje, da vsebnik doseže internet, ne da ga doseže urejevalnik. Preberite dnevnik razširitve za zadnji URL, ki ga je poskusila. Tam navedeni gostitelj določi proces in pravilnik, ki velja zanj.

Lokalni urejevalnik in oddaljeni vsebnik sta dve okolji

V oddaljenem delovnem prostoru se razširitev izvaja na strani, ki jo razglasi njen tip. Vmesniške razširitve ostanejo pri lokalnem urejevalniku, razširitve delovnega prostora pa se izvajajo v vsebniku. Posredniški strežnik, nastavljen v enem, je neviden za drugega, ponovna gradnja pa ustvari okolje vsebnika iz njegove konfiguracijske datoteke, ne iz tega, kar ste izvozili v lupini. Ta delitev pojasnjuje, zakaj se ista razširitev namesti na prenosnem računalniku in spodleti v istem projektu prek SSH.

Preberite mesto namestitve, preden karkoli spremenite. Ko dnevnik poroča o oddaljeni namestitvi, je pomembno okolje vsebnika.

Postavite posredniški strežnik tja, kjer se zahteva začne

Za Dev Container, ki resnično potrebuje HTTP posredniški strežnik, spremenljivka sodi v konfiguracijo vsebnika, da jo ponovna gradnja reproducira. Spodnji odlomek jo nastavi za to okolje. Nadomestni naslov predstavlja vaš lastni prehod, izključitve pa niso neobvezno polnilo.

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

Ime spremenljivke opisuje ciljni protokol, zato se lahko vrednost HTTPS_PROXY zakonito začne s http. Spremembo uporabite po podprti poti ponovne gradnje in obdržite izključitve, ker posredniški strežnik, ki prestreza notranje gostitelje, pokvari storitve, ki jih vsebnik potrebuje.

Ločite napake zaupanja od dosegljivosti

Posredniški strežnik, ki se poveže in nato vrne napako preverjanja potrdila, je dosegel poznejšo stopnjo kot tisti, ki povezavo zavrne. Prva napaka zahteva organizacijsko odobreno gradivo zaupanja, nameščeno v okolju, ki izvaja zahtevo. Druga zahteva dosegljiv naslov in vrata. Če ju obravnavamo kot eno težavo, dobimo popravek, ki ne deluje za nobeno.

Izklop preverjanja ali zagon urejevalnika z dvignjenimi pravicami ni popravilo manjkajočega posredniškega strežnika ali manjkajoče verige zaupanja. Oboje zamenja vidno napako s tiho. Nato poskusite isto razširitev znova in zapišite naslednji URL, ki spodleti.

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

Zapišite, katera stran delovnega prostora je ustvarila ta URL. Kratka opomba s stopnjo, gostiteljem in stranjo je vredna več kot seznam nastavitev, ki jih je nekdo spremenil, ker lahko prav to opombo naslednja oseba ponovi.

Sorodni članki