ക്ലയന്റ് ഹുക്കോ സർവർ ഹുക്കോ? OpenVPN സ്ക്രിപ്റ്റ് എവിടെ പ്രവർത്തിക്കുന്നു

ജോലി വ്യക്തമാണ്: ലാപ്ടോപ്പ് കണക്റ്റ് ചെയ്യുമ്പോൾ ലാപ്ടോപ്പിൽ എന്തെങ്കിലും മാറണം. എഡിറ്റ് ചെയ്യുന്ന കോൺഫിഗറേഷൻ സർവറിന്റേതാണ്, അവിടെത്തന്നെയാണ് അനുമാനം തകരുന്നത്. സർവർ ഫയലിലെ പാത്ത് ആ സർവറിലെ ഫയലിനെ സൂചിപ്പിക്കുന്നു, എത്ര push ചെയ്താലും ഏത് പ്രോസസ് അത് പ്രവർത്തിപ്പിക്കുന്നു എന്നത് മാറുന്നില്ല. രണ്ട് ഹുക്കുകളിൽ ഒന്ന് തിരഞ്ഞെടുക്കുന്നത് പ്രധാനമായും ഏത് യന്ത്രമാണ് ജോലിയുടെ ഉടമ എന്ന് തീരുമാനിക്കുകയും അതിൽ നിന്ന് ഉണ്ടാകുന്ന പരിധികൾ അംഗീകരിക്കുകയും ചെയ്യുന്നതാണ്.

രണ്ട് യന്ത്രങ്ങൾ, ആദ്യം ഉത്തരം നൽകേണ്ട രണ്ട് ചോദ്യങ്ങൾ

സ്റ്റേറ്റ് മാറ്റം എവിടെ സംഭവിക്കണം എന്ന് ചോദിക്കുക, തുടർന്ന് ഏത് സംഭവമാണ് അതിന് യോജിക്കുന്നതെന്ന് ചോദിക്കുക. മാറ്റം ഓരോ ഉപയോക്താവിനുമുള്ള അനുമതിയോ ഓരോ ക്ലയന്റിനുമുള്ള കോൺഫിഗറേഷൻ തീരുമാനമോ ആണെങ്കിൽ, ഉപയോക്തൃ ഡയറക്ടറി അറിയാവുന്നിടത്ത് അത് പെടുന്നു: സർവറിൽ. മാറ്റം ഒരു റൂട്ട് ആണെങ്കിൽ, resolver ക്രമീകരണമോ എൻഡ്പോയിന്റിലെ ലോക്കൽ സഹായിയോ ആണെങ്കിൽ, അത് എൻഡ്പോയിന്റിൽ പെടുന്നു, എൻഡ്പോയിന്റിന് മാത്രമേ അത് ചെയ്യാനാകൂ.

ഈ രണ്ട് ചോദ്യങ്ങൾക്ക് വിപരീത ക്രമത്തിൽ ഉത്തരം നൽകുന്നതാണ് ആളുകൾ Windows ലാപ്ടോപ്പിലേക്ക് ബാച്ച് ഫയൽ push ചെയ്യാൻ ശ്രമിക്കുന്നതിൽ എത്തുന്ന വഴി. സർവറിന് ആരാണ് കണക്റ്റ് ചെയ്തതെന്ന് അറിയാം; ലാപ്ടോപ്പിന് അതിന്റെ സ്വന്തം നെറ്റ്വർക്ക് സ്റ്റാക്ക് എങ്ങനെയിരിക്കുമെന്ന് അറിയാം. ഒന്നിനും മറ്റേതിന്റെ വിവരമില്ല, ശ്രമം പൊതുവെ വ്യക്തമായ പിശകിന് പകരം നിശബ്ദമായി പരാജയപ്പെടുന്നു.

