OpenConnect-ലെ --key-password നിങ്ങളുടെ VPN അക്കൗണ്ട് പാസ്വേഡാണോ?

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

ആശയക്കുഴപ്പമുള്ള ഭാഗം, ഒരൊറ്റ കണക്ഷന് രണ്ട് രഹസ്യങ്ങളും ന്യായമായി ആവശ്യമായി വന്നേക്കാം എന്നതാണ്. ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് പ്രാമാണീകരണത്തിന് എൻക്രിപ്റ്റ് ചെയ്ത കീ ആവശ്യമായി വന്നേക്കാം, സർട്ടിഫിക്കറ്റ് സ്വീകരിച്ചതിന് ശേഷവും അതേ ഗേറ്റ്വേ ഉപയോക്തൃ പ്രാമാണീകരണ കൈമാറ്റം നടത്തിയേക്കാം. ഒരു രഹസ്യവും മറ്റേ ഘട്ടം പൂർത്തിയാക്കുന്നില്ല, ഒന്നിലെ പരാജയം പുറമേനിന്ന് നോക്കുമ്പോൾ മറ്റൊന്നിലെ പരാജയത്തോട് വളരെ സാമ്യമുള്ളതാണ്.

രണ്ട് രഹസ്യങ്ങൾ, രണ്ട് വ്യത്യസ്ത ജോലികൾ

ഫയൽ പ്രവേശനം, നെറ്റ്വർക്ക് പ്രവേശനാനുമതി എന്നിവയായി റോളുകൾ വായിക്കുക. കീ പാസ്വേഡ് --sslkey ൽ പേരിട്ടിരിക്കുന്ന PEM സ്വകാര്യ കീ ഡീക്രിപ്റ്റ് ചെയ്യുന്നു, അതുവഴി TLS ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് അവതരിപ്പിക്കാം. ആ ഡീക്രിപ്ഷൻ പ്രാദേശികമായി, ക്ലയന്റ് പ്രോസസ്സിനുള്ളിൽ നടക്കുന്നു, പാസ്ഫ്രേസ് തന്നെ ഒരിക്കലും ഗേറ്റ്വേയിലേക്ക് പോകുന്നില്ല. ഗേറ്റ്വേ കാണുന്നത് സർട്ടിഫിക്കറ്റും കീ ഉപയോഗിച്ച് ഉണ്ടാക്കിയ ഒപ്പും ആണ്. OpenConnect-ന്റെ മാനുവൽ --key-password എന്നത് --certificate, --sslkey എന്നിവയ്ക്കൊപ്പം സൂക്ഷിക്കുന്നു, TPM-ൽ സൂക്ഷിച്ച കീ ഉപയോഗിക്കാനാകുന്ന ബിൽഡുകളിൽ അതേ ഓപ്ഷൻ പകരം സംഭരണത്തിന്റെ റൂട്ട് കീയുടെ പാസ്വേഡ് വഹിക്കുന്നു.

അക്കൗണ്ട് പാസ്വേഡ് വ്യത്യസ്ത തരത്തിലുള്ളതാണ്. അത് പ്രാമാണീകരണ കൈമാറ്റത്തിലേക്ക് പോകുന്നു: ഉപയോക്തൃനാമവും പാസ്വേഡും അടങ്ങിയ ഫോം, ടോക്കൺ, SAML റൗണ്ട്, അല്ലെങ്കിൽ ഗേറ്റ്വേ പ്രഖ്യാപിക്കുന്ന ഏതെങ്കിലും സംയോജനം. സർട്ടിഫിക്കറ്റ് മാത്രമാണ് ഘടകമെങ്കിൽ ചില വിന്യാസങ്ങൾ അത് അശേഷം ആവശ്യപ്പെടുന്നില്ല, ചിലത് സർട്ടിഫിക്കറ്റിന് ശേഷവും ആവശ്യപ്പെടുന്നു, കാരണം സർട്ടിഫിക്കറ്റ് ഉപകരണത്തെ തെളിയിക്കുമ്പോൾ അക്കൗണ്ട് വ്യക്തിയെ തെളിയിക്കുന്നു.

രണ്ടും കലർത്തുന്നത് തെറ്റിദ്ധരിപ്പിക്കുന്ന പിശകുകൾ സൃഷ്ടിക്കുന്നു. ലോഗിൻ നിരസിക്കുന്ന ഗേറ്റ്വേ സാധാരണയായി പ്രാമാണീകരണ പരാജയം റിപ്പോർട്ട് ചെയ്യുന്നു, തെറ്റായ കീ പാസ്ഫ്രേസ് സാധാരണയായി അതിനേക്കാൾ മുമ്പ്, TLS പാളിക്ക് കീ ഫയൽ വായിക്കാനാകാത്തപ്പോൾ പരാജയപ്പെടുന്നു. ഇവ വ്യത്യസ്ത ഘട്ടങ്ങളും വ്യത്യസ്ത പരിഹാരങ്ങളുമാണ്, പേരുകൾ വളരെ സാമ്യമുള്ളതിനാൽ ആളുകൾ അവ പരസ്പരം മാറ്റി പിന്നീട് തെറ്റായ ലോഗിനെ പിന്തുടരുന്നു. ഏതെങ്കിലും ക്രമീകരണം മാറ്റുന്നതിന് മുമ്പ് ഏത് പ്രോംപ്റ്റ് വന്നുവെന്ന് ശ്രദ്ധിക്കുക, കാരണം പ്രോംപ്റ്റിന്റെ വാക്കുകളാണ് നിങ്ങളുടെ പക്കലുള്ള ഏറ്റവും വിലകുറഞ്ഞ രോഗനിർണയം.

