curl kan ikke lese PAC-filen din: send proxyen i stedet

Adressen til PAC-filen og endepunktet til proxyen ser ut som om de kan byttes om i en konfigurasjonsfil, og det kan de ikke. Det ene er et policyprogram som må evalueres for hver URL; det andre er et vertsnavn og en port som tar imot tilkoblinger. curl forstår bare det andre. Å sende en PAC-adresse til --proxy er en kategorifeil som feiler på en forvirrende måte, vanligvis etter en lang CONNECT-tidsavbrudd mot en webserver.

Hva hver av dem egentlig er

Det sier FAQ-en for curl klart: curl tilbyr ingen JavaScript- eller PAC-tolkning. En PAC-bevisst innpakning rundt curl kan gjøre det, men curl selv gjør det ikke, og ingen flagg gjør den til en nettleser.

Hvorfor nettleseren virker og curl ikke

En nettleser integrerer med systemets proxykonfigurasjon, henter PAC-filen og kjører reglene dens mot URL-en du åpner. Den evalueringen er tjenesten PAC-filen leverer, og den skjer inne i nettleseren, ikke inne i terminalen din.

Å hente PAC-filen med curl gir bare teksten. Det får ikke curl til å kjøre policyen, og å lese den manuelt for å finne en proxy er en manuell versjon av samme evaluering, med samme sjanse for å velge feil gren. Hvis du leser den, les return-setningen som passer til verten din i stedet for det første proxynavnet i filen. De fleste PAC-filer inneholder flere, og bare én gren gjelder for deg.

For en godkjent HTTP-proxy og en godkjent HTTPS-tjeneste er en illustrerende forespørsel:

curl --proxy http://proxy.corp.example:8080 https://service.example.net/status

Den første adressen er proxylytteren, den andre er tjenesten du vil ha. Dette er eksempelendepunkter og ikke en test noen har utført, så bytt dem ut med organisasjonens skjema, port og autentiseringsflyt.

Velg proxyen for denne destinasjonen

Spør administratoren hvilken proxy policyen velger for URL-en du trenger, ikke hvilken proxy organisasjonen eier. PAC-regler kan gi forskjellige resultater for interne tjenester, offentlige nettsteder og failover-tilstander, og en regel som passer URL-en din i dag, kan etter en endring passe en annen.

Hvis arbeidsflyten trenger mer enn én kjent forespørsel, bruk en statisk innstilling som administratoren støtter, eller en godkjent PAC-bevisst integrasjon. Å hardkode én kopiert adresse fungerer til den dagen policyen endres og ingen lenger husker hvorfor den adressen ble valgt.

Se så på hva curl arver. Proxy-miljøvariabler og NO_PROXY kan overstyre eller utelukke proxyen du sendte, og en utelukkelse som passer målet ditt sender forespørselen direkte uten å si det. Behold den tiltenkte policyen i stedet for å slette hver utelukkelse eller tvinge alt gjennom én adresse. Kjør forespørselen én gang med -v og sjekk hvilken adresse den faktisk koblet til.

Hold de to TLS-identitetene fra hverandre

Med en HTTPS-proxy er to TLS-tilkoblinger i spill: din til proxyen og proxyens til destinasjonen. Hver har sin egen identitet å verifisere, og å slå av verifiseringen for en av dem er ikke en PAC-løsning, det er et andre problem lagt til det første.

La verifiseringen stå på og les feilen du får. En proxyautentiseringsutfordring, en utilgjengelig proxy og en avvisning fra nettstedet er tre forskjellige resultater, og bare det første handler om påloggingsinformasjon. VPN-en må fortsatt gi en tillatt vei til en privat proxy, inkludert navneoppslag for proxyverten selv, før noe av dette kan lykkes.

Skriv ned endepunktet, skjemaet, porten, autentiseringsmetoden, utelukkelsene og VPN-veien til proxyen. Den registreringen er det som gjør den neste forespørselen reproduserbar, og det er forskjellen mellom å kjenne proxyen sin og å gjette på den.