രണ്ടിനും മുൻപ് മൂന്നാമതൊരു ചോദ്യം ചോദിക്കുന്നത് ഉചിതമാണ്: പ്ലാറ്റ്ഫോം നിങ്ങൾ ആഗ്രഹിക്കുന്ന ഹുക്ക് ഒട്ടും നൽകുന്നുണ്ടോ? സ്വന്തം കോൺഫിഗറേഷൻ തന്നെ ഉണ്ടാക്കുന്ന ഉപകരണം അതേ സംഭവനാമങ്ങൾ നൽകണമെന്നില്ല, കൂടാതെ .ovpn ഫയൽ ഇംപോർട്ട് ചെയ്യുന്ന ഡെസ്ക്ടോപ്പ് ക്ലയന്റ് ഫയൽ എഴുതിയ ക്ലയന്റ് തന്നെയായിരിക്കണമെന്നുമില്ല. പ്ലാറ്റ്ഫോം ആദ്യം സ്ഥിരീകരിക്കുന്നത് അവിടെ ഇല്ലാത്ത ഒരു ഹുക്കിനെ ചുറ്റിപ്പറ്റി രൂപകൽപ്പന ചെയ്യുന്നതിൽ നിന്ന് നിങ്ങളെ രക്ഷിക്കുന്നു. നിങ്ങളുടെ മുന്നിലുള്ള യന്ത്രത്തിന് ഏത് ഡോക്യുമെന്റേഷൻ യഥാർഥത്തിൽ ബാധകമാണെന്നും അത് പറയുന്നു.

സർവർ വശത്തെ ഓപ്ഷൻ: ഓരോ കണക്ഷനും ഒരു സംഭവം

client-connect സ്ക്രിപ്റ്റ് പ്രാമാണീകരിച്ച ക്ലയന്റ് കണക്റ്റ് ചെയ്യുമ്പോൾ സർവറിന്റെ പ്രോസസ് സന്ദർഭത്തിൽ പ്രവർത്തിക്കുന്നു, common name, അനുവദിച്ച വിലാസം തുടങ്ങിയ രേഖപ്പെടുത്തിയ കണക്ഷൻ വിവരങ്ങൾ സ്വീകരിക്കുന്നു. ഓരോ ക്ലയന്റിനുമുള്ള കോൺഫിഗറേഷൻ ഭാഗം എഴുതാനും നയ തീരുമാനം നടപ്പാക്കാനും സർവറിന്റെ ഉടമസ്ഥതയിലുള്ള സ്റ്റേറ്റ് രേഖപ്പെടുത്താനും ഇത് ശരിയായ സ്ഥലമാണ്.

ആളുകൾ വിട്ടുപോകുന്ന വ്യത്യാസം ആ ഹുക്കും സർവറിന്റെ up ഹുക്കും തമ്മിലുള്ള വ്യത്യാസമാണ്. സർവർ അതിന്റെ ടണൽ ഉപകരണം തുറക്കുമ്പോൾ up ഹുക്ക് പ്രവർത്തിക്കുന്നു, ഒന്നിലധികം ക്ലയന്റുകളുള്ള സർവറിൽ ഡീമൺ ആരംഭിക്കുമ്പോൾ ഇത് ഒരിക്കൽ മാത്രം സംഭവിക്കുന്നു. ഇത് ഓരോ ലോഗിനിലും ഉള്ള സംഭവമല്ല, അവിടെ വെക്കുന്ന കോഡ് ഉപയോക്താക്കൾ കണക്റ്റ് ചെയ്യുമ്പോഴല്ല, സേവനം ആരംഭിക്കുമ്പോൾ പ്രവർത്തിക്കുന്നു.

