Mac VPN at PAC proxy: dalawang desisyon, hindi isang setting

Nagda-download ang Mac mo ng policy script at pagkatapos ay tinatanong ang script na iyon kung aling tagapamagitan ang dapat gamitin ng isang kahilingan, habang ang tunnel ay nagpapasya lamang kung paano maabot ang napiling hop. Parehong napupunta ang dalawang sagot sa parehong socket, kaya ang kahilingang nabigo matapos magtagumpay ang dalawa ay mukhang isang fault kapag dalawa. Ang paghihiwalay ng download sa pagpili, at ng pagpili sa ruta, ang malaking bahagi ng trabaho sa mga ticket na ito. Sinusundan ng pagkakasunod-sunod sa ibaba ang aktwal na ginagawa ng macOS, kasama ang mga pagsusuring nagpapakita ng bawat yugto.

Saan naghihiwalay ang PAC address at ang proxy

Ang address na tulad ng https://config.corp.example/proxy.pac ay pinangalanan ang dokumentong ida-download, at ang dokumentong iyon ay pinangalanan ang server na pagdadaanan ng trapiko. Ang pagdikit ng URL sa field ng host ng proxy ay humihiling sa client na magbukas ng koneksyon ng proxy sa isang file server na hindi kailanman nakikinig para doon. Sa loob ng file ay may function na tinatawag ng client sa bawat kahilingan, at ang return value nito ang susunod na hop para sa nag-iisang destinasyong iyon. Ipinapaliwanag ng indirectness na ito kung bakit dalawang makina sa parehong serbisyo ng network ay maaaring kumilos nang iba kahit pareho silang may tamang URL. Ipinapaliwanag din nito kung bakit nagkakabisa ang pagbabago ng patakaran nang walang sinumang humahawak sa proxy mismo.

Basahin ang script bago bigyang-kahulugan ang anumang bagay sa ibaba, dahil dala ng mga patakaran sa loob nito ang mga eksepsiyon ng organisasyon at ang pagkakasunod-sunod ng paggamit nila. Ang maagang malawak na saklaw ay maaaring magtakip sa isang huling panloob na suffix, at ang host na dapat malinaw na laktawan ang proxy ay patuloy na gumagamit nito. Kapag may nagsabi na mali ang patakaran, ang script lang ang lugar kung saan dinidiskarte ang claim na iyon.

Kailangang makuha ang script bago ito magpasya ng anuman

Ang pag-download ng patakaran ay nangangailangan ng naresolba na pangalan at ruta patungo sa kung ano man ang naghahain ng file, at ang konektadong tunnel ay hindi nagbibigay ng alinman. Kung ang host ay naresolba lamang sa pamamagitan ng pribadong DNS, ang resolver na ginagamit sa sandaling iyon ang magpapasya kung makakapagsimula ang download. Kung ang host ay nasa pribadong saklaw, dapat may ruta mula sa makinang ito, hindi mula sa laptop ng katrabaho. Ang kopyang naka-cache sa naunang sesyon ay nagtatago ng lahat ng ito hanggang mag-expire ang cache o mag-restart ang makina.

Patakbuhin ang tatlong pagsusuri sa ibaba nang sunud-sunod at huminto sa unang pagpalya, dahil hindi nagbabahagi ng dahilan ang mga yugto. Sama-sama nilang ipinapakita kung naka-configure ang patakaran, kung naaabot ito, at kung ano ang ibinabalik nito.

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

Ang unang command ay nagpi-print ng diksyunaryo ng proxy para sa aktibong serbisyo, kasama ang anumang auto-configuration URL na hawak ng system. Ang pangalawa ay nag-uulat ng URL na nakakabit sa isang pinangalanang serbisyo, na mahalaga sa laptop na lumilipat sa pagitan ng Wi-Fi at Ethernet. Ang pangatlo ay kumukuha ng file nang hindi ito nire-render, kaya nananatiling natatangi ang 404, timeout at pagpalya ng resolver. Kung ang huling command na iyon ay nagbabalik ng script habang nabigo pa rin ang mga aplikasyon, nalampasan na ng problema ang pagkuha.

