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, പരാജയപ്പെടുന്ന ഹോസ്റ്റിന്റെ മൂല്യനിർണ്ണയ ഫലം, പിശക് പ്രത്യക്ഷപ്പെട്ട ഘട്ടം എന്നിവ അയയ്ക്കുക. ഏത് ലെയർ ഉൾപ്പെട്ടിരുന്നു എന്ന് ഊഹിക്കുന്നതിന് പകരം തീരുമാനം പുനരുൽപ്പാദിപ്പിക്കാൻ ഈ നാലും അടുത്ത വ്യക്തിക്ക് അനുവദിക്കുന്നു. പരിശോധനയുടെ നിമിഷത്തിലെ ടണൽ അവസ്ഥ ചേർക്കുക, വീണ്ടും ബന്ധിപ്പിക്കുന്നതിന് മുൻപ് എടുത്ത ഫലം കാലഹരണപ്പെട്ടതാണ്. സ്ക്രിപ്റ്റിന്റെ പതിപ്പും സൂക്ഷിക്കുക, പോളിസി ഫയൽ അറിയിപ്പില്ലാതെ മാറുന്നു, ഇന്നലത്തെ ഉത്തരം ഇനി സാധുവായിരിക്കണമെന്നില്ല.

സ്ക്രിപ്റ്റ് എത്തിക്കാൻ കഴിയാത്തപ്പോൾ ക്ലയന്റ് എങ്ങനെ പെരുമാറുന്നു എന്ന് രേഖപ്പെടുത്തുക, നടപ്പാക്കലുകൾ വ്യത്യസ്തമാണ്, പ്രോക്സി തീരുമാനം മുഴുവൻ ഉപകരണത്തിന്റെ കിൽ സ്വിച്ചല്ല. ചിലത് നേരിട്ടുള്ള കണക്ഷനിലേക്ക് മടങ്ങുന്നു, മറ്റുള്ളവ അടഞ്ഞ് പരാജയപ്പെടുന്നു, ഈ വ്യത്യാസം തകരാർ തകർന്ന പ്രോക്സിയായി തോന്നുമോ പ്രവർത്തിക്കുന്ന പോളിസിയായി തോന്നുമോ എന്ന് മാറ്റുന്നു. സംഭവവേളയിൽ അതിനെ ആശ്രയിക്കുന്നതിന് മുൻപ് കൃത്യമായ ക്ലൈന്റിനും പതിപ്പിനും വേണ്ടി പെരുമാറ്റം സ്ഥിരീകരിക്കുക.