Requests ProxyError privātā API? Vispirms pārbaudiet vidi

VPN darbojas, iekšējais panelis atveras pārlūkā, un Python skripts joprojām izmet starpniekservera kļūdu. Šajā attēlā ar tuneli viss ir kārtībā: interpretators nolasa starpniekservera adresi no savas vides un sūta pieprasījumu uz turieni. Šī rokasgrāmata nolasa vidi, ko process patiešām redz, piemēro šaurāko izslēgšanu un tikai pēc tam apsver skaidru sesijas politiku. Katrs solis beidzas ar komandu, kuras izvade nosaka, vai turpināt.

Izlasiet vidi, ko process patiešām redz

Darbvirsmas starpniekservera iestatījumi, čaulas eksporti un systemd vienības Environment= rindas ir trīs dažādi avoti, un Requests lasa tikai pēdējo, ko manto. Palaidiet zemāk esošo diagnostiku tajā pašā čaulā, konteinerā vai vienībā, kur darbojas neveiksmīgais skripts, nevis savā interaktīvajā terminālī. Pieslēgšanās čaulā eksportētais mainīgais konteinera procesam nav redzams, un šī plaisa izskaidro daudzos ziņojumus par starpniekserveri, kas parādās no nekurienes. Abas komandas izdrukā vienus un tos pašus datus dažādos detalizācijas līmeņos.

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

Tiek lasītas abas katra mainīgā rakstības, un dublētie ieraksti tiek piemēroti tādā secībā, kādā process tos saņēma, tāpēc novecojis HTTP_PROXY var pārrakstīt tikko eksportēto vērtību. CA saišķa mainīgie šeit arī ir svarīgi, jo tie maina, uz ko atrisinās verify, nekur neparādoties kodā. Ja izvade ir tukša, vide nav jūsu problēma, un jūs varat pārtraukt šīs sadaļas lasīšanu. Ja tajā ir uzskaitīts starpniekserveris, kuru nepazīstat, pirms kaut ko mainīt atrodiet failu vai vienību, kas to iestata.

Pajautājiet Requests, ko tas darītu ar konkrētu URL. Šis izsaukums parāda apvienotās šī pieprasījuma starpniekservera, verify un cert vērtības, neizsūtot paketi.

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

Ne tukšs proxies ieraksts privātajam resursdatoram ir jūsu atbilde, un izdrukātā verify vērtība pasaka, kuram CA saišķim pieprasījums uzticētos. Ja abi izskatās pareizi, kļūme ir tālāk stekā, un jums jādodas uz pārbaudes sadaļu. Neminiet no koda: apvienošana notiek katram pieprasījumam, tāpēc viena sesija var uzvesties citādi ar diviem resursdatoriem.

Izslēdziet privāto resursdatoru, pirms kaut ko atslēdzat

Kad starpniekserveris patiešām ir nepieciešams citiem galamērķiem, šaurais labojums ir šī resursdatora izslēgšana. Pievienojiet esošajam sarakstam, nevis aizstājiet to, jo NO_PROXY dzēšana salauž katru citu iekšējo galamērķi, kas uz to paļāvās. Tālāk esošās komandas pievieno ierakstu un pēc tam jautā Requests, vai apiešana ir spēkā.

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

Saskaņošana notiek pēc resursdatora galotnes, tāpēc .corp.example aptver visu domēnu, bet api.corp.example — vienu nosaukumu. Tukša zvaigznīte atslēdz starpniekserveri visiem resursdatoriem, un gandrīz nekad tas nav tas, ko vēlas ražošanas uzdevums. Vai CIDR ieraksts tiks ņemts vērā, ir atkarīgs no Requests un urllib3 versijām attēlā, tāpēc pārbaudiet precīzo ierakstu, nevis pieņemiet, ka tas darbojas. Pārbaudiet should_bypass_proxies rezultātu īstajam URL, nevis resursdatora nosaukumam, ko ierakstījāt no atmiņas.

