टर्मिनल में डाउनलोड काम करते हैं, पर VPN पर VS Code एक्सटेंशन विफल हो जाते हैं

कंटेनर के टर्मिनल में सफल होने वाले डाउनलोड उस टर्मिनल के वातावरण के वास्तविक प्रमाण हैं। वे एडिटर प्रक्रिया, एक्सटेंशन इंस्टॉलर या उस बाइनरी के बारे में कुछ नहीं कहते जो एक्सटेंशन बाद में लाता है। उन तीनों के बीच प्रॉक्सी चर कॉपी करना एक विफल अनुरोध को असंबंधित संपादनों की पूरी दोपहर में बदल देता है।

दो वातावरण आमतौर पर ठीक एक बिंदु पर भिन्न होते हैं। उस बिंदु को खोजना प्रॉक्सी दस्तावेज़ को दो बार पढ़ने से तेज़ है।

किस प्रक्रिया ने विफल अनुरोध किया

एक ही इंस्टॉल के दौरान तीन अनुरोध विफल हो सकते हैं, और हर एक की अपनी नेटवर्क पहचान होती है। एडिटर Marketplace से मेटाडेटा और पैकेज URL माँगता है, फिर पैकेज डाउनलोड करता है। उसके बाद ही एक्सटेंशन होस्ट ऐसा कोड चलाता है जो भाषा सर्वर या अपनी बाइनरी ला सकता है। कौन-सा चरण टूटा, यह तय करता है कि किस प्रक्रिया को प्रॉक्सी चाहिए, और त्रुटि की सतह उस चरण का नाम शायद ही बताती है।

काम करता टर्मिनल साबित करता है कि कंटेनर इंटरनेट तक पहुँच सकता है, यह नहीं कि एडिटर पहुँच सकता है। एक्सटेंशन लॉग में वह अंतिम URL पढ़ें जिसे उसने आज़माया। वहाँ नामित होस्ट प्रक्रिया और उस पर लागू नीति की पहचान करता है।

स्थानीय एडिटर और दूरस्थ कंटेनर दो वातावरण हैं

दूरस्थ वर्कस्पेस में एक्सटेंशन उस पक्ष पर चलता है जिसकी घोषणा उसका प्रकार करता है। इंटरफ़ेस एक्सटेंशन स्थानीय एडिटर के साथ रहते हैं, और वर्कस्पेस एक्सटेंशन कंटेनर में चलते हैं। एक में सेट प्रॉक्सी दूसरे के लिए अदृश्य है, और पुनर्निर्माण कंटेनर का वातावरण उसकी कॉन्फ़िगरेशन फ़ाइल से बनाता है, न कि उससे जो आपने शेल में निर्यात किया। यह विभाजन बताता है कि वही एक्सटेंशन लैपटॉप पर क्यों इंस्टॉल होता है और SSH से उसी प्रोजेक्ट में क्यों विफल होता है।

कुछ भी संपादित करने से पहले इंस्टॉलेशन स्थान पढ़ें। जब लॉग दूरस्थ इंस्टॉल की सूचना दे, तब कंटेनर का वातावरण ही मायने रखता है।

प्रॉक्सी वहाँ रखें जहाँ अनुरोध शुरू होता है

ऐसे Dev Container के लिए जिसे वास्तव में HTTP प्रॉक्सी चाहिए, चर कंटेनर कॉन्फ़िगरेशन में होना चाहिए ताकि पुनर्निर्माण उसे पुन: उत्पन्न करे। नीचे का अंश उसे उस वातावरण के लिए सेट करता है। प्लेसहोल्डर पता आपके अपने गेटवे का प्रतिनिधित्व करता है, और अपवाद वैकल्पिक भराव नहीं हैं।

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

चर का नाम गंतव्य प्रोटोकॉल बताता है, इसलिए HTTPS_PROXY मान वैध रूप से http से शुरू हो सकता है। परिवर्तन को समर्थित पुनर्निर्माण पथ से लागू करें और अपवाद रखें, क्योंकि आंतरिक होस्ट को रोकने वाली प्रॉक्सी उन सेवाओं को तोड़ती है जिनकी कंटेनर को आवश्यकता है।

विश्वास की विफलताओं को पहुँच से अलग करें

जो प्रॉक्सी जुड़ती है और फिर प्रमाणपत्र सत्यापन त्रुटि लौटाती है, वह कनेक्शन अस्वीकार करने वाली प्रॉक्सी से बाद के चरण तक पहुँची है। पहली विफलता को संगठन की अनुमोदित ट्रस्ट सामग्री उस वातावरण में स्थापित चाहिए जो अनुरोध करता है। दूसरी को पहुँचने योग्य पता और पोर्ट चाहिए। दोनों को एक समस्या मानने से ऐसा समाधान बनता है जो किसी के लिए भी काम नहीं करता।

सत्यापन बंद करना, या एडिटर को उच्च अधिकारों के साथ चलाना, अनुपस्थित प्रॉक्सी या अनुपस्थित ट्रस्ट श्रृंखला की मरम्मत नहीं है। दोनों एक दिखने वाली त्रुटि को चुपचाप त्रुटि से बदल देते हैं। बाद में वही एक्सटेंशन फिर आज़माएँ और अगला विफल URL नोट करें।

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

नोट करें कि वर्कस्पेस के किस पक्ष ने वह URL बनाया। चरण, होस्ट और पक्ष का नाम बताने वाला छोटा नोट किसी द्वारा बदली गई सेटिंग्स की सूची से अधिक मूल्यवान है, क्योंकि अगला व्यक्ति उसी नोट को पुन: उत्पन्न कर सकता है।