OpenVPN ഹുക്ക് സ്ക്രിപ്റ്റിന് ഇപ്പോൾ നിർമ്മിച്ച ടണൽ ഉപയോഗിക്കാമോ?

ഒരു ഹുക്ക് സ്ക്രിപ്റ്റ് ടണലിന്റെ മറുവശത്ത് എത്തുമോ എന്നത് മൂന്ന് വ്യവസ്ഥകളെ ആശ്രയിച്ചിരിക്കുന്നു: അത് ഏത് ഇവന്റുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു, സ്ക്രിപ്റ്റ് പ്രവർത്തിക്കുമ്പോൾ OpenVPN ഇപ്പോഴും അതിന്റെ സ്റ്റാർട്ടപ്പ് ക്രമത്തിനുള്ളിലാണോ, കൂടാതെ ജോലി ആ ക്രമത്തിൽ നിന്ന് വേർതിരിച്ചിട്ടുണ്ടോ എന്നത്. മിക്ക സ്ക്രിപ്റ്റുകളും മൂന്നാമത്തേതിൽ പരാജയപ്പെടുന്നു. ഉറക്കം ചേർക്കുന്നത് ജീവിതചക്ര പ്രശ്നത്തെ സമയ പ്രശ്നമായി കാണുന്നു, അത് തെറ്റിദ്ധരിപ്പിക്കാൻ മാത്രം പ്രവർത്തിക്കുന്നു.

ആദ്യം ഇവന്റ് തീരുമാനിക്കുക, പിന്നെ ജോലി മാറ്റിവയ്ക്കാനുള്ള സംവിധാനം, പിന്നെ മാറ്റിവച്ച ജോലി പ്രവർത്തിക്കുന്ന സ്ഥലം. ഈ മൂന്ന് തീരുമാനങ്ങൾ സ്വതന്ത്രമാണ്, അവ കൂട്ടിക്കുഴയ്ക്കുന്നതാണ് രണ്ട് വരി ഹുക്കിനെ ഒരു ഉച്ചയാക്കുന്നത്.

ഹുക്ക് തന്നെ കാത്തിരിക്കുന്ന ടണലിനായി കാത്തിരിക്കുന്നത് എന്തുകൊണ്ട്

OpenVPN പാക്കറ്റുകൾ നീക്കുന്ന അതേ പ്രക്രിയയ്ക്കുള്ളിൽ ഹുക്കുകളെ സമകാലികമായി വിളിക്കുന്നു. tun അല്ലെങ്കിൽ tap ഉപകരണം നിലവിലുള്ളപ്പോൾ പക്ഷേ ഏതെങ്കിലും റൂട്ട് ചേർക്കുന്നതിന് മുൻപ് up പ്രവർത്തിക്കുന്നു, റൂട്ടുകൾക്ക് ശേഷം route-up പ്രവർത്തിക്കുന്നു; ആ നിമിഷങ്ങളിൽ ഒന്നും എതിർവശം മറുപടി നൽകുമെന്ന് ഉറപ്പ് നൽകുന്നില്ല. ഏതെങ്കിലും ഹുക്കിന്റെ സ്ക്രിപ്റ്റ് ഇപ്പോഴും പ്രവർത്തിക്കുന്നിടത്തോളം ഡീമൺ കൈമാറുന്നില്ല, അതിനാൽ ടണലിലൂടെ ട്രാഫിക് കടക്കുമെന്ന് പ്രതീക്ഷിക്കുന്ന കമാൻഡ് ആ കമാൻഡിനായി കാത്തിരിക്കുന്ന ടണലിനായി കാത്തിരിക്കുന്നു. ഈ വൃത്താകൃതിയിലുള്ള കാത്തിരിപ്പാണ് കൈകൊണ്ട് പ്രവർത്തിപ്പിക്കുമ്പോൾ വിജയിക്കാനും ഹുക്ക് സമയപരിധി കടക്കാനും കാരണം.

വ്യക്തമായ പരിഹാരം, അതായത് കുറച്ച് സെക്കൻഡ് ഉറങ്ങുക, ചിലപ്പോൾ പ്രവർത്തിക്കുന്നു കാരണം അകലെയുള്ള അറ്റം സ്വയം ഉയർന്നു, ഉറക്കം എന്തെങ്കിലും ശരിയാക്കിയതുകൊണ്ടല്ല. സന്നദ്ധത ചോദിക്കുന്ന സഹായി മറ്റൊരു ഉത്തരമാണ്: ഹുക്ക് മടങ്ങുന്നു, കൈമാറ്റം തുടങ്ങുന്നു, സഹായിക്ക് വേണ്ടത് അത് യഥാർത്ഥത്തിൽ ഉള്ളപ്പോൾ ലഭിക്കുന്നു.

