Kāpēc PAC starpniekserveris viesa VM nedarbojas ar uzturētāja URL

„Uzturētājs izmanto šo PAC failu, tāpēc es ievietoju to pašu URL VM“ ir pamatots teikums un nepilnīgs plāns. PAC URL norāda uz politikas skriptu, nevis starpniekserveri. Kamēr viesis nevar iegūt šo skriptu, novērtēt to ar viesa paša adresēm un pēc tam sasniegt jebkuru skripta nosaukto starpniekserveri, URL ir tikai virkne iestatījumu laukā. Lielākā daļa neskaidrības par starpniekservera politiku virtuālajās mašīnās rodas tāpēc, ka šī vienīgā rinda tiek uzskatīta par visu konfigurāciju.

PAC URL ir skripts, nevis starpniekserveris

Failā ir funkcija, kas saņem URL un uzturētāju un atgriež starpniekservera aprakstu vai vārdu DIRECT. Nekas URL nav tāds, kas lietojumprogrammai pateiktu, kur sūtīt datplūsmu; šis lēmums tiek pieņemts izpildes laikā, skripta iekšienē, ar datiem, ko skripts pieprasa no platformas. Iestatījumu dialogs, kas pieņem PAC URL, pieņem rādītāju uz lēmuma procedūru.

Tieši šī atšķirība izskaidro, kāpēc URL kopēšana var izskatīties veiksmīga. Lauks tiek aizpildīts, iestatījums tiek saglabāts, un kļūme parādās tikai vēlāk, kad skriptu nevar iegūt vai kad tas atgriež starpniekserveri, kuru viesis nevar sasniegt.

Četri soļi neizdodas katrs savā veidā

Viesa iekšienē pēc kārtas jānotiek četrām lietām, un katrai ir sava kļūdas pazīme. Viesis iegūst PAC failu. Lietojumprogramma novērtē skriptu pieprasītajam URL, izmantojot vietējo informāciju. Izvēlētais starpniekserveris tiek atrisināts un sasniegts. Autentifikācija notiek, ja starpniekserveris to pieprasa.

Sāciet ar iegūšanas pierādīšanu, jo bez tās viss pārējais ir bezjēdzīgs. PAC fails privātā serverī prasa atļautu ceļu uz šo serveri, pirms jebkurš noteikums var palīdzēt, un starpniekservera izvēle nesasniedzamā skriptā nevar radīt ceļu, kas to iegūtu:

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

Ja šis pieprasījums no viesa neizdodas un no uzturētāja darbojas, problēma ir viesa ceļš uz PAC serveri, nevis skripta saturs. Ja tas atgriež JavaScript failu, pārejiet uz otro soli un noskaidrojiet, ko skripts izlemj viesa kontekstam.

Tas pats skripts VM iekšienē izlemj citādi

PAC funkcijas var pārbaudīt pieprasīto uzturētāju un informāciju par mašīnu, kas veic novērtēšanu. Noteikums, kas veidots uz paša klienta adresi, piemēram, tāds, kas pārbauda saskarnes adresi vai piederību apakštīklam, redzēs viesa adresi, nevis fiziskā uzturētāja adresi. Aiz uzturētāja puses NAT tās ir dažādas adreses, tāpēc tas pats skripts var izvēlēties citu starpniekserveri vai VM iekšienē atgriezties pie DIRECT.

Tā nav skripta kļūda. Skripts dara tieši to, kam tas rakstīts, ar citu ievadi, un tas izskaidro mulsinošo ziņojumu, kurā uzturētājs izmanto starpniekserveri, bet viesis savienojas tieši. Reproducējiet lēmumu, nevis spriediet par to: PAC novērtētājs, kas saņem adresi un URL, ja jūsu distributīvā tāds ir, atrisina jautājumu ar vienu komandu. Pretējā gadījumā testējiet ar lietojumprogrammu, kas patiešām tiks izmantota, un lasiet tās starpniekservera žurnālu, nevis miniet.

Neizdariet secinājumu, ka viesis ir mantojis uzturētāja starpniekservera iestatījumus jo tā datplūsma iet caur uzturētāja puses tulkojumu. Tīkla tulkojums pārsūta paketes; tas nekopē lietojumprogrammu konfigurāciju, un sistēmas starpniekserveris ir lietojumprogrammas konfigurācija.

Rīki, kas PAC nemaz nelasa

Komandrindas rīki ir atsevišķa robeža, un tieši šeit tiek zaudēts daudz laika. curl neizpilda PAC failus, kā tā starpniekservera dokumentācija skaidri saka. Starpniekservera mainīgā vēršana uz PAC lejupielādes URL nepārvērš skriptu par starpniekservera galapunktu; rīks mēģinās runāt HTTP ar JavaScript failu un neizdosies tā, ka tas izskatīsies pēc tīkla problēmas.

Tas pats attiecas uz daudziem pakotņu pārvaldniekiem, valodu izpildes vidēm un būvēšanas rīkiem, kas ievēro tikai skaidrus starpniekservera mainīgos vai savu konfigurāciju. Ja tests, kas jums svarīgs, ir CLI rīks, konfigurējiet to ar konkrēto starpniekserveri, kuru PAC skripts būtu izvēlējies, un pierakstiet, kā jūs nonācāt pie šīs izvēles, lai nākamā persona to varētu atkārtot.

Linux darbvirsmas lietojumprogrammām sistēmas iestatījums ir jāpārslēdz automātiskajā režīmā un tam jāpiešķir arī URL; URL, kas saglabāts, kamēr režīms vēl ir manuāls, neko nedara. Pārbaudiet abus un pārbaudiet tos viesa iekšienē:

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

DIRECT arī ir lēmums

PAC rezultāts DIRECT nozīmē, ka lietojumprogramma apiet HTTP starpniekserveri, nevis ka tā ir izkļuvusi no tīkla. Iegūtais savienojums joprojām var sekot operētājsistēmas maršrutam caur tuneli vai neizdoties tādu iemeslu dēļ, kuriem nav nekāda sakara ar starpniekservera lietošanu. Pretēji, starpniekservera rezultāts apraksta vienas lietojumprogrammas pieprasījumu, nevis katru viesa procesu.

Tāpēc pārbaudiet tajā virzienā, kurā prasība tika rakstīta. Ja prasība ir „šī lietojumprogramma sasniedz iekšējo vietni“, pierādiet, ka šī lietojumprogramma to sasniedz, un pierakstiet, kurš starpniekserveris vai maršruts to nesa. Ja prasība ir „VM atrodas uzņēmuma tīklā“, pārlūks, kas darbojas caur izvēlētu starpniekserveri, ir pierādījums šim pārlūkam un nekas vairāk.

Salabojiet ķēdi viesa iekšienē, nevis izslēdziet uzturētāja tuneli vai mīkstiniet pārsūtīšanas politiku, lai tests izietu. Ķēdei ir četri posmi, un izmaiņas, kas izlaiž vienu no tiem, saglabāsies līdz nākamajai reizei, kad skripts tiks atjaunināts vai mainīsies viesa adrese.