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 തടസ്സമായി രോഗനിർണയം ചെയ്യുന്നത് തടയുന്നു.