Terminaldeki indirmeler çalışıyor ama VPN üzerinden VS Code uzantıları başarısız oluyor

curl konteynerde çalışıyor ve uzantı yine de kurulmuyor. Proxy ayarlarını kopyalamadan önce yerel düzenleyiciyi ve uzak ortamı karşılaştırın.

Konteynerin terminalinde başarılı olan indirmeler, o terminalin ortamı hakkında gerçek bir kanıttır. Düzenleyici süreci, uzantı yükleyicisi veya bir uzantının sonradan indirdiği ikili dosya hakkında hiçbir şey söylemezler. Proxy değişkenlerini bu üçü arasında kopyalamak tek bir başarısız isteği ilgisiz düzenlemelerle dolu bir öğleden sonraya çevirir.

İki ortam genellikle tam olarak tek bir açıdan farklıdır. O açıyı bulmak, proxy belgelerini iki kez okumaktan daha hızlıdır.

Başarısız isteği hangi süreç yaptı

Tek bir kurulum sırasında üç istek başarısız olabilir ve her birinin kendi ağ kimliği vardır. Düzenleyici Marketplace'ten üst verileri ve bir paket URL'sini ister, ardından paketi indirir. Ancak ondan sonra uzantı ana bilgisayarı bir dil sunucusu veya kendi ikili dosyasını indirebilecek kodu çalıştırır. Hangi aşamanın bozulduğu hangi sürecin proxy'ye ihtiyacı olduğunu belirler ve hata yüzeyi bu aşamayı nadiren adlandırır.

Çalışan bir terminal konteynerin internete erişebildiğini kanıtlar, düzenleyicinin erişebildiğini değil. Uzantı günlüğünde denediği son URL'yi okuyun. Orada adı geçen ana bilgisayar, süreci ve ona uygulanan ilkeyi tanımlar.

Yerel düzenleyici ve uzak konteyner iki ortamdır

Uzak bir çalışma alanında bir uzantı, türünün bildirdiği tarafta çalışır. Arayüz uzantıları yerel düzenleyiciyle kalır ve çalışma alanı uzantıları konteynerde çalışır. Birinde ayarlanan proxy diğeri için görünmezdir ve yeniden derleme konteyner ortamını yapılandırma dosyasından yeniden oluşturur, kabukta dışa aktardığınızdan değil. Bu ayrım, aynı uzantının neden bir dizüstü bilgisayarda kurulup aynı projede SSH üzerinden başarısız olduğunu açıklar.

Herhangi bir şeyi düzenlemeden önce kurulum konumunu okuyun. Günlük uzak bir kurulum bildirdiğinde önemli olan konteynerin ortamıdır.

Proxy'yi isteğin başladığı yere koyun

Gerçekten HTTP proxy'ye ihtiyaç duyan bir Dev Container için değişken, yeniden derlemenin onu üretmesi için konteyner yapılandırmasına aittir. Aşağıdaki parça onu o ortam için ayarlar. Yer tutucu adres kendi ağ geçidinizin yerini tutar ve istisnalar isteğe bağlı dolgu değildir.

"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ğişkenin adı hedef protokolü tanımlar, bu nedenle bir HTTPS_PROXY değeri meşru olarak http ile başlayabilir. Değişikliği desteklenen yeniden derleme yoluyla uygulayın ve istisnaları koruyun, çünkü iç ana bilgisayarları kesen bir proxy konteynerin ihtiyaç duyduğu hizmetleri bozar.

Güven arızalarını erişilebilirlikten ayırın

Bağlanıp ardından sertifika doğrulama hatası döndüren bir proxy, bağlantıyı reddedenden daha sonraki bir aşamaya ulaşmıştır. İlk arıza, kuruluşun onaylı güven malzemesinin isteği yapan ortamda kurulu olmasını ister. İkincisi erişilebilir bir adres ve bağlantı noktası ister. İkisini tek bir sorun olarak ele almak, hiçbirine yaramayan bir düzeltme üretir.

Doğrulamayı devre dışı bırakmak veya düzenleyiciyi yükseltilmiş haklarla çalıştırmak, eksik bir proxy veya eksik bir güven zinciri için onarım değildir. İkisi de görünür bir hatayı sessiz bir hatayla değiştirir. Ardından aynı uzantıyı yeniden deneyin ve başarısız olan sonraki URL'yi not edin.

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

Çalışma alanının hangi tarafının o URL'yi ürettiğini not edin. Aşamayı, ana bilgisayarı ve tarafı adlandıran kısa bir not, birinin değiştirdiği ayarlar listesinden daha değerlidir, çünkü sonraki kişinin yeniden üretebileceği şey tam olarak o nottur.

İlgili makaleler