OpenVPN ക്രെഡൻഷ്യൽ ഫയലോ മാനേജ്മെന്റ് സോക്കറ്റോ: ഏതാണ് സ്ക്രിപ്റ്റ് ചെയ്യേണ്ടത്

OpenVPN ആരംഭിച്ചിട്ടും ഒരിക്കലും കണക്ട് ചെയ്യാത്ത സ്ക്രിപ്റ്റ് സാധാരണയായി നെറ്റ്വർക്ക് പ്രശ്നമല്ല: ടെർമിനൽ ഇല്ലാത്ത ഒരു പ്രോംപ്റ്റിന് മുന്നിൽ ക്ലയന്റ് ഇരിക്കുന്നു. OpenVPN-ന് മനുഷ്യനില്ലാതെ ആ പ്രോംപ്റ്റിന് ഉത്തരം നൽകാൻ കൃത്യമായി രണ്ട് പിന്തുണയുള്ള വഴികളുണ്ട്, auth-user-pass-ന് പിന്നിലെ ക്രെഡൻഷ്യൽ ഫയലും മാനേജ്മെന്റ് സോക്കറ്റും, അവ പരസ്പരം മാറ്റാനാവില്ല. ഫയൽ ഒരു നിർദ്ദേശത്തിന് വില നൽകി ഒരു പ്രോംപ്റ്റിന് ഉത്തരം നൽകുന്നു; സോക്കറ്റ് എല്ലാ പ്രോംപ്റ്റിനും ഉത്തരം നൽകുകയും loopback പോർട്ട് തുറക്കാൻ കഴിയുന്ന ഏതിനും പ്രാമാണീകരണമില്ലാത്ത നിയന്ത്രണ ചാനൽ നൽകുകയും ചെയ്യുന്നു. നിങ്ങളുടെ വിന്യാസത്തിന് ഏതാണ് യോജിക്കുന്നത് എന്നത് യഥാർത്ഥത്തിൽ ഏത് പ്രോംപ്റ്റ് തടയുന്നു, ഏത് രഹസ്യം ശാന്തമായി വിടാൻ നിങ്ങൾക്ക് കഴിയും എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

സംവിധാനം തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് പ്രോംപ്റ്റിന് പേര് നൽകുക

നാല് പ്രോംപ്റ്റുകൾ ടെർമിനലിൽ ഒരേപോലെ കാണാം. അക്കൗണ്ട് ജോടി സർവറിന്റെ PAM അല്ലെങ്കിൽ auth-user-pass-verify ക്രമീകരണത്തിൽ നിന്ന് വരുന്നു, അതിന് auth-user-pass ഉത്തരം നൽകുന്നു. സ്വകാര്യ കീയുടെ പാസ്ഫ്രേസ് കീ ഫയലിന് സ്വന്തമാണ്, --askpass വഴി വായിക്കുകയോ കൈകൊണ്ട് ടൈപ്പ് ചെയ്യുകയോ ചെയ്യുന്നു. PKCS#12 ബണ്ടിൽ സ്വന്തം പാസ്വേഡ് ആവശ്യപ്പെടുന്നു. പ്രോക്സി പ്രാമാണീകരണം അക്കൗണ്ട് ക്രെഡൻഷ്യലുകളല്ല, --http-proxy എടുക്കുന്ന auth ഫയൽ ഉപയോഗിക്കുന്നു.

OpenVPN systemd, PHP അല്ലെങ്കിൽ Node-ന്റെ കുട്ടിയായി പ്രവർത്തിക്കുമ്പോൾ ടെർമിനൽ ഇല്ല, അതിനാൽ ഇവയിൽ ഏതെങ്കിലും നിശബ്ദമായി തടയുന്നു. പ്രോസസ് അവിടെ ഇരിക്കുന്നു, സൈഫർ വരിക്ക് ശേഷം ലോഗ് നിലയ്ക്കുന്നു, യൂണിറ്റ് ഒടുവിൽ സമയപരിധി കടക്കുന്നു; ഏത് പ്രോംപ്റ്റ് കാത്തിരിക്കുന്നു എന്ന് നോക്കുന്നതിന് പകരം ആളുകൾ റിട്രൈ ലൂപ്പോ sleep-ഓ ചേർക്കുന്നതിന്റെ കാരണം ആ നിശബ്ദതയാണ്. നാലിനും ഉത്തരം നൽകാൻ മാനേജ്മെന്റ് സോക്കറ്റിന് മാത്രമേ കഴിയൂ. ക്രെഡൻഷ്യൽ ഫയൽ ആദ്യത്തേതിന് ഉത്തരം നൽകുന്നു, മറ്റൊന്നിനുമല്ല.

auth-user-pass: ഒരു ഫയൽ, ഒരു പ്രോംപ്റ്റ്

