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 अवरोधका रूपमा निदान गर्नबाट रोक्छ।