ശരിയായ VPN പാസ്വേഡിന് കാണാതായ സർട്ടിഫിക്കറ്റിനെ മാറ്റിസ്ഥാപിക്കാനാവില്ല

ക്രെഡൻഷ്യലുകൾ ശരിയാണ്, പ്രൊഫൈൽ വൃത്തിയായി ഇമ്പോർട്ട് ചെയ്യുന്നു, എന്നിട്ടും പ്രാമാണീകരണം പൂർത്തിയാകുന്നതിന് മുമ്പ് കണക്ഷൻ പരാജയപ്പെടുന്നു. Windows-ൽ EAP രീതിക്ക് കണ്ടെത്താനാകാത്ത സർട്ടിഫിക്കറ്റിനെക്കുറിച്ചുള്ള പിശക് 798 ആകാം സന്ദേശം. OpenVPN-ൽ ക്ലയന്റ് ലോഗ് സെർവറിനെ ഒരിക്കലും തൃപ്തിപ്പെടുത്താത്ത TLS ഹാൻഡ്ഷേക്ക് കാണിക്കുന്നു. രണ്ടും ഒരേ കാണാതായ വസ്തുവിനെ വിവരിക്കുന്നു: ക്ലയന്റ് അവതരിപ്പിക്കേണ്ടിയിരുന്ന ക്ലയന്റ് സർട്ടിഫിക്കറ്റ്.

പാസ്വേഡ് ഒരു രഹസ്യത്തിന്റെ അറിവ് തെളിയിക്കുന്നു; സർട്ടിഫിക്കറ്റ് ഒരു കീയുടെ കൈവശം തെളിയിക്കുന്നു, ഒന്ന് മറ്റൊന്നിനെ മാറ്റിസ്ഥാപിക്കുന്നില്ല.

പാസ്വേഡ് ഒരിക്കലും പ്രശ്നമായിരുന്നില്ല

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

പ്രവർത്തിക്കുന്നതിന് മുമ്പ് സന്ദേശം വായിക്കുക. ക്രെഡൻഷ്യൽ നിരസിക്കൽ, സർട്ടിഫിക്കറ്റ് തിരയലിന്റെ പരാജയം, TLS ഹാൻഡ്ഷേക്ക് പരാജയം എന്നിവ മൂന്ന് വ്യത്യസ്ത കണ്ടെത്തലുകളാണ്, അവയിലൊന്ന് മാത്രമേ പാസ്വേഡുമായി ബന്ധപ്പെട്ടിട്ടുള്ളൂ.

ക്ലയന്റ് സ്റ്റോറിൽ എന്ത് ഉണ്ടായിരിക്കണം

രണ്ട് വസ്തുക്കൾ ഉൾപ്പെട്ടിരിക്കുന്നു. VPN ക്ലയന്റ് പ്രവർത്തിപ്പിക്കുന്ന ഉപയോക്താവിന് ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് അതിന്റെ സ്വകാര്യ കീയോടൊപ്പം ഇൻസ്റ്റാൾ ചെയ്യണം, കൂടാതെ ഇഷ്യൂ ചെയ്യുന്ന റൂട്ട് വിശ്വസനീയമായിരിക്കണം. .cer ഫയലിൽ പൊതു സർട്ടിഫിക്കറ്റ് മാത്രമേയുള്ളൂ, അതിനാൽ അതിനൊറ്റയ്ക്ക് ഒന്നും പ്രാമാണീകരിക്കാനാവില്ല. Windows സർട്ടിഫിക്കറ്റ് മാനേജറിൽ, ക്ലയന്റ് ഐഡന്റിറ്റി നിലവിലെ ഉപയോക്താവിന്റെ വ്യക്തിഗത സ്റ്റോറിലും റൂട്ട് വിശ്വസ്ത റൂട്ട് സ്റ്റോറിലും ആണ്.

ഐഡന്റിറ്റി മെഷീൻ സ്റ്റോറിലോ റൂട്ട് സ്റ്റോറിൽ മാത്രമോ ഇൻസ്റ്റാൾ ചെയ്യുന്നത് ഉപയോക്താവിന്റെ വ്യക്തിഗത സ്റ്റോറിനെ ലക്ഷ്യമിട്ടുള്ള തിരയൽ തൃപ്തിപ്പെടുത്തുന്നില്ല. സ്റ്റോർ, സ്വകാര്യ-കീ ഫ്ലാഗ്, സാധുതാ തീയതികൾ എന്നിവ ഒരുമിച്ച് പരിശോധിച്ച്, സ്റ്റോർ വീണ്ടും വായിക്കാൻ ക്ലയന്റ് പുനരാരംഭിക്കുക.

രണ്ട് ഉൽപ്പന്നങ്ങൾ, അതേ കാണാതായ ക്രെഡൻഷ്യൽ