ഫയൽ ആദ്യ വരിയിൽ ഉപയോക്തൃനാമവും രണ്ടാം വരിയിൽ പാസ്വേഡും സൂക്ഷിക്കുന്നു, മറ്റൊന്നുമില്ല: ഉദ്ധരണികളില്ല, കീ പേരുകളില്ല, കമന്റില്ല. മോഡ് 600 സജ്ജമാക്കി openvpn പ്രവർത്തിപ്പിക്കുന്ന അക്കൗണ്ടിനെ ഉടമയാക്കുക, സേവനത്തിന് ഇത് പലപ്പോഴും നിങ്ങളുടെ ലോഗിൻ എന്നതിന് പകരം സമർപ്പിത ഉപയോക്താവാണ്. /root-ന് കീഴിൽ root ന്റെ ഉടമസ്ഥതയിലുള്ള ഫയൽ നിങ്ങളുടെ ഷെല്ലിൽ പ്രവർത്തിക്കുന്ന കമാൻഡും ബൂട്ടിൽ പരാജയപ്പെടുന്ന യൂണിറ്റും തമ്മിലുള്ള വ്യത്യാസമാണ്.

രണ്ട് വിശദാംശങ്ങൾ ശരിയായ ഫയലിനെ പ്രോംപ്റ്റാക്കി മാറ്റുന്നു. CRLF സംരക്ഷിക്കുന്ന എഡിറ്റർ പാസ്വേഡിൽ പറ്റിപ്പിടിച്ച കാരിയേജ് റിട്ടേൺ വിടുന്നു, അതിനാൽ ഫയലിൽ ശരിയായി തോന്നുന്ന പാസ്വേഡ് സർവർ നിരസിക്കുന്നു; കണ്ണുകൊണ്ടല്ല, cat -A അല്ലെങ്കിൽ od -c ഉപയോഗിച്ച് പരിശോധിക്കുക. പ്രൊഫൈലിനുള്ളിലെ ആർഗ്യുമെന്റില്ലാത്ത auth-user-pass ഡിസൈൻ പ്രകാരം «ഉപയോക്താവിനോട് ചോദിക്കുക» എന്നർത്ഥം, അതിനെ കമാൻഡ് ലൈനിലെ രണ്ടാം നിർദ്ദേശം അതിലംഘിച്ചേക്കില്ല, കാരണം പ്രൊഫൈൽ അത് നിൽക്കുന്നിടത്ത് തന്നെ പാഴ്സ് ചെയ്യപ്പെടുന്നു.

ഓപ്ഷനുകളുടെ ക്രമം മൂന്നാം കെണിയാണ്, അത് പതിപ്പിനെ ആശ്രയിച്ചിരിക്കുന്നു. ചില OpenVPN 2.4 ബിൽഡുകൾ --config-ന് മുമ്പ് വരുമ്പോൾ --auth-user-pass അവഗണിക്കുന്നു, അതിനാൽ അതേ രണ്ട് ഓപ്ഷനുകൾ വിപരീത ക്രമത്തിൽ കണക്ട് ചെയ്യുന്നു. നിർദ്ദേശം പ്രൊഫൈലിനുള്ളിലോ കമാൻഡ് ലൈനിൽ --config-ന് ശേഷമോ വയ്ക്കുക, മറ്റെന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് പ്രൊഫൈലിൽ ഓരോ സംഭവവും grep ചെയ്യുക.

auth-nocache ഈ സംവിധാനത്തിന്റേതാണ്, പക്ഷേ ഒന്നും നൽകുന്നില്ല. ക്ലയന്റ് ക്രെഡൻഷ്യൽ മെമ്മറിയിൽ എത്ര കാലം സൂക്ഷിക്കുന്നു എന്ന് പരിമിതപ്പെടുത്തുന്നു, അത് ക്രാഷിന് ശേഷം സഹായിക്കും, ഫയൽ ഇല്ലാത്തപ്പോൾ ഒട്ടും സഹായിക്കില്ല. സർവർ വശത്തെ സെഷൻ സമയപരിധിക്ക് ശേഷം വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ ഫയൽ വീണ്ടും വായിക്കുന്നു, അതിനാൽ ബൂട്ടിൽ പ്രവർത്തിച്ച ക്രെഡൻഷ്യൽ പകൽ മധ്യത്തിലും കാലഹരണപ്പെടാം.

മാനേജ്മെന്റ് സോക്കറ്റ്: ഓരോ പ്രോംപ്റ്റും, കൂടുതൽ ഉപരിതലം

ഒരു ലിസണറോടെ ക്ലയന്റ് ആരംഭിക്കുകയും പ്രോംപ്റ്റുകൾ അതിൽ റിപ്പോർട്ട് ചെയ്യുമെന്ന് വ്യക്തമായി പ്രഖ്യാപിക്കുകയും ചെയ്യുക, OpenVPN 2.6 മാനുവലിൽ രേഖപ്പെടുത്തിയ നിർദ്ദേശങ്ങൾ ഉപയോഗിച്ച്:

