ولې د کوربه URL سره د مېلمه VM کې PAC پراکسي ناکامېږي

«کوربه دا 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 ته راوګرځي.

دا د سکریپټ نقص نه دی. سکریپټ هغه څه کوي چې د هغه لپاره لیکل شوی، د بل انپټ سره، او همدا هغه ګډوډ راپور څرګندوي چې کوربه پراکسي کاروي او مېلمه مستقیم نښلېږي. د پرېکړې په اړه فکر کولو پر ځای هغه بیا تولید کړئ: د پتې او URL اخیستونکی PAC ارزونکی، که ستاسو وېش یو ولري، په یوه حکم سره پوښتنه حل کوي. که نه، هغه اپلیکیشن سره ازموینه وکړئ چې واقعاً به کارول کېږي، او د اټکل کولو پر ځای یې د پراکسي ثبت ولولئ.

دې پایلې ته مه رسېږئ چې مېلمه د کوربه پراکسي تنظیمات په میراث اخیستي دي ځکه چې د هغه ټرافیک د کوربه خوا ژباړې څخه تېریږي. شبکه ژباړه پاکټونه لېږدوي؛ هغه د اپلیکیشنونو ترتیبات کاپي نه کوي، او سیسټم پراکسي د اپلیکیشن ترتیبات دي.

هغه وسایل چې 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 د کارپوریټ شبکې په سر دی»، د غوره شوې پراکسي له لارې کار کوونکی براوزر د هغه براوزر لپاره شاهد دی او نور نه.

د ازموینې د تېرېدو لپاره د کوربه تونل بندول یا د لېږد تګلاره نرمول پر ځای د مېلمه دننه زنځیر سم کړئ. زنځیر څلور کړۍ لري، او هغه بدلون چې یوه ترې پرېږدي تر بل ځل پورې چې سکریپټ تازه شي یا د مېلمه پته بدله شي دوام کوي.