സ്വകാര്യ API-യിൽ Requests ProxyError? ആദ്യം പരിസ്ഥിതി പരിശോധിക്കുക

VPN ഓണാണ്, ആന്തരിക ഡാഷ്ബോർഡ് ബ്രൗസറിൽ തുറക്കുന്നു, എന്നിട്ടും Python സ്ക്രിപ്റ്റ് പ്രോക്സി പിശക് നൽകുന്നു. ആ ചിത്രത്തിൽ ടണലിൽ ഒരു പ്രശ്നവുമില്ല: ഇന്റർപ്രിറ്റർ സ്വന്തം പരിസ്ഥിതിയിൽ നിന്ന് പ്രോക്സി വിലാസം വായിച്ച് അഭ്യർത്ഥന അങ്ങോട്ട് അയക്കുന്നു. ഈ ഗൈഡ് പ്രോസസ് യഥാർത്ഥത്തിൽ കാണുന്ന പരിസ്ഥിതി വായിക്കുന്നു, ഏറ്റവും ശക്തമായ ഒഴിവാക്കൽ പ്രയോഗിക്കുന്നു, അതിനുശേഷം മാത്രം വ്യക്തമായ സെഷൻ നയം പരിഗണിക്കുന്നു. ഓരോ ഘട്ടവും ഔട്ട്പുട്ട് തുടരണോ എന്ന് തീരുമാനിക്കുന്ന കമാൻഡിൽ അവസാനിക്കുന്നു.

പ്രോസസ് യഥാർത്ഥത്തിൽ കാണുന്ന പരിസ്ഥിതി വായിക്കുക

ഡെസ്ക്ടോപ്പ് പ്രോക്സി ക്രമീകരണങ്ങൾ, shell എക്സ്പോർട്ടുകൾ, systemd യൂണിറ്റിന്റെ Environment= വരികൾ എന്നിവ മൂന്ന് വ്യത്യസ്ത സ്രോതസ്സുകളാണ്, Requests അവസാനം പാരമ്പര്യമായി ലഭിക്കുന്നത് മാത്രം വായിക്കുന്നു. പരാജയപ്പെടുന്ന സ്ക്രിപ്റ്റ് പ്രവർത്തിക്കുന്ന അതേ shell, കണ്ടെയ്നർ അല്ലെങ്കിൽ യൂണിറ്റിൽ താഴെയുള്ള ഡയഗ്നോസ്റ്റിക്സ് പ്രവർത്തിപ്പിക്കുക, നിങ്ങളുടെ ഇന്ററാക്ടീവ് ടെർമിനലിൽ അല്ല. നിങ്ങളുടെ ലോഗിൻ shell-ൽ എക്സ്പോർട്ട് ചെയ്ത വേരിയബിൾ കണ്ടെയ്നർ പ്രോസസ്സിന് അദൃശ്യമാണ്, ആ വിടവാണ് എവിടെ നിന്നോ ഉയർന്നുവരുന്ന പ്രോക്സിയെക്കുറിച്ചുള്ള പല റിപ്പോർട്ടുകളും വിശദീകരിക്കുന്നത്. രണ്ട് കമാൻഡുകളും ഒരേ ഡാറ്റ വ്യത്യസ്ത വിശദാംശ തലങ്ങളിൽ പ്രിന്റ് ചെയ്യുന്നു.

env | grep -i -E 'proxy|requests_ca_bundle|curl_ca_bundle'
python3 -c "import os;[print(k,'=',v) for k,v in sorted(os.environ.items()) if 'proxy' in k.lower()]"

ഓരോ വേരിയബിളിന്റെയും രണ്ട് അക്ഷരവിന്യാസങ്ങളും വായിക്കുന്നു, ആവർത്തിച്ചുള്ള എൻട്രികൾ പ്രോസസ് ലഭിച്ച ക്രമത്തിൽ പ്രയോഗിക്കുന്നു, അതിനാൽ പഴയ HTTP_PROXY നിങ്ങൾ ഇപ്പോൾ എക്സ്പോർട്ട് ചെയ്ത മൂല്യത്തെ മറികടക്കാം. CA ബണ്ടിൽ വേരിയബിളുകൾ ഇവിടെയും പ്രധാനമാണ്, കാരണം കോഡിൽ എവിടെയും കാണാതെ തന്നെ verify എന്തിലേക്ക് പരിഹരിക്കുന്നു എന്ന് അവ മാറ്റുന്നു. ഔട്ട്പുട്ട് ശൂന്യമാണെങ്കിൽ പരിസ്ഥിതി നിങ്ങളുടെ പ്രശ്നമല്ല, ഈ വിഭാഗം വായിക്കുന്നത് നിർത്താം. നിങ്ങൾ തിരിച്ചറിയാത്ത ഒരു പ്രോക്സി അത് പട്ടികപ്പെടുത്തിയാൽ, എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് അത് സെറ്റ് ചെയ്യുന്ന ഫയലോ യൂണിറ്റോ കണ്ടെത്തുക.

