VPN से जुड़े होने पर Git 403: जवाब देने वाले को खोजें
403 एक जवाब है, VPN पर फैसला नहीं। पहचानें कि किस घटक ने अनुरोध ठुकराया, फिर नेटवर्क के बीच एक बार में एक चर की तुलना करें और लिखें कि क्या बदला।
ऑफ़िस के Wi-Fi पर काम करता है और फ़ोन के हॉटस्पॉट पर विफल होता है, दोनों ही स्थितियों में VPN जुड़ा है। Git 403 लौटाता है और त्रुटि तीन पंक्तियों की है। लुभावना यह है कि हॉटस्पॉट को कारण मान लिया जाए और नेटवर्क सेटिंग्स बदली जाएँ जब तक कुछ हिल न जाए। HTTP 403 का अर्थ है कि किसी सर्वर ने अनुरोध समझा और उसे ठुकरा दिया, इसलिए उपयोगी सवाल यह है कि कौन सा सर्वर, और उपयोगी अगला कदम वह तुलना है जो एक बार में एक चीज़ बदलती है।
नेटवर्क से पहले स्थिति पढ़ें
403 न विफल खोज है, न TCP का समय-समाप्त होना, न ही अधूरा रह गया TLS हैंडशेक। यह एक निर्णय है, जो किसी ऐसी चीज़ ने लिया जिसने आपका अनुरोध पढ़ा।
जब तक आप नहीं जानते कि वह निर्णय किसने लिया, आप जो भी नेटवर्क बदलाव आज़माते हैं वह विश्वसनीय कहानी के साथ एक अनुमान है।
403 के साथ कौन जवाब दे सकता है?
रिपॉज़िटरी एप्लिकेशन केवल एक उम्मीदवार है। कोई प्रॉक्सी, गेटवे या फ़िल्टरिंग सेवा उसके आगे बैठकर पहले जवाब दे सकती है, और क्लाइंट को दोनों ही स्थितियों में वही स्थिति दिखती है। स्थिति, संबंधित हेडर और साफ़ किया गया त्रुटि निकाय सुरक्षित रखें, फिर उन्हें अधिकृत सेवा के लॉग से मिलाएँ। दूरस्थ URL और वास्तव में पहुँचा गया एंडपॉइंट भी DNS या प्रॉक्सी कॉन्फ़िगरेशन के कारण अलग हो सकते हैं, इसलिए कॉन्फ़िगर किया गया पता और अनुरोध करने वाली प्रक्रिया जाँचें।
अगर इनकार कभी रिपॉज़िटरी तक नहीं पहुँचा, तो उसके लॉग शांत रहेंगे, और वह शांति एक सबूत है।
एक बार में एक चर की तुलना करें
हॉटस्पॉट तुलना इसलिए उपयोगी है क्योंकि यह समस्या को सीमित करती है, इसलिए नहीं कि यह कारण सिद्ध करती है। दो नेटवर्क एक ही समय पर पतों, IP परिवार, प्रॉक्सी, TLS बातचीत और निकास नीति में अलग हो सकते हैं।
हर प्रयास में एक चीज़ बदलें और बाकी लिख लें। नीचे दी तालिका वह न्यूनतम है जो मैं यह करते समय एक नोट में रखता हूँ:
| Keep constant | Record when it changes |
|---|---|
| Repository, operation and credentials | Resolved address and IP family |
| Git process and configuration | Proxy use and the responding component |
| Intended VPN profile | Actual route and exit seen by the service |
काम करने वाले और विफल होने वाले रन के बीच जो एक पंक्ति अलग होती है, अगला घंटा वहीं जाता है।
वर्कअराउंड सबूत है, व्याख्या नहीं
किसी दूसरे पता परिवार को थोपने से गंतव्य, मार्ग या चुना जाने वाला मध्यस्थ बदल सकता है, इसलिए यह परिणाम बदल सकता है पर यह सिद्ध नहीं करता कि IPv6 रिपॉज़िटरी के साथ असंगत है। कोई दूसरा तय किया गया TLS संस्करण उसी श्रेणी का अवलोकन है। इनमें से कोई भी प्रमाणपत्र जाँच बंद करने या कनेक्शन कमज़ोर करने को उचित नहीं ठहराता। पहले काम करने वाले बदलाव पर रुकने के बजाय इनकार करने वाले घटक की नीति और लॉग को असली निर्णय तक ले जाएँ।
जिस वर्कअराउंड को आप समझा नहीं सकते, वह कहीं और फिर विफल होगा।
ऐसी रिपोर्ट लिखें जो ठीक की जाए
जवाब देने वाले घटक के मालिक को वही क्रिया, दो रास्ते और वह घटक दें जिसने मना किया। कुछ भी साझा करने से पहले प्राधिकरण हेडर, अंतर्निहित क्रेडेंशियल और निजी रिपॉज़िटरी विवरण हटा दें।
उपयोगी रिपोर्ट छोटी, दोहराई जा सकने वाली होती है और लक्षण के बजाय परत का नाम लेती है।
जो जाँच मैं क्रम से करता हूँ
दूरस्थ URL और हल किया गया एंडपॉइंट पक्का करें, फिर विफल रन से स्थिति और हेडर कैप्चर करें। दूसरे नेटवर्क पर वही क्रिया दोहराएँ और दोनों रिकॉर्ड की तुलना करें।
फिर वह अंतर उस घटक तक ले जाएँ जिसने जवाब दिया:
- क्लाइंट पर और नेटवर्क पर प्रॉक्सी कॉन्फ़िगरेशन।
- रिपॉज़िटरी के आगे निकास नीति या फ़िल्टरिंग।
- टोकन या खाते का दायरा, समाप्ति और SSO शर्तों सहित।
- टोकन जिस पहचान का प्रतिनिधित्व करता है उसके लिए रिपॉज़िटरी अनुमति।
स्थिति का अर्थ स्वयं RFC 9110 में है, और रिपोर्ट लिखते समय उसे उद्धृत करना उचित है।