Mac-ի VPN և PAC փրոքսի՝ երկու որոշում, ոչ թե մեկ կարգավորում

Ձեր Mac-ը ներբեռնում է քաղաքականության սկրիպտ, ապա հարցնում այդ սկրիպտին, թե որ միջնորդը պետք է օգտագործի հարցումը, մինչդեռ թունելը միայն որոշում է, թե ինչպես հասնել ընտրված ցատկին։ Երկու պատասխաններն էլ հայտնվում են նույն սոքեթի վրա, ուստի հարցումը, որը ձախողվում է երկուսի հաջողվելուց հետո, երկուսի դեպքում էլ մեկ խափանում է թվում։ Ներբեռնումը ընտրությունից, իսկ ընտրությունը՝ երթուղուց առանձնացնելը այս տոմսերի աշխատանքի մեծ մասն է։ Ստորև բերված կարգը հետևում է այն, ինչ macOS-ը իրականում անում է, այն ստուգումներով, որոնք տեսանելի են դարձնում յուրաքանչյուր փուլ։

Որտեղ են տարբերվում PAC հասցեն և փրոքսին

https://config.corp.example/proxy.pac-ի նման հասցեն անվանում է ներբեռնվող փաստաթուղթ, և այդ փաստաթուղթը անվանում է սերվեր, որով պետք է անցնի երթևեկությունը։ URL-ը փրոքսիի հոսթի դաշտում տեղադրելը պահանջում է, որ հաճախորդը փրոքսի կապ բացի ֆայլային սերվերի հետ, որը երբեք չի լսում նման կապի։ Ֆայլի ներսում կա ֆունկցիա, որը հաճախորդը կանչում է յուրաքանչյուր հարցման համար, և դրա վերադարձվող արժեքը հաջորդ ցատկն է այդ մեկ նպատակակետի համար։ Այս անուղղակիությունը բացատրում է, թե ինչու նույն ցանցային ծառայության երկու մեքենաներ կարող են տարբեր վարվել, երբ երկուսն էլ ունեն ճիշտ URL։ Այն նաև բացատրում է, թե ինչու քաղաքականության փոփոխությունն ուժի մեջ է մտնում առանց որևէ մեկի դիպչելու փրոքսիին։

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

Սկրիպտը պետք է բերվի նախքան այն ինչ-որ բան կորոշի

Քաղաքականությունը ներբեռնելու համար անհրաժեշտ է լուծված անուն և երթուղի դեպի այն, ինչ սպասարկում է ֆայլը, և միացված թունելը ոչ մեկը չի ենթադրում։ Եթե հոսթը լուծվում է միայն մասնավոր DNS-ով, այդ պահին օգտագործվող լուծիչը որոշում է, թե արդյոք ներբեռնումը կարող է սկսվել։ Եթե հոսթը գտնվում է մասնավոր տիրույթում, երթուղին պետք է գոյություն ունենա այս մեքենայից, ոչ թե գործընկերոջ դյուրակիրից։ Ավելի վաղ սեսիայում քեշավորված պատճենը թաքցնում է այս ամենը, մինչև քեշը սպառվի կամ մեքենան վերագործարկվի։

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

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

Առաջին հրամանը տպում է ակտիվ ծառայության փրոքսիի բառարանը, ներառյալ ցանկացած ինքնակազմաձևման URL, որը համակարգը պահում է։ Երկրորդը հաղորդում է մեկ անվանված ծառայությանը կցված URL-ը, ինչը կարևոր է Wi-Fi-ի և Ethernet-ի միջև տեղաշարժվող դյուրակիրում։ Երրորդը բերում է ֆայլը առանց այն արտապատկերելու, այնպես որ 404-ը, ժամանակի սպառումը և լուծիչի ձախողումը մնում են տարբերելի։ Եթե այդ վերջին հրամանը վերադարձնում է սկրիպտը, մինչ հավելվածները դեռ ձախողվում են, խնդիրն արդեն անցել է բերումից։

Ինչ է իրականում բաց թողնում DIRECT պատասխանը

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

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

Երեք ձախողումներ, որոնք հայտնվում են որպես մեկ սխալի էջ

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

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

Փրոքսիի հետ ավարտված կապը հարցը տեղափոխում է նույնականացման կամ փրոքսիի սեփական քաղաքականության, որն այլ սեփականատեր ունի։ Առանց փրոքսիի ներքին հոսթի հետ ավարտված կապը բացառում է երթուղին և մատնանշում քաղաքականությանը։ Երկու հրամաններն էլ անտեսում են macOS-ի փրոքսիի բառարանը, եթե shell-ը փրոքսիի փոփոխականներ չարտահաներ, ուստի նախ մաքրեք դրանք։ Փորձարկումներից ոչ մեկը չի ապացուցում մյուսին, և դրա համար է, որ մեկ սխալի էջ այդքան երկար մոլորեցնում է։

Ինչ փոխանցել տոմսի հետ

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

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