വെബ് ഇന്റർഫേസുള്ള ഉപകരണത്തിൽ ഉത്പാദിപ്പിച്ച ഡീമൺ ഫയലുകൾ എഡിറ്റ് ചെയ്യുന്നതിന് പകരം പിന്തുണയുള്ള എക്സ്റ്റൻഷൻ സംവിധാനം ഉപയോഗിക്കുക. ഉത്പാദിപ്പിച്ച ഫയലുകൾ അടുത്ത സേവ് ചെയ്യുമ്പോൾ വീണ്ടും എഴുതപ്പെടുന്നു, ആ പുനർലേഖനം ഏറ്റവും മോശം നിമിഷത്തിൽ നിങ്ങളുടെ മാറ്റം നിശബ്ദമായി നീക്കിക്കളയുന്നു. എക്സ്റ്റൻഷൻ ടെക്സ്റ്റിന്റെ പകർപ്പ് ഉപകരണത്തിന് പുറത്ത് സൂക്ഷിക്കുക, അങ്ങനെ ഫേംവെയർ അപ്ഡേറ്റും ഉദ്ദേശ്യം നഷ്ടപ്പെടുത്തില്ല.

ക്ലയന്റ് വശത്തെ ഓപ്ഷൻ: ലോക്കലായി പ്രവർത്തിക്കേണ്ട ജോലി

കമ്മ്യൂണിറ്റി ക്ലയന്റിന് ടണൽ ഉപകരണം ഉയരുമ്പോൾ, വീണ്ടും റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുമ്പോൾ ലോക്കൽ സ്ക്രിപ്റ്റ് പ്രവർത്തിപ്പിക്കാം. ഇവ രണ്ട് വ്യത്യസ്ത നിമിഷങ്ങളാണ്, തെറ്റായത് തിരഞ്ഞെടുത്താൽ ആശ്രയിക്കുന്ന റൂട്ട് നിലവിലുള്ളതിന് മുൻപ് സഹായി ആരംഭിക്കുന്ന പരമ്പരാഗത മത്സരം ഉണ്ടാകുന്നു.

സഹായി ആ ക്ലയന്റിൽ ഉണ്ടായിരിക്കണം, ക്ലയന്റ് പ്രവർത്തിപ്പിക്കുന്ന അക്കൗണ്ടിന് വായിക്കാനും പ്രവർത്തിപ്പിക്കാനും കഴിയണം, കൂടാതെ വ്യക്തമായ script-security ക്രമീകരണം അനുവദിക്കണം. അഡ്മിനിസ്ട്രേറ്ററായി ക്ലയന്റ് പ്രവർത്തിപ്പിക്കുമ്പോൾ പ്രവർത്തിക്കുന്ന സ്ക്രിപ്റ്റ് ലോഗിന് മുൻപുള്ള സേവനത്തെക്കുറിച്ചോ മറ്റൊരു ഉപയോക്താവിന്റെ സെഷനെക്കുറിച്ചോ ഒന്നും പറയുന്നില്ല.

പേരിടലും പ്രധാനമാണ്. up ഹുക്ക് ഉപകരണ സൃഷ്ടിയുമായും route-up റൂട്ട് ഇൻസ്റ്റാളേഷനുമായും യോജിക്കുന്നു, പക്ഷേ സ്വകാര്യ നെറ്റ്വർക്ക് എത്തിച്ചേരാൻ കഴിയണം എന്ന് ആവശ്യപ്പെടുന്ന ജോലി ഉപകരണ സൃഷ്ടി എന്നാൽ എല്ലാ റൂട്ടും resolver എൻട്രിയും ആപ്ലിക്കേഷനും തയ്യാറാണെന്ന് അനുമാനിക്കുന്നതിന് പകരം എത്തിച്ചേരാനുള്ള കഴിവ് പരിശോധിക്കണം.

എക്സിക്യൂട്ടബിൾ കോഡ് push ചെയ്യുന്നത് ഓപ്ഷനുകളിൽ ഇല്ലാത്തത് എന്തുകൊണ്ട്

push ചെയ്യുന്ന ഓപ്ഷനുകൾ ബോധപൂർവം പരിമിതപ്പെടുത്തിയിരിക്കുന്നു, സ്ക്രിപ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുന്ന ഓപ്ഷനുകൾ സർവറിന് കൈമാറാൻ അനുവാദമില്ലാത്ത വിഭാഗങ്ങളിൽ പെടുന്നു. ആ നിയന്ത്രണം ഉള്ളത്, അല്ലാത്തപക്ഷം വിട്ടുപോയതോ തെറ്റായി കോൺഫിഗർ ചെയ്തതോ ആയ സർവറിന് എപ്പോഴെങ്കിലും കണക്റ്റ് ചെയ്യുന്ന ഓരോ ക്ലയന്റിലും ഏകപക്ഷീയ കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കാൻ കഴിയുമായിരുന്നു എന്നതുകൊണ്ടാണ്.

