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 खंड म्हणून निदान होण्यापासून थांबवते।