PAC faila adrese un starpniekservera galapunkts konfigurācijas failā izskatās aizvietojami, bet nav. Viens ir politikas programma, kas jāizvērtē katram URL; otrs ir resursdators un ports, kas pieņem savienojumus. curl saprot tikai otro. PAC adreses nodošana --proxy ir kategorijas kļūda, kas neizdodas maldinoši, parasti pēc ilgas CONNECT gaidīšanas uz tīmekļa serveri.

Kas katrs no tiem patiesībā ir

Jums irKas tas irKo curl ar to dara
http://wpad.corp.example/proxy.pacJavaScript, kas konkrētam URL atgriež starpniekserveri vai tiešu savienojumuLejupielādē to kā failu un tur apstājas
http://proxy.corp.example:8080Klausītājs, kas pieņem starpniekservera pieprasījumusTo izmanto, tostarp CONNECT HTTPS mērķiem

To skaidri saka curl BUJ: curl nenodrošina JavaScript vai PAC interpretāciju. Apvalks ap curl, kas saprot PAC, to var, bet pats curl ne, un neviens karodziņš to nepārvērš par pārlūku.

Kāpēc pārlūks strādā, bet curl ne

Pārlūks integrējas ar sistēmas starpniekservera konfigurāciju, lejupielādē PAC failu un izpilda tā noteikumus pret URL, ko atverat. Šis novērtējums ir pakalpojums, ko sniedz PAC fails, un tas notiek pārlūkā, nevis jūsu terminālī.

PAC faila lejupielāde ar curl iegūst tikai tā tekstu. Tas neliek curl izpildīt politiku, un tā lasīšana ar roku, lai atrastu starpniekserveri, ir tā paša novērtējuma manuāla versija ar tādu pašu iespēju izvēlēties nepareizo atzaru. Ja tomēr lasāt, lasiet return paziņojumu, kas atbilst jūsu resursdatoram, nevis pirmo starpniekservera nosaukumu failā. Lielākajā daļā PAC failu to ir vairāki, un tikai viens atzars attiecas uz jums.

Apstiprinātam HTTP starpniekserverim un apstiprinātam HTTPS pakalpojumam ilustratīvs pieprasījums ir:

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

Pirmā adrese ir starpniekservera klausītājs, otrā ir pakalpojums, kuru vēlaties. Šie ir piemēra galapunkti, nevis kāda veikts tests, tāpēc aizstājiet tos ar savas organizācijas shēmu, portu un autentifikācijas plūsmu.

Izvēlieties starpniekserveri šim galamērķim

Jautājiet administratoram, kuru starpniekserveri politika izvēlas vajadzīgajam URL, nevis kuru starpniekserveri organizācijai pieder. PAC noteikumi var atgriezt atšķirīgus rezultātus iekšējiem pakalpojumiem, publiskām vietnēm un failover situācijām, un noteikums, kas šodien atbilst jūsu URL, pēc labojuma var atbilst citam.

Ja darbplūsmai nepieciešams vairāk nekā viens zināms pieprasījums, izmantojiet administratora atbalstītu statisku iestatījumu vai apstiprinātu PAC saprotošu integrāciju. Vienas nokopētas adreses iekodēšana darbojas līdz dienai, kad politika mainās un neviens vairs neatceras, kāpēc šī adrese tika izvēlēta.

Pēc tam apskatiet, ko curl manto. Starpniekservera vides mainīgie un NO_PROXY var ignorēt vai izslēgt nodoto starpniekserveri, un izslēgšana, kas atbilst jūsu mērķim, klusi nosūta pieprasījumu tieši. Saglabājiet paredzēto politiku, tā vietā lai dzēstu katru izslēgšanu vai dzītu visu caur vienu adresi. Izpildiet pieprasījumu vienreiz ar -v un pārbaudiet, kurai adresei tas faktiski pieslēdzās.

Turiet abas TLS identitātes atsevišķi

Ar HTTPS starpniekserveri darbojas divi TLS savienojumi: jūsu uz starpniekserveri un starpniekservera uz galamērķi. Katram ir sava identitāte, kas jāpārbauda, un pārbaudes izslēgšana jebkuram no tiem nav PAC labojums, bet otra problēma, kas pievienota pirmajai.

Atstājiet pārbaudi ieslēgtu un izlasiet saņemto kļūdu. Starpniekservera autentifikācijas izaicinājums, nesasniedzams starpniekserveris un vietnes atteikums ir trīs dažādi rezultāti, un tikai pirmais attiecas uz akreditācijas datiem. VPN joprojām ir jānodrošina atļauts ceļš uz privātu starpniekserveri, tostarp paša starpniekservera resursdatora nosaukumu atrisināšana, pirms kaut kas no šī izdodas.

Pierakstiet galapunktu, shēmu, portu, autentifikācijas metodi, izslēgšanu un VPN ceļu līdz starpniekserverim. Tieši šis ieraksts padara nākamo pieprasījumu atkārtojamu, un tā ir atšķirība starp sava starpniekservera pārzināšanu un minēšanu par to.

Saistītie raksti