ലോക്കലായി സ്ക്രിപ്റ്റ് പ്രവർത്തനം പ്രാപ്തമാക്കുന്നത് അത് മാറ്റുന്നില്ല. നിങ്ങളുടെ script-security ക്രമീകരണം നിങ്ങൾ തിരഞ്ഞെടുത്ത ലോക്കൽ സ്ക്രിപ്റ്റുകൾക്ക് അനുമതി നൽകുന്നു; അത് സർവറിന് പുതിയവ നൽകാനുള്ള അധികാരം നൽകുന്നില്ല.

ലക്ഷ്യം VPN റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുക മാത്രമാണെങ്കിൽ, ദൂരസ്ഥ എക്സിക്യൂഷൻ പദ്ധതി കണ്ടുപിടിക്കുന്നതിന് പകരം പിന്തുണയുള്ള റൂട്ട് കോൺഫിഗറേഷൻ ഉപയോഗിക്കുക. ലക്ഷ്യത്തിന് യഥാർഥത്തിൽ ലോക്കൽ കോഡ് ആവശ്യമാണെങ്കിൽ, സംഘടനയുടെ എൻഡ്പോയിന്റ് മാനേജ്മെന്റ് ടൂളുകളിലൂടെ അത് വിതരണം ചെയ്യുക, ഉപയോക്താവിന്റെ പ്രത്യേകാവകാശങ്ങളോടെ പ്രവർത്തിക്കുന്ന മറ്റേതൊരു സോഫ്റ്റ്വെയറിനെയും പോലെ അത് അവലോകനം ചെയ്യുക.

ഏത് ഹുക്കിനെയും വിശ്വസിക്കുന്നതിന് മുൻപ് എന്ത് പരിശോധിക്കണം

ഓരോ ഹുക്കിനും നാല് കാര്യങ്ങൾ എഴുതുക: യന്ത്രം, സംഭവത്തിന്റെ പേര്, അത് പ്രവർത്തിക്കുന്ന അക്കൗണ്ട്, അത് ഉണ്ടാക്കേണ്ട സ്റ്റേറ്റ് മാറ്റം. തുടർന്ന് കണക്ഷൻ, വീണ്ടും കണക്ഷൻ, ക്ലീനപ്പ് പാത്ത് എന്നിവ പരിശോധിക്കുക, കാരണം വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ സ്റ്റേറ്റ് ചോരുന്ന ഹുക്ക് ഒരിക്കലും പ്രവർത്തിക്കാത്ത ഹുക്കിനെക്കാൾ മോശമാണ്.

യഥാർഥത്തിൽ അത് പ്രവർത്തിപ്പിക്കുന്ന അക്കൗണ്ടിന് കീഴിൽ, യഥാർഥത്തിൽ പ്രവർത്തിക്കുന്ന നിമിഷത്ത് പരിശോധിക്കുക. openvpn(8) മാനുവൽ രണ്ട് ഹുക്ക് കുടുംബങ്ങളും push പരിധികളും രേഖപ്പെടുത്തുന്നു; നിങ്ങൾ വിന്യസിക്കുന്ന പ്ലാറ്റ്ഫോം അവ ഒട്ടും നൽകുന്നുണ്ടോ എന്ന് രേഖപ്പെടുത്തുന്നു. ഇന്ററാക്ടീവ് അഡ്മിനിസ്ട്രേറ്റർ ടെർമിനലിൽ വിജയിക്കുന്ന സ്ക്രിപ്റ്റ് ഒരു അനുമാനമാണ്, പരിശോധനയല്ല.