കീ പാസ്വേഡ് യഥാർഥത്തിൽ എപ്പോൾ ആവശ്യമാണ്

തുറക്കാൻ എൻക്രിപ്റ്റ് ചെയ്ത കീ ഉള്ളപ്പോൾ മാത്രമാണ് ഓപ്ഷന് അർഥമുള്ളത്. ഉപയോക്തൃനാമവും പാസ്വേഡും ഉപയോഗിച്ച് ക്ലയന്റ് സർട്ടിഫിക്കറ്റില്ലാതെ കണക്ട് ചെയ്യുന്നുവെങ്കിൽ, --key-password ന് പ്രവർത്തിക്കാൻ ഒന്നുമില്ല, അത് ചേർക്കുന്നത് ഒന്നും മാറ്റുന്നില്ല. --certificate ഉം --sslkey ഉം ഉപയോഗിച്ച് കണക്ട് ചെയ്യുന്നുവെങ്കിൽ, പാസ്ഫ്രേസ് ആവശ്യപ്പെടുമോ ഇല്ലയോ എന്ന് കീ ഫയലിന്റെ സ്വന്തം ഫോർമാറ്റാണ് തീരുമാനിക്കുന്നത്.

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

പരാജയം എപ്പോൾ സംഭവിക്കുന്നു എന്ന് നോക്കുന്നത് ഉപയോഗപ്രദമായ രോഗനിർണയമാണ്. ഏതെങ്കിലും നെറ്റ്വർക്ക് പ്രാമാണീകരണം തുടങ്ങുന്നതിന് മുമ്പ് ക്ലയന്റ് നിൽക്കുന്നുവെങ്കിൽ, കീ ഫയൽ, അതിന്റെ ഫോർമാറ്റ് അല്ലെങ്കിൽ പാസ്ഫ്രേസ് സംശയിക്കുക. TLS സെഷൻ സ്ഥാപിതമായി പിന്നീട് ഗേറ്റ്വേ ഉപയോക്താവിനെ നിരസിക്കുന്നുവെങ്കിൽ, കീ അതിന്റെ ജോലി ചെയ്തു, പ്രശ്നം അക്കൗണ്ട് കൈമാറ്റത്തിലാണ്.

രണ്ട് രഹസ്യങ്ങളും ഷെൽ ചരിത്രത്തിന് പുറത്ത് സൂക്ഷിക്കുക

കമാന്റ് ലൈൻ ആർഗ്യുമെന്റുകൾ പ്രോസസ് പട്ടിക വഴി മറ്റ് പ്രാദേശിക ഉപയോക്താക്കൾക്ക് വായിക്കാം, അവ പലപ്പോഴും ഷെൽ ചരിത്രത്തിലും സ്ക്രിപ്റ്റുകളിലും പിന്തുണാ ട്രാൻസ്ക്രിപ്റ്റുകളിലും പെടുന്നു. OpenConnect --passwd-on-stdin ഉപയോഗിച്ച് സ്റ്റാൻഡേർഡ് ഇൻപുട്ടിൽ നിന്ന് അക്കൗണ്ട് പാസ്വേഡ് വായിക്കാം, കീ പാസ്ഫ്രേസ് ആർഗ്യുമെന്റിന് പകരം സംവേദനാത്മക പ്രോംപ്റ്റിൽ നിന്നോ ഏജന്റിൽ നിന്നോ വരാം. ഏത് സംവിധാനവും രഹസ്യത്തെ സ്വയം സുരക്ഷിതമാക്കുന്നില്ല, പക്ഷേ രണ്ടും അതിനെ ഏറ്റവും തുറന്ന സ്ഥലങ്ങളിൽ നിന്ന് അകറ്റി നിർത്തുന്നു.

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

രോഗനിർണയ ഔട്ട്പുട്ടാണ് നിശബ്ദ ചോർച്ച. കൂടുതൽ വിശദാംശത്തിൽ ക്ലയന്റ് ലോഗുകൾ അഭ്യർഥനാ ബോഡികളോ ഓപ്ഷൻ മൂല്യങ്ങളോ കാണിക്കാം, പകർത്തിയ ടെർമിനൽ ട്രാൻസ്ക്രിപ്റ്റ് ടിക്കറ്റിൽ ഒട്ടിക്കാൻ എളുപ്പമാണ്, അതിനാൽ പങ്കിടുന്നതിന് മുമ്പ് ഔട്ട്പുട്ട് വായിക്കുക.

മരിച്ച ഡെസ്ക്ടോപ്പ് ബട്ടൺ മറ്റൊരു തകരാറാണ്

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

GUI കണക്ട് ചെയ്യാൻ വിസമ്മതിക്കുമ്പോൾ സർട്ടിഫിക്കറ്റ് പരിശോധന അയച്ചുവിടുന്നതോ ഒരു പരിശോധന ഓഫാക്കുന്നതോ പ്രലോഭനമാണ്. അത് ക്ലയന്റ് സംയോജനത്തിലെ തകരാറിനെ സുരക്ഷാ തകർച്ചയാക്കി മാറ്റുന്നു, ലോഞ്ച് പ്രശ്നം അപൂർവമായി പരിഹരിക്കുന്നു. സർവർ പരിശോധന സ്പർശിക്കാതെ സൂക്ഷിക്കുക, പ്രൊഫൈൽ ഉദ്ദേശിച്ച ഗേറ്റ്വേയിലേക്കാണോ എന്ന് ഉറപ്പാക്കുക, GUI പ്രതീക്ഷിക്കുന്ന ഹെൽപ്പർ യഥാർഥത്തിൽ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടോ എന്ന് പരിശോധിക്കുക.

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