സൗകര്യത്തിനല്ല, ഇവന്റ് അനുസരിച്ച് ഹുക്ക് തിരഞ്ഞെടുക്കുക

ഉപകരണം മാത്രം ആവശ്യമുള്ള ജോലിയിൽ up ബന്ധിപ്പിക്കുക, റൂട്ടുകൾ ആവശ്യമുള്ള ജോലിയിൽ route-up, കൂടാതെ client-connect, client-disconnect എന്നിവ സർവർ ഭാഗത്ത് ഓരോ ക്ലയന്റിനുമുള്ള ജോലികൾക്കായി സൂക്ഷിക്കുക. വിച്ഛേദനത്തിലെ വൃത്തിയാക്കൽ രണ്ടുതവണ പ്രവർത്തിക്കുന്നത് സഹിക്കണം, കാരണം സ്ഥിരമായ ഇന്റർഫേസിലൂടെയുള്ള പുനഃബന്ധനം പൂർണ്ണ പുനരാരംഭത്തിന്റെ അതേ ക്രമം പിന്തുടരുന്നില്ല. സർവറിൽ, ഡീമൺ തുടങ്ങുമ്പോഴല്ല, ക്ലയന്റ് പ്രാമാണീകരിക്കുമ്പോൾ client-connect പ്രവർത്തിക്കുന്നു, അത് യുക്തി അങ്ങോട്ട് മാറ്റുന്നതിന് മുൻപ് സ്ഥിരീകരിക്കേണ്ടതാണ്. ജോലി ഒരു ബന്ധത്തിന്റേതല്ലാതെ സേവനത്തിന്റെ ജീവിതചക്രത്തിന്റേതാണെങ്കിൽ, systemd യൂണിറ്റാണ് ഏത് ഹുക്കിനേക്കാളും നല്ല വീട്.

ഹുക്ക് കമാൻഡുകൾ ഡീമൺ നേരിട്ട് പ്രവർത്തിപ്പിക്കുന്നു, ഇടയിൽ ഷെല്ലില്ല, അതിനാൽ up വരിയിലെ ifconfig_remote അക്ഷരാർത്ഥത്തിലുള്ള പാഠമായി വരുന്നു. കമാൻഡ് വ്യക്തമായ ഷെല്ലിൽ പൊതിയുക, അല്ലെങ്കിൽ യുക്തി പരിസ്ഥിതി വായിക്കുന്ന സ്ക്രിപ്റ്റിൽ സൂക്ഷിക്കുക. ipchange സ്വന്തം ആർഗ്യുമെന്റുകൾ ചേർക്കുന്ന ഒരു നിർദ്ദേശമാണ്: അത് കമാൻഡിന് വിലാസവും പോർട്ടും നൽകുന്നു, അതിനാൽ ഒന്നിനും വേണ്ടി എഴുതാത്ത സ്ക്രിപ്റ്റ് രണ്ട് അപ്രതീക്ഷിതമായവ കാണുന്നു.

ജോലി വേർതിരിക്കാനുള്ള മൂന്ന് വഴികൾ

ആദ്യ ഓപ്ഷൻ ഹുക്കിനുള്ളിൽ നിന്ന് സഹായിയെ പശ്ചാത്തലത്തിലേക്ക് അയയ്ക്കുകയാണ്: setsid അല്ലെങ്കിൽ systemd-run --scope ഉപയോഗിച്ച് അത് തുടങ്ങുക, പാരമ്പര്യമായി ലഭിച്ച ഡിസ്ക്രിപ്റ്ററുകൾ അടയ്ക്കുക, ഉടൻ പൂജ്യത്തോടെ പുറത്തുകടക്കുക. രണ്ടാമത്തേത് ഹുക്ക് ഒരു ചെറിയ അവസ്ഥാ ഫയൽ എഴുതി systemd ടൈമറോ പാത്ത് യൂണിറ്റോ അതിൽ പ്രവർത്തിക്കാൻ അനുവദിക്കുകയാണ്, അത് ഹുക്കിനെ ലളിതമായി നിർത്തി വീണ്ടും ശ്രമിക്കാനുള്ള നയം ലോഗുകളുള്ളിടത്ത് വയ്ക്കുന്നു. മൂന്നാമത്തേത് ഹുക്ക് പൂർണ്ണമായി ഉപേക്ഷിച്ച് ജോലി VPN സേവനത്തിന് ശേഷം ക്രമീകരിച്ച യൂണിറ്റിലേക്ക് മാറ്റുകയാണ്, ജോലി ഒട്ടും ഓരോ ബന്ധത്തിന്റേതല്ലെങ്കിൽ ഇതാണ് ശരിയായ ഉത്തരം. മൂന്നും ഒരു നിയമം പങ്കിടുന്നു: ടണൽ ആവശ്യമാകുന്നതിന് മുൻപ് ഹുക്ക് മടങ്ങണം.

