Ինչու հյուր VM-ում PAC փրոքսին չի աշխատում հոսթի URL-ով

«Հոսթը օգտագործում է այս PAC ֆայլը, ուստի ես նույն URL-ը դրեցի VM-ում» ողջամիտ նախադասություն է և թերի պլան։ PAC URL-ը ցույց է տալիս քաղաքականության սկրիպտի, ոչ թե փրոքսիի։ Քանի դեռ հյուրը չի կարող ներբեռնել այդ սկրիպտը, գնահատել այն հյուրի սեփական հասցեներով և ապա հասնել ցանկացած փրոքսիի, որը սկրիպտը նշում է, URL-ը պարզապես տող է կարգավորումների դաշտում։ Վիրտուալ մեքենաներում փրոքսի քաղաքականության շուրջ շփոթության մեծ մասը գալիս է այն բանից, որ այդ մեկ տողը համարվում է ամբողջ կազմաձևումը։

PAC URL-ը սկրիպտ է, ոչ փրոքսի

Ֆայլը պարունակում է ֆունկցիա, որը վերցնում է URL և հոսթ և վերադարձնում փրոքսիի նկարագրություն կամ DIRECT բառը։ URL-ում ոչինչ չի ասում հավելվածին, թե ուր ուղարկել տրաֆիկը. այդ որոշումը կայացվում է կատարման պահին, սկրիպտի ներսում, տվյալներով, որ սկրիպտը խնդրում է հարթակից։ Կարգավորումների երկխոսությունը, որն ընդունում է PAC URL, ընդունում է ցուցիչ որոշման ընթացակարգի նկատմամբ։

Հենց այս տարբերությունն է պատճառը, որ URL-ի պատճենումը կարող է թվալ, թե ստացվել է։ Դաշտը լցված է, կարգավորումը պահված է, և խափանումը երևում է միայն ավելի ուշ, երբ սկրիպտը հնարավոր չէ ներբեռնել կամ երբ այն վերադարձնում է փրոքսի, որին հյուրը չի կարող հասնել։

Չորս քայլերից յուրաքանչյուրը ձախողվում է յուրովի

Հյուրի ներսում չորս բան պետք է տեղի ունենան հերթականությամբ, և յուրաքանչյուրն ունի իր սխալի նշանը։ Հյուրը ներբեռնում է PAC ֆայլը։ Հավելվածը գնահատում է սկրիպտը պահանջված URL-ի համար տեղական տեղեկություններով։ Ընտրված փրոքսին լուծարվում է և հասանելի է դառնում։ Նույնականացումը տեղի է ունենում, եթե փրոքսին պահանջում է այն։

Սկսեք ներբեռնումն ապացուցելուց, քանի որ առանց դրա մնացած ամեն ինչ անիմաստ է։ Մասնավոր սերվերի վրա գտնվող PAC ֆայլը պահանջում է թույլատրված ուղի դեպի այդ սերվեր, նախքան որևէ կանոն կօգնի, և անհասանելի սկրիպտի ներսում փրոքսիի ընտրությունը չի կարող ստեղծել այն ուղին, որը կներբեռնի այն:

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

Եթե այդ հարցումը ձախողվում է հյուրից և աշխատում է հոսթից, խնդիրը հյուրի ուղին է դեպի PAC սերվեր, ոչ թե սկրիպտի բովանդակությունը։ Եթե այն վերադարձնում է JavaScript ֆայլ, անցեք երկրորդ քայլին և պարզեք, թե ինչ է որոշում սկրիպտը հյուրի համատեքստի համար։

Նույն սկրիպտը VM-ի ներսում այլ կերպ է որոշում

PAC ֆունկցիաները կարող են ստուգել պահանջված հոսթը և տեղեկություններ այն մեքենայի մասին, որն անում է գնահատումը։ Կլիենտի սեփական հասցեի վրա կառուցված կանոնը, օրինակ ինտերֆեյսի հասցեն կամ ենթացանցին պատկանելը ստուգողը, կտեսնի հյուրի հասցեն, ոչ թե ֆիզիկական հոսթինը։ Հոսթի կողմի NAT-ի հետևում դրանք տարբեր հասցեներ են, ուստի նույն սկրիպտը կարող է ընտրել այլ փրոքսի կամ VM-ի ներսում վերադառնալ DIRECT-ին։

