Requests ProxyError API pribatu batean? Egiaztatu ingurunea lehenengo

VPN-a martxan dago, barne-panelak nabigatzailean irekitzen dira, eta Python scriptak oraindik proxy errore bat jaurtitzen du. Irudi horretan ez dago ezer oker tunelarekin: interpreteak proxy helbide bat irakurtzen du bere ingurunetik eta eskaera bertara bidaltzen du. Gida honek prozesuak benetan ikusten duen ingurunea irakurtzen du, bazterketa estuena aplikatzen du eta ondoren bakarrik aztertzen du saio-politika esplizitua. Urrats bakoitza irteerak jarraitzeko erabakitzen duen komando batekin amaitzen da.

Irakurri prozesuak benetan ikusten duen ingurunea

Mahaigaineko proxy ezarpenak, shell esportazioak eta systemd unitate baten Environment= lerroak hiru iturri desberdin dira, eta Requestsek heredatzen duen azkena bakarrik irakurtzen du. Exekutatu beheko diagnostikoa script huts egiten ari den shell, edukiontzi edo unitate berean, ez zure terminal interaktiboan. Zure saio-hasierako shellan esportatutako aldagai bat ikusezina da edukiontzi prozesu batentzat, eta hutsune horrek azaltzen ditu nondik ezerezetik agertzen den proxy bati buruzko txosten asko. Bi komandoek datu berak inprimatzen dituzte xehetasun maila desberdinetan.

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()]"

Aldagai bakoitzaren bi idazkerak irakurtzen dira, eta erregistro bikoiztuak prozesuak jaso zituen ordenan aplikatzen dira, beraz HTTP_PROXY zaharkitu batek orain esportatu duzun balioa gaindi dezake. CA bundle aldagaiek ere garrantzia dute hemen, aldatzen baitute verify zertara ebazten den kodean inon agertu gabe. Irteera hutsik badago, ingurunea ez da zure arazoa eta atal hau irakurtzeari utz diezaiokezu. Ezagutzen ez duzun proxy bat zerrendatzen badu, aurkitu ezartzen duen fitxategia edo unitatea ezer aldatu aurretik.

Galdetu Requests-i zer egingo lukeen URL zehatz batekin. Deialdi honek eskaera horretarako proxy, verify eta cert balio bateratuak erakusten ditu paketerik bidali gabe.

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

Host pribaturako proxies sarrera ez-hutsa da zure erantzuna, eta inprimatutako verify balioak eskaerak zein CA bundle izango lukeen fidagarri esaten dizu. Biak zuzenak badirudi, hutsegitea pilaren geroago dago eta egiaztapen atalera joan beharko zenuke. Ez asmatu kodetik: bateratzea eskaera bakoitzeko gertatzen da, horregatik saio batek modu desberdinean joka dezake bi hostentzat.

Baztertu host pribatua ezer desgaitu aurretik

Proxy-a benetan beharrezkoa denean beste helmuga batzuetarako, konponketa estua host honetarako bazterketa da. Gehitu lehendik dagoen zerrendari ordezkatu beharrean, NO_PROXY ezabatzeak harekin fidatzen zen beste barne-helmuga guztiak apurtzen baititu. Beheko komandoek sarrera gehitzen dute eta gero Requestsi galdetzen diote saihesbidea aplikatzen den.

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))"

Bat-etortzea host atzizkiaren araberakoa da, beraz .corp.example domeinu osoa estaltzen du eta api.corp.example izen bakarra. Izar soil batek proxy-a desgaitzen du host guztientzat eta ia inoiz ez da ekoizpen-lan batek nahi duena. CIDR sarrera bat errespetatzen den Requestsen eta urllib3ren irudiko bertsioen araberakoa da, beraz probatu sarrera zehatza funtzionatzen duela suposatu beharrean. Egiazta itzazu should_bypass_proxies-ren emaitza URL erreala, memoriatik idatzitako host izen batentzat ez.

Eduki bi geruzak bereiz buruan. HTTP proxy-a saihesteak ez du VPN-a saihesten, proxy-erabakia liburutegian hartzen baita eta tunel-erabakia nukleoaren bideratze-taulan.

Desgaitu trust_env saio-politika kontziente gisa soilik

Lan osoak inguruneko konfigurazioa alde batera utzi behar badu, eraiki saioa modu esplizituan eta erregistratu erabakia kodean. Hori politika da, ez konponbide alternatiboa, eta berrikusleak ikus dezakeen diff batean dagokio. Beheko adibideak timeout bat, CA bide esplizitu bat eta egoera egiaztatze bat mantentzen ditu.

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 desgaitzeak hiru jokabide aldatzen ditu aldi berean, eta horietako bakarra da proxiri buruzkoa. Requestsek .netrc kredentzialak irakurtzeari uzten dio, eta REQUESTS_CA_BUNDLE eta CURL_CA_BUNDLE aldagaiek verify-ri eragiteari uzten diote, eta hark barnean dakarren ziurtagiri biltegira jotzen du orduan. Zure erakundeak bere CA propioarekin amaitzen badu TLS, atzera-egite horrek egiaztapen errore bat sortzen du, orain egin berri duzun aldaketarekin zerikusirik ez duela dirudiena. verify modu esplizituan pasatzea da bi efektuak bereiz mantentzen dituena.

Egin behar ez duzuna verify=False ezartzea da sortutako errorea isilarazteko. Horrek proxy konfigurazio okerra egiaztatu gabeko konexio batekin trukatzen du, eta bazterketak agerian utzi behar zuen ziurtagiri arazoa ezkutatzen du.

Egiaztatu huts egiten duen geruza eta mantendu atzera-egiteko aukera

Hiru hutsegitek berdin dirudite erregistro batean eta ez dute ezer komunik: helmugara iristen ez den proxy batek ProxyError jaurtitzen du edo 502 itzultzen du, konfiantza arazo batek SSLError jaurtitzen du, eta aplikazioaren ukapen batek 401 edo 403 itzultzen du. Erakutsi eskaera Requestsetik kanpo zein duzun ikusteko. Beheko komandoek proxy-a kentzen dute, ziurtagiri katea probatzen dute eta gero deialdia liburutegitik errepikatzen dute.

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 deialdia ondo ateratzen bada eta Python deialdia huts egiten badu, ingurunea da oraindik aldea. Biak TLS fasean huts egiten badute, proxy-a inoiz ez zen arazoa eta ziurtagiri katea da. Biak 401 itzultzen badute, eskaera aplikaziora iritsi da eta gainerako lana autentifikazioa da. Hiruretatik zein behatu duzun erregistratzeak hurrengo pertsonari ordu bat aurrezten dio.

Atzera-egitea lerro bat da edozein norabidetan: kendu bazterketa edo itzuli trust_env atzera. Gorde aurreko NO_PROXY balioa gehitu aurretik, eta hobetsi bilgarri script bat edo unitate mailako Environment= sarrera bat zure terminaleko historian soilik bizi den esportazio baten ordez. Bi aldaketak prozesuaren ingurunean ikusgai daude, beraz berrabiarazteak normalean jokabide zaharrera itzultzen zaitu.

Amaitu lau gauza baieztatuz: URL pribaturako ezarpen bateratuek ez dute proxy-rik erakusten, ziurtagiriak aurreikusitako CAren aurka balioztatzen du, eskaerak espero duzun egoera itzultzen du, eta aldaketa errepika daitekeen leku batean konprometituta dago. Ingurune azaldugabea duen script berde bat hurrengo makinan berriro apurtzen den konponketa da. Gida honetako komandoak txartelean itsastekoak dira.