ഒരു പിശക്, മൂന്ന് രഹസ്യങ്ങൾ: ഏത് VPN ക്രെഡൻഷ്യലാണ് പരാജയപ്പെട്ടത്?
ക്ലയന്റ് ഓരോ ഘട്ടത്തിനും ഒരു പിശക് കാണിക്കുന്നു. ആരും പരിശോധിക്കാത്ത ഒരു പാസ്വേഡ് പുനഃസജ്ജീകരിക്കുന്നതിന് മുമ്പ് അസോസിയേഷൻ, ഉപയോക്തൃ കൈമാറ്റം, രീതി എന്നിവ വായിക്കുക.
«പ്രമാണീകരണം പരാജയപ്പെട്ടു» എന്നത് സെർവർ സർട്ടിഫിക്കറ്റ്, മെഷീന്റെ മുൻകൂട്ടി പങ്കിട്ട കീ അല്ലെങ്കിൽ ഉപയോക്തൃ പാസ്വേഡ് എന്നിവയെ സൂചിപ്പിച്ചേക്കാം. അവയിൽ ഏതാണെന്ന് പ്രോട്ടോക്കോളിനെ ആശ്രയിച്ചിരിക്കുന്നു, കാരണം ഓരോ പ്രോട്ടോക്കോളും വ്യത്യസ്തമായ രഹസ്യങ്ങളുടെ കൂട്ടം നിർവചിക്കുന്നു. തെറ്റായത് പുനഃസജ്ജീകരിച്ചാൽ പിശക് മാറ്റമില്ലാതെ തുടരും. എന്തെങ്കിലും എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് പ്രോട്ടോക്കോൾ എത്ര തെളിവുകൾ ആവശ്യപ്പെടുന്നുവെന്ന് നിർണ്ണയിക്കുകയാണ് പോംവഴി.
വിപരീത ദിശകളിലേക്ക് ചൂണ്ടുന്ന രണ്ട് തെളിവുകൾ
ഒരു ടണൽ ശരിയായ ഗേറ്റ്വേയിൽ എത്തിയോ എന്നതിനും, വേറെയായി ഉപയോക്താവ് ആരാണെന്നതിനും ഉത്തരം നൽകണം. ഗേറ്റ്വേ തെളിവ് മെഷീൻ തലത്തിലാണ്: സെർവർ സർട്ടിഫിക്കറ്റ്, മുൻകൂട്ടി പങ്കിട്ട കീ അല്ലെങ്കിൽ സ്റ്റാറ്റിക് പൊതു കീ. ഉപയോക്തൃ തെളിവ് വ്യക്തി തലത്തിലാണ്: പാസ്വേഡ്, ടോക്കൺ, ക്ലയന്റ് സർട്ടിഫിക്കറ്റ്, അല്ലെങ്കിൽ ഒന്നുമില്ല. ഇവ വിശ്വാസത്തിന്റെ വിപരീത ദിശകളാണ്, വ്യത്യസ്ത വസ്തുക്കൾ ഉപയോഗിക്കുന്നു.
IKEv2 ഗേറ്റ്വേ തെളിവ് IKE_AUTH-നുള്ളിൽ നിർവഹിക്കുന്നു, EAP ഉപയോഗിക്കുമ്പോൾ പിന്നീട് ഉപയോക്തൃ തെളിവ് പ്രത്യേക കൈമാറ്റത്തിൽ പ്രവർത്തിപ്പിക്കുന്നു. IKEv2 വിവരണം ഇവയെ വേറെ വിഭാഗങ്ങളായി സൂക്ഷിക്കുന്നു, ഒരു സന്ദേശം രണ്ട് റൗണ്ടുകളെയും ഉൾക്കൊള്ളുമ്പോൾ എവിടെ നോക്കണമെന്നതിന് ഇത് ശക്തമായ സൂചനയാണ്.
സന്ദേശമല്ല, ഘട്ടം വായിക്കുക
ഏത് ഘട്ടം പരാജയപ്പെട്ടാലും ക്ലയന്റ് ഒരേ പിശക് സ്ട്രിംഗ് കാണിക്കുന്നു, അതിനാൽ സ്ട്രിംഗ് തന്നെ ഏതാണ്ട് വിവരങ്ങളൊന്നും വഹിക്കുന്നില്ല. വിവരം വഹിക്കുന്നത് ഓരോ ഘട്ടത്തിലും നിങ്ങൾക്ക് പരിശോധിക്കാവുന്ന അവസ്ഥയാണ്: അസോസിയേഷൻ ഉണ്ടോ, ഉപയോക്തൃ കൈമാറ്റം തുടങ്ങിയോ, ഗേറ്റ്വേ ആവശ്യപ്പെട്ട രീതി ക്ലയന്റ് വാഗ്ദാനം ചെയ്തോ. പട്ടിക ഘട്ടങ്ങളെ പ്രോട്ടോക്കോൾ പേരിന് പകരം അങ്ങനെ ക്രമീകരിക്കുന്നു.
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
ഉപയോക്താവിന് വീണ്ടും ടൈപ്പ് ചെയ്യാവുന്ന ക്രെഡൻഷ്യലിനെക്കുറിച്ച് രണ്ടാമത്തെ വരി മാത്രമാണ്. ബാക്കി മൂന്നും കോൺഫിഗറേഷൻ വസ്തുതകളാണ്, ഈ പൊരുത്തക്കേടാണ് ഇത്തരം റിപ്പോർട്ടുകളിൽ പലതും ഒന്നും മാറ്റാത്ത പാസ്വേഡ് റീസെറ്റിൽ അവസാനിക്കാനുള്ള കാരണം. ഏതെങ്കിലും ഫീൽഡ് തൊടുന്നതിന് മുമ്പ് നിങ്ങളുടെ തെളിവിനോട് യോജിക്കുന്ന വരി വായിക്കുക.
രണ്ട് രഹസ്യങ്ങളുള്ള പ്രോട്ടോക്കോൾ കൈകൾ കാണിക്കുന്നു
L2TP IPsec-ന് മുകളിൽ എണ്ണം ദൃശ്യമാക്കുന്നു, കാരണം രണ്ട് പരിശോധനകളും വ്യത്യസ്ത പ്രോസസുകളിൽ സംഭവിക്കുന്നു. IPsec പാളി ആദ്യം മുൻകൂട്ടി പങ്കിട്ട കീയോ സർട്ടിഫിക്കറ്റോ ഉപയോഗിച്ച് ഉയരണം, അതിന് ശേഷം മാത്രമാണ് അതിനുള്ളിലെ PPP ഒരു ഉപയോക്തൃ ലോഗിൻ ശ്രമിക്കുന്നത്.
മെഷീന്റെ രഹസ്യം തെറ്റാണെങ്കിൽ അസോസിയേഷൻ ഉണ്ടാകുന്നില്ല, ഉപയോക്തൃ ക്രെഡൻഷ്യൽ ഒരിക്കലും പരീക്ഷിക്കപ്പെടുന്നില്ല. മെഷീന്റെ രഹസ്യം ശരിയും ഉപയോക്താവിന്റെ രഹസ്യം തെറ്റും ആണെങ്കിൽ അസോസിയേഷൻ നിലനിൽക്കുന്നു, ടണൽ ഇതിനകം ഉയർന്നതിന് ശേഷം PPP ലോഗിൻ നിരസിക്കുന്നു. രണ്ടും രണ്ട് വ്യത്യസ്ത സംഭവങ്ങളിൽ നിന്ന് സ്ക്രീനിൽ ഒരേ സന്ദേശം നൽകുന്നു.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerശൂന്യമായ അസോസിയേഷൻ ലിസ്റ്റ് ഉപയോക്തൃ പാളിയെ ഉടനടി ഒഴിവാക്കുന്നു, അതിനാൽ പാസ്വേഡിന് മുമ്പ് അത് പരിശോധിക്കുക. ആവർത്തിച്ചുള്ള PPP പരാജയങ്ങളുള്ള സ്ഥാപിത അസോസിയേഷൻ മറുവശത്തേക്ക്, ഉപയോക്തൃ പാളിയിലേക്കോ അതിനുള്ളിലെ പ്രമാണീകരണ പ്രോട്ടോക്കോളിലേക്കോ ചൂണ്ടുന്നു. രണ്ട് നിഗമനങ്ങളിൽ ഒന്നും ക്ലയന്റിന്റെ പിശക് വാചകത്തിൽ നിന്ന് ലഭ്യമല്ല.
പാസ്വേഡ് മാത്രമുള്ള പ്രവേശനം യഥാർത്ഥത്തിൽ എന്തിനെ ആശ്രയിച്ചിരിക്കുന്നു
പാസ്വേഡ് മാത്രമുള്ള പ്രവേശനം L2TP, PPTP, SSTP, EAP-യുള്ള IKEv2 എന്നിവയ്ക്ക് സാധാരണമാണ്. WireGuard-ന് അത്തരം ഒരു ഓപ്ഷനും ഇല്ല, കാരണം അതിന്റെ പങ്കാളികൾ ഉപയോക്താക്കളല്ല, കീകളാണ്. OpenVPN-ന് ഉത്തരം സെർവറിന്റെ ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് ആവശ്യകതയിൽ നിന്ന് വരുന്നു: സർട്ടിഫിക്കറ്റും പാസ്വേഡും ഒരുമിച്ച് ആവശ്യപ്പെടുന്ന ഗേറ്റ്വേ ഫീൽഡിൽ എന്ത് ടൈപ്പ് ചെയ്താലും പാസ്വേഡ് മാത്രമുള്ള ക്ലയന്റിനെ നിരസിച്ചുകൊണ്ടിരിക്കും.
നിങ്ങൾക്ക് ഏത് ഘടകം വേണമെന്നത് അതേ ഉത്തരത്തിൽ നിന്ന് വരുന്നു. IKEv2-ന് കീഴിൽ പാസ്വേഡ് ലോഗിന് EAP സംസാരിക്കുന്ന ക്ലയന്റ് വേണം, അതേസമയം സർട്ടിഫിക്കറ്റ് ലോഗിന് ക്ലയന്റിന്റെ സ്വകാര്യ കീയും സെർവറിന്റെ ശൃംഖലയും വേണം. തെറ്റായത് ഇൻസ്റ്റാൾ ചെയ്താൽ പ്രമാണീകരണ രീതി തന്നെയാണ് ഇല്ലാത്തതെങ്കിലും പരാജയം ക്രെഡൻഷ്യൽ പിശകായി വായിക്കപ്പെടും.
ഒരു കാര്യം മാറ്റുക, പിന്നീട് വീണ്ടും പരിശോധിക്കുക
ആദ്യം മൂന്ന് വസ്തുതകൾ നിർണ്ണയിക്കുക: ഏത് പ്രോട്ടോക്കോൾ പ്രവർത്തിക്കുന്നു, അത് എത്ര രഹസ്യങ്ങൾ നിർവചിക്കുന്നു, അവയിൽ ഏതാണ് ഉപയോക്താവിനല്ല മെഷീനുള്ളത്. മെഷീനുകൾ ആദ്യ ഘട്ടത്തിലും മനുഷ്യർ രണ്ടാം ഘട്ടത്തിലും പരാജയപ്പെടുന്നു, ഇവ രണ്ടും കൂട്ടിക്കുഴയ്ക്കുന്നതാണ് ഈ മുഴുവൻ പ്രശ്നം.
തുടർന്ന് കൃത്യമായി ഒരു കാര്യം മാറ്റി അതേ ക്ലയന്റിൽ നിന്ന് വീണ്ടും പരിശോധിക്കുക. ആ അച്ചടക്കം ആശയക്കുഴപ്പമുള്ള പരാജയത്തെ അടുത്ത വ്യക്തിക്ക് വിവരിക്കാവുന്ന ഒരു പരിഹാരമാക്കി മാറ്റുന്നു, അത് ആർക്കും വിശദീകരിക്കാനാകാത്ത പ്രവർത്തിക്കുന്ന ഒരു ബന്ധനത്തേക്കാൾ ഉപയോഗപ്രദമാണ്.