सामग्री पर जाएंप्रतिबंधित नेटवर्क में GitHub Codespaces के साथ प्रॉक्सी का उपयोग कैसे करें
GitHub Codespace अपना डेवलपमेंट कंटेनर होस्ट किए गए परिवेश में चलाता है, जबकि उसे दिखाने वाला ब्राउज़र आपके अपने डिवाइस पर चलता है। यह अंतर महत्वपूर्ण है: कंटेनर के भीतर प्रॉक्सी कॉन्फ़िगर करने से Codespace से पैकेज डाउनलोड प्रॉक्सी के ज़रिए हो सकते हैं, लेकिन इससे यह अपने-आप नहीं बदलता कि आपका स्थानीय ब्राउज़र वेबसाइटों तक कैसे पहुँचता है। इसलिए GitHub Codespaces में प्रॉक्सी कैसे सेट करें, यह जानने से पहले तय करें कि समस्या कंटेनर के ट्रैफ़िक में है या आपके स्थानीय ब्राउज़र में।
अगर कॉर्पोरेट फ़ायरवॉल के पीछे कोई निर्भरता इंस्टॉल नहीं हो रही है, तो पहले पता करें कि कौन-सा कनेक्शन ब्लॉक है। इसी से तय होगा कि प्रॉक्सी कहाँ कॉन्फ़िगर करनी है और आपके संगठन को किन चीज़ों की अनुमति देनी होगी।
1. पहचानें कि Codespaces के किस ट्रैफ़िक को प्रॉक्सी चाहिए
उस खास कार्रवाई की सूची बनाएँ जो विफल हो रही है। pip से Python पैकेज इंस्टॉल करना, npm से Node.js निर्भरता फ़ेच करना और टर्मिनल से कमांड-लाइन टूल डाउनलोड करना—ये सभी अनुरोध डेवलपमेंट कंटेनर के सॉफ़्टवेयर भेजते हैं। इसके उलट, आपके लैपटॉप पर खोला गया ब्राउज़र टैब लैपटॉप के नेटवर्क मार्ग का उपयोग करता है।
इस अंतर को समझने से समय बच सकता है। अगर आपकी स्थानीय ब्राउज़र में वेबसाइट नहीं खुल रही है, तो Codespace में HTTPS_PROXY जोड़ने से शायद कोई फ़र्क न पड़े। वहीं, अगर Codespace टर्मिनल में npm install विफल हो रहा है, तो सिर्फ़ लैपटॉप पर कॉन्फ़िगर की गई प्रॉक्सी भी मददगार नहीं होगी।
विफल हो रहे टूल, उसके पहुँचने की कोशिश वाले गंतव्य और अनुरोध के स्रोत—टर्मिनल, एडिटर एक्सटेंशन या आपका स्थानीय ब्राउज़र—का विवरण लिख लें। उदाहरण के लिए, pip install की विफलता कंटेनर ट्रैफ़िक की ओर इशारा करती है; स्थानीय ब्राउज़र में साइन-इन पेज न खुलना स्थानीय नेटवर्क या ब्राउज़र कॉन्फ़िगरेशन की समस्या हो सकती है।
दायरा सीमित रखें। अगर सिर्फ़ एक पैकेज रजिस्ट्री ब्लॉक है, तो सारा ट्रैफ़िक प्रॉक्सी से भेजने पर अनावश्यक समस्याएँ हो सकती हैं—खासकर तब, जब आंतरिक सेवाओं तक सीधे पहुँचना चाहिए।
2. जाँचें कि आपके संगठन की प्रॉक्सी किन चीज़ों की अनुमति देती है
अपने नेटवर्क प्रशासक से प्रॉक्सी का होस्टनेम और पोर्ट, आवश्यक प्रोटोकॉल और प्रमाणीकरण का तरीका पूछें। यह भी पता करें कि प्रॉक्सी के लिए उपयोगकर्ता नाम और पासवर्ड चाहिए, क्लाइंट सर्टिफ़िकेट चाहिए या कंटेनर में इंस्टॉल किया गया सर्टिफ़िकेट अथॉरिटी चाहिए। किसी दूसरे डिवाइस की प्रॉक्सी सेटिंग देखकर इन बातों का अनुमान न लगाएँ।
जिस खास काम के लिए प्रॉक्सी चाहिए, उसके अनुमत गंतव्यों की जानकारी लें। पैकेज मैनेजर को किसी रजिस्ट्री तक पहुँच चाहिए हो सकती है, जबकि टूल इंस्टॉलर किसी अलग रिलीज़ होस्ट से डाउनलोड कर सकता है। आपका प्रशासक बता सकता है कि किन होस्टनेम की अनुमति है। समस्या की जाँच शुरू करने से पहले उन्हें नोट कर लें, ताकि आप ब्लॉक हुए गंतव्य और गलत प्रॉक्सी पते में अंतर कर सकें।
जाँचें कि HTTPS निरीक्षण चालू है या नहीं। निरीक्षण चालू होने पर प्रॉक्सी ऐसा सर्टिफ़िकेट दिखा सकती है जो सार्वजनिक सर्टिफ़िकेट अथॉरिटी के बजाय आपके संगठन ने जारी किया हो। संगठन का सर्टिफ़िकेट और उसे इंस्टॉल करने की स्वीकृत प्रक्रिया प्रशासक से लें—किसी त्रुटि संदेश से सर्टिफ़िकेट कॉपी करके इस्तेमाल न करें।
अगर आप प्रॉक्सी के प्रकारों की तुलना कर रहे हैं या अन्य टूल के लिए पहुँच सेट कर रहे हैं, तो प्रॉक्सी प्रमाणीकरण की सर्वोत्तम प्रक्रियाओं की गाइड में क्रेडेंशियल सुरक्षित ढंग से संभालने की जानकारी है। नेटवर्क रूटिंग के बारे में व्यापक निर्णय लेने के लिए VPN चुनने का तरीका देखें; VPN और प्रॉक्सी को Codespaces में एक ही तरह से कॉन्फ़िगर नहीं किया जाता।
3. डेवलपमेंट कंटेनर के लिए प्रॉक्सी वेरिएबल कॉन्फ़िगर करें
कई कमांड-लाइन टूल HTTP_PROXY और HTTPS_PROXY एनवायरनमेंट वेरिएबल पढ़ते हैं। Codespaces में HTTPS_PROXY कैसे कॉन्फ़िगर करें, इसके लिए इन्हें डेवलपमेंट-कंटेनर एनवायरनमेंट में प्रशासक द्वारा दिए गए पते के फ़ॉर्मैट के अनुसार सेट करें। आम तौर पर मान का स्वरूप http://proxy.example.net:8080 जैसा होता है, लेकिन अपने संगठन का असली प्रोटोकॉल, होस्टनेम और पोर्ट ही इस्तेमाल करें।
जिन गंतव्यों को प्रॉक्सी से नहीं भेजना है—जैसे स्वीकृत आंतरिक सेवाएँ या स्थानीय पते—उनके लिए NO_PROXY सेट करें। इसमें कौन-सी प्रविष्टियाँ होंगी, यह आपके नेटवर्क और टूल पर निर्भर करता है। बहुत व्यापक मान से आंतरिक अनुरोध गलत रास्ते से बाहर जा सकते हैं; बहुत सीमित मान से कोई अनुरोध ब्लॉक किए गए गंतव्य तक सीधे पहुँचने की कोशिश कर सकता है।
जल्दी से अस्थायी जाँच करने के लिए, कोई कमांड चलाने से पहले टर्मिनल सत्र में वेरिएबल सेट कर सकते हैं। इससे पता चल सकता है कि पैकेज इंस्टॉल हो रहा है या नहीं, लेकिन यह हर टर्मिनल या भविष्य के Codespace सत्र को कॉन्फ़िगर करने का भरोसेमंद तरीका नहीं है। शेल का सिंटैक्स भी अलग-अलग हो सकता है। क्रेडेंशियल वाले प्रॉक्सी URL को ऐसे कमांड में पेस्ट न करें जो शेल हिस्ट्री में सेव हो सकता है।
प्रोजेक्ट का सेटअप बार-बार एक जैसा रखने के लिए, रिपॉज़िटरी में इस्तेमाल होने वाले डेवलपमेंट-कंटेनर कॉन्फ़िगरेशन—जैसे उपयुक्त Dev Container कॉन्फ़िगरेशन या सेटअप स्क्रिप्ट—में गैर-गोपनीय सेटिंग रखें। पासवर्ड और टोकन को ट्रैक की जाने वाली फ़ाइलों से बाहर रखें। क्रेडेंशियल की ज़रूरत हो तो अपने संगठन की स्वीकृत सीक्रेट-इंजेक्शन विधि अपनाएँ और जाँचें कि कौन-सी प्रक्रियाएँ उसे पढ़ सकती हैं।
यह न मानें कि हर ऐप्लिकेशन इन वेरिएबल का पालन करेगा। कुछ टूल इनके छोटे अक्षरों वाले रूप पढ़ते हैं, कुछ अपनी कॉन्फ़िगरेशन फ़ाइलें इस्तेमाल करते हैं और कुछ एनवायरनमेंट वेरिएबल को अनदेखा कर देते हैं। जिस कमांड में समस्या आई थी, उसी को जाँचें। सिर्फ़ HTTPS_PROXY मौजूद होने से यह साबित नहीं होता कि Codespace का सारा ट्रैफ़िक प्रॉक्सी से जा रहा है।
4. Codespace रीबिल्ड होने पर भी प्रॉक्सी सेटिंग बनाए रखें
एक टर्मिनल में दर्ज की गई सेटिंग टर्मिनल बंद होने या Codespace रीबिल्ड होने पर गायब हो सकती है। प्रोजेक्ट के लिए ज़रूरी, गैर-संवेदनशील सेटिंग बनाए रखने के लिए रिपॉज़िटरी-स्तर का कॉन्फ़िगरेशन इस्तेमाल करें, जो डेवलपमेंट कंटेनर बनाते समय लागू हो। इससे उसी प्रोजेक्ट को खोलने वाले सहकर्मी को भी बुनियादी सेटअप मिल सकता है—बिना किसी निजी क्रेडेंशियल को रिपॉज़िटरी में कॉपी किए।
अगर प्रॉक्सी सिर्फ़ आपके खाते पर लागू होती है या सेटिंग संवेदनशील है, तो निजी सेटिंग बेहतर हो सकती है। यह तरीका चुनने से पहले अपने संगठन की Codespaces नीतियाँ और उपलब्ध सेटिंग जाँच लें: हो सकता है कि प्रशासक निजी कॉन्फ़िगरेशन, सीक्रेट या डेवलपमेंट-कंटेनर की कुछ सुविधाओं के इस्तेमाल पर पाबंदी लगाए।
कॉन्फ़िगरेशन बदलने के बाद, अगर बदलाव कंटेनर बनने के तरीके को प्रभावित करता है तो Codespace रीबिल्ड करें। फिर नया टर्मिनल खोलकर वेरिएबल जाँचें। रीबिल्ड एक उपयोगी कसौटी है: अगर उसके बाद प्रॉक्सी सेटिंग गायब हो जाए, तो संभवतः वह स्थायी कॉन्फ़िगरेशन स्रोत के बजाय सिर्फ़ पिछले शेल में जोड़ी गई थी।
साझा कॉन्फ़िगरेशन और सीक्रेट अलग रखें। रिपॉज़िटरी में प्रॉक्सी वेरिएबल के नाम और अपेक्षित फ़ॉर्मैट दर्ज किए जा सकते हैं, लेकिन असली पासवर्ड किसी स्वीकृत सीक्रेट-मैकेनिज़्म से दिया जाना चाहिए। इससे सामान्य कमिट के ज़रिए प्रोजेक्ट का इतिहास पढ़ सकने वाले सभी लोगों के सामने क्रेडेंशियल उजागर नहीं होंगे।
5. ज़रूरत पड़ने पर प्रॉक्सी के सर्टिफ़िकेट पर भरोसा करें
अगर HTTPS अनुरोध सर्टिफ़िकेट सत्यापन की त्रुटि के साथ विफल हों और आपका संगठन पुष्टि करे कि HTTPS निरीक्षण चालू है, तो कंटेनर को संगठन की सर्टिफ़िकेट अथॉरिटी पर भरोसा करना पड़ सकता है। आधिकारिक सर्टिफ़िकेट और इंस्टॉलेशन के निर्देश प्रशासक से लें। बचाव के तौर पर सर्टिफ़िकेट जाँच बंद न करें; इससे समस्या ठीक होने के बजाय ट्रैफ़िक में दखल छिप सकता है।
इंस्टॉलेशन की प्रक्रिया कंटेनर के ऑपरेटिंग सिस्टम और बेस इमेज पर निर्भर करती है। Debian-आधारित इमेज, Alpine-आधारित इमेज और भाषा-विशिष्ट इमेज में सर्टिफ़िकेट बंडल अलग-अलग तरीके से संभाले जा सकते हैं। यह भी पता करें कि रीबिल्ड के बाद सर्टिफ़िकेट उपलब्ध रखने के लिए उसे कंटेनर बनाते समय जोड़ना ज़रूरी है या नहीं।
इंस्टॉल होने के बाद, उसी टूल से किसी स्वीकृत गंतव्य पर सामान्य HTTPS अनुरोध जाँचें जिसमें पहले समस्या आई थी। अगर ब्राउज़र काम कर रहा है, लेकिन कमांड-लाइन क्लाइंट अब भी किसी अविश्वसनीय जारीकर्ता की शिकायत कर रहा है, तो हो सकता है कि वह क्लाइंट अलग सर्टिफ़िकेट स्टोर इस्तेमाल करता हो या उसे अपनी अलग सेटिंग चाहिए हो। भरोसे की सेटिंग बदलने से पहले प्रशासक से पूछें कि कंटेनर में कौन-सी सर्टिफ़िकेट फ़ाइल और फ़ॉर्मैट इस्तेमाल करना चाहिए।
6. Git और डेवलपमेंट टूल की अलग-अलग जाँच करें
पहले प्रशासक द्वारा स्वीकृत किसी गंतव्य पर एक साधारण अनुरोध करके देखें। फिर उस पैकेज मैनेजर या टूल की जाँच करें जिसमें समस्या आई थी। एक कमांड का सफल होना इस बात का सबूत नहीं है कि Git, pip, npm और भाषा-विशिष्ट इंस्टॉलर सभी प्रॉक्सी के साथ एक जैसा व्यवहार करेंगे।
Git के लिए जाँचें कि आपके सेटअप में इंस्टॉल किया गया संस्करण प्रॉक्सी एनवायरनमेंट वेरिएबल पढ़ता है या नहीं। अगर नहीं, तो Git को अपनी अलग प्रॉक्सी कॉन्फ़िगरेशन की ज़रूरत हो सकती है। पासवर्ड सीधे ऐसी Git कॉन्फ़िगरेशन फ़ाइल में न डालें जिसे कमिट किया जा सकता हो या लॉग में कॉपी किया जा सकता हो; इसके बजाय संगठन द्वारा स्वीकृत क्रेडेंशियल विधि अपनाएँ।
पैकेज मैनेजर के लिए प्रॉक्सी सेटिंग और कॉन्फ़िगर की गई रजिस्ट्री—दोनों जाँचें। किसी आंतरिक रजिस्ट्री की ओर निर्देशित पैकेज मैनेजर को सीधे डाउनलोड के लिए इस्तेमाल होने वाले बाहरी गंतव्य तक पहुँच की ज़रूरत नहीं भी हो सकती, जबकि रिलीज़ आर्काइव फ़ेच करने वाला टूल किसी अन्य होस्ट से जुड़ सकता है। त्रुटि में बताए गए गंतव्य की तुलना आपको मिली अनुमति-सूची से करें। कॉर्पोरेट नेटवर्क में Codespaces पैकेज इंस्टॉल समस्या की जाँच करते समय यह पुष्टि करें कि अनुरोध सही रजिस्ट्री और अनुमत होस्ट तक पहुँच रहा है।
लिख लें कि कौन-सी जाँच सफल हुई, कौन-सी विफल और उसमें कौन-सा होस्टनेम शामिल था। इससे प्रशासक को कार्रवाई योग्य जानकारी मिलेगी—जैसे, “Git स्वीकृत होस्ट तक पहुँच रहा है, लेकिन पैकेज रजिस्ट्री प्रॉक्सी अनुरोध अस्वीकार कर रही है”—न कि सिर्फ़ यह अस्पष्ट शिकायत कि Codespaces में इंटरनेट नहीं है।
7. क्रेडेंशियल उजागर किए बिना कनेक्शन की समस्याओं का पता लगाएँ
किसी स्वीकृत गंतव्य पर सुरक्षित कनेक्टिविटी जाँच करें और देखें कि नतीजा DNS रेज़ॉल्यूशन, टाइमआउट, प्रॉक्सी प्रमाणीकरण, गंतव्य अस्वीकृत होने या सर्टिफ़िकेट सत्यापन की ओर इशारा करता है या नहीं। हर समस्या के लिए अगला कदम अलग होगा। उदाहरण के लिए, टाइमआउट और प्रमाणीकरण अस्वीकृति एक ही बात नहीं हैं।
जाँचें कि प्रॉक्सी का होस्टनेम और पोर्ट प्रशासक द्वारा दिए गए मानों से मेल खाते हैं और जिस टर्मिनल सत्र में आप जाँच चला रहे हैं, उसमें वेरिएबल मौजूद है। अगर प्रॉक्सी को प्रमाणीकरण चाहिए, तो पता सही होने पर भी गायब या समय-सीमा समाप्त हो चुका क्रेडेंशियल पहुँच रोक सकता है।
टर्मिनल आउटपुट साझा करने से पहले उपयोगकर्ता नाम, पासवर्ड, टोकन और क्रेडेंशियल वाले URL हटा दें। प्रॉक्सी की त्रुटियों में पूरा अनुरोध पता शामिल हो सकता है, और शेल हिस्ट्री में सीक्रेट वाले कमांड सेव रह सकते हैं। इसके बजाय त्रुटि का प्रकार, गंतव्य होस्टनेम, टूल का नाम और समस्या आने का समय साझा करें; इन जानकारियों से नेटवर्क सहायता टीम अक्सर अपने लॉग जाँच सकती है।
अगर एक Codespace में प्रॉक्सी काम करती है, लेकिन दूसरे में नहीं, तो उनके कंटेनर कॉन्फ़िगरेशन, ऑपरेटिंग-सिस्टम इमेज, एनवायरनमेंट वेरिएबल और सर्टिफ़िकेट सेटअप की तुलना करें। एक बार में एक ही बदलाव करें, फिर वही जाँच दोहराएँ। इससे पता लगाना आसान होगा कि वजह गायब वेरिएबल है, ब्लॉक किया गया गंतव्य है या भरोसेमंद सर्टिफ़िकेट स्टोर में अंतर है।