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 પ્રોક્સી ડિક્શનરીને અવગણે છે સિવાય કે શેલ પ્રોક્સી ચલો નિકાસ કરે, તેથી પહેલા તે સાફ કરો. બે પ્રોબમાંથી કોઈ એક પણ બીજાને સાબિત કરતું નથી, તેથી એક ભૂલ પૃષ્ઠ આટલા લાંબા સમય સુધી ભ્રમિત કરે છે.

ટિકિટ સાથે શું સોંપવું

સક્રિય નેટવર્ક સેવા, PAC URL, નિષ્ફળ જતા હોસ્ટ માટેનું મૂલ્યાંકન પરિણામ અને ભૂલ જ્યાં દેખાઈ તે તબક્કો મોકલો. તે ચાર પછીની વ્યક્તિને કયું સ્તર સંડોવાયેલું હતું તે અનુમાન કરવાને બદલે નિર્ણય પુનઃઉત્પાદન કરવા દે છે. પરીક્ષણની ક્ષણે ટનલની સ્થિતિ ઉમેરો, કારણ કે ફરી જોડાવા પહેલાં લેવાયેલું પરિણામ જૂનું છે. સ્ક્રિપ્ટની આવૃત્તિ પણ રાખો, કારણ કે નીતિ ફાઇલ જાણ કર્યા વિના બદલાય છે અને ગઈકાલનો જવાબ હવે ચાલુ ન પણ હોય.

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