pipin check_hostname-virhe välityspalvelimen takana: pip vai tunneli?

Kaksi eri vikaa tulostaa saman pipin jäljityksen, ja toiselle sopiva korjaus pahentaa toista. Asiakas, joka on liian vanha nimeämään tunneloidun isännän, tarvitsee päivityksen. Välityspalvelin, joka allekirjoittaa liikenteen uudelleen, tarvitsee luotetun juurivarmenteen, ei version laskemista. Selvitä, kumpi näistä kahdesta sinulla on, ennen kuin muokkaat välityspalvelinmuuttujaa, sillä polut vievät vastakkaisiin suuntiin.

Lue viimeiset kehykset ennen asetuksiin koskemista

Se, mihin jäljitys päättyy, kertoo, mikä kerros antoi periksi. Jos sulkevat kehykset ovat pipin mukana tulevassa urllib3:n TLS-koodissa ja teksti valittaa isäntänimeä, asiakaskirjasto ei saanut vahvistusvaihetta valmiiksi, ja se on versio-ongelma paljon useammin kuin varmenteongelma. Jos teksti sen sijaan kertoo torjutusta yhteydestä, ratkaisemattomasta välityspalvelimen nimestä tai HTTP 407 -virheestä, vika on tunnelin päätepisteessä eikä mikään päivitys muuta sitä.

Tallenna pipin versio ja välityspalvelinmuuttujat samassa kuoressa, joka epäonnistuu. Ennen tunnelin nousua avattu kuori kantaa eri arvoja kuin sen jälkeen avattu, ja niiden ero on usein koko diagnoosi.

python3 -m pip --version
env | grep -i -E 'proxy|no_proxy'

Kun asiakas on tunnelia vanhempi

Vanhemmat pipin versiot sisälsivät HTTPS-pinon, joka menetti kohdeisäntänimen, kun tunnelia verhosi pistoke. check_hostname-viesti on se, mitä pino tulostaa saavuttaessaan vahvistuksen ilman vertailtavaa nimeä. Päivitys poistaa vian, koska uudempi asiakas säilyttää nimen kättelyn ajan, ja muutos on tarpeeksi halpa kokeiltavaksi ensin aina, kun sulkevat kehykset osoittavat mukana tulevaan TLS-koodiin.

Jos indeksiin ei pääse vialliselta koneelta, hae ajantasainen wheel koneella, joka pystyy siihen, ja asenna tiedostosta. Käytä tiedostonimeä, jonka todella latasit, älä blogikirjoituksesta kopioitua versiota.

python3 -m pip install --upgrade pip
python3 -m pip install ./pip-24.2-py3-none-any.whl

Kun välityspalvelin allekirjoittaa liikenteen uudelleen

Välityspalvelin, joka päättää TLS:n ja myöntää varmenteet uudelleen yrityksen juuren alla, tuottaa erilaisen virheen: certificate verify failed, ei valitusta isäntänimestä. Tämä ero on vihje, koska asiakas saavutti palvelimen ja hylkäsi sitten sille näytetyn identiteetin. Korjaus on luottaa tuohon juureen nimenomaisesti, joko yhtä komentoa varten tai PIP_CERT-muuttujan kautta, jotta asiakas voi rakentaa ketjun siihen, mitä välityspalvelin esittää. Juuren lisääminen järjestelmän luottamusvarastoon toimii myös, mutta se muuttaa luottamusta jokaiselle koneen ohjelmalle, ja se on suurempi päätös kuin yhden paketinasennuksen korjaaminen.

Pidä --trusted-host diagnostiikkana, älä koskaan pysyvänä tilana. Se kytkee pois tarkistuksen, jota yritit säilyttää, joten aidosti väärä varmenne näyttää sen jälkeen terveeltä. Jos käytit sitä yhden paketin asentamiseen, poista se ja korjaa ketju ennen seuraavaa julkaisua.

Oma Python-koodisi jättää pipin asetukset kokonaan huomiotta. requests-kutsu tarvitsee välityspalvelimen ja nipun sinne, missä kyseinen istunto näkee ne, siksi alla oleva lohko asettaa molemmat istunto-objektiin.

pip install --cert /usr/local/share/ca-certificates/corp-root.crt requests
export PIP_CERT=/usr/local/share/ca-certificates/corp-root.crt

s = requests.Session()
s.proxies = {"https": "http://10.20.30.40:8080"}
s.verify = "/usr/local/share/ca-certificates/corp-root.crt"
s.get("https://pypi.org/simple/", timeout=15)

Kun päätepiste tai portti on väärä

Tunneliasiakas usein kirjoittaa järjestelmän välityspalvelimen uudelleen yhdistäessään, mikä voi jättää pipin osoittamaan isäntään, joka ei koskaan vastaa sillä portilla. Testaa päätepiste asiakkaalla, joka ei ole pip, ennen kuin muutat mitään pipin asetusta. Jos curl epäonnistuu samalla välityspalvelinargumentilla, vika on pipin yläpuolella eikä mikään määrä pipin sisäistä asetusta auta.

Komennon lippu ja ympäristömuuttujat sanovat saman asian eri laajuuksille: lippu koskee yhtä kutsua, muuttujat jokaista sen jälkeen käynnistettyä prosessia. Lisää NO_PROXY sisäiselle indeksille, jotta yksityinen pakettiliikenne ohittaa tunnelin kautta kiertämisen.

curl -x http://proxy.corp.internal:8080 --head https://pypi.org/simple/
pip install --proxy http://proxy.corp.internal:8080 requests

Tallenna asetus ja todista, että polku toimii

Tallenna välityspalvelin pipin omaan asetukseen, kun sen pitää elää nykyisen kuoren ohi, ja lue sitten takaisin, mitä pip todella käyttää. Debug-tuloste nimeää tiedoston ja muuttujan jokaisen arvon takana, mikä ratkaisee kiistat ensisijaisuudesta nopeammin kuin dokumentaation lukeminen.

Vahvistus käyttää tarkoituksella kahta asiakasta. Standardikirjaston pyyntö todistaa reitin ja luottamusketjun, kun taas lataus todistaa, että pipin oma asetus on niiden kanssa samaa mieltä. Kun ensimmäinen onnistuu ja toinen epäonnistuu, ero on pipin sisällä eikä verkossa.

pip config set global.proxy http://proxy.corp.internal:8080
pip config debug
python3 -c "import urllib.request as r; print(r.urlopen('https://pypi.org/simple/').status)"
pip download --no-deps -d /tmp/wheelcheck requests