Turiet abus slāņus atsevišķi galvā. HTTP starpniekservera apiešana neapiet VPN, jo lēmums par starpniekserveri tiek pieņemts bibliotēkā, bet lēmums par tuneli — kodola maršrutēšanas tabulā.

Atslēdziet trust_env tikai kā apzinātu sesijas politiku

Ja visam darbam ir jāignorē vides konfigurācija, izveidojiet sesiju skaidri un ierakstiet lēmumu kodā. Tā ir politika, nevis apiešanas risinājums, un tā pieder diff, ko redz recenzents. Tālāk esošais piemērs saglabā noildzes laiku, skaidru CA ceļu un statusa pārbaudi.

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

Atslēdzot trust_env, vienlaikus mainās trīs uzvedības, un tikai viena no tām attiecas uz starpniekserveri. Requests pārstāj lasīt .netrc akreditācijas datus, un mainīgie REQUESTS_CA_BUNDLE un CURL_CA_BUNDLE pārstāj ietekmēt verify, kas pēc tam atgriežas pie iekļautās sertifikātu krātuves. Ja jūsu organizācija pabeidz TLS ar savu CA, šī atkāpšanās rada pārbaudes kļūdu, kas izskatās nesaistīta ar tikko veikto izmaiņu. Tieši skaidra verify nodošana notur abus efektus atsevišķi.

Ko jums nevajadzētu darīt, ir iestatīt verify=False, lai apklusinātu radušos kļūdu. Tas apmaina nepareizu starpniekservera konfigurāciju pret nepārbaudītu savienojumu un slēpj sertifikāta problēmu, ko izslēgšanai bija jāatklāj.

Pārbaudiet neveiksmīgo slāni un saglabājiet atritināšanas iespēju

Trīs kļūmes žurnālā izskatās vienādi un tām nav nekā kopīga: starpniekserveris, kas nevar sasniegt galamērķi, met ProxyError vai atgriež 502, uzticēšanās problēma met SSLError, un lietojumprogrammas noraidījums atgriež 401 vai 403. Atkārtojiet pieprasījumu ārpus Requests, lai redzētu, kura no tām jums ir. Tālāk esošās komandas noņem starpniekserveri, pārbauda sertifikātu ķēdi un pēc tam atkārto izsaukumu caur bibliotēku.

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

Ja curl izsaukums izdodas un Python izsaukums neizdodas, atšķirība joprojām ir vide. Ja abi neizdodas TLS posmā, starpniekserveris nekad nav bijis problēma, un problēma ir sertifikātu ķēde. Ja abi atgriež 401, pieprasījums sasniedza lietojumprogrammu, un atlikušais darbs ir autentifikācija. Tā ierakstīšana, kuru no trim novērojāt, ietaupa nākamajam cilvēkam stundu.

Atritināšana ir viena rinda abos virzienos: noņemiet izslēgšanu vai atgrieziet trust_env atpakaļ. Saglabājiet iepriekšējo NO_PROXY vērtību, pirms kaut ko pievienojat, un dodiet priekšroku ietvara skriptam vai vienības līmeņa Environment= ierakstam, nevis eksportam, kas dzīvo tikai jūsu termināļa vēsturē. Abas izmaiņas ir redzamas procesa vidē, tāpēc restartēšana parasti atgriež jūs pie vecās uzvedības.

Pabeidziet, apstiprinot četras lietas: apvienotie privātā URL iestatījumi neuzrāda starpniekserveri, sertifikāts validējas pret paredzēto CA, pieprasījums atgriež gaidīto statusu, un izmaiņa ir iesaiņota vietā, ko var atkārtot. Zaļš skripts ar neizskaidrotu vidi ir labojums, kas atkal salūzt nākamajā mašīnā. Šīs rokasgrāmatas komandas ir tās, kas jāielīmē biļetē.