ifconfig-noexec നിങ്ങളുടെ SSH സെഷൻ രക്ഷിക്കില്ല: അത് യഥാർത്ഥത്തിൽ എന്ത് ചെയ്യുന്നു
ഇത് OpenVPN-ന്റെ സ്വന്തം ഇന്റർഫേസ് വിലാസ ക്രമീകരണം അടിച്ചമർത്തുന്നു. ഇത് SSH-നുള്ള മറുപടി റൂട്ട് സംവരണം ചെയ്യുന്നില്ല, എല്ലാ റൂട്ട് മാറ്റങ്ങളും ഓഫ് ചെയ്യുന്നില്ല, കാണാത്ത വിലാസം നൽകുന്നുമില്ല.
ഒരു ഫോറം ത്രെഡിൽ, ifconfig-noexec ടണൽ ഉയരുമ്പോൾ SSH സെഷൻ ജീവനോടെ നിലനിർത്തുന്ന പരിഹാരമായി നിർദ്ദേശിക്കപ്പെടുന്നു. ഈ ഓപ്ഷൻ എന്തിനെ തൊടുന്നു എന്ന് പരിശോധിക്കുന്നതുവരെ ആ വാദം ന്യായയുക്തമായി തോന്നും. ഇത് OpenVPN ടണൽ ഇന്റർഫേസിന്റെ വിലാസം ക്രമീകരിക്കുന്നതിൽ നിന്ന് തടയുകയും ആ മൂല്യങ്ങൾ പകരം സ്ക്രിപ്റ്റുകൾക്ക് നൽകുകയും ചെയ്യുന്നു; നിങ്ങളുടെ മാനേജ്മെന്റ് കണക്ഷനുള്ള മറുപടികൾ എവിടെ പോകുന്നു എന്നതിനെക്കുറിച്ച് ഇത് ഒന്നും പറയുന്നില്ല. വിപരീതം വിശ്വസിക്കുന്നത് ഉപയോഗയോഗ്യമായ വിലാസമില്ലാത്ത ടണലും എന്നിട്ടും മരിക്കുന്ന SSH സെഷനും സൃഷ്ടിക്കുന്നു.
ഈ ഓപ്ഷൻ യഥാർത്ഥത്തിൽ എന്താണ് കൈമാറുന്നത്
സ്വതവേ, ക്ലയന്റ് ടണൽ ഉപകരണം ഉയർത്തുകയും സെർവർ നൽകിയ പ്രാദേശിക, ദൂര വിലാസങ്ങൾ അനുവദിക്കുകയും ചെയ്യുന്നു. ifconfig-noexec സെറ്റ് ചെയ്താൽ ആ ഘട്ടം ഒഴിവാക്കപ്പെടുന്നു, ചർച്ച ചെയ്ത മൂല്യങ്ങൾ സ്ക്രിപ്റ്റ് പരിസ്ഥിതിയിലേക്ക് കയറ്റുമതി ചെയ്യുന്നു, അതുവഴി മറ്റെന്തെങ്കിലും അവ പ്രയോഗിക്കാം.
ഉടമസ്ഥത മാറുന്നു. അതിന്റെ സ്ഥാനത്ത് ഒന്നും കെട്ടിച്ചമയ്ക്കുന്നില്ല.
അതിനാൽ ഈ ഓപ്ഷൻ ഉത്തരം നൽകുന്ന ചോദ്യം ഇന്റർഫേസ് ആരാണ് ക്രമീകരിക്കുന്നത് എന്നതാണ്, കൂടാതെ അത് ഉത്തരം നൽകാത്ത ചോദ്യം പാക്കറ്റുകൾ എങ്ങനെ നിങ്ങളിലേക്ക് തിരികെ എത്തുന്നു എന്നതാണ്. ഈ രണ്ടും വേർതിരിച്ച് വയ്ക്കുക, അല്ലെങ്കിൽ വിലാസമില്ലാത്ത ഇന്റർഫേസ് നികത്താൻ നിങ്ങൾ ഒരു വൈകുന്നേരം റൂട്ടുകൾ തിരുത്തുന്നതിൽ കളയും.
വ്യത്യസ്ത ജോലികളുള്ള മൂന്ന് സമാന ഓപ്ഷനുകൾ
പേരുകൾ ഒരു വാക്കിനാൽ വ്യത്യാസപ്പെടുന്നതും ലക്ഷണങ്ങൾ ഒന്നിച്ചുകൂടുന്നതും ഈ കുടുംബത്തെ ആശയക്കുഴപ്പമാക്കുന്നു. ഏതെങ്കിലും തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് ഓരോന്നും എന്താണ് അടിച്ചമർത്തുന്നത് എന്ന് വായിക്കുക.
| Option | What stops happening |
|---|---|
ifconfig-noexec | OpenVPN's own tunnel-address configuration; values go to scripts instead |
route-noexec | Automatic route addition and removal; route details go to a script |
route-nopull | Server-pushed routes and related options such as DNS are rejected |
ഇവ വെവ്വേറെ മനസ്സിലാക്കേണ്ട ബദലുകളാണ്, ഒരുമിച്ച് ഒട്ടിക്കാനുള്ള ഒരു കൂട്ടമല്ല. വിലാസ ക്രമീകരണം അടിച്ചമർത്തുന്നത് റൂട്ട് മാറ്റങ്ങൾ, ഫയർവാൾ നിയമങ്ങൾ, DNS വഹിക്കുന്ന തള്ളിവിട്ട ഓപ്ഷനുകൾ എന്നിവ അടിച്ചമർത്തുന്നില്ല. കൈമാറിയ സ്ക്രിപ്റ്റിനും റൂട്ടുകൾ മാറ്റാൻ സ്വാതന്ത്ര്യമുണ്ട്, അത് ഒഴിവാക്കുന്നതിന് പകരം നിങ്ങൾ കൈമാറുന്ന തീരുമാനമാണ്.
വെണ്ടർ ക്ലയന്റ് എൻജിൻ പൊതിഞ്ഞാൽ, പ്രൊഫൈലിൽ താഴ്ന്ന നിലയിലുള്ള നിർദ്ദേശം ഇട്ട് റാപ്പർ അത് മാനിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നതിന് പകരം അതിന്റെ പിന്തുണയുള്ള സംയോജനം ഉപയോഗിക്കുക. റാപ്പറുകൾ കണക്ട് ചെയ്യുമ്പോൾ പ്രൊഫൈൽ പലപ്പോഴും വീണ്ടും ഉണ്ടാക്കുന്നു, അതിനാൽ കൈകൊണ്ടുള്ള മാറ്റം പിശകില്ലാതെ അപ്രത്യക്ഷമാകും. ഫയലിൽ ഒരു വൈകുന്നേരം ചെലവഴിക്കുന്നതിന് മുമ്പ് ക്ലയന്റ് തന്റെ ക്രമീകരണങ്ങൾ എവിടെ സൂക്ഷിക്കുന്നു എന്ന് പരിശോധിക്കുക. ഇത് പട്ടികയിലെ ഓരോ വരിയ്ക്കും ബാധകമാണ്, നിങ്ങൾ വന്ന വരിയ്ക്ക് മാത്രമല്ല.
നിങ്ങൾ സംരക്ഷിക്കാൻ ഉദ്ദേശിച്ച SSH സെഷൻ
SSH കണക്ഷന് ഒരു ഉറവിട വിലാസവും ലക്ഷ്യ വിലാസവും മറുപടി പാതയും ഉണ്ട്. ഇപ്പോൾ പൂർണ്ണ ടണൽ സ്വതവേ സ്ഥാപിച്ച സെർവറിൽ, നിങ്ങളുടെ പൊതു വിലാസത്തിനുള്ള മറുപടി ടണലുമായി ഒത്തുപോകുന്നു, VPN ഗേറ്റ്വേ അത് ഉപേക്ഷിക്കുന്നു.
ടണൽ ഇന്റർഫേസിന്റെ വിലാസ ക്രമീകരണത്തിൽ ഒന്നും അത് മാറ്റുന്നില്ല.
അത് ശരിയാക്കുന്നത് ടണലിന് മുമ്പുള്ള ഗേറ്റ്വേയിലൂടെ നിങ്ങളുടെ മാനേജ്മെന്റ് വിലാസത്തിലേക്കുള്ള കൂടുതൽ നിർദ്ദിഷ്ട റൂട്ട്, അല്ലെങ്കിൽ ആ ട്രാഫിക് തിരിക്കുന്ന നയ നിയമം, കൂടാതെ നിങ്ങളുടെ ഹോസ്റ്റ് പ്രയോഗിക്കുന്ന ഫിൽട്ടർ ക്രമീകരണങ്ങളുമാണ്. രണ്ട് പ്രശ്നങ്ങളും ചിലപ്പോൾ ഒരുമിച്ച് പ്രത്യക്ഷപ്പെടുന്നു, അങ്ങനെ ഒന്ന് മറ്റൊന്നിന്റെ ചികിത്സയായി തെറ്റിദ്ധരിക്കപ്പെടുന്നു. അവ വെവ്വേറെ പരീക്ഷിക്കുക: ഓപ്ഷൻ ഇല്ലാതെ ടണൽ ഉയർത്തുക, ഇന്റർഫേസ് വിലാസവും മറുപടി പാതയും നോക്കുക, എന്നിട്ട് രണ്ടിൽ ഏതാണ് യഥാർത്ഥത്തിൽ തകർന്നതെന്ന് തീരുമാനിക്കുക.
കൈമാറിയ സ്ക്രിപ്റ്റ് ഏറ്റെടുക്കേണ്ടത്
ഇന്റർഫേസ് മറ്റൊരു ഉടമ ക്രമീകരിക്കണമെന്ന് യഥാർത്ഥത്തിൽ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ജോലി എണ്ണിപ്പറയുക: പ്രാദേശിക, ദൂര വിലാസങ്ങൾ പ്രയോഗിക്കുക, ഉപകരണം ഉയർത്തുക, പൊളിക്കുമ്പോൾ വിലാസവൽക്കരണം പുനഃസ്ഥാപിക്കുകയോ നീക്കുകയോ ചെയ്യുക, വീണ്ടും കണക്ട് ചെയ്ത ശേഷം അതേ കാര്യം വീണ്ടും ചെയ്യുക. ഒരു വിജയകരമായ സെഷന്റെ മൂല്യങ്ങൾ ഹാർഡ്കോഡ് ചെയ്യരുത്, കാരണം അടുത്ത തവണ സെർവർ മറ്റൊരു ജോടി നൽകിയേക്കാം.
ക്ലയന്റ് കയറ്റുമതി ചെയ്യുന്ന പരിസ്ഥിതി ചരങ്ങളാണ് ആ ജോലിക്കുള്ള ഏക പിന്തുണയുള്ള ഇൻപുട്ട്.
env | grep -E '^ifconfig_|^route_'ഏതെങ്കിലും route-up സ്ക്രിപ്റ്റിനുള്ളിൽ ആ ചരങ്ങൾ ലഭ്യമാണ്; cron ജോലിയിൽ നിന്നോ കൈകൊണ്ട് പ്രവർത്തിപ്പിച്ച ഷെല്ലിൽ നിന്നോ അല്ല. നിങ്ങളുടെ പതിപ്പ് ഏത് ലൈഫ്സൈക്കിൾ ഹൂക്ക് ഉപയോഗിക്കുന്നു എന്നും, ഇന്റർഫേസ് മാറ്റാൻ മതിയായ അനുമതികളോടെ ഹൂക്ക് പ്രവർത്തിക്കുന്നു എന്നും സ്ഥിരീകരിക്കുക, കാരണം ക്ലയന്റ് ഇതിനകം പ്രത്യേകാവകാശമില്ലാത്ത ഉപയോക്താവിലേക്ക് ഇറങ്ങിയിരിക്കാം.
ഒരു സെഷനല്ല, മുഴുവൻ ലൈഫ്സൈക്കിളും പരീക്ഷിക്കുക
ടണൽ ഉയർത്തുക, ഉപകരണത്തിലെ വിലാസം പരിശോധിക്കുക, എന്നിട്ട് വീണ്ടും കണക്ട് ചെയ്ത് വീണ്ടും പരിശോധിക്കുക. ഒരിക്കൽ പ്രവർത്തിച്ച് രണ്ടാം ശ്രമത്തിൽ പരാജയപ്പെടുന്ന ക്രമീകരണം സാധാരണയായി അർത്ഥമാക്കുന്നത് കൈമാറിയ ഘട്ടം ആദ്യ കണക്ഷനിൽ മാത്രം പ്രവർത്തിക്കുന്നു എന്നാണ്.
തുടർന്ന് രണ്ട് സ്വീകാര്യതാ മാനദണ്ഡങ്ങളും ഒരുമിച്ച് പരീക്ഷിക്കുക: ഉദ്ദേശിച്ച മാനേജ്മെന്റ് പാതയിലൂടെയുള്ള പുതിയ SSH കണക്ഷൻ പ്രവർത്തിക്കുന്നു, അനുവദിച്ച ആപ്ലിക്കേഷൻ ടണൽ ശരിയായി ഉപയോഗിക്കുന്നു.
ടണലിന് വിലാസമില്ലാത്തപ്പോൾ യാദൃച്ഛികമായി അതിജീവിക്കുന്ന പഴയ SSH സെഷൻ വിജയമല്ല, ആരും ജോലി ഏറ്റെടുക്കാത്തപ്പോൾ ഈ ഓപ്ഷൻ സൃഷ്ടിക്കുന്നത് കൃത്യമായി ആ അവസ്ഥയാണ്. ആദ്യം ഇന്റർഫേസ് വിലാസം, പിന്നെ മാനേജ്മെന്റ് മറുപടി പാത, പിന്നെ ആപ്ലിക്കേഷൻ പരിശോധിക്കുക. മൂന്നിൽ രണ്ട് തെറ്റാണെങ്കിൽ, ഓപ്ഷൻ ജോലി നീക്കി, പക്ഷേ അതിന് ഉടമയെ നൽകിയില്ല.