curl-ന് നിങ്ങളുടെ PAC ഫയൽ വായിക്കാൻ കഴിയില്ല: പകരം proxy നൽകുക
PAC ഒരു JavaScript നയമാണ്; curl-ന് ഒരു എൻഡ്‌പോയിന്റ് വേണം. നയം നിങ്ങളുടെ URL-ന് ഏത് proxy തിരഞ്ഞെടുക്കുന്നുവെന്ന് ചോദിച്ച് അത് നൽകുക, NO_PROXY-യും TLS-ഉം ശ്രദ്ധിക്കുക.
കോൺഫിഗ് ഫയലിൽ PAC ഫയലിന്റെ വിലാസവും proxy-യുടെ എൻഡ്‌പോയിന്റും പരസ്പരം മാറ്റാവുന്നതുപോലെ തോന്നും, എന്നാൽ അല്ല. ഒന്ന് ഓരോ URL-നും വിലയിരുത്തേണ്ട നയ പ്രോഗ്രാമാണ്; മറ്റൊന്ന് കണക്ഷനുകൾ സ്വീകരിക്കുന്ന ഹോസ്റ്റും പോർട്ടുമാണ്. curl രണ്ടാമത്തേത് മാത്രം മനസ്സിലാക്കുന്നു. PAC വിലാസം --proxy എന്നതിന് നൽകുന്നത് ഒരു വിഭാഗ തെറ്റാണ്, അത് ആശയക്കുഴപ്പമുണ്ടാക്കുന്ന രീതിയിൽ പരാജയപ്പെടുന്നു, സാധാരണയായി ഒരു വെബ് സർവറിലേക്കുള്ള നീണ്ട CONNECT കാലയളവിന് ശേഷം.
ഓരോന്നും യഥാർത്ഥത്തിൽ എന്താണ്
| നിങ്ങളുടെ കൈവശം | അത് എന്താണ് | curl അതുകൊണ്ട് എന്ത് ചെയ്യുന്നു |
|---|---|---|
http://wpad.corp.example/proxy.pac | നൽകിയ URL-ന് proxy അല്ലെങ്കിൽ നേരിട്ടുള്ള കണക്ഷൻ തിരികെ നൽകുന്ന JavaScript | അത് ഒരു ഫയലായി എടുക്കുന്നു, അവിടെ നിർത്തുന്നു |
http://proxy.corp.example:8080 | proxy വഴിയുള്ള അഭ്യർത്ഥനകൾ സ്വീകരിക്കുന്ന ശ്രോതാവ് | അത് ഉപയോഗിക്കുന്നു, HTTPS ലക്ഷ്യങ്ങൾക്ക് CONNECT ഉൾപ്പെടെ |
ഇത് വ്യക്തമായി പറയുന്നു curl-സംബന്ധിച്ച പതിവ് ചോദ്യങ്ങൾ: curl JavaScript-ന്റെയോ PAC-ന്റെയോ ഒരു വ്യാഖ്യാനവും നൽകുന്നില്ല. curl-ന് ചുറ്റുമുള്ള PAC മനസ്സിലാക്കുന്ന ഒരു ആവരണത്തിന് അത് ചെയ്യാം, പക്ഷേ curl തന്നെയല്ല, ഒരു ഫ്ലാഗും അതിനെ ബ്രൗസറാക്കുന്നില്ല.
ബ്രൗസർ പ്രവർത്തിക്കുന്നതും curl പ്രവർത്തിക്കാത്തതും എന്തുകൊണ്ട്
ബ്രൗസർ സിസ്റ്റത്തിന്റെ proxy കോൺഫിഗറേഷനുമായി സംയോജിക്കുന്നു, PAC ഫയൽ എടുക്കുന്നു, നിങ്ങൾ തുറക്കുന്ന URL-നെതിരെ അതിന്റെ നിയമങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നു. ആ വിലയിരുത്തലാണ് PAC ഫയൽ നൽകുന്ന സേവനം, അത് നിങ്ങളുടെ ടെർമിനലിനുള്ളിൽ അല്ല, ബ്രൗസറിനുള്ളിൽ സംഭവിക്കുന്നു.
curl ഉപയോഗിച്ച് PAC ഫയൽ ഡൗൺലോഡ് ചെയ്താൽ അതിന്റെ ടെക്സ്റ്റ് മാത്രം ലഭിക്കും. അത് curl നയം നടപ്പിലാക്കാൻ പ്രേരിപ്പിക്കുന്നില്ല, proxy കണ്ടെത്താൻ അത് കൈകൊണ്ട് വായിക്കുന്നത് അതേ വിലയിരുത്തലിന്റെ കൈകൊണ്ടുള്ള പതിപ്പാണ്, തെറ്റായ ശാഖ തിരഞ്ഞെടുക്കാനുള്ള അതേ സാധ്യതയോടെ. നിങ്ങൾ വായിക്കുകയാണെങ്കിൽ, ഫയലിലെ ആദ്യ proxy നാമത്തിന് പകരം നിങ്ങളുടെ ഹോസ്റ്റിന് യോജിക്കുന്ന return പ്രസ്താവന വായിക്കുക. മിക്ക PAC ഫയലുകളിലും നിരവധി ഉണ്ടാകും, നിങ്ങൾക്ക് ബാധകമാകുന്നത് ഒരു ശാഖ മാത്രമാണ്.
അംഗീകൃത HTTP proxy-യ്ക്കും അംഗീകൃത HTTPS സേവനത്തിനും, ഒരു ഉദാഹരണ അഭ്യർത്ഥന ഇതാണ്:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusആദ്യ വിലാസം proxy-യുടെ ശ്രോതാവാണ്, രണ്ടാമത്തേത് നിങ്ങൾ ആഗ്രഹിക്കുന്ന സേവനമാണ്. ഇവ ഉദാഹരണ എൻഡ്‌പോയിന്റുകളാണ്, ആരെങ്കിലും നടത്തിയ പരിശോധനയല്ല, അതിനാൽ അവ നിങ്ങളുടെ സ്ഥാപനത്തിന്റെ സ്കീമും പോർട്ടും പ്രാമാണീകരണ പ്രവാഹവും കൊണ്ട് മാറ്റുക.
ഈ ലക്ഷ്യത്തിന് proxy തിരഞ്ഞെടുക്കുക
സ്ഥാപനത്തിന് ഏത് proxy ഉണ്ടെന്നല്ല, നയം നിങ്ങൾക്ക് ആവശ്യമായ URL-ന് ഏത് proxy തിരഞ്ഞെടുക്കുന്നുവെന്ന് അഡ്മിനിസ്ട്രേറ്ററിനോട് ചോദിക്കുക. PAC നിയമങ്ങൾ ആന്തരിക സേവനങ്ങൾക്കും പൊതു സൈറ്റുകൾക്കും പരാജയ-മാറ്റ സാഹചര്യങ്ങൾക്കും വ്യത്യസ്ത ഫലങ്ങൾ നൽകാം, ഇന്ന് നിങ്ങളുടെ URL-നോട് യോജിക്കുന്ന ഒരു നിയമം എഡിറ്റിന് ശേഷം മറ്റൊന്നിനോട് യോജിച്ചേക്കാം.
ജോലിപ്രവാഹത്തിന് ഒന്നിലധികം അറിയപ്പെടുന്ന അഭ്യർത്ഥനകൾ വേണമെങ്കിൽ, അഡ്മിനിസ്ട്രേറ്റർ പിന്തുണയ്ക്കുന്ന സ്റ്റാറ്റിക് ക്രമീകരണമോ അംഗീകൃത PAC-ബോധ്യമുള്ള ഇന്റഗ്രേഷനോ ഉപയോഗിക്കുക. പകർത്തിയ ഒരു വിലാസം ഹാർഡ്‌കോഡ് ചെയ്യുന്നത് നയം മാറുന്നതും ആ വിലാസം എന്തിന് തിരഞ്ഞെടുത്തുവെന്ന് ആർക്കും ഓർമ്മയില്ലാത്തതുമായ ദിവസം വരെ പ്രവർത്തിക്കും.
അതിന് ശേഷം curl എന്ത് പാരമ്പര്യമായി ലഭിക്കുന്നു എന്ന് നോക്കുക. proxy പരിസ്ഥിതി ചരങ്ങളും NO_PROXY നിങ്ങൾ നൽകിയ proxy-യെ അതിലംഘിക്കുകയോ ഒഴിവാക്കുകയോ ചെയ്യാം, നിങ്ങളുടെ ലക്ഷ്യവുമായി യോജിക്കുന്ന ഒഴിവാക്കൽ അഭ്യർത്ഥന നിശബ്ദമായി നേരിട്ട് അയയ്ക്കുന്നു. എല്ലാ ഒഴിവാക്കലുകളും മായ്ച്ചുകളയുന്നതിനോ എല്ലാം ഒരു വിലാസത്തിലൂടെ നിർബന്ധിക്കുന്നതിനോ പകരം ഉദ്ദേശിച്ച നയം സംരക്ഷിക്കുക. അഭ്യർത്ഥന ഒരിക്കൽ -v ഉപയോഗിച്ച് പ്രവർത്തിപ്പിച്ച് അത് യഥാർത്ഥത്തിൽ ഏത് വിലാസത്തിലേക്ക് കണക്റ്റ് ചെയ്തുവെന്ന് പരിശോധിക്കുക.
രണ്ട് TLS ഐഡന്റിറ്റികൾ വേർതിരിച്ച് സൂക്ഷിക്കുക
HTTPS proxy ഉപയോഗിക്കുമ്പോൾ രണ്ട് TLS കണക്ഷനുകൾ പ്രവർത്തനത്തിലുണ്ട്: proxy-യിലേക്കുള്ള നിങ്ങളുടേതും proxy-യിൽ നിന്ന് ലക്ഷ്യത്തിലേക്കുള്ളതും. ഓരോന്നിനും പരിശോധിക്കാനുള്ള സ്വന്തം ഐഡന്റിറ്റിയുണ്ട്, ഇവയിലേതെങ്കിലും ഒന്നിന് പരിശോധന ഓഫ് ചെയ്യുന്നത് PAC പരിഹാരമല്ല, ആദ്യ പ്രശ്നത്തോട് ചേർക്കുന്ന രണ്ടാമത്തെ പ്രശ്നമാണ്.
പരിശോധന ഓണായി വയ്ക്കുക, ലഭിക്കുന്ന പരാജയം വായിക്കുക. proxy പ്രാമാണീകരണ വെല്ലുവിളി, എത്തിച്ചേരാൻ കഴിയാത്ത proxy, വെബ്സൈറ്റിൽ നിന്നുള്ള നിരസിക്കൽ എന്നിവ മൂന്ന് വ്യത്യസ്ത ഫലങ്ങളാണ്, ആദ്യത്തേത് മാത്രമാണ് ക്രെഡൻഷ്യലുകളെക്കുറിച്ച്. VPN ഇപ്പോഴും സ്വകാര്യ proxy-യിലേക്ക് അനുവദനീയമായ പാത നൽകണം, proxy ഹോസ്റ്റിന്റെ നാമ വിശകലനം ഉൾപ്പെടെ, ഇവയൊന്നും വിജയിക്കുന്നതിന് മുമ്പ്.
എൻഡ്‌പോയിന്റ്, സ്കീം, പോർട്ട്, പ്രാമാണീകരണ രീതി, ഒഴിവാക്കലുകൾ, proxy വരെയുള്ള VPN പാത എന്നിവ എഴുതി സൂക്ഷിക്കുക. ആ രേഖയാണ് അടുത്ത അഭ്യർത്ഥന പുനരുൽപാദിപ്പിക്കാവുന്നതാക്കുന്നത്, നിങ്ങളുടെ proxy അറിയുന്നതും അതിനെക്കുറിച്ച് ഊഹിക്കുന്നതും തമ്മിലുള്ള വ്യത്യാസം അതാണ്.