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 అంతరాయంగా నిర్ధారణ కాకుండా ఆపుతుంది.