അധികാരങ്ങൾ കുറച്ചതിന് ശേഷം: ഏത് OpenVPN ഫയലുകൾ ഇപ്പോഴും പ്രവർത്തിക്കുന്നു?
കുറയ്ക്കുന്നതിന് മുമ്പ് തുറന്ന ഡിസ്ക്രിപ്റ്ററുകൾ പ്രവർത്തിക്കുന്നത് തുടരുന്നു; പിന്നീട് വീണ്ടും തുറക്കുന്ന പാതകൾ തുടരുന്നില്ല. നിങ്ങളുടെ സജ്ജീകരണം മൂന്ന് റൺടൈം ഫയലുകളിൽ ഏത് വീണ്ടും തുറക്കണമെന്ന് തീരുമാനിക്കുക.
നീണ്ട പ്രവർത്തനസമയം, ആ നിമിഷത്തിൽ ഡീമണിനുണ്ടായിരുന്ന അധികാരങ്ങളോടെ സ്റ്റാർട്ട് വിജയിച്ചു എന്ന് മാത്രം തെളിയിക്കുന്നു. ഇവിടെ പ്രധാനമായ പരാജയങ്ങൾ പിന്നീട് വരുന്നു: പുതിയ ക്ലയന്റ് ബന്ധിപ്പിക്കുന്നു, റദ്ദാക്കൽ പട്ടിക മാറ്റിസ്ഥാപിക്കുന്നു, സഹായ സ്ക്രിപ്റ്റിന് ഫയൽ എഴുതണം. ഇവയോരോന്നും അധികാരമില്ലാത്ത അക്കൗണ്ട് നടത്തുന്ന പുതിയ തുറക്കലാണ്, അതിന്റേതായ അനുമതി ചോദ്യവും പിശക് സന്ദേശവും സഹിതം. മൂന്ന് തീരുമാനങ്ങൾ തുടർന്നും പ്രവർത്തിക്കുന്ന ക്രമീകരണത്തെ അടുത്ത സംഭവത്തിൽ പരാജയപ്പെടുന്നതിൽ നിന്ന് വേർതിരിക്കുന്നു.
നേരത്തെ ലോഡ് ചെയ്തതും പിന്നീട് തുറക്കുന്നതും വേർതിരിക്കുക
ഡിസ്ക്രിപ്റ്റർ എന്നത് തുറന്ന ഫയൽ വിവരണത്തിന്റെ മേലുള്ള ഹാൻഡിലാണ്, പ്രവേശന രീതി ആ വിവരണം സൃഷ്ടിച്ചപ്പോൾ തന്നെ നിശ്ചയിക്കപ്പെട്ടു. പിന്നീട് പ്രോസസിന്റെ ഉപയോക്താവിനെ മാറ്റുന്നത് ഹാൻഡിൽ അടയ്ക്കുന്നില്ല, അതുകൊണ്ടാണ് root ആയി വായിച്ച കീ ഫയൽ അധികാരം കുറച്ചതിന് ശേഷവും പ്രവർത്തിക്കുന്നത്. രീതിയും മാറുന്നില്ല: വായനയ്ക്കായി തുറന്ന ഹാൻഡിൽ എഴുതാവുന്നതാകുന്നില്ല, എഴുതാവുന്ന ഹാൻഡിൽ അക്കൗണ്ടിന് പാതയിലുള്ള അവകാശം നഷ്ടപ്പെട്ടതുകൊണ്ട് മാത്രം പിൻവലിക്കപ്പെടുന്നുമില്ല. ഈ രണ്ട് വസ്തുതകളാണ് ഈ റിപ്പോർട്ടുകളിലെ അത്ഭുതകരമായ പെരുമാറ്റത്തിന്റെ ഭൂരിഭാഗവും വിശദീകരിക്കുന്നത്.
രണ്ടാം പകുതി ഓർമ്മയാണ്. ഡീമണിന് സർട്ടിഫിക്കറ്റ് പാഴ്സ് ചെയ്യാം, പാഴ്സ് ചെയ്ത വസ്തു സൂക്ഷിക്കാം, ഫയൽ അടയ്ക്കാം; ഉപയോഗത്തിൽ തുടരുന്നത് ഡാറ്റയാണ്, തുറന്ന ഫയലല്ല. അതിനാൽ തുടരുന്ന ട്രാഫിക് ഡിസ്ക്രിപ്റ്റർ തുറന്നിരിക്കുന്നു എന്നോ പാതയുടെ പേര് എത്താവുന്നതാണ് എന്നോ തെളിയിക്കുന്നില്ല. നിലവിലെ സെഷന് ആവശ്യമായ വസ്തു മുമ്പ് ലഭിച്ചു എന്ന് മാത്രം തെളിയിക്കുന്നു.
പിന്നീടുള്ള തുറക്കൽ മറ്റൊരു ഇടപാടാണ്. അത് നിലവിലെ ആധികാരികതകൾ, നിലവിലെ സുരക്ഷാ സന്ദർഭം, നിലവിലെ മൗണ്ട് കാഴ്ച എന്നിവയ്ക്ക് കീഴിൽ നടക്കുന്നു, അതിനാൽ സ്റ്റാർട്ടപ്പിൽ വായിക്കാവുന്ന പാത അടുത്ത കണക്ഷനിൽ നിരസിക്കപ്പെടാം. റൊട്ടേഷൻ ഒരു കെണി ചേർക്കുന്നു: അതേ പാതനാമത്തിന്മേൽ പുതിയ ഫയൽ എഴുതുമ്പോൾ നിലവിലുള്ള ഡിസ്ക്രിപ്റ്റർ പഴയ വസ്തുവിൽ ബന്ധിപ്പിച്ചിരിക്കും, അതിനാൽ വീണ്ടും ലോഡ് ചെയ്യൽ വിജയിച്ചതായി തോന്നാം, എന്നാൽ ഡീമൺ മുൻ ഉള്ളടക്കം ഉപയോഗിക്കുന്നു. റൊട്ടേഷൻ പ്രാബല്യത്തിൽ വന്നു എന്ന് വിശ്വസിക്കുന്നതിന് മുമ്പ് പ്രോസസ് കൈവശമുള്ള inode ഡിസ്കിലുള്ളതുമായി താരതമ്യപ്പെടുത്തുക.
മൂന്ന് റൺടൈം വായനകളും ഓരോന്നും എപ്പോൾ സംഭവിക്കുന്നു എന്നും പേരിടുക
മൂന്ന് വിഭവങ്ങൾ സാധാരണയായി ഇനിഷ്യലൈസേഷന് വളരെ ശേഷം തുറക്കപ്പെടുന്നു, വ്യത്യസ്ത നിമിഷങ്ങളിൽ അവ പരാജയപ്പെടുന്നു. ഒരു നിർദ്ദിഷ്ട ക്ലയന്റിന്റെ കോൺഫിഗറേഷൻ ഫയൽ ആ ക്ലയന്റ് ബന്ധിപ്പിക്കുമ്പോൾ വായിക്കുന്നു, അതിനാൽ മറ്റുള്ളവർ തുടരുമ്പോൾ ഒരാൾക്ക് മാത്രം അത് തകരാം. റദ്ദാക്കൽ ഡാറ്റ പിയർ ഓതന്റിക്കേഷനിലും ഫയൽ മാറ്റിസ്ഥാപിക്കുമ്പോൾ വീണ്ടും പരിശോധിക്കുന്നു. താൽക്കാലിക ഡയറക്ടറിയിൽ സ്പർശിക്കുന്നത് സ്ക്രിപ്റ്റോ പ്ലഗിനോ എന്തെങ്കിലും എഴുതുമ്പോൾ മാത്രമാണ്.
മൂന്നിൽ ഒന്നും സ്റ്റാർട്ടപ്പ് പാതയിൽ പെടുന്നില്ല, അതിനാൽ ആഴ്ചകളോളം ആരോഗ്യകരമായിരുന്ന സെർവർ അടുത്ത കണക്ഷനിൽ പരാജയപ്പെടാം. വിഭാഗം തിരുത്തലിന്റെ ഉടമയെയും പേരിടുന്നു: ആദ്യ രണ്ടും ഡീമൺ അക്കൗണ്ടിന് കീഴിലുള്ള കോൺഫിഗറേഷനിലെ വായനാനുമതികളാണ്, മൂന്നാമത്തേത് ഇടുങ്ങിയ ലക്ഷ്യമുള്ള എഴുതാവുന്ന സ്ഥലമാണ്.
| Path reopened later | What triggers the open | First sign when it fails |
|---|---|---|
| Client configuration file | A connection for that client identity | One client rejected while others connect |
| Revocation data | Peer authentication, including after replacement | Revoked and valid peers both refused |
| Script or plugin temporary directory | A helper needs to create a file | The helper exits with a path error |
persist-key മിക്ക ആളുകളും കരുതുന്നതിനേക്കാൾ ഇടുങ്ങിയ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു. അത് രേഖപ്പെടുത്തിയ SIGUSR1 ഉം ping-restart ഉം റീസെറ്റുകളിലുടനീളം കീ ഫയൽ തുറന്നു സൂക്ഷിക്കുന്നു, കൂടാതെ CCD ഫയലുകൾക്കും റദ്ദാക്കൽ ഡാറ്റയ്ക്കും സഹായ എക്സിക്യൂട്ടബിളുകൾക്കും പൂർണ്ണ പ്രോസസ് പുനരാരംഭത്തിനും അത് ഒന്നും ചെയ്യുന്നില്ല. അവ ഇപ്പോഴും സ്വന്തം തുറക്കൽ പാതകൾ പിന്തുടരുന്നു, അപ്പോൾ പ്രവർത്തിക്കുന്ന ഏത് അക്കൗണ്ടിന് കീഴിലും.
അക്കൗണ്ടും അതിന് യഥാർത്ഥത്തിലുള്ള കാഴ്ചയും സ്ഥിരീകരിക്കുക
unit ഫയൽ വിശ്വസിക്കുന്നതിന് പകരം പ്രവർത്തിക്കുന്ന ഡീമണിനോട് ഏത് അക്കൗണ്ട് ഉപയോഗിക്കുന്നു എന്ന് ചോദിക്കുക, പിന്നീട് ഉത്തരം unit നിശ്ചയിക്കുന്നതുമായി താരതമ്യപ്പെടുത്തുക. വ്യത്യാസമാണ് ആദ്യം പരിഹരിക്കേണ്ടത്, കാരണം തുടർന്നുള്ള ഓരോ അനുമതി പരിശോധനയും പ്രോസസ് യഥാർത്ഥത്തിൽ ആരോ അവരുടെ രൂപത്തിൽ നടക്കുന്നു. പിന്നീട് പാത ഓരോ ഘടകമായി നടക്കുക; കടന്നുപോകൽ ഓരോ തലത്തിലും വിലയിരുത്തപ്പെടുന്നു, അതിനാൽ കടന്നുപോകാൻ കഴിയാത്ത ഡയറക്ടറിയിലെ വായിക്കാവുന്ന ഫയൽ വായിക്കാനാവാത്തതായി തുടരുന്നു. അന്തിമ ഫയൽ മോഡ് ആദ്യത്തെ ചോദ്യമല്ല, അവസാനത്തെ ചോദ്യമാണ്.
നെയിംസ്പേസുകളും സേവന സാൻഡ്ബോക്സുകളും ഉടമസ്ഥതയും മോഡ് ബിറ്റുകളും വിവരിക്കാത്ത അതിർത്തികൾ ചേർക്കുന്നു. നിങ്ങളുടെ ഷെല്ലിൽ കാണുന്ന പാത chroot, മൗണ്ട് നെയിംസ്പേസ് അല്ലെങ്കിൽ ഹോം ഡയറക്ടറികൾ മറയ്ക്കുന്ന unit എന്നിവയ്ക്കുള്ളിൽ ഇല്ലാതിരിക്കാം, അല്ലെങ്കിൽ വായനയ്ക്ക് മാത്രമായിരിക്കാം. സുരക്ഷാ മൊഡ്യൂളുകൾ ഒരു പാളികൂടി ചേർക്കുന്നു, അതിനാൽ വായിക്കാവുന്നതായി തോന്നുന്ന ഫയൽ തുറക്കുമ്പോൾ നിരസിക്കപ്പെടാം.
ps -o user:12,pid,args -C openvpn
systemctl show -p User -p Group -p ProtectHome -p RootDirectory [email protected]
sudo -u openvpn namei -l /etc/openvpn/ccd/aliceഅഡ്മിനിസ്ട്രേറ്ററുടെ ഷെല്ലിലെ വിജയകരമായ വായന ആ സംയോജിത വ്യവസ്ഥകളിൽ ഒന്നുപോലും പരിശോധിക്കുന്നില്ല. ഡീമൺ അക്കൗണ്ടായി, അതേ നെയിംസ്പേസും സാൻഡ്ബോക്സും ഉപയോഗിച്ച് പരിശോധന നടത്തുക, അല്ലെങ്കിൽ ഫലം സെർവറിനെയല്ല നിങ്ങളുടെ ഷെല്ലിനെയാണ് വിവരിക്കുന്നത് എന്ന് അംഗീകരിക്കുക. മൂന്നാമത്തെ കമാൻഡ് ആ പരീക്ഷയുടെ വിലകുറഞ്ഞ പതിപ്പാണ്: അത് ഓരോ ഘടകത്തിന്റെയും മോഡ് പ്രിന്റ് ചെയ്യുന്നു, ഡീമൺ അക്കൗണ്ടിന് കടക്കാൻ കഴിയാത്ത ആദ്യ ഘടകത്തിൽ പരാജയപ്പെടുന്നു.
റൺടൈം എഴുത്തിന് സ്വന്തമായി ഒരു ഡയറക്ടറി നൽകുക
വായന പട്ടികയുടെ പകുതി മാത്രമാണ്. സഹായ സ്ക്രിപ്റ്റിന് ഒരു സ്റ്റാറ്റസ് ഫയൽ സൃഷ്ടിക്കേണ്ടിവരാം, പ്ലഗിന് തന്റെ കോൺഫിഗറേഷന് അരികിൽ അവസ്ഥ എഴുതേണ്ടിവരാം, ആ എഴുത്തുകൾ കോൺഫിഗറേഷൻ വൃക്ഷം എഴുതാവുന്നതാക്കുന്നതുകൊണ്ട് മൂടപ്പെടുന്നില്ല. നിർദ്ദിഷ്ട ഡയറക്ടറിക്ക് അതിന്റെ ധർമ്മത്തിന് ആവശ്യമായ എഴുത്തനുമതി നൽകുക, നിങ്ങൾക്ക് വിശദീകരിക്കാവുന്ന ഉടമയും മോഡും സഹിതം. വായിക്കാൻ മാത്രമുള്ള എല്ലാത്തിനും വായനയ്ക്ക് മാത്രമുള്ള പ്രവേശനം തിരഞ്ഞെടുക്കുക.
സ്വകാര്യ കീയുടെ അനുമതികൾ നയ ഫയലുകളിൽ നിന്ന് വേർതിരിച്ച് സൂക്ഷിക്കുക. റീസെറ്റിന് ശേഷം വീണ്ടും വായിക്കേണ്ട കീയുടെ ആവശ്യകത ഓരോ കണക്ഷനിലും വായിക്കുന്ന ക്ലയന്റ് ഫയലിൽ നിന്ന് വ്യത്യസ്തമാണ്, രണ്ടിനും ഒരു അയഞ്ഞ മോഡ് നൽകിയാൽ പ്രശ്നം ആവശ്യപ്പെടുന്നതിലധികം പ്രവേശനം ലഭിക്കും. ഇടുങ്ങിയ ഉടമസ്ഥതയുള്ള സമർപ്പിത ഡീമൺ അക്കൗണ്ട് വിശാലമായ ഗ്രൂപ്പിനെക്കാൾ എളുപ്പത്തിൽ പരിശോധിക്കാം. കീ റീസെറ്റുകളെ അതിജീവിക്കേണ്ടിവരുമ്പോൾ, persist-key ഡയറക്ടറി വിശാലമാക്കുന്നതിന് പകരം വീണ്ടും വായന നീക്കം ചെയ്യുന്നു.
നിങ്ങൾക്ക് പുനർനിർമ്മിക്കാവുന്ന സംഭവത്തിൽ നിന്ന് തീരുമാനിക്കുക
ജീവനുള്ള ടണൽ കോഡിലൂടെ ഒരു പാത മാത്രം തെളിയിക്കുന്നു. ഫയൽ ആവശ്യമുള്ള സംഭവമാണ് നിങ്ങൾക്ക് പ്രധാനമായ തുറക്കൽ ഉൾക്കൊള്ളുന്ന ഏക പരീക്ഷ; പുതിയ ക്ലയന്റ് കണക്ഷനോ, മാറ്റിസ്ഥാപിച്ച റദ്ദാക്കൽ ഫയലോ, അനുവദിച്ച മൃദു റീസെറ്റോ, ആസൂത്രിത പുനരാരംഭമോ ആകട്ടെ. സംഭവം തിരഞ്ഞെടുക്കുക, അത് പ്രവർത്തിപ്പിക്കുക, അവസാനത്തേതല്ല ആദ്യത്തെ പിശക് സൂക്ഷിക്കുക.
മൃദു റീസെറ്റിന് ഒരു സിഗ്നലും unit ന്റെ ലോഗും കീ വീണ്ടും വായിച്ചോ എന്ന് കാണിക്കും. സിഗ്നൽ അയയ്ക്കുക, പിന്നീട് unit എഴുതിയ അവസാന വരികൾ വായിക്കുക:
systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pagerഅധികാരങ്ങൾ കുറഞ്ഞതുകൊണ്ട് മാത്രം വിട്ടുപോയ ഡീമണിന് ഇനി ഫയലുകൾ മാറ്റാൻ കഴിയില്ല എന്ന് അനുമാനിക്കരുത്. ഇനി എന്ത് ചെയ്യാനാകും എന്നത് ബാക്കിയുള്ള ആധികാരികതകൾ, അതിന്റെ കഴിവുകൾ, എഴുതാവുന്ന ഡയറക്ടറികൾ, ഇപ്പോഴും കൈവശമുള്ള എഴുതാവുന്ന ഡിസ്ക്രിപ്റ്റർ എന്നിവയെ ആശ്രയിച്ചിരിക്കുന്നു. അധികാര കുറവ് അധികാരപരിധി ചുരുക്കുന്നു, റൺടൈം തുറക്കലുകളുടെ പട്ടികയാണ് എത്രത്തോളം എന്ന് കാണിക്കുന്നത്. ആ അതിർത്തി കോൺഫിഗറേഷന് അരികിൽ എഴുതിവയ്ക്കുക, അടുത്തയാൾ അത് വീണ്ടും കണ്ടെത്തേണ്ടിവരാതിരിക്കാൻ.