ProxyError fan Requests by in privee-API? Kontrolearje earst de omjouwing

De VPN is oan, it ynterne dashboard iepenet yn in browser, en it Python-skript smyt noch altyd in proxy-flater. Oan 'e tunnel is yn dat byld neat mis: de ynterpretearder lêst in proxy-adres út syn eigen omjouwing en stjoert it fersyk dêrhinne. Dit hânboek lêst de omjouwing dy't it proses echt sjocht, past de smelste útsluting ta en betinkt pas dêrnei in eksplisyt sesjebelied. Eltse stap einiget mei in opdracht waans útfier beslút oft jo trochgeane.

Lês de omjouwing dy't it proses echt sjocht

Proxy-ynstellings fan it buroblêd, shell-eksporten en de Environment=-regels fan in systemd-ienheid binne trije ferskillende boarnen, en Requests lêst allinnich de lêste dy't it erft. Rin de diagnoaze hjirûnder yn deselde shell, container of ienheid dy't it mislearjende skript draait, net yn jo ynteraktive terminal. In fariabele dy't yn jo oanmeldingsshell eksportearre is, is ûnsichtber foar in containerproses, en dy kleau ferklearret in soad rapporten oer in proxy dy't fan neat ôf ferskynt. De twa opdrachten printsje deselde gegevens op ferskillende detailnivo's.

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

Beide staveringen fan elke fariabele wurde lêzen, en dûbele ynfieringen wurde tapast yn 'e folchoarder wêryn it proses se krige, sadat in ferâldere HTTP_PROXY de wearde dy't jo krekt eksportearre hawwe, oerskriuwe kin. De CA-bundelfariabelen binne hjir ek fan belang, want se feroarje wêryn't verify oplost sûnder earne yn 'e koade te ferskinen. As de útfier leech is, is de omjouwing net jo probleem en kinne jo ophâlde dizze seksje te lêzen. As it in proxy listet dy't jo net werkenne, fyn dan it bestân of de ienheid dy't it ynstelt foardat jo wat feroarje.

Freegje Requests wat it mei in spesifike URL dwaan soe. Dizze oprop toant de gearfoege proxy-, verify- en cert-wearden foar dat fersyk sûnder in pakket te stjoeren.

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

In net-lege proxies-ynfier foar de privee-host is jo antwurd, en de printe verify-wearde fertelt jo hokker CA-bundel it fersyk fertrouwe soe. As beide goed lykje, is de mislearring letter yn 'e stapel en moatte jo nei de ferifikaasjeseksje springe. Riedt net út 'e koade: de gearfoeging bart per fersyk, dêrom kin ien sesje him foar twa hosts oars hâlde.

Slút de privee-host út foardat jo wat útsette

As de proxy echt nedich is foar oare bestimmingen, is de smelle oplossing in útsluting foar dizze host. Foegje ta oan 'e besteande list ynstee fan dy te ferfangen, want it wiskjen fan NO_PROXY brekt elke oare ynterne bestimming dy't dêrop fertroude. De opdrachten hjirûnder foegje de ynfier ta en freegje Requests dan oft de omgong jildt.

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

It oerienkommen is op host-suffiks, dus .corp.example beslacht it hiele domein wylst api.corp.example ien namme beslacht. In bleate stjer set proxy foar elke host út en is hast nea wat in produksjetaak wol. Oft in CIDR-ynfier respektearre wurdt, hinget ôf fan 'e Requests- en urllib3-ferzjes yn 'e image, dus test de krekte ynfier ynstee fan oan te nimmen dat it wurket. Kontrolearje it resultaat fan should_bypass_proxies foar de echte URL, net foar in hostnamme dy't jo út 't ûnthâld typt hawwe.

Hâld de twa lagen apart yn jo holle. It omgean fan 'e HTTP-proxy omgiet net de VPN, want it proxy-beslút falt yn 'e bibleteek en it tunnelbeslút falt yn 'e routeringstabel fan 'e kearn.

Sette trust_env allinnich út as in bewust sesjebelied

As de hiele taak de omjouwingskonfiguraasje negearje moat, bou dan de sesje eksplisyt en liz it beslút fêst yn 'e koade. Dat is in belied, gjin omgong, en it heart yn in diff dy't in resinsint sjen kin. It foarbyld hjirûnder hâldt in timeout, in eksplisyt CA-paad en in statuskontrôle oan.

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

It útsetten fan trust_env feroaret trije gedragingen tagelyk, en mar ien dêrfan giet oer proxies. Requests hâldt op mei it lêzen fan .netrc-bewizen, en de fariabelen REQUESTS_CA_BUNDLE en CURL_CA_BUNDLE beynfloedzje verify net mear, dat dan weromfalt op 'e bundele sertifikaatopslach. As jo organisaasje TLS mei har eigen CA beëiniget, smyt dat weromfallen in ferifikaasjeflater op dy't neat mei de wiziging liket te meitsjen. It eksplisyt trochjaan fan verify is wat de twa effekten apart hâldt.

Wat jo net dwaan moatte is verify=False ynstelle om de resultearjende flater stil te meitsjen. Dat ruilet in ferkearde proxy-konfiguraasje foar in net-ferifisearre ferbining, en it ferberget it sertifikaatprobleem dat de útsluting bleatlegje moast.

Ferifisearje de mislearjende laach en hâld in weromdraai

Trije flaters lykje yn in log itselde en hawwe neat mienskiplik: in proxy dy't de bestimming net berikt smyt ProxyError of jout 502 werom, in fertrouwensprobleem smyt SSLError, en in ôfwizing fan 'e applikaasje jout 401 of 403 werom. Meitsje it fersyk bûten Requests opnij om te sjen hokker fan 'e trije jo hawwe. De opdrachten hjirûnder ferwiderje de proxy, testen de sertifikaatkeatling en werhelje dan de oprop fia de bibleteek.

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

As de curl-oprop slagget en de Python-oprop mislearret, is de omjouwing noch altyd it ferskil. As beide yn 'e TLS-faze mislearje, wie de proxy nea it probleem en is it de sertifikaatkeatling. As beide 401 weromjouwe, hat it fersyk de applikaasje berikt en is it oerbleaune wurk autentikaasje. It fêstlizzen fan hokker fan 'e trije jo seagen, sparret de folgjende persoan in oere.

Weromdraaie is ien rigel yn beide rjochtingen: ferwiderje de útsluting, of set trust_env werom. Bewarje de foarige NO_PROXY-wearde foardat jo derby foegje, en jou de foarkar oan in wrapper-skript of in Environment=-ynfier op ienheidsnivo boppe in eksport dy't allinnich yn jo terminalskiednis libbet. Beide wizigingen binne sichtber yn 'e prosesomjouwing, sadat in werstart jo normaal werom bringt nei it âlde gedrach.

Einigje mei it befestigjen fan fjouwer dingen: de gearfoege ynstellings foar de privee-URL litte gjin proxy sjen, it sertifikaat falt mei de bedoelde CA, it fersyk jout de status werom dy't jo ferwachtsje, en de wiziging is fêstlein op in plak dat werhelle wurde kin. In grien skript mei in ûnferklearre omjouwing is in repaaraasje dy't op 'e folgjende masine wer brekt. De opdrachten yn dit hânboek binne dejinge dy't jo yn 'e ticket plakke.