ولې د 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 خنډ په توګه تشخیصیدو څخه منع کوي۔