Bakit nabibigo ang PAC proxy sa guest VM gamit ang URL ng host

„Ginagamit ng host ang PAC file na ito, kaya inilagay ko ang parehong URL sa VM“ ay isang makatwirang pangungusap at isang kulang na plano. Ang URL ng PAC ay tumuturo sa isang script ng patakaran, hindi sa proxy. Hangga't hindi nakukuha ng panauhin ang script na iyon, hindi ito nasusuri gamit ang sariling mga address ng panauhin at hindi naaabot ang anumang proxy na pinangalanan ng script, ang URL ay isang string lamang sa isang field ng mga setting. Karamihan sa kalituhan tungkol sa patakaran ng proxy sa mga virtual machine ay nagmumula sa pagtrato sa isang linyang iyon bilang buong configuration.

Ang URL ng PAC ay isang script, hindi proxy

Naglalaman ang file ng isang function na kumukuha ng URL at host at nagbabalik ng paglalarawan ng proxy o ang salitang DIRECT. Wala sa URL ang nagsasabi sa application kung saan ipapadala ang trapiko; ang desisyong iyon ay nangyayari sa runtime, sa loob ng script, gamit ang data na hinihingi ng script sa platform. Ang dialog ng mga setting na tumatanggap ng URL ng PAC ay tumatanggap ng pointer sa isang pamamaraan ng pagpapasya.

Ang pagkakaibang iyon ang dahilan kung bakit maaaring magmukhang gumana ang pagkopya ng URL. Napupuno ang field, naitatago ang setting, at ang pagkabigo ay lumilitaw lamang mamaya, kapag hindi makuha ang script o kapag nagbalik ito ng proxy na hindi naaabot ng panauhin.

Nabibigo ang apat na hakbang sa kanya-kanyang paraan

Sa loob ng panauhin, apat na bagay ang dapat mangyari sa pagkakasunod-sunod, at bawat isa ay may sariling tanda ng error. Kinukuha ng panauhin ang PAC file. Sinusuri ng application ang script para sa hiniling na URL gamit ang lokal na impormasyon. Naresolba at naaabot ang napiling proxy. Nangyayari ang authentication kung kailangan ito ng proxy.

Simulan sa pagpapatunay ng pagkuha, dahil walang saysay ang lahat ng kasunod kung wala ito. Ang PAC file sa isang pribadong server ay nangangailangan ng pinapayagang landas patungo sa server na iyon bago makatulong ang anumang tuntunin, at ang pagpili ng proxy sa loob ng hindi maabot na script ay hindi makakalikha ng landas na kukuha nito:

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

Kung nabibigo ang kahilingang iyon mula sa panauhin at gumagana mula sa host, ang problema ay ang landas ng panauhin patungo sa PAC server, hindi ang nilalaman ng script. Kung nagbabalik ito ng JavaScript file, pumunta sa ikalawang hakbang at alamin kung ano ang pinagpapasyahan ng script para sa konteksto ng panauhin.

Iba ang pinagpapasyahan ng parehong script sa loob ng VM

Maaaring siyasatin ng mga function ng PAC ang hiniling na host at impormasyon tungkol sa makina na gumagawa ng pagsusuri. Ang tuntuning itinayo sa sariling address ng kliyente, halimbawa ang nagsusuri ng address ng interface o pagiging kasapi sa subnet, ay makikita ang address ng panauhin at hindi ang ng pisikal na host. Sa likod ng NAT sa panig ng host, magkaibang address ang mga ito, kaya maaaring pumili ang parehong script ng ibang proxy o bumalik sa DIRECT sa loob ng VM.

Hindi ito depekto sa script. Ginagawa ng script ang eksaktong layunin nito, sa ibang input, at ipinapaliwanag nito ang nakalilitong ulat kung saan gumagamit ang host ng proxy at direktang kumokonekta ang panauhin. Reproduktuhin ang desisyon sa halip na mangatwiran tungkol dito: ang PAC evaluator na kumukuha ng address at URL, kung mayroon ang iyong distribution, ay nilulutas ang tanong sa isang utos. Kung hindi, subukan gamit ang application na talagang gagamitin, at basahin ang log ng proxy nito sa halip na manghula.

Huwag tapusin na namana ng panauhin ang mga setting ng proxy ng host dahil dumadaan ang trapiko nito sa pagsasalin sa panig ng host. Nagpapasa ng mga packet ang pagsasalin ng network; hindi nito kinokopya ang configuration ng application, at ang proxy ng system ay configuration ng application.

Mga tool na hindi nagbabasa ng PAC

Ang mga command-line tool ay hiwalay na hangganan, at dito napupunta ang maraming oras. Hindi nagpapatupad ang curl ng mga PAC file, gaya ng dokumentasyon ng proxy nito na malinaw na sinasabi. Ang pagturo ng variable ng proxy patungo sa URL ng pag-download ng PAC ay hindi ginagawang endpoint ng proxy ang script; susubukan ng tool na magsalita ng HTTP sa isang JavaScript file at mabibigo sa paraang mukhang problema sa network.

Ganoon din sa maraming package manager, runtime ng wika at build tool, na gumagalang lamang sa tahasang variable ng proxy o sa sarili nilang configuration. Kung ang pagsubok na mahalaga sa iyo ay isang CLI tool, i-configure ito gamit ang konkretong proxy na pipiliin sana ng PAC script, at itala kung paano mo nakuha ang pagpipiliang iyon upang maulit ito ng susunod na tao.

Para sa mga desktop application sa Linux, kailangang ilagay ang setting ng system sa awtomatikong mode at bigyan din ito ng URL; ang URL na nai-save habang manu-mano pa ang mode ay walang ginagawa. Suriin ang dalawa, at suriin ang mga ito sa loob ng panauhin:

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

Ang DIRECT ay isa ring desisyon

Ang resultang PAC na DIRECT ay nangangahulugang nilalampasan ng application ang HTTP proxy, hindi na nakatakas ito sa network. Ang magreresultang koneksyon ay maaari pa ring sumunod sa ruta ng operating system sa pamamagitan ng tunnel, o mabigo dahil sa mga dahilan na walang kinalaman sa paggamit ng proxy. Sa kabaligtaran, inilalarawan ng resulta ng proxy ang kahilingan ng isang application, hindi ang bawat proseso sa panauhin.

Kaya i-verify sa direksyon kung saan isinulat ang pangangailangan. Kung ang pangangailangan ay «naaabot ng application na ito ang panloob na site», patunayan na naaabot iyon ng application, at itala kung aling proxy o ruta ang nagdala nito. Kung ang pangangailangan ay «ang VM ay nasa corporate network», ang browser na gumagana sa pamamagitan ng napiling proxy ay ebidensya para sa browser na iyon at wala nang iba.

Ayusin ang chain sa loob ng panauhin sa halip na patayin ang tunnel ng host o luwagan ang patakaran ng pagpapasa upang pumasa ang isang pagsubok. Apat na link ang chain, at ang pagbabagong lumalaktaw sa isa sa mga ito ay tatagal hanggang sa susunod na ma-update ang script o magbago ang address ng panauhin.