Սա սկրիպտի սխալ չէ։ Սկրիպտը անում է հենց այն, ինչի համար գրվել է, այլ մուտքով, և դա է բացատրում այն շփոթեցնող հաշվետվությունը, որտեղ հոսթը օգտագործում է փրոքսին, իսկ հյուրը միանում է ուղիղ։ Վերարտադրեք որոշումը՝ փոխարենը դրա մասին դատելու. PAC գնահատիչը, որը վերցնում է հասցե և URL, եթե ձեր բաշխումը ունի այդպիսին, հարցը լուծում է մեկ հրամանով։ Հակառակ դեպքում փորձարկեք այն հավելվածով, որն իսկապես կօգտագործվի, և կարդացեք նրա փրոքսիի մատյանը՝ գուշակելու փոխարեն։

Մի եզրակացրեք, որ հյուրը ժառանգել է հոսթի փրոքսիի կարգավորումները քանի որ նրա տրաֆիկը անցնում է հոսթի կողմի թարգմանությամբ։ ցանցային թարգմանությունը փոխանցում է փաթեթներ, այն չի պատճենում հավելվածների կազմաձևումը, և համակարգային փրոքսին հավելվածի կազմաձևում է։

Գործիքներ, որոնք ընդհանրապես չեն կարդում PAC

Հրամանի տողի գործիքները առանձին սահման են, և հենց այստեղ է կորչում շատ ժամանակ։ curl-ը չի կատարում PAC ֆայլեր, ինչպես որ նրա փրոքսիի փաստաթղթավորումը հստակ ասում է։ Փրոքսիի փոփոխականը PAC ներբեռնման URL-ին ուղղելը սկրիպտը փրոքսիի վերջնակետ չի դարձնում. գործիքը կփորձի JavaScript ֆայլի հետ խոսել HTTP լեզվով և կձախողվի այնպես, որ նման է ցանցային խնդրի։

Նույնը վերաբերում է շատ փաթեթների կառավարիչների, լեզուների կատարման միջավայրերի և կառուցման գործիքների, որոնք հարգում են միայն բացահայտ փրոքսիի փոփոխականները կամ իրենց սեփական կազմաձևումը։ Եթե ձեզ հետաքրքրող թեստը CLI գործիք է, կարգավորեք այն կոնկրետ փրոքսիով, որը PAC սկրիպտը կընտրեր, և գրի առեք, թե ինչպես հասաք այդ ընտրությանը, որպեսզի հաջորդ մարդը կարողանա կրկնել այն։

Linux-ում աշխատասեղանի հավելվածների համար համակարգի կարգավորումը պետք է դրվի ավտոմատ ռեժիմի և նաև URL տրվի. URL-ը, որը պահվում է, երբ ռեժիմը դեռ ձեռքով է, ոչինչ չի անում։ Ստուգեք երկուսը, և ստուգեք դրանք հյուրի ներսում:

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

DIRECT-ը նույնպես որոշում է

PAC-ի DIRECT արդյունքը նշանակում է, որ հավելվածը շրջանցում է HTTP փրոքսին, այլ ոչ թե որ այն փախել է ցանցից։ Ստացված կապը դեռ կարող է գնալ օպերացիոն համակարգի երթուղով թունելով, կամ ձախողվել պատճառներով, որոնք որևէ կապ չունեն փրոքսիի օգտագործման հետ։ Հակառակը, փրոքսիի արդյունքը նկարագրում է մեկ հավելվածի հարցումը, ոչ թե հյուրի բոլոր գործընթացները։

Ուստի ստուգեք այն ուղղությամբ, որով գրվել է պահանջը։ Եթե պահանջն այն է, որ «այս հավելվածը հասնում է ներքին կայքին», ապացուցեք, որ այդ հավելվածը հասնում է, և նշեք, թե որ փրոքսին կամ երթուղին է տարել այն։ Եթե պահանջն այն է, որ «VM-ը կորպորատիվ ցանցում է», ընտրված փրոքսիով աշխատող զննարկիչը վկայություն է այդ զննարկիչի համար և ոչ ավելին։

Ուղղեք շղթան հյուրի ներսում՝ փոխարենը անջատելու հոսթի թունելը կամ մեղմելու փոխանցման քաղաքականությունը, որպեսզի թեստը անցնի։ Շղթան ունի չորս օղակ, և փոփոխությունը, որը բաց է թողնում դրանցից մեկը, կպահպանվի մինչև հաջորդ անգամ, երբ սկրիպտը թարմացվի կամ հյուրի հասցեն փոխվի։