OpenVPN സെർവറുകൾ സ്വതവേ ഒരു ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് ആവശ്യപ്പെടുന്നു. ക്ലയന്റിൽ auth-user-pass ചേർക്കുന്നത് ഉപയോക്തൃനാമവും പാസ്വേഡും അയയ്ക്കുന്നു, TLS ഹാൻഡ്ഷേക്ക് ഇപ്പോഴും സർട്ടിഫിക്കറ്റ് ആവശ്യപ്പെടുന്നു, അതിനാൽ verify-client-cert require പ്രകാരം പാസ്വേഡ് മാത്രം കണക്ഷൻ പൂർത്തിയാക്കാനാവില്ല. ഒന്നും ആവശ്യപ്പെടാതിരിക്കാൻ സെർവർ ക്രമീകരിക്കാം, അത് പാസ്വേഡിനെ ക്ലയന്റിന്റെ ഏക ക്രെഡൻഷ്യലാക്കുന്നു, ഇത് ശക്തിയിൽ യഥാർത്ഥ കുറവാണ്. auth-user-pass-verify ന് പിന്നിലെ shell സ്ക്രിപ്റ്റിന് ക്രെഡൻഷ്യലുകൾ സാധൂകരിക്കാനാകും, അതിന് സ്ക്രിപ്റ്റ് പ്രവർത്തനം പ്രവർത്തനക്ഷമമാക്കണം, ഇത് ശരിയായ പ്രാമാണീകരണ ബാക്ക്എൻഡിനേക്കാൾ അപകടകരമായ രൂപകൽപ്പനയാക്കുന്നു.

പാസ്വേഡിൽ മാത്രം ആശ്രയിക്കുന്ന പ്രൊഫൈൽ തള്ളിവിടുന്ന ഓപ്ഷനുകളെയും ആശ്രയിക്കുന്നു, അവ വീണ്ടും വലിക്കൽ സംവിധാനം പ്രവർത്തനക്ഷമമായിരിക്കുന്നതിനെ ആശ്രയിക്കുന്നു.

പരിശോധനകൾ ഓഫ് ചെയ്ത് കാണാതായ സർട്ടിഫിക്കറ്റ് ശരിയാക്കരുത്

സന്ദേശം അപ്രത്യക്ഷമാകാൻ പരിശോധന അയച്ചുവിടാനുള്ള പ്രലോഭനമുണ്ട്. അത് തന്റെ ജോലി ചെയ്തിരുന്ന നിയന്ത്രണം നീക്കം ചെയ്യുകയും ഇനി തന്റെ അവകാശവാദം തെളിയിക്കാത്ത കണക്ഷൻ അവശേഷിപ്പിക്കുകയും ചെയ്യുന്നു. ഗേറ്റ്വേ അടുത്തിടെ അതിന്റെ റൂട്ട് മാറ്റിയിട്ടുണ്ടെങ്കിൽ, പ്രൊഫൈൽ എഡിറ്റ് ചെയ്യുന്നതിന് പകരം ക്ലയന്റ് പാക്കേജ് വീണ്ടും ഡൗൺലോഡ് ചെയ്യുക, കാരണം പഴയ പാക്കേജിൽ മുൻ റൂട്ട് ഇപ്പോഴും ഉണ്ടായിരിക്കാം. പ്രൊഫൈൽ എഡിറ്ററിൽ സർട്ടിഫിക്കറ്റ് പ്രാമാണീകരണ ഓപ്ഷൻ ഇല്ലെങ്കിൽ, ഇൻസ്റ്റാൾ ചെയ്ത Windows പതിപ്പ് ആ രീതി കാണിച്ചേക്കില്ല; XML കൈകൊണ്ട് എഡിറ്റ് ചെയ്യുന്നതിന് പകരം സിസ്റ്റം അപ്ഡേറ്റ് ചെയ്യുക.

സർട്ടിഫിക്കറ്റ് ഏത് സ്റ്റോറിലായിരുന്നു, ഏത് ഉപയോക്താവ് ക്ലയന്റ് പ്രവർത്തിപ്പിച്ചു, സ്വകാര്യ കീ ഉണ്ടായിരുന്നോ എന്നിവ രേഖപ്പെടുത്തുക. ആ മൂന്നും ഈ പരാജയത്തിന്റെ ഏതാണ്ടെല്ലാ സന്ദർഭങ്ങളും വിശദീകരിക്കുന്നു.

പാസ്വേഡ് കുഴപ്പമില്ലായിരുന്നു. രീതിക്ക് യഥാർത്ഥത്തിൽ വേണ്ടിയിരുന്ന ക്രെഡൻഷ്യൽ മറ്റൊരിടത്തായിരുന്നു.