macOS-ൽ OpenConnect: പാക്കേജ്, റിലീസ് ആർക്കൈവ് അല്ലെങ്കിൽ git ക്ലോൺ
Homebrew ഒരു ബൈനറിയും നെറ്റ്വർക്ക് സ്ക്രിപ്റ്റും നൽകുന്നു; സോഴ്സ് ട്രീ അവ നിർമ്മിച്ച് പ്രവർത്തിപ്പിക്കുന്നതുവരെ ഒന്നും നൽകുന്നില്ല. നിങ്ങളുടെ കണക്ഷൻ ഏതാണ് ഉപയോഗിക്കുന്നതെന്ന് അറിയുക.
Mac-ൽ OpenConnect ക്ലയന്റ് ലഭിക്കാൻ മൂന്ന് വഴികളുണ്ട്, അവ ഡിസ്കിൽ വ്യത്യസ്ത കാര്യങ്ങൾ വിടുന്നു. Homebrew ഫോർമുല ഒരു കംപൈൽ ചെയ്ത ബൈനറിയും റൂട്ടുകളും DNS-ഉം ക്രമീകരിക്കുന്ന നെറ്റ്വർക്ക് സ്ക്രിപ്റ്റും ഇൻസ്റ്റാൾ ചെയ്യുന്നു. റിലീസ് ആർക്കൈവ് ജനറേറ്റ് ചെയ്ത ബിൽഡ് സിസ്റ്റത്തോടുകൂടിയ സോഴ്സ് കോഡ് നൽകുന്നു. git ചെക്ക്ഔട്ട് അതില്ലാതെ സോഴ്സ് കോഡ് നൽകുന്നു. തെറ്റായത് തിരഞ്ഞെടുക്കുന്നതാണ് ട്യൂട്ടോറിയൽ തുടങ്ങി കുറച്ച് മിനിറ്റുകൾക്കുള്ളിൽ കാണാതായ configure അഭിമുഖീകരിക്കാൻ കാരണം.
ഒരേ പേരിൽ രണ്ട് വ്യത്യസ്ത യന്ത്രങ്ങൾ
പാക്കേജ് വഴി ഒരു കമാൻഡ് മാത്രമാണ്, വികസനമല്ല കണക്ട് ചെയ്യലാണ് ജോലിയെന്നുള്ളവർക്ക് ഇതാണ് ശരിയായ ഡിഫോൾട്ട്.
brew install openconnect
ഇത് എന്ത് ഇൻസ്റ്റാൾ ചെയ്യുന്നു എന്നത് കമാൻഡിനെക്കാൾ പ്രധാനമാണ്. ക്ലയന്റിന്റെ ബൈനറി ലഭിക്കുന്നു, കൂടാതെ ഇന്റർഫേസും റൂട്ടുകളും റിസോൾവറും പ്രോഗ്രാം ചെയ്യാൻ ക്ലയന്റ് വിളിക്കുന്ന vpnc-script ഉം ലഭിക്കുന്നു. രണ്ടും ജോടിയായി പ്രവർത്തിക്കുന്നു: ബൈനറി TLS സെഷൻ അവസാനിപ്പിച്ച് ഉണ്ടായ ഇന്റർഫേസ് സ്ക്രിപ്റ്റിന് നൽകുന്നു, ഈ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം തന്റെ നെറ്റ്വർക്ക് എങ്ങനെ മാറ്റണമെന്ന് അറിയുന്ന ഭാഗമാണ് സ്ക്രിപ്റ്റ്.
ഈ വിഭജനം ആശയക്കുഴപ്പമുള്ള റിപ്പോർട്ടുകളുടെ ഒരു മുഴുവൻ വിഭാഗത്തെ വിശദീകരിക്കുന്നു. കണക്ട് ചെയ്ത് വിജയം റിപ്പോർട്ട് ചെയ്ത ശേഷം ട്രാഫിക് തെറ്റായ വഴിയിലേക്ക് അയക്കുന്ന ക്ലയന്റിൽ സാധാരണയായി സ്ക്രിപ്റ്റ് പ്രശ്നമാണ്, ടണൽ പ്രശ്നമല്ല, ഫോർമുല വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുമ്പോൾ ശരിയാകുന്നത് സ്ക്രിപ്റ്റും വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നതുകൊണ്ട് മാത്രമാണ്. ഫോർമുലയുടെ നിലവിലെ macOS, CPU ആർക്കിടെക്ചർ പിന്തുണ അതിനെ ആശ്രയിച്ച് ആസൂത്രണം ചെയ്യുന്നതിന് മുമ്പ് പരിശോധിക്കുക; ഷെൽ തികച്ചും പ്രവർത്തിപ്പിക്കുന്ന Mac-നും ഇപ്പോഴും അതിനായി നിർമ്മിച്ച നിലവിലെ പാക്കേജ് ഇല്ലായിരിക്കാം.
സോഴ്സ് വഴി യഥാർത്ഥത്തിൽ എന്ത് ചെയ്യുന്നു
റിലീസ് ആർക്കൈവ് ജനറേറ്റ് ചെയ്ത ബിൽഡ് സിസ്റ്റത്തോടെ വരുന്നു, അതിനാൽ പരിചിതമായ ./configure തുടക്കം മുതലേ ഉണ്ട്. git ചെക്ക്ഔട്ടിൽ ഇല്ല, കാരണം ജനറേറ്റ് ചെയ്ത ഫയലുകൾ ബിൽഡ് ഉൽപ്പന്നങ്ങളാണ്, പ്രോജക്ട് സൂക്ഷിക്കുന്ന കാര്യങ്ങളല്ല. ./autogen.sh ആർക്കൈവുകളിൽ അല്ലാതെ ചെക്ക്ഔട്ടുകളുടെ നിർദ്ദേശങ്ങളിൽ പ്രത്യക്ഷപ്പെടുന്നതിന്റെ മുഴുവൻ കാരണം ഇതാണ്.
./autogen.sh
./configure
make
make install
ഓരോ വരിയും നിർദ്ദിഷ്ടമായ എന്തോ ചെയ്യുന്നു, ഏതാണ് പരാജയപ്പെട്ടതെന്ന് അറിയുന്നത് ഒരുപാട് ഊഹങ്ങൾ ലാഭിക്കുന്നു. autogen ഘട്ടം configure നിർമ്മിക്കാൻ autotools പ്രവർത്തിപ്പിക്കുന്നു. configure ഘട്ടം ക്ലയന്റിന് ആവശ്യമായ കംപൈലർ, ലൈബ്രറികൾ, ഹെഡറുകൾ എന്നിവ പരിശോധിച്ച് കണ്ടെത്തിയത് പ്രതിഫലിപ്പിക്കുന്ന makefile എഴുതുന്നു. make ഘട്ടം കംപൈൽ ചെയ്യുന്നു. install ഘട്ടം ഫലങ്ങൾ നിങ്ങളുടെ പാത്തിലെവിടെയോ പകർത്തുന്നു.
ആ അവസാന വരിയിലാണ് ഉപദേശം സാധാരണയായി പിഴയ്ക്കുന്നത്. ഇൻസ്റ്റലേഷൻ ബിൽഡ് വിജയിച്ചതിന്റെ തെളിവല്ല, ഒരു ഏകപക്ഷീയ ഡൗൺലോഡ് ഫോൾഡറിൽ ഉയർന്ന അനുമതികളോടെ അത് പ്രവർത്തിപ്പിക്കുന്നത് പിന്നീട് ഓർക്കാത്ത ഫയലുകൾ ചിതറിക്കാൻ നല്ല വഴിയാണ്. ലൈബ്രറി ഇല്ലാത്തതിനാൽ configure പരാജയപ്പെട്ടാൽ, ഉപയോഗപ്രദമായ ഔട്ട്പുട്ട് അത് പ്രിന്റ് ചെയ്ത ആദ്യ പിശകാണ്, ലോഗിന്റെ അവസാന ഇരുപത് വരികളല്ല.
സെഷനും നെറ്റ്വർക്ക് കോൺഫിഗറേഷനും വേറിട്ടതാണ്
ഈ വ്യത്യാസം കണക്ഷൻ യഥാർത്ഥത്തിൽ ട്രാഫിക് വഹിക്കുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു. TLS സെഷൻ സ്ഥാപിക്കുന്നത് ക്ലയന്റ് ഭാഗത്ത് ഒരു ഇന്റർഫേസ് നൽകുന്നു. റൂട്ടുകളും വിലാസങ്ങളും DNS റിസോൾവറുകളും പ്രയോഗിക്കുന്നത് നെറ്റ്വർക്ക് സ്ക്രിപ്റ്റ് വഴി ചെയ്യുന്ന രണ്ടാം ഘട്ടമാണ്, സ്ക്രിപ്റ്റില്ലാതെ ബൈനറി നിർമ്മിച്ച ബിൽഡിന് പകുതി ക്ലയന്റേ ഉള്ളൂ.
അതേ വേർതിരിവ് ഒരേപോലെയുള്ള ക്ലയന്റുകളുള്ള രണ്ട് യന്ത്രങ്ങൾ എന്തുകൊണ്ട് വ്യത്യസ്തമായി പെരുമാറുന്നു എന്ന് വിശദീകരിക്കുന്നു: സ്ക്രിപ്റ്റ് സിസ്റ്റത്തിന്റെ നെറ്റ്വർക്ക് കോൺഫിഗറേഷൻ ആലോചിക്കുന്നു, ആ കോൺഫിഗറേഷനിൽ ഒരു റൂട്ട് ആവശ്യപ്പെട്ട മറ്റെല്ലാം ഉൾപ്പെടുന്നു. സ്പ്ലിറ്റ് ടണൽ ട്രാഫിക് അപ്രതീക്ഷിതമായ സ്ഥലത്തേക്ക് അയക്കുമ്പോൾ ടണൽ തന്റെ ജോലി ചെയ്യുകയാണ്, പരിശോധിക്കേണ്ടത് റൂട്ടിംഗ് തീരുമാനമാണ്.
അതിനാൽ ഡീബഗ് ചെയ്യുമ്പോൾ ഏത് പാളി പരാജയപ്പെട്ടു എന്ന് ചോദിക്കുക. ഒരിക്കലും സ്ഥാപിക്കാത്ത സെഷൻ പ്രോട്ടോക്കോൾ, സർട്ടിഫിക്കറ്റ് അല്ലെങ്കിൽ ക്രെഡൻഷ്യലുകളാണ്. സ്ഥാപിക്കുകയും ഒന്നും കൈമാറാതിരിക്കുകയും ചെയ്യുന്ന സെഷൻ ഇന്റർഫേസും സ്ക്രിപ്റ്റുമാണ്. ഒരു നെറ്റ്വർക്കിൽ നിന്ന് പ്രവർത്തിക്കുകയും മറ്റൊന്നിൽ നിന്ന് പ്രവർത്തിക്കാതിരിക്കുകയും ചെയ്യുന്ന ഇൻസ്റ്റാൾ ചെയ്ത ക്ലയന്റ് എത്തിച്ചേരലാണ്, എത്ര പുനർനിർമ്മാണവും അത് മാറ്റില്ല.
നിങ്ങൾ ഏത് ബൈനറിയാണ് പ്രവർത്തിപ്പിക്കുന്നതെന്ന് അറിയുക
കൈകൊണ്ട് ഇൻസ്റ്റാൾ ചെയ്ത ബിൽഡും പാക്കേജ് ചെയ്ത ബൈനറിയും സമാധാനത്തോടെ ഒരുമിച്ച് നിലനിൽക്കാം, ഏതാണ് പ്രവർത്തിക്കുന്നതെന്ന് നിങ്ങളുടെ ഉദ്ദേശ്യങ്ങളല്ല, പാത്ത് തീരുമാനിക്കുന്നു. ആർക്കെങ്കിലും പതിപ്പ് നമ്പർ റിപ്പോർട്ട് ചെയ്യുന്നതിന് മുമ്പ് ഇത് കണ്ടെത്തുക.
which -a openconnect
openconnect --version
brew list --versions openconnect
ആദ്യ കമാൻഡ് നിങ്ങളുടെ ഷെല്ലിന് കാണാവുന്ന എല്ലാ പകർപ്പുകളും അത് പരീക്ഷിക്കുന്ന ക്രമത്തിൽ ലിസ്റ്റ് ചെയ്യുന്നു. രണ്ടാമത്തേത് ഏതാണ് ഉത്തരം നൽകിയതെന്ന് പറയുന്നു. അത് നിങ്ങളുടെ പ്രതീക്ഷയുമായി പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, നിങ്ങൾ പഴയ പരീക്ഷണത്തിൽ നിന്നുള്ള ബിൽഡ് പ്രവർത്തിപ്പിക്കുകയാണ്, ഒരു കോൺഫിഗറേഷൻ മാറ്റവും അതിനെ നീക്കില്ല.
ക്ലയന്റ് ഇൻസ്റ്റാൾ ചെയ്യുന്നത് ഗേറ്റ്വേ അനുമതിയല്ല
പ്രവർത്തിക്കുന്ന ബൈനറി ഒരു വിന്യാസത്തെ അനുയോജ്യമാക്കുന്നില്ല. ഗേറ്റ്വേയുടെ പ്രോട്ടോക്കോൾ, അതിന്റെ പ്രാമാണീകരണ പ്രവാഹം, മാനേജ്ഡ് ഉപകരണ ആവശ്യകത എന്നിവ അത് ഉടമസ്ഥരായ ആളുകളുമായി സ്ഥിരീകരിക്കുക, കാരണം അവ ബിൽഡ് നൽകാനാകാത്ത നയ-ആപ്ലിക്കേഷൻ പാളി വസ്തുതകളാണ്.
പ്രോജക്ടിന്റെ ബിൽഡ് നിർദ്ദേശങ്ങൾ autotools ക്രമവും നെറ്റ്വർക്ക് സ്ക്രിപ്റ്റ് ആവശ്യകതയും കൂടുതൽ വിശദമായി പരിഗണിക്കുന്നു, നിങ്ങളുടെ macOS പതിപ്പിനേക്കാൾ പഴയ ഒരു ബ്ലോഗ് പോസ്റ്റല്ല, ഇവ പിന്തുടരണം. ലക്ഷ്യം വെറും കണക്ട് ചെയ്യലാണെങ്കിൽ, പാക്കേജ് എടുക്കുക, സ്ക്രിപ്റ്റ് സൂക്ഷിക്കുക, കംപൈലർ പുറത്ത് നിർത്തുക.