ഹോസ്റ്റിന്റെ 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 കോർപ്പറേറ്റ് നെറ്റ്വർക്കിലാണ്» എന്നാണെങ്കിൽ, തിരഞ്ഞെടുത്ത പ്രോക്സിയിലൂടെ പ്രവർത്തിക്കുന്ന ബ്രൗസർ ആ ബ്രൗസറിനുള്ള തെളിവാണ്, അതിൽ കൂടുതലല്ല.

പരിശോധന കടക്കാൻ ഹോസ്റ്റിന്റെ ടണൽ ഓഫ് ചെയ്യുന്നതിനോ ഫോർവേഡിംഗ് നയം അയച്ചുവിടുന്നതിനോ പകരം അതിഥിക്കുള്ളിൽ ശൃംഖല ശരിയാക്കുക. ശൃംഖലയിൽ നാല് കണ്ണികളുണ്ട്, അവയിലൊന്ന് ഒഴിവാക്കുന്ന മാറ്റം അടുത്ത തവണ സ്ക്രിപ്റ്റ് അപ്ഡേറ്റ് ചെയ്യുന്നതുവരെയോ അതിഥിയുടെ വിലാസം മാറുന്നതുവരെയോ നിലനിൽക്കും.