કેમ હોસ્ટની 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 કોર્પોરેટ નેટવર્ક પર છે» હોય, તો પસંદ કરેલ પ્રોક્સી દ્વારા ચાલતું બ્રાઉઝર એ બ્રાઉઝર માટે પુરાવો છે અને વધુ કંઈ નહીં.

પરીક્ષણ પસાર થાય તે માટે હોસ્ટની ટનલ બંધ કરવાને બદલે અથવા ફોરવર્ડિંગ નીતિ ઢીલી કરવાને બદલે ગેસ્ટની અંદર સાંકળ સુધારો. સાંકળમાં ચાર કડીઓ છે, અને તેમાંથી એક છોડી દેતો ફેરફાર ત્યાં સુધી ટકશે જ્યાં સુધી સ્ક્રિપ્ટ આગલી વખતે અપડેટ ન થાય અથવા ગેસ્ટનું સરનામું ન બદલાય.