ഏത് തിരഞ്ഞെടുത്താലും, സഹായിയെ ഐഡംപോട്ടന്റും നിരീക്ഷിക്കാവുന്നതുമാക്കുക. രണ്ട് ഓവർലാപ്പിംഗ് വിളികൾ ഒരേ മാറ്റാനാവാത്ത പ്രവർത്തനം രണ്ടുതവണ നടത്തരുത്, പരാജയപ്പെടുന്ന സഹായി മനുഷ്യന് വായിക്കാവുന്ന എന്തെങ്കിലും അവശേഷിപ്പിക്കണം.

സാൻഡ്ബോക്സ് പരാജയങ്ങളെ ജീവിതചക്ര പരാജയങ്ങളിൽ നിന്ന് വേർതിരിക്കുക

സ്ക്രിപ്റ്റ് root പ്രോംപ്റ്റിൽ നിന്ന് പ്രവർത്തിച്ച് സേവനമായി പരാജയപ്പെടുമ്പോൾ, കാരണം സാധാരണയായി നെറ്റ്വർക്കല്ല, സാൻഡ്ബോക്സാണ്. നിയന്ത്രിക്കുന്ന ProtectHome, വായനയ്ക്ക് മാത്രമുള്ള ProtectSystem, അല്ലെങ്കിൽ നിലവിലില്ലാത്ത ജോലി ഡയറക്ടറി സ്ക്രിപ്റ്റിനെയോ അതിന്റെ ഡാറ്റയെയോ എത്തിച്ചേരാനാകാത്തതാക്കാം, SELinux ഹോസ്റ്റിൽ ഫയലിന് പ്രവർത്തിപ്പിക്കാൻ അനുവദിക്കുന്ന സന്ദർഭവും വേണം. systemctl cat openvpn-server@server ഉപയോഗിച്ച് യൂണിറ്റും journalctl -u openvpn-server@server -n 80 ഉപയോഗിച്ച് ജേണലും വായിക്കുക, പിന്നെ കണക്ഷൻ സമയപരിധിക്ക് പകരം അനുമതിയോ സന്ദർഭമോ ഉള്ള പിശക് തിരയുക. സാൻഡ്ബോക്സ് പ്രവർത്തനരഹിതമാക്കുന്നത് ആദ്യത്തേതല്ല, അവസാന നടപടിയായിരിക്കണം.

ജീവിതചക്ര പരാജയം വ്യത്യസ്തമായി കാണപ്പെടുന്നു: ഹുക്ക് തുടങ്ങുന്നു, സഹായി പ്രവർത്തിക്കുന്നു, സോക്കറ്റ് ഇപ്പോഴും അവിടെയില്ല. ഹുക്കിൽ നിന്നുതന്നെ ടൈംസ്റ്റാമ്പുള്ള വരി എഴുതുക, വിച്ഛേദിച്ച് വീണ്ടും ബന്ധിപ്പിക്കുക, ഇവന്റുകൾ ക്രമത്തിൽ വായിക്കുക. സഹായിക്ക് യഥാർത്ഥത്തിൽ ടണൽ വേണമെങ്കിൽ, നിശ്ചിത സമയം ഉറങ്ങുന്നതിന് പകരം സന്നദ്ധത ചോദിക്കാൻ അനുവദിക്കുക.

മൂന്ന് ഫീൽഡുകൾ അടുത്ത റിപ്പോർട്ടിനെ ഉപയോഗപ്രദമാക്കുന്നു: ഏത് ഹുക്ക് പ്രവർത്തിച്ചു, ഏത് അക്കൗണ്ട് ഉപയോഗിച്ചു, എവിടെ നിർത്തി. അവയില്ലാതെ ഓരോ തുടർ അന്വേഷണവും വീണ്ടും തുടക്കം മുതൽ ആരംഭിക്കുന്നു.