curl ei lue PAC-tiedostoasi: välitä sen sijaan proxy
PAC on JavaScript-käytäntö; curl haluaa päätepisteen. Kysy, minkä proxyn käytäntö valitsee URL:llesi, välitä se ja seuraa NO_PROXYa ja TLS:ää.
PAC-tiedoston osoite ja proxyn päätepiste näyttävät asetustiedostossa vaihdettavilta, mutta eivät ole. Toinen on käytäntöohjelma, joka on arvioitava jokaiselle URL:lle; toinen on isäntä ja portti, joka vastaanottaa yhteyksiä. curl ymmärtää vain jälkimmäisen. PAC-osoitteen antaminen parametrille --proxy on kategoriavirhe, joka epäonnistuu hämmentävällä tavalla, yleensä pitkän CONNECT-aikakatkaisun jälkeen web-palvelimeen.
Mikä kumpikin oikeastaan on
| Sinulla on | Mikä se on | Mitä curl tekee sillä |
|---|---|---|
http://wpad.corp.example/proxy.pac | JavaScript, joka palauttaa proxyn tai suoran yhteyden tietylle URL:lle | Lataa sen tiedostona ja pysähtyy siihen |
http://proxy.corp.example:8080 | Kuuntelija, joka vastaanottaa proxy-pyyntöjä | Käyttää sitä, mukaan lukien CONNECT HTTPS-kohteille |
Sen sanoo selvästi curlin UKK: curl ei tarjoa JavaScriptin tai PACin tulkintaa. PACin ymmärtävä kääre curlin ympärillä voi, mutta curl itse ei, eikä mikään valitsin tee siitä selainta.
Miksi selain toimii ja curl ei
Selain integroituu järjestelmän proxy-asetuksiin, lataa PAC-tiedoston ja suorittaa sen säännöt avaamallesi URL:lle. Tämä arviointi on palvelu, jonka PAC-tiedosto tarjoaa, ja se tapahtuu selaimen sisällä, ei päätteessäsi.
PAC-tiedoston lataaminen curlilla tuo vain sen tekstin. Se ei saa curlia suorittamaan käytäntöä, ja sen lukeminen käsin proxyn löytämiseksi on saman arvioinnin käsiversio, samalla mahdollisuudella valita väärä haara. Jos luet sitä, lue return-lause, joka vastaa isäntääsi, et tiedoston ensimmäistä proxyn nimeä. Useimmat PAC-tiedostot sisältävät useita, ja vain yksi haara koskee sinua.
Hyväksytylle HTTP-proxylle ja hyväksytylle HTTPS-palvelulle havainnollistava pyyntö on:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusEnsimmäinen osoite on proxyn kuuntelija, toinen on palvelu, jonka haluat. Nämä ovat esimerkkipäätepisteitä, eivät testi, jonka joku teki, joten korvaa ne organisaatiosi skeemalla, portilla ja todennusmenetelmällä.
Valitse proxy tälle kohteelle
Kysy ylläpitäjältä, minkä proxyn käytäntö valitsee tarvitsemallesi URL:lle, ei minkä proxyn organisaatio omistaa. PAC-säännöt voivat palauttaa eri tuloksia sisäisille palveluille, julkisille sivustoille ja vikasietotilanteille, ja tänään URL:llesi sopiva sääntö voi muokkauksen jälkeen sopia toiselle.
Jos työnkulku tarvitsee useamman kuin yhden tunnetun pyynnön, käytä ylläpitäjän tukemaa staattista asetusta tai hyväksyttyä PACin ymmärtävää integraatiota. Yhden kopioidun osoitteen kovakoodaus toimii siihen päivään, jolloin käytäntö muuttuu eikä kukaan enää muista, miksi kyseinen osoite valittiin.
Katso sitten, mitä curl perii. Proxy-ympäristömuuttujat ja NO_PROXY voivat ohittaa tai sulkea pois välittämäsi proxyn, ja kohdettasi vastaava poissulkeminen lähettää pyynnön hiljaa suoraan. Säilytä aiottu käytäntö sen sijaan, että poistaisit jokaisen poissulkemisen tai pakottaisit kaiken yhden osoitteen kautta. Suorita pyyntö kerran -v kanssa ja tarkista, mihin osoitteeseen se todella yhdisti.
Pidä kaksi TLS-identiteettiä erillään
HTTPS-proxyn kanssa kaksi TLS-yhteyttä on pelissä: sinun proxyyn ja proxyn yhteys kohteeseen. Kummallakin on oma identiteettinsä tarkistettavana, ja vahvistuksen poistaminen kummaltakaan ei ole PAC-korjaus, vaan toinen ongelma ensimmäisen päälle.
Pidä vahvistus päällä ja lue saamasi virhe. Proxy-todennuspyyntö, tavoittamaton proxy ja verkkosivuston hylkäys ovat kolme eri tulosta, ja vain ensimmäinen koskee tunnistetietoja. VPN:n on yhä tarjottava sallittu reitti yksityiseen proxyyn, mukaan lukien proxy-isännän oma nimiresoluutio, ennen kuin mikään tästä onnistuu.
Kirjoita ylös päätepiste, skeema, portti, todennusmenetelmä, poissulkemiset ja VPN-polku proxyyn. Juuri tuo merkintä tekee seuraavasta pyynnöstä toistettavan, ja se on ero proxysi tuntemisen ja sen arvailemisen välillä.