OpenVPN PAM: login ആർഗ്യുമെന്റ് ഒരു സേവനമാണ്, ഉപയോക്താവല്ല

സെർവറിൽ ഉപയോക്താവിനെ ചേർത്തു, പാസ്വേഡ് ശരിയായി നൽകി, എന്നിട്ടും കണക്ഷൻ AUTH_FAILED എന്നതോടെ അവസാനിക്കുന്നു. സാധാരണയായി പ്ലഗിൻ വരിയാണ് കാരണം വിശദീകരിക്കുന്നത്: പ്ലഗിൻ പാതയ്ക്കുശേഷമുള്ള വാക്ക് ഒരു PAM സേവന നാമമാണ്, ഏത് മൊഡ്യൂൾ കൂട്ടമാണ് ചോദ്യത്തിന് ഉത്തരം നൽകുന്നതെന്ന് അതാണ് തീരുമാനിക്കുന്നത്. അത് ഒരു ഉപയോക്തൃനാമമല്ല, OpenVPN സ്വയം വായിക്കുന്ന ഒരു പാസ്വേഡ് ഫയലിലേക്കുള്ള സൂചികയുമല്ല.

രണ്ടാമത്തെ വാക്ക് എന്താണ് തിരഞ്ഞെടുക്കുന്നത്

കോൺഫിഗറേഷൻ വരി ഒരു പ്ലഗിൻ പാതയും ഒരു ആർഗ്യുമെന്റും സ്വീകരിക്കുന്നു:

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

ആ ആർഗ്യുമെന്റ് സേവന നാമമായി PAM ലൈബ്രറിയിലേക്ക് കൈമാറുന്നു, അതിനാൽ /etc/pam.d/openvpn-ലെ സ്റ്റാക്ക് പ്രവർത്തിക്കുന്നു. അവിടെ login എന്ന് എഴുതിയാൽ പകരം ഇന്ററാക്ടീവ് ലോഗിൻ നയം പ്രാബല്യത്തിൽ വരും, നിങ്ങളുടെ വിതരണത്തിൽ ആ നയം ഉൾക്കൊള്ളുന്ന മൊഡ്യൂളുകളോടെ.

ഇൻസ്റ്റാൾ ചെയ്ത പാക്കേജ് നൽകുന്ന പ്ലഗിൻ പാത ഉപയോഗിക്കുക, മറ്റൊരു ഹോസ്റ്റിൽനിന്ന് പകർത്തിയ പാതയല്ല. ഫയൽനാമവും ഡയറക്ടറിയും വിതരണങ്ങൾക്കിടയിൽ വ്യത്യാസപ്പെടുന്നു, തെറ്റായ പാത സാധൂകരണ സമയത്തല്ല, ആരംഭത്തിൽ പ്ലഗിൻ ലോഡ് പിശകോടെ പരാജയപ്പെടുന്നു.

സ്റ്റാക്ക് യഥാർത്ഥത്തിൽ അക്കൗണ്ടുകൾ വായിക്കുന്നത് എവിടെനിന്ന്

PAM ഒരു ഡിസ്പാച്ചറാണ്. സേവന ഫയൽ മൊഡ്യൂളുകൾ ക്രമത്തിൽ പട്ടികപ്പെടുത്തുന്നു, ഉത്തരം നൽകാൻ കഴിയുന്ന ആദ്യത്തേത് ഫലം തീരുമാനിക്കുന്നു. pam_unix വിളിക്കുന്ന സ്റ്റാക്ക് പ്രാദേശിക അക്കൗണ്ടുകൾ വായിക്കുന്നു; LDAP അല്ലെങ്കിൽ RADIUS മൊഡ്യൂൾ വിളിക്കുന്ന സ്റ്റാക്ക് ക്രെഡൻഷ്യലുകൾ തികച്ചും മറ്റൊരിടത്തേക്ക് അയയ്ക്കുന്നു.

സേവന നാമം റിസോൾവ് ചെയ്യുന്ന ഫയൽ, അത് ഉൾക്കൊള്ളുന്ന എല്ലാം ഉൾപ്പെടെ വായിക്കുക:

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

സ്റ്റാക്ക് തീരുമാനം ഒരു ഡയറക്ടറിക്ക് കൈമാറുകയാണെങ്കിൽ, പ്രാദേശിക അക്കൗണ്ട് ചേർക്കുന്നത് ഒന്നും മാറ്റുന്നില്ല. അത് പ്രാദേശിക അക്കൗണ്ടുകൾ വായിക്കുകയാണെങ്കിൽ, ഡയറക്ടറിയിൽ ഉപയോക്താവിനെ സൃഷ്ടിക്കുന്നതും ഒന്നും മാറ്റുന്നില്ല. സ്റ്റാക്ക് തിരയുന്നിടത്ത് അക്കൗണ്ട് ഉണ്ടായിരിക്കണം, ഇത്തരം റിപ്പോർട്ടുകളിൽ ഭൂരിഭാഗത്തിലും മുഴുവൻ രോഗനിർണയവും ഇതുതന്നെ.

ഒരു ശ്രമം, രണ്ട് ലോഗുകൾ

