curl ei suuda teie PAC-faili lugeda: edastage selle asemel puhverserver

PAC-faili aadress ja puhverserveri lõpp-punkt näivad konfiguratsioonifailis vahetatavad olevat, kuid ei ole. Üks on reegliprogramm, mida tuleb iga URL-i jaoks hinnata; teine on host ja port, mis võtab ühendusi vastu. curl mõistab ainult teist. PAC-aadressi edastamine parameetrile --proxy on kategooriaviga, mis ebaõnnestub segasel viisil, tavaliselt pärast pikka CONNECT-ooteaega veebiserverile.

Mis kumbki tegelikult on

Seda ütleb selgelt curl-i KKK: curl ei paku JavaScripti ega PAC-i tõlgendamist. PAC-i mõistev ümbris curl-i ümber võib seda teha, aga curl ise mitte, ja ükski lipp ei tee sellest brauserit.

Miks brauser töötab ja curl mitte

Brauser integreerub süsteemi puhverserveri seadistusega, laadib PAC-faili alla ja käivitab selle reeglid URL-i vastu, mille avate. See hindamine on teenus, mida PAC-fail pakub, ja see toimub brauseri sees, mitte teie terminalis.

PAC-faili allalaadimine curl-iga toob ainult selle teksti. See ei pane curl-i reeglistikku täitma, ja selle käsitsi lugemine puhverserveri leidmiseks on sama hindamise käsitsi versioon, sama võimalusega valida vale haru. Kui te seda loete, lugege return-lauset, mis vastab teie hostile, mitte faili esimest puhverserveri nime. Enamik PAC-faile sisaldab mitut ja ainult üks haru kehtib teie kohta.

Heakskiidetud HTTP-puhverserveri ja heakskiidetud HTTPS-teenuse jaoks on näidispäring:

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

Esimene aadress on puhverserveri kuulaja, teine on teenus, mida soovite. Need on näidislõpp-punktid, mitte test, mille keegi tegi, seega asendage need oma organisatsiooni skeemi, pordi ja autentimisprotsessiga.

Valige selle sihtkoha jaoks puhverserver

Küsige administraatorilt, millise puhverserveri reeglistik teie vajaliku URL-i jaoks valib, mitte milline puhverserver organisatsioonil on. PAC-reeglid võivad anda erinevaid tulemusi sise-, avalike ja varustusülemineku olukordade jaoks, ja reegel, mis sobib täna teie URL-iga, võib pärast muudatust sobida mõne teisega.

Kui töövoog vajab rohkem kui üht teadaolevat päringut, kasutage administraatori toetatud staatilist seadet või heakskiidetud PAC-i mõistvat integratsiooni. Ühe kopeeritud aadressi kõvakodeerimine töötab kuni päevani, mil reeglistik muutub ja keegi ei mäleta, miks see aadress valiti.

Seejärel vaadake, mida curl pärinud on. Puhverserveri keskkonnamuutujad ja NO_PROXY võivad edastatud puhverserveri üle kirjutada või selle välistada, ja teie sihtmärgiga sobiv välistus saadab päringu vaikselt otse. Säilitage kavandatud reeglistik, selle asemel et kustutada iga välistus või sundida kõik ühe aadressi kaudu käima. Käivitage päring üks kord koos -v ja kontrollige, millise aadressiga see tegelikult ühendus.

Hoidke kaks TLS-identiteeti lahus

HTTPS-puhverserveri korral on mängus kaks TLS-ühendust: teie oma puhverserverini ja puhverserveri oma sihtkohani. Kummallagi on oma identiteet, mida kontrollida, ja kummagi kontrolli väljalülitamine ei ole PAC-i parandus, vaid teine probleem, mis lisandub esimesele.

Jätke kontroll sisse ja lugege tõrget, mille saate. Puhverserveri autentimiskutse, kättesaamatu puhverserver ja veebisaidi keeldumine on kolm erinevat tulemust ning ainult esimene puudutab mandaate. VPN peab endiselt tagama lubatud tee privaatse puhverserverini, sealhulgas puhverserveri hosti enda nimelahenduse, enne kui midagi sellest õnnestub.

Kirjutage üles lõpp-punkt, skeem, port, autentimismeetod, välistused ja VPN-i tee puhverserverini. Just see kirje teeb järgmise päringu korratavaks ja see on vahe selle vahel, et oma puhverserverit teada, ja selle üle oletada.