management 127.0.0.1 3030
management-query-passwords

bash-ൽ നിന്ന് കണക്ഷൻ ഒരു അധിക ഫയൽ ഡിസ്ക്രിപ്റ്ററിൽ സൂക്ഷിച്ച് സ്ഥാനത്തിന് പകരം പ്രോംപ്റ്റിന്റെ പേര് അനുസരിച്ച് ഉത്തരം നൽകുക, കാരണം വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ മറ്റൊരു ക്രമത്തിൽ ചോദിച്ചേക്കാം:

exec 3<>/dev/tcp/127.0.0.1/3030
while read -r -u 3 line; do
  case "$line" in
    *"Need 'Auth' username/password"*)
      echo 'username "Auth" alice' >&3
      echo 'password "Auth" secret' >&3 ;;
    *"Need 'Private Key' password"*)
      echo 'password "Private Key" secret' >&3 ;;
  esac
done

അതിർത്തി ഗതാഗതമാണ്. മാനേജ്മെന്റ് പ്രോട്ടോക്കോൾ loopback-ൽ TCP-ക്ക് മുകളിലുള്ള പ്ലെയിൻ ടെക്സ്റ്റാണ്, അതിനാൽ ദൂരസ്ഥ നിയന്ത്രകന് എത്താൻ ലിസണർ LAN അല്ലെങ്കിൽ ടണൽ വിലാസത്തിൽ പ്രസിദ്ധീകരിക്കരുത്; ദൂരസ്ഥ നിയന്ത്രകൻ എന്നാൽ SSH ഫോർവേഡിംഗ്, വിശാലമായ ബൈൻഡല്ല. കമ്മ്യൂണിറ്റി ഡീമൺ ഒരു സമയത്ത് ഒരു മാനേജ്മെന്റ് ക്ലയന്റിനെ മാത്രം സ്വീകരിക്കുന്നു, അതിനാൽ GUI-ക്കോ മോണിറ്ററിനോ നിങ്ങളുടെ സ്ക്രിപ്റ്റുമായി സോക്കറ്റ് പങ്കിടാനാവില്ല. രണ്ടാം കണക്ഷൻ ക്യൂവിൽ വയ്ക്കാതെ നിരസിക്കുന്നു, പരാജയം ബധിരനായ സ്ക്രിപ്റ്റിനെപ്പോലെ തോന്നുന്നു.

ആ സോക്കറ്റ് ഒരു നിയന്ത്രണ ചാനലുമാണ്. മാനേജ്മെന്റ് പാസ്വേഡ് ഇല്ലാതെ 127.0.0.1:3030-ലേക്ക് കണക്ട് ചെയ്യാൻ കഴിയുന്ന ഏതിനും നില വായിക്കാം, ടണൽ കൊല്ലാം, അല്ലെങ്കിൽ സ്വയം ഒരു പ്രോംപ്റ്റിന് ഉത്തരം നൽകാം. മാനേജ്മെന്റ് പാസ്വേഡും ക്രെഡൻഷ്യൽ ഫയലും ഒരേ വിഭാഗത്തിലെ രഹസ്യങ്ങളാണ്, രണ്ടും ഒരേ ശ്രദ്ധയർഹിക്കുന്നു.

വിന്യാസത്തിന് ഏതാണ് യോജിക്കുന്നത്

ഏക പ്രോംപ്റ്റ് അക്കൗണ്ട് ജോടിയാകുമ്പോൾ, ക്ലയന്റ് സ്ഥിരമായ ഉടമയുള്ള സേവനമായി പ്രവർത്തിക്കുമ്പോൾ, നിങ്ങൾ നിയന്ത്രിക്കാത്ത ബാക്കപ്പുകൾക്ക് പുറത്ത് 600 ഫയൽ സൂക്ഷിക്കാൻ കഴിയുമ്പോൾ ക്രെഡൻഷ്യൽ ഫയൽ തിരഞ്ഞെടുക്കുക. കീ പാസ്ഫ്രേസ് അല്ലെങ്കിൽ PKCS#12 പാസ്വേഡ് ഉൾപ്പെടുമ്പോൾ, റാപ്പർ ഇതിനകം പ്രോസസിനെ മേൽനോട്ടം ചെയ്യുമ്പോൾ, അല്ലെങ്കിൽ വീണ്ടും കണക്ട് ചെയ്യുന്നത് ഡീബഗ് ചെയ്യുമ്പോൾ നിലയും പ്രോംപ്റ്റുകളും കാണേണ്ടിവരുമ്പോൾ മാനേജ്മെന്റ് സോക്കറ്റ് തിരഞ്ഞെടുക്കുക.