ഒരു പരാജയപ്പെട്ട കണക്ഷൻ ഇരുവശത്തും ചേർത്ത് പരിശോധിക്കുക. OpenVPN ലോഗ് പ്ലഗിൻ ഫലവും ക്ലയന്റിന്റെ നിരസനവും കാണിക്കുന്നു; സിസ്റ്റം സാധൂകരണ ലോഗ് ഏത് മൊഡ്യൂൾ പ്രവർത്തിച്ചു, എന്താണ് തീരുമാനിച്ചത് എന്ന് കാണിക്കുന്നു. ഒരേ സമയ വിൻഡോയിൽ അവ രണ്ടും വായിക്കുന്നതാണ് കാണാത്ത സേവന ഫയലിനെ ബാക്ക്എൻഡ് സമയപരിധി കവിയുന്നതിൽനിന്ന് വേർതിരിക്കുന്നത്. സാധൂകരണ ലോഗിൽ ഒരു വിടവ് ഉണ്ടെങ്കിൽ സ്റ്റാക്കിൽ എത്തിയേയില്ല എന്നർത്ഥം.

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

VPN-ഉം സ്റ്റാക്കും ഒരുമിച്ച് ഡീബഗ് ചെയ്യേണ്ടിവരാതിരിക്കാൻ, PAM സംസാരിക്കുന്ന ഒരു യൂട്ടിലിറ്റി ഉപയോഗിച്ച് സേവനം നേരിട്ട് പരിശോധിക്കുക. അതേ സേവന നാമവും അക്കൗണ്ടും ഉപയോഗിച്ചുള്ള നേരിട്ടുള്ള പരിശോധന വിജയിച്ചാൽ, പ്രശ്നം അക്കൗണ്ടിലല്ല, ഡീമൺ ക്രെഡൻഷ്യലുകൾ എങ്ങനെ കൈമാറുന്നു എന്നതിലേക്ക് ചുരുങ്ങുന്നു.

pamtester openvpn alice authenticate

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

സമർപ്പിത സേവനം login തിരുത്തുന്നതിനേക്കാൾ നല്ലത്

VPN-ന്റെ ആവശ്യകതകൾ ഇന്ററാക്ടീവ് ലോഗിനിൽനിന്ന് വ്യത്യസ്തമാകുമ്പോൾ, സാധാരണ വ്യത്യസ്തമാണ്, അതിന് സ്വന്തം സേവന ഫയൽ നൽകുക. login അല്ലെങ്കിൽ common-auth തിരുത്തുന്നത് അവ ഉൾക്കൊള്ളുന്ന ഓരോ പ്രോഗ്രാമിന്റെയും നയം മാറ്റുന്നു, ഇതുമായി ബന്ധമില്ലാത്ത ഒരു ലോഗിൻ പ്രശ്നം ഡീബഗ് ചെയ്യുന്ന അടുത്തയാൾ നിങ്ങളുടെ മാറ്റം സ്വീകരിക്കും.

ആവശ്യമായ മൊഡ്യൂളുകൾ ഒരു ചെറിയ സേവന ഫയലിലേക്ക് പകർത്തുക, ക്രമം വ്യക്തമായി നിലനിർത്തുക, ആരാണ് ഉടമ എന്ന് രേഖപ്പെടുത്തുക. പാസ്വേഡ് പുനഃസജ്ജീകരണം ഫലമില്ലാത്തതായി തോന്നുമ്പോൾ പരിശോധിക്കേണ്ടത് അതേ ഫയലാണ്.

ക്ലയന്റ് എന്താണ് അയയ്ക്കുന്നത്, എന്താണ് അയയ്ക്കാത്തത്

ക്ലയന്റ് ഉപയോക്തൃനാമവും പാസ്വേഡും അത് പിന്തുണയ്ക്കുന്ന പ്രോംപ്റ്റ് അല്ലെങ്കിൽ ഫയൽ വഴി നൽകുന്നു. സെർവർ പ്ലഗിൻ ആ മൂല്യങ്ങൾ PAM സംഭാഷണത്തിലേക്ക് കൈമാറുന്നു; അവ സെർവറിന്റെ കോൺഫിഗറേഷനിൽനിന്ന് വായിക്കുന്നില്ല. പാസ്വേഡ് നിർവചിക്കുന്നതുപോലെ തോന്നുന്ന ഒരു സെർവർ-വശ വരി അങ്ങനെ ചെയ്യുന്നില്ല, ഒരു പ്രൊഫൈൽ തിരുത്തും അക്കൗണ്ട് സൃഷ്ടിക്കില്ല.

ഉപയോക്തൃനാമവും പാസ്വേഡും ക്ലയന്റ് സർട്ടിഫിക്കറ്റുകളുമായി ഒരുമിച്ച് നിലനിൽക്കാം, PAM പ്രവർത്തനക്ഷമമാക്കുന്നത് സർട്ടിഫിക്കറ്റുകൾ പരിശോധിക്കുന്നത് നിർത്താനുള്ള കാരണമല്ല. വിന്യാസം ഉദ്ദേശിച്ച പാളികൾ നിലനിർത്തി അക്കൗണ്ട് ഉറവിടം മാത്രം പരിഹരിക്കുക.

സ്വീകാര്യത ഇരുവശത്തുമുണ്ട്: ഉദ്ദേശിച്ച അക്കൗണ്ട് വിജയിക്കുന്നു, നിരസിക്കേണ്ട അക്കൗണ്ട് ഇപ്പോഴും പരാജയപ്പെടുന്നു. auth-pam പ്ലഗിന്റെ README സേവന ആർഗ്യുമെന്റും അതിന് മുന്നിൽ നിർത്താൻ കഴിയുന്ന ബാക്ക്എൻഡുകളും വിവരിക്കുന്നു, നിങ്ങൾ നിർമ്മിക്കാൻ ശ്രമിക്കുന്ന ക്രമീകരണം സ്ഥിരീകരിക്കേണ്ടത് അവിടെയാണ്.