Ano talaga ang nilalaktawan ng sagot na DIRECT

Ang espesipikasyon ng PAC ay nagbibigay sa client ng maliit na bokabularyo, at DIRECT ay isa sa mga salita nito. Sinasabi ng salita sa client na laktawan ang proxy para sa kahilingang iyon at walang sinasabi tungkol sa kung aling interface ang gagamitin ng socket pagkatapos. Ang direktang socket sa isang buong tunnel ay lumalabas pa rin sa VPN at nagpapakita pa rin sa destinasyon ng exit address ng tunnel.

Ang pagbasa sa DIRECT bilang labas ng VPN ang pagkakamaling nagpapadala ng mga tao sa maling panel ng settings. Ang salamin na larawan ay kasingkaraniwan, dahil naaabot ang pribadong proxy sa isang hati na ruta habang nananatili sa labas ng tunnel ang natitirang makina. Ang iniuulat ng destinasyon noon ay pag-aari ng sariling labasan ng proxy, na maaaring nasa ibang bansa. Ang pagsulat ng inaasahan para sa isang panloob na host at isang pampublikong host ay mabilis na naglalantad nito, dahil madalas na iba ang sagot ng script sa dalawa. Kapag alam mo kung aling hop ang gumawa ng address, hindi na misteryoso ang ulat.

Tatlong pagpalya na lumilitaw bilang isang pahina ng error

Maaaring mabigo ang patakaran sa pag-download, maaaring hindi maabot ang napiling proxy, at ang kahilingang nakarating sa serbisyo ay maaari pa ring tanggihan doon. Tatlo sa kanila ay dumarating bilang timeout o pangkalahatang pahina ng error, at wala sa kanila ang nagpangalan sa yugtong nasira. Ang pagkuha ng desisyon sa tabi ng error ang naghihiwalay sa kanila. Sinusubok ng dalawang probe sa ibaba ang hop na pinili ng script, isa para sa bawat sangay na maibabalik nito.

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

Ang kumpletong koneksyon sa proxy ay naglilipat ng tanong sa authentication o sa sariling patakaran ng proxy, na may ibang may-ari. Ang kumpletong koneksyon sa panloob na host na walang proxy sa landas ay nag-aalis ng ruta at itinuturo ang patakaran. Parehong binabalewala ng dalawang command ang diksyunaryo ng proxy ng macOS maliban kung nag-e-export ang shell ng mga variable ng proxy, kaya i-clear muna ang mga iyon. Wala sa dalawang probe ang nagpapatunay sa isa, at iyon ang dahilan kung bakit isang pahina ng error ang nakakapanlinlang nang matagal.

Ano ang isusumite kasama ng ticket

Ipadala ang aktibong serbisyo ng network, ang URL ng PAC, ang resulta ng pagsusuri para sa host na nabigo, at ang yugto kung saan lumitaw ang error. Ang apat na iyon ay nagpapahintulot sa susunod na tao na muling gawin ang desisyon sa halip na hulaan kung aling layer ang kasama. Idagdag ang estado ng tunnel sa sandali ng pagsubok, dahil luma na ang resultang nakuha bago ang muling pagkonekta. Itago rin ang rebisyon ng script, dahil nagbabago ang file ng patakaran nang walang abiso at maaaring hindi na wasto ang sagot kahapon.

Itala kung paano kumilos ang client kapag hindi makuha ang script, dahil nagkakaiba ang mga implementasyon at ang desisyon sa proxy ay hindi isang kill switch ng buong device. Ang ilan ay bumabalik sa direktang koneksyon at ang iba ay nabigo nang sarado, at ang pagkakaibang iyon ay nagbabago kung ang isang outage ay mukhang sirang proxy o gumaganang patakaran. Kumpirmahin ang pag-uugali para sa eksaktong client at bersyon bago umasa dito sa panahon ng insidente.