രണ്ട് വ്യവസ്ഥകൾ തീരുമാനം മാറ്റുന്നു. റാപ്പർ /bin/sh ആണെങ്കിൽ, ബൈനറിയെ നേരിട്ട് വിളിക്കുന്ന systemd യൂണിറ്റാണെങ്കിൽ, അല്ലെങ്കിൽ കുറഞ്ഞ കണ്ടെയ്നർ ആണെങ്കിൽ, bash-ന് മാത്രമുള്ള സോക്കറ്റ് പശ ലഭ്യമല്ല, ഫയലാണ് വിലകുറഞ്ഞ ഉത്തരം. രഹസ്യം പലപ്പോഴും കറങ്ങുന്നുവെങ്കിൽ ഒരു ഫയലും അതിന് നല്ല വീടല്ല: ചെറിയ റാപ്പറിൽ നിന്ന് കീറിംഗ് ചോദിക്കുകയും യൂണിറ്റിനെ റാപ്പറെ വിളിക്കാൻ അനുവദിക്കുകയും ചെയ്യുക, അത് കറക്കം ഒരിടത്ത് നിർത്തുകയും പാസ്വേഡിനെ ഷെൽ ചരിത്രത്തിന് പുറത്താക്കുകയും ചെയ്യുന്നു.

പ്രോസസ് സബ്സ്റ്റിറ്റ്യൂഷൻ രണ്ടിനും ഇടയിലാണ്, ഒന്നിനും സ്വന്തമല്ല. താഴെയുള്ള ഒറ്റ വരി പ്രവർത്തിക്കുന്നത് openvpn തുടങ്ങുന്നതിന് മുമ്പ് bash അത് വിപുലീകരിക്കുന്നതുകൊണ്ടാണ്, ക്ലയന്റ് വാക്യഘടന മനസ്സിലാക്കുന്നതുകൊണ്ടല്ല:

openvpn --config client.ovpn --auth-user-pass <(printf "%s
%s
" "$USER" "$PASS")

അത് /bin/sh-ന് കീഴിൽ, ഷെൽ ഒഴിവാക്കുന്ന യൂണിറ്റിൽ, bash അല്ലെങ്കിൽ /dev/fd ഇല്ലാത്ത ഇമേജുകളിൽ തകരുന്നു. ഇന്ററാക്ടീവ് പരിശോധനയ്ക്കായി സൂക്ഷിക്കുക, ഒരിക്കലും സേവനം ആശ്രയിക്കുന്ന കരാറായി അല്ല.

രഹസ്യം സംരക്ഷിക്കുക, എന്നിട്ട് ലോഗിൽ നിന്ന് പരിശോധിക്കുക

രണ്ട് സംവിധാനങ്ങളും OpenVPN പ്രോസസിന് വായിക്കാവുന്ന ഒരു രഹസ്യം വിടുന്നു. പാസ്വേഡ് ഒരിക്കലും കമാൻഡ് ലൈനിലോ യൂണിറ്റ് ഫയലിലോ വയ്ക്കരുത്, അവിടെ ps-ഉം systemctl-ഉം അത് ഓരോ ലോക്കൽ ഉപയോക്താവിനും കാണിക്കുന്നു; ഫയലിലേക്കുള്ള പാത നൽകുക, അതിലെ മൂല്യമല്ല. സർട്ടിഫിക്കറ്റുകൾക്ക് അക്കൗണ്ട് ജോടിയെ മാറ്റാൻ കഴിയുന്നിടത്ത്, അത് പ്രോംപ്റ്റ് വിഭാഗത്തെ മറയ്ക്കുന്നതിന് പകരം നീക്കം ചെയ്യുന്നു.

ശരിയായ പ്രവർത്തനം പ്രോംപ്റ്റ് ക്രമം പൂർത്തിയാകുന്നതും സെഷൻ «Initialization Sequence Completed»-ൽ എത്തുന്നതും കാണിക്കുന്നു. ക്ലയന്റ് അതേ പ്രോംപ്റ്റിൽ നിന്നാൽ പൊരുത്തപ്പെടൽ പരാജയപ്പെട്ടു: സോക്കറ്റ് അയച്ച കൃത്യമായ വരികൾ പ്രിന്റ് ചെയ്യുക, ഉദ്ധരണികളും പ്രോംപ്റ്റിന്റെ പേരും പരിശോധിക്കുക, sleep ചേർക്കുന്നതിന് പകരം പാറ്റേൺ ശരിയാക്കുക. വിജയം റിപ്പോർട്ട് ചെയ്ത് ഒന്നും വഹിക്കാത്ത ടണൽ റൂട്ടിംഗ് അല്ലെങ്കിൽ push പ്രശ്നമാണ്, ക്രെഡൻഷ്യൽ പ്രശ്നമല്ല.

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