VPN साइट से 403 प्रॉक्सी विफलता क्यों नहीं है
मूल से 403, अस्वीकृत CONNECT और 407 चुनौती अलग-अलग सीमाएँ दर्शाते हैं। पहले प्रॉक्सी का निकास पथ ब्राउज़र के VPN पते से तुलना करें।
उपयोगकर्ता VPN काट देते हैं, किसी आंतरिक साइट पर 403 पाते हैं और बताते हैं कि प्रॉक्सी खराब है। तीन अलग चीज़ें वह पृष्ठ बना सकती हैं: मूल ने अनुरोध अस्वीकार किया, फ़ॉरवर्ड प्रॉक्सी ने सुरंग खोलने से इनकार किया, या प्रॉक्सी ने अपने स्वयं के क्रेडेंशियल माँगे। इनमें से हर एक अलग प्रश्न का सही उत्तर है, और इन्हें एक सामान्य विफलता पृष्ठ में समतल करना आपके पास मौजूद एकमात्र साक्ष्य को नष्ट कर देता है। अस्वीकृति को उस घटक के अनुसार छाँटें जिसने उसे बनाया, फिर हर घटक द्वारा वास्तव में उपयोग किए जाने वाले नेटवर्क पथ की तुलना करें।
403 उत्पन्न करने वाले घटक का नाम बताएँ
HTTP स्थिति कोड उस पक्ष का है जिसने उसे भेजा। जब मूल 403 लौटाता है, तो उसने अनुरोध का विश्लेषण किया है और तय किया है कि कॉलर के पास संसाधन नहीं हो सकता, जो प्राधिकरण का उत्तर है, परिवहन की समस्या नहीं। जब फ़ॉरवर्ड प्रॉक्सी CONNECT को 403 उत्तर देता है, तो उसने सुरंग बनाने से पूरी तरह इनकार कर दिया है और ऊपर की ओर किसी से कभी संपर्क नहीं हुआ। जब वह 407 उत्तर देता है, तो वह अपने स्वयं के क्रेडेंशियल चाहता है, जिनका अनुप्रयोग के लॉगिन से कोई संबंध नहीं है।
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
RFC 9110 इन भूमिकाओं को परिभाषित करता है, जिसमें प्रॉक्सी-विशिष्ट चुनौती भी शामिल है। मुख्य भाग पढ़ने से पहले प्रतिक्रिया की अपनी स्थिति और कोई भी Proxy-Authenticate हेडर पढ़ें, क्योंकि मैत्रीपूर्ण HTML त्रुटि पृष्ठ आमतौर पर छिपा देता है कि इसे किस घटक ने लिखा।
CONNECT सुरंग बाइट रिले से क्या छिपाती है
प्रॉक्सी के CONNECT को 200 लौटाने के बाद वह बाइट्स रिले कर रहा होता है और ब्राउज़र मूल के साथ अपना TLS सत्र रखता है। इसलिए बाइट-रिले करने वाला प्रॉक्सी उस सत्र के भीतर एन्क्रिप्टेड 403 नहीं पढ़ सकता, और वह कभी अस्वीकृति का लेखक नहीं बनता। सुरंग खुलने से पहले की अस्वीकृति पूरी तरह अलग घटना है, जो एक परत नीचे उत्पन्न होती है।
TLS समाप्त करने वाला रिवर्स प्रॉक्सी अलग स्थिति में है: वह TLS सीमा का स्वामी है, HTTP का विश्लेषण करता है और वैध रूप से प्रतिक्रियाएँ फिर से लिख या रोक सकता है। यह क्षमता कॉन्फ़िगरेशन का चुनाव है, सामान्य रूप से प्रॉक्सी की विशेषता नहीं, और यह अनुप्रयोग की पहुँच नीति को दरकिनार करने का अधिकार नहीं देती। प्रतिक्रिया पढ़ना एक क्षमता है; कॉलर क्या देख सकता है यह तय करना मूल का काम ही रहता है।
व्यावहारिक परिणाम यह है कि 403 की व्याख्या करने से पहले आपको जानना होगा कि आप तीन रूपों में से कौन-सा चलाते हैं। स्ट्रीम प्रॉक्सी में HTTP निरीक्षण नियम जोड़ने से उसे दृश्यता नहीं मिलती, और बाइट रिले से मूल की अस्वीकृति समझाने की अपेक्षा आपको गलत लॉग में भेजेगी।
प्रॉक्सी के निकास पथ की ब्राउज़र की सुरंग पते से तुलना करें
VPN से जुड़ा ब्राउज़र अलग प्रॉक्सी सर्वर को स्वतः उस सुरंग पर नहीं ले जाता। मूल प्रॉक्सी का निकास पता देखता है, और यदि प्रॉक्सी अब भी स्थानीय डिफ़ॉल्ट मार्ग से बाहर जाता है, तो संरक्षित साइट ऐसा पता देखती है जिस पर कभी भरोसा करने के लिए कॉन्फ़िगर नहीं किया गया था। लैपटॉप का आंतरिक VPN पता उस मूल के लिए अदृश्य है। यह सबसे आम कारण है कि काम करती सुरंग भी ऐसी साइट से 403 देती है जो बाकी सबके लिए सही व्यवहार करती है।
दोनों पथों को अलग-अलग जाँचें ताकि पते भ्रमित न हों।
curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/privateपहला अनुरोध दिखाता है कि मूल आपके अपने पते के लिए क्या उत्तर देता है, दूसरा दिखाता है कि प्रॉक्सी के पते के लिए क्या उत्तर देता है। मेल खाती 403 की जोड़ी मूल के प्राधिकरण नियमों की ओर संकेत करती है; 200 के बाद 403 प्रॉक्सी पथ की ओर संकेत करता है। यह मानने के बजाय कि VPN पूल शामिल है, मूल के स्वामी से पूछें कि नियम-समूह वास्तव में कौन-से स्रोत पते स्वीकार करता है।
हर सीमा को उस अनुरोध से जाँचें जो उसे अलग करता है
प्रॉक्सी परत को अलग करें उससे ऐसी चीज़ माँगकर जिसे वह अनुप्रयोग के कारणों से अस्वीकार नहीं कर सकता। जिस होस्ट तक प्रॉक्सी को पहुँचने की अनुमति है, उसके लिए CONNECT, आउटपुट फेंककर, आपको बताता है कि सुरंग प्रवेश बिलकुल काम करता है या नहीं।
curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'
यदि यह CONNECT के लिए 200 और फिर TLS हैंडशेक छापता है, तो प्रॉक्सी प्रवेश ठीक है और बाद वाला 403 मूल से आया। यदि यह 407 छापता है, तो --proxy-user के साथ प्रॉक्सी क्रेडेंशियल दें और साइट के बारे में कोई निष्कर्ष निकालने से पहले दोहराएँ। यदि यह CONNECT पंक्ति पर 403 छापता है, तो प्रॉक्सी की अपनी अनुमति सूची जाँचने की सीमा है, और अनुप्रयोग इसमें शामिल नहीं है।
क्रेडेंशियल को शेल इतिहास और चिपकाए गए ट्रांस्क्रिप्ट से दूर रखें। कमांड पंक्ति में टाइप किया गया प्रॉक्सी पासवर्ड अन्य स्थानीय उपयोगकर्ताओं को दिखाई देता है, और क्रेडेंशियल के साथ पकड़ा गया CONNECT निशान किसी भी निशान से बुरा है।
पृष्ठ को फिर से लिखने के बजाय निर्णय को पठनीय रखें
यह जानने के बाद कि किस घटक ने अस्वीकार किया, उस उत्तर को सुरक्षित रखें। जो रिवर्स प्रॉक्सी मूल के 403 को 504 टाइमआउट के रूप में फिर से लेबल करता है, या उसे सफलता पृष्ठ से बदल देता है, वह प्राधिकरण के निर्णय को उपलब्धता की कहानी के पीछे छिपाता है और अगले उत्तरदाता को गलत टीम में भेजता है। कस्टम त्रुटि पृष्ठ तब अच्छे होते हैं जब वे स्थिति रखते हैं और संदर्भ जोड़ते हैं।
कैशिंग भी उसी देखभाल की हक़दार है। RFC 9111 नियंत्रित करता है कि साझा कैश प्रतिक्रियाओं का पुनः उपयोग कैसे कर सकते हैं, और एक कॉलर के लिए उत्पन्न अस्वीकृति को दूसरे को अनुमति की तरह नहीं दिया जाना चाहिए। यदि अस्वीकृति प्रतिक्रियाएँ बिलकुल संग्रहीत की जाती हैं, तो उन्हें निजी और सीमित रखें, और केवल ऊपर की ओर ट्रैफ़िक घटाने के लिए कभी सार्वजनिक ताज़गी नियम न जोड़ें।
एक लिखित निर्णय के साथ समाप्त करें जो घटक, उसकी उत्पन्न स्थिति और मूल द्वारा देखे गए स्रोत पते का नाम बताए। सटीक अनुरोध, लागू प्रॉक्सी सेटिंग्स और समय दर्ज करें, ताकि अगली रिपोर्ट को स्मृति से फिर से निकालने के बजाय उन्हीं साक्ष्यों से मिलाया जा सके। वह रिकॉर्ड अगली रिपोर्ट का उत्तर सेकंडों में देता है और उसी 403 को फिर से VPN व्यवधान के रूप में निदान होने से रोकता है।