check_hostname-feil i pip bak en proxy: pip eller tunnelen?

To forskjellige feil skriver ut den samme pip-sporene, og reparasjonen som passer den ene gjør den andre verre. En klient som er for gammel til å navngi en tunnelert vert, trenger en oppgradering. En proxy som signerer trafikken på nytt, trenger et klarert rotsertifikat, ikke en nedgradering. Finn ut hvilken av de to du har før du redigerer en proxyvariabel, fordi stiene går i motsatte retninger.

Les de siste rammene før du rører innstillingene

Der sporene slutter, forteller deg hvilket lag som ga opp. Hvis de avsluttende rammene ligger i pip sin medfølgende urllib3-TLS-kode og teksten klager på et vertsnavn, kunne klientbiblioteket ikke fullføre et verifiseringstrinn, og det er et versjonsproblem langt oftere enn et sertifikatproblem. Hvis teksten i stedet rapporterer en avvist tilkobling, et uløst proxynavn eller en HTTP 407, er tunneleendepunktet skylden, og ingen oppgradering vil endre det.

Fang pip-versjonen og proxyvariablene i det samme skallet som feiler. Et skall som ble åpnet før tunnelen kom opp, bærer andre verdier enn et som ble åpnet etterpå, og forskjellen mellom dem er ofte hele diagnosen.

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

Når klienten er eldre enn tunnelen

Eldre pip-utgivelser inkluderte en HTTPS-stack som mistet destinasjonsvertenavnet når sockelen ble pakket inn av en tunnel. check_hostname-meldingen er det den stacken sender ut når den når verifiseringen uten et navn å sammenligne med. En oppgradering fjerner feilen fordi den nyere klienten beholder navnet gjennom håndtrykket, og endringen er billig nok til å prøve først når de avsluttende rammene peker på medfølgende TLS-kode.

Hvis indeksen ikke kan nås fra maskinen som feiler, hent en gjeldende wheel på en vert som kan, og installer fra filen. Bruk filnavnet du faktisk lastet ned, ikke en versjon kopiert fra et blogginnlegg.

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

Når proxyen signerer trafikken på nytt

En proxy som avslutter TLS og utsteder sertifikater på nytt under en bedriftsrot, produserer en annen feil: certificate verify failed, ikke en klage på vertsnavn. Den forskjellen er ledetråden, fordi klienten nådde en server og avviste deretter identiteten den ble vist. Reparasjonen er å stole på den roten eksplisitt, enten for én kommando eller via PIP_CERT-variabelen, slik at klienten kan bygge en kjede til det proxyen presenterer. Å legge roten til systemets tillitslager fungerer også, men det endrer tilliten for hvert program på maskinen, og det er en større beslutning enn å fikse én pakkeinstallasjon.

Behold --trusted-host som diagnose, aldri som en varig tilstand. Det slår av sjekken du prøvde å beholde, så et virkelig feil sertifikat ser friskt ut etterpå. Hvis du brukte det for å installere én pakke, fjern det og reparer kjeden før neste utgivelse.

Din egen Python-kode ignorerer pip-konfigurasjonen helt. Et requests-kall trenger at proxyen og pakken sendes dit den økten kan se dem, og derfor setter blokken nedenfor begge på sesjonsobjektet.

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)

Når endepunktet eller porten er feil

En tunnelklient skriver ofte om systemproxyen mens den kobler til, noe som kan la pip peke på en vert som aldri svarer på den porten. Test endepunktet med en klient som ikke er pip, før du endrer noen pip-innstilling. Hvis curl feiler med det samme proxyargumentet, sitter feilen over pip, og ingen konfigurasjon inne i pip vil hjelpe.

Kommandoflagget og miljøvariablene sier det samme til ulike omfang: flagget gjelder for ett kall, variablene for hver prosess som startes etterpå. Legg til NO_PROXY for en intern indeks, slik at privat pakketrafikk hopper over omveien gjennom tunnelen.

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

Gjør innstillingen varig og bevis at stien fungerer

Lagre proxyen i pips egen konfigurasjon når den skal overleve den gjeldende skallet, og les deretter tilbake hva pip faktisk vil bruke. Debug-utdataene navngir filen og variabelen bak hver verdi, noe som avgjør diskusjoner om forrang raskere enn å lese dokumentasjonen.

Verifiseringen bruker bevisst to klienter. Forespørselen fra standardbiblioteket beviser ruten og tillitskjeden, mens nedlastingen beviser at pips egen konfigurasjon er enig med dem. Når den første lykkes og den andre feiler, ligger forskjellen inne i pip og ikke i nettverket.

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