ഒരു നിർദ്ദിഷ്ട URL-നൊപ്പം Requests എന്ത് ചെയ്യുമെന്ന് ചോദിക്കുക. ഈ വിളി പാക്കറ്റ് അയക്കാതെ ആ അഭ്യർത്ഥനയുടെ ലയിപ്പിച്ച പ്രോക്സി, verify, cert മൂല്യങ്ങൾ കാണിക്കുന്നു.

python3 -c "import requests;s=requests.Session();print(s.merge_environment_settings('https://api.corp.example/status',{},None,None,None))"

സ്വകാര്യ ഹോസ്റ്റിനുള്ള ശൂന്യമല്ലാത്ത proxies എൻട്രിയാണ് നിങ്ങളുടെ ഉത്തരം, പ്രിന്റ് ചെയ്ത verify മൂല്യം അഭ്യർത്ഥന ഏത് CA ബണ്ടിലിനെ വിശ്വസിക്കുമെന്ന് പറയുന്നു. രണ്ടും ശരിയാണെന്ന് തോന്നിയാൽ പരാജയം സ്റ്റാക്കിൽ പിന്നീടാണ്, നിങ്ങൾ പരിശോധനാ വിഭാഗത്തിലേക്ക് പോകണം. കോഡിൽ നിന്ന് ഊഹിക്കരുത്: ലയനം ഓരോ അഭ്യർത്ഥനയ്ക്കും സംഭവിക്കുന്നു, അതിനാലാണ് ഒരു സെഷൻ രണ്ട് ഹോസ്റ്റുകളിൽ വ്യത്യസ്തമായി പെരുമാറുന്നത്.

എന്തെങ്കിലും പ്രവർത്തനരഹിതമാക്കുന്നതിന് മുമ്പ് സ്വകാര്യ ഹോസ്റ്റ് ഒഴിവാക്കുക

മറ്റ് ലക്ഷ്യസ്ഥാനങ്ങൾക്ക് പ്രോക്സി യഥാർത്ഥത്തിൽ ആവശ്യമാണെങ്കിൽ, ഇടുങ്ങിയ പരിഹാരം ഈ ഹോസ്റ്റിനുള്ള ഒഴിവാക്കലാണ്. നിലവിലുള്ള പട്ടിക മാറ്റിസ്ഥാപിക്കാതെ അതിൽ ചേർക്കുക, കാരണം NO_PROXY മായ്ക്കുന്നത് അതിനെ ആശ്രയിച്ചിരുന്ന മറ്റെല്ലാ ആന്തരിക ലക്ഷ്യസ്ഥാനങ്ങളെയും തകർക്കും. താഴെയുള്ള കമാൻഡുകൾ എൻട്രി ചേർത്ത്, ബൈപാസ് ബാധകമാണോ എന്ന് Requests-നോട് ചോദിക്കുന്നു.

export NO_PROXY="${NO_PROXY:+$NO_PROXY,}api.corp.example,.corp.example"
python3 -c "import requests;print(requests.utils.should_bypass_proxies('https://api.corp.example/status',None))"

പൊരുത്തം ഹോസ്റ്റ് പ്രത്യയത്തിന്റെ അടിസ്ഥാനത്തിലാണ്, അതിനാൽ .corp.example മുഴുവൻ ഡൊമെയ്നും ഉൾക്കൊള്ളുന്നു, api.corp.example ഒരു പേര് മാത്രം. വെറും നക്ഷത്രചിഹ്നം എല്ലാ ഹോസ്റ്റുകൾക്കും പ്രോക്സി പ്രവർത്തനരഹിതമാക്കുന്നു, ഉത്പാദന ജോലി അതാണ് ആവശ്യപ്പെടുന്നത് എന്നത് ഏറെക്കുറെ ഒരിക്കലും സംഭവിക്കില്ല. CIDR എൻട്രി പരിഗണിക്കപ്പെടുമോ എന്നത് ഇമേജിലെ Requests, urllib3 പതിപ്പുകളെ ആശ്രയിച്ചിരിക്കുന്നു, അതിനാൽ പ്രവർത്തിക്കുമെന്ന് അനുമാനിക്കാതെ കൃത്യമായ എൻട്രി പരീക്ഷിക്കുക. should_bypass_proxies ന്റെ ഫലം യഥാർത്ഥ URL-ന് പരിശോധിക്കുക, ഓർമ്മയിൽ നിന്ന് ടൈപ്പ് ചെയ്ത ഹോസ്റ്റ്നാമിനല്ല.

രണ്ട് പാളികളും മനസ്സിൽ വേർതിരിച്ച് സൂക്ഷിക്കുക. HTTP പ്രോക്സി ബൈപാസ് ചെയ്യുന്നത് VPN ബൈപാസ് ചെയ്യുന്നില്ല, കാരണം പ്രോക്സി തീരുമാനം ലൈബ്രറിയിലും ടണൽ തീരുമാനം കെർണലിന്റെ റൂട്ടിംഗ് പട്ടികയിലും എടുക്കുന്നു.

trust_env ബോധപൂർവമായ സെഷൻ നയമായി മാത്രം പ്രവർത്തനരഹിതമാക്കുക

മുഴുവൻ ജോലിയും ചുറ്റുമുള്ള കോൺഫിഗറേഷൻ അവഗണിക്കേണ്ടതുണ്ടെങ്കിൽ, സെഷൻ വ്യക്തമായി നിർമ്മിച്ച് തീരുമാനം കോഡിൽ രേഖപ്പെടുത്തുക. ഇത് ഒരു നയമാണ്, പരിഹാരമല്ല, അത് അവലോകകന് കാണാവുന്ന diff-ൽ ഉണ്ടായിരിക്കണം. താഴെയുള്ള ഉദാഹരണം ടൈംഔട്ട്, വ്യക്തമായ CA പാത, സ്റ്റാറ്റസ് പരിശോധന എന്നിവ നിലനിർത്തുന്നു.

import requests

with requests.Session() as session:
    session.trust_env = False
    response = session.get(
        "https://api.corp.example/status",
        timeout=(5, 20),
        verify="/etc/ssl/certs/corp-ca.pem",
    )
    response.raise_for_status()

trust_env പ്രവർത്തനരഹിതമാക്കുന്നത് ഒരേസമയം മൂന്ന് പെരുമാറ്റങ്ങൾ മാറ്റുന്നു, അവയിൽ ഒന്ന് മാത്രമാണ് പ്രോക്സിയെക്കുറിച്ചുള്ളത്. Requests .netrc ക്രെഡൻഷ്യലുകൾ വായിക്കുന്നത് നിർത്തുന്നു, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE വേരിയബിളുകൾ verify-നെ സ്വാധീനിക്കുന്നത് നിർത്തുന്നു, അത് പിന്നീട് ഉൾപ്പെടുത്തിയ സർട്ടിഫിക്കറ്റ് സ്റ്റോറിലേക്ക് പോകുന്നു. നിങ്ങളുടെ സ്ഥാപനം സ്വന്തം CA ഉപയോഗിച്ച് TLS അവസാനിപ്പിക്കുന്നുവെങ്കിൽ, ആ പിൻവാങ്ങൽ ഇപ്പോൾ വരുത്തിയ മാറ്റവുമായി ബന്ധമില്ലെന്ന് തോന്നുന്ന ഒരു പരിശോധനാ പിശക് ഉയർത്തുന്നു. verify വ്യക്തമായി കൈമാറുന്നതാണ് രണ്ട് ഫലങ്ങളെ വേർതിരിച്ച് നിർത്തുന്നത്.

ചെയ്യരുതാത്തത് ഉണ്ടായ പിശക് ശാന്തമാക്കാൻ verify=False സെറ്റ് ചെയ്യുന്നതാണ്. അത് പ്രോക്സിയുടെ തെറ്റായ കോൺഫിഗറേഷനെ പരിശോധിക്കാത്ത കണക്ഷനുമായി കൈമാറുന്നു, ഒഴിവാക്കൽ വെളിപ്പെടുത്തേണ്ടിയിരുന്ന സർട്ടിഫിക്കറ്റ് പ്രശ്നം മറയ്ക്കുന്നു.

പരാജയപ്പെടുന്ന പാളി പരിശോധിച്ച് പിൻവലിക്കാനുള്ള കഴിവ് നിലനിർത്തുക

മൂന്ന് പരാജയങ്ങൾ ലോഗിൽ ഒരുപോലെ കാണപ്പെടുന്നു, അവയ്ക്ക് പൊതുവായത് ഒന്നുമില്ല: ലക്ഷ്യസ്ഥാനത്ത് എത്താത്ത പ്രോക്സി ProxyError എറിയുന്നു അല്ലെങ്കിൽ 502 തിരികെ നൽകുന്നു, വിശ്വാസ പ്രശ്നം SSLError എറിയുന്നു, ആപ്ലിക്കേഷൻ നിരസിക്കൽ 401 അല്ലെങ്കിൽ 403 നൽകുന്നു. നിങ്ങൾക്ക് ഏതാണെന്ന് കാണാൻ അഭ്യർത്ഥന Requests-ന് പുറത്ത് പുനർനിർമ്മിക്കുക. താഴെയുള്ള കമാൻഡുകൾ പ്രോക്സി നീക്കി, സർട്ടിഫിക്കറ്റ് ശൃംഖല പരിശോധിച്ച്, പിന്നീട് ലൈബ്രറിയിലൂടെ വിളി ആവർത്തിക്കുന്നു.

curl -sv --noproxy '*' https://api.corp.example/status -o /dev/null
openssl s_client -connect api.corp.example:443 -servername api.corp.example </dev/null
python3 -c "import requests;r=requests.get('https://api.corp.example/status',timeout=10);print(r.status_code)"

curl വിളി വിജയിക്കുകയും Python വിളി പരാജയപ്പെടുകയും ചെയ്താൽ വ്യത്യാസം ഇപ്പോഴും പരിസ്ഥിതിയാണ്. രണ്ടും TLS ഘട്ടത്തിൽ പരാജയപ്പെട്ടാൽ പ്രോക്സി ഒരിക്കലും പ്രശ്നമായിരുന്നില്ല, പ്രശ്നം സർട്ടിഫിക്കറ്റ് ശൃംഖലയാണ്. രണ്ടും 401 നൽകിയാൽ അഭ്യർത്ഥന ആപ്ലിക്കേഷനിൽ എത്തി, ബാക്കിയുള്ള ജോലി പ്രാമാണീകരണമാണ്. മൂന്നിൽ ഏതാണ് നിരീക്ഷിച്ചതെന്ന് രേഖപ്പെടുത്തുന്നത് അടുത്തയാൾക്ക് ഒരു മണിക്കൂർ ലാഭിക്കുന്നു.

പിൻവലിക്കൽ ഏത് ദിശയിലും ഒരു വരിയാണ്: ഒഴിവാക്കൽ നീക്കുക, അല്ലെങ്കിൽ trust_env തിരികെ മാറ്റുക. ചേർക്കുന്നതിന് മുമ്പ് മുൻ NO_PROXY മൂല്യം സംരക്ഷിക്കുക, നിങ്ങളുടെ ടെർമിനൽ ചരിത്രത്തിൽ മാത്രം ജീവിക്കുന്ന എക്സ്പോർട്ടിനേക്കാൾ റാപ്പർ സ്ക്രിപ്റ്റോ യൂണിറ്റ് തലത്തിലുള്ള Environment= എൻട്രിയോ തിരഞ്ഞെടുക്കുക. രണ്ട് മാറ്റങ്ങളും പ്രോസസ് പരിസ്ഥിതിയിൽ കാണാം, അതിനാൽ പുനരാരംഭം സാധാരണയായി നിങ്ങളെ പഴയ പെരുമാറ്റത്തിലേക്ക് തിരികെ കൊണ്ടുവരുന്നു.

നാല് കാര്യങ്ങൾ സ്ഥിരീകരിച്ച് അവസാനിക്കുക: സ്വകാര്യ URL-ന്റെ ലയിപ്പിച്ച ക്രമീകരണങ്ങൾ പ്രോക്സി കാണിക്കുന്നില്ല, സർട്ടിഫിക്കറ്റ് ഉദ്ദേശിച്ച CA-യ്ക്കെതിരെ സാധൂകരിക്കുന്നു, അഭ്യർത്ഥന നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന സ്റ്റാറ്റസ് നൽകുന്നു, മാറ്റം പുനർനിർമ്മിക്കാവുന്ന ഇടത്ത് commit ചെയ്തിട്ടുണ്ട്. വിശദീകരിക്കാത്ത പരിസ്ഥിതിയോടെയുള്ള പച്ച സ്ക്രിപ്റ്റ് അടുത്ത യന്ത്രത്തിൽ വീണ്ടും തകരുന്ന ഒരു പരിഹാരമാണ്. ഈ ഗൈഡിലെ കമാൻഡുകളാണ് ടിക്കറ്റിൽ ഒട്ടിക്കേണ്ടത്.