ടോക്കണിന് OpenConnect-ന് ഏത് PKCS#11 URI വേണം?

ശരിയായ കീ ഇതിനകം ഉള്ള സ്മാർട്ട് കാർഡിനും അതിൽ ഏത് വസ്തു ഉപയോഗിക്കണം എന്ന് പറയണം. ആ സാഹചര്യത്തിൽ OpenConnect പകർത്തിയ .key ഫയൽ ആഗ്രഹിക്കുന്നില്ല; സർട്ടിഫിക്കറ്റ് പേരിടുന്ന PKCS#11 URI ആണ് അതിന് വേണ്ടത്, സ്വയമേവയുള്ള തിരച്ചിൽ ജോലി പൂർത്തിയാക്കാൻ കഴിയാത്തപ്പോൾ അതിനടുത്തുള്ള സ്വകാര്യ കീയും പേരിടണം. അസ്വസ്ഥതയുള്ള ഭാഗം, വ്യാകരണപരമായി സാധുവായ URI ഒന്നും തെളിയിക്കുന്നില്ല എന്നതാണ്. കാർഡ് തുറക്കാൻ തയ്യാറുള്ള ഒരു വസ്തുവല്ല, ഗേറ്റ്വേ ഇതിനകം വിശ്വസിക്കുന്ന രജിസ്ട്രേഷനെ പേരിടണം അതിന്.

കയറ്റുമതി ചെയ്ത കീയ്ക്ക് പകരം ക്ലയന്റ് എന്താണ് ആഗ്രഹിക്കുന്നത്

-c ഓപ്ഷൻ സാധാരണയായി ഫയൽ പാത്ത് എടുക്കുന്നു, എന്നാൽ മൂല്യം PKCS#11 URI ആയി പാഴ്സ് ചെയ്യുമ്പോൾ, OpenConnect അതിനെ ഡിസ്കിലെ ഫയലല്ല, ടോക്കണിനുള്ളിലെ വസ്തുവിലേക്കുള്ള റഫറൻസായി കണക്കാക്കുന്നു. -k ഓപ്ഷൻ സ്വകാര്യ കീയോട് അതേ രീതിയിൽ പെരുമാറുന്നു. ഒന്നും കയറ്റുമതി ചെയ്യപ്പെടുന്നില്ല, കീ കാർഡ് നൽകുന്ന സംരക്ഷണം ഒരിക്കലും വിടുന്നുമില്ല. ക്ലയന്റിന് നിങ്ങളിൽ നിന്ന് വേണ്ടത് ടോക്കൺ മൊഡ്യൂൾ, സർട്ടിഫിക്കറ്റ് സംഭരണി, ഗേറ്റ്വേ രജിസ്ട്രേഷൻ എന്നിവ യോജിക്കുന്ന ഒരു പേരാണ്.

ഈ അവസാന നിയന്ത്രണത്തിലാണ് മിക്ക ശ്രമങ്ങളും നിൽക്കുന്നത്. URI തികച്ചും നന്നായി രൂപപ്പെട്ടതായിരിക്കാം, എന്നിട്ടും ഗേറ്റ്വേ നിരസിക്കുന്ന സർട്ടിഫിക്കറ്റ് തിരഞ്ഞെടുക്കാം, കാരണം സാധുതയും പ്രസക്തിയും വേറിട്ട ചോദ്യങ്ങളാണ്. ചെയ്യാൻ യോഗ്യമായ പരിശോധന രജിസ്ട്രേഷൻ രേഖയുമായുള്ള താരതമ്യമാണ്, യാദൃച്ഛികമായി തുറക്കുന്ന ആദ്യ വസ്തുവിനെ തിരയലല്ല.

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

സർട്ടിഫിക്കറ്റിന്റെ URI നിങ്ങൾ ഏത് ഐഡന്റിറ്റി അവകാശപ്പെടുന്നു എന്നതിന് ഉത്തരം നൽകുന്നു. പൊതു കീയും വിഷയ വരിയും VPN അഡ്മിനിസ്ട്രേറ്റർ നൽകിയ അക്കൗണ്ട് അല്ലെങ്കിൽ ഉപകരണ പ്രൊഫൈലുമായി ഒത്തുപോകുന്ന സർട്ടിഫിക്കറ്റ് വസ്തുവിനെ അത് ചൂണ്ടിക്കാണിക്കുന്നു. അതേ സർട്ടിഫിക്കറ്റ് സാധാരണയായി അടുത്ത് സൂക്ഷിച്ച സ്വകാര്യ കീ വസ്തുവിനൊപ്പം വരുന്നു, ആ ജോടിയാണ് TLS ഹാൻഡ്ഷേക്കിന് യഥാർത്ഥത്തിൽ വേണ്ടത്.

കീയുടെ URI, OpenConnect-ന് അനുമാനിക്കാൻ കഴിയാത്തപ്പോൾ ഒത്തുപോകുന്ന സ്വകാര്യ വസ്തു എവിടെയാണെന്നതിന് ഉത്തരം നൽകുന്നു. -c മാത്രം സെറ്റ് ചെയ്താൽ, ക്ലയന്റ് സർട്ടിഫിക്കറ്റിന്റെ ഗുണങ്ങളിൽ നിന്ന് കീ-തിരച്ചിൽ നിർമ്മിക്കുന്നു; -k നൽകുന്നത് ഊഹത്തെ വ്യക്തമായ വസ്തു റഫറൻസ് കൊണ്ട് മാറ്റുന്നു. ടോക്കണിന്റെ PIN മൂന്നാമത്തെ, ബന്ധമില്ലാത്ത ഇൻപുട്ടാണ്: അത് പ്രവർത്തനത്തിനായി കാർഡ് തുറക്കുന്നു, ഒരിക്കലും ഒരു വസ്തുവിനെ തിരിച്ചറിയുന്നുമില്ല.

openconnect --protocol=anyconnect \
  -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
  vpn.example.net

ആ ഉദ്ധരിച്ച സ്ട്രിംഗിലുള്ളതെല്ലാം ഡാറ്റയാണ്. അർദ്ധവിരാമങ്ങൾ URI ഗുണങ്ങളെ വേർതിരിക്കുന്നു, ശതമാന-എസ്കേപ്പുകൾ പാഴ്സിംഗ് തകർക്കുന്ന പ്രതീകങ്ങളെ എൻകോഡ് ചെയ്യുന്നു, അതിനാൽ മുഴുവൻ ആർഗ്യുമെന്റും ഷെല്ലിൽ നിന്ന് അക്ഷതമായി കടന്നുപോകണം.

നിങ്ങളുടെ രജിസ്ട്രേഷനുമായി ഒത്തുപോകുന്ന URI കണ്ടെത്തൽ

GnuTLS-നൊപ്പം p11tool വരുന്നു, ഇപ്പോഴത്തെ ഉപയോക്താവിന് p11-kit വഴി യഥാർത്ഥത്തിൽ എത്താൻ കഴിയുന്നത് അത് പട്ടികപ്പെടുത്തുന്നു. p11tool --list-tokens ഉപയോഗിച്ച് തുടങ്ങുക, പിന്നീട് നിങ്ങൾക്ക് പ്രധാനമായ ടോക്കണിലെ സർട്ടിഫിക്കറ്റ് വസ്തുക്കൾ പട്ടികപ്പെടുത്തുക. വസ്തുക്കൾ PIN-ന് ശേഷം മാത്രം കാണുന്നുവെങ്കിൽ --login ചേർക്കുക, ആദ്യം കാണുന്നത് തിരഞ്ഞെടുക്കുന്നതിന് പകരം വിഷയവും ഇഷ്യൂവറും രജിസ്ട്രേഷൻ രേഖയുമായി താരതമ്യം ചെയ്യുക.

ടോക്കൺ ഒട്ടും കാണുന്നില്ലെങ്കിൽ, പ്രശ്നം OpenConnect-ന് താഴെയാണ്: p11-kit-ൽ ആ മിഡിൽവെയറിന് രജിസ്റ്റർ ചെയ്ത മൊഡ്യൂളില്ല, അല്ലെങ്കിൽ മൊഡ്യൂൾ മറ്റൊരു അക്കൗണ്ടിന് രജിസ്റ്റർ ചെയ്തിരിക്കുന്നു. സിസ്റ്റം-വ്യാപക രജിസ്ട്രേഷൻ /etc/pkcs11/modules-ന് കീഴിലാണ്, ഉപയോക്തൃ ഡയറക്ടറിക്ക് സിസ്റ്റം പകർപ്പ് തൊടാതെ അതേ കാര്യം സൂക്ഷിക്കാം. മൊഡ്യൂൾ ഫയലിലെ പ്രൊവൈഡർ പാത്ത് റീഡറിന്റെ സോഫ്റ്റ്വെയർ യഥാർത്ഥത്തിൽ ഇൻസ്റ്റാൾ ചെയ്ത ലൈബ്രറിയിലേക്കാണോ എന്ന് പരിശോധിക്കുക.

പട്ടികയിൽ നിന്ന് URI പകർത്തുമ്പോൾ അതിന്റെ ചുറ്റുമുള്ള ഉദ്ധരണികൾ സൂക്ഷിക്കുക. ഉദ്ധരണിയില്ലാത്ത അർദ്ധവിരാമങ്ങൾ ആർഗ്യുമെന്റ് ആദ്യ ഗുണത്തിൽ മുറിക്കുന്നു, ക്ലയന്റ് പിന്നീട് കണ്ടെത്താനാകാത്ത ഒരു വസ്തുവിനെക്കുറിച്ച് റിപ്പോർട്ട് ചെയ്യുന്നു.

സ്വയമേവയുള്ള കീ-തിരച്ചിൽ വിട്ടുകൊടുക്കുമ്പോൾ

OpenConnect-ന് സർട്ടിഫിക്കറ്റിന്റെ URI-ൽ നിന്ന് കീ-തിരച്ചിൽ ഉരുത്തിരിയ്ക്കാം, പക്ഷേ അത് നടത്തുന്ന കൃത്യമായ പൊരുത്തം പതിപ്പിനെ ആശ്രയിച്ചിരിക്കുന്നു, വസ്തു തരവും ലേബലും കൈകാര്യം ചെയ്യുന്ന രീതി കാലക്രമേണ മാറിയിട്ടുണ്ട്. പ്രവർത്തിക്കുന്നതുവരെ URI ചെറുതാക്കൂ എന്ന ഉപദേശം പഴയ ഒരു വഴിവളയ്ക്കലിനെ വിവരിക്കുന്നു, ഒരു ആവശ്യകതയല്ല. ഉരുത്തിരിഞ്ഞ തിരച്ചിൽ പരാജയപ്പെട്ടാൽ, സർട്ടിഫിക്കറ്റിന്റെ URI-നെ കൂടുതൽ അവ്യക്തമാക്കുന്നതിന് പകരം -k ഉപയോഗിച്ച് കീയ്ക്ക് വ്യക്തമായി പേരിടുക.

ക്ലയന്റിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുൻപ് കീ നിലവിലുണ്ടെന്നും p11tool --list-keys ഉപയോഗിച്ച് കാണാമെന്നും സ്ഥിരീകരിക്കുക. പിന്നീട് വസ്തു ഒപ്പിടലിനോ ഡീക്രിപ്ഷനോ ഉപയോഗയോഗ്യമെന്ന് അടയാളപ്പെടുത്തിയിട്ടുണ്ടോ എന്ന് പരിശോധിക്കുക, കാരണം തെറ്റായ ഗുണങ്ങളോടെ സൃഷ്ടിച്ച കീ, URI എത്ര ശരിയായാലും ഹാൻഡ്ഷേക്ക് പൂർത്തിയാക്കാൻ കഴിയില്ല. OpenVPN പ്രൊഫൈലിലെ സീരിയലൈസ് ചെയ്ത pkcs11-id മൂല്യം OpenConnect ഓപ്ഷനിലേക്ക് മാറ്റരുത്; ഒരേ കാർഡിനോട് സംസാരിക്കുമ്പോഴും രണ്ട് ക്ലയന്റുകൾ വ്യത്യസ്ത ഐഡന്റിഫയർ ഫോർമാറ്റുകൾ ഉപയോഗിക്കുന്നു.

URI പരിഹരിക്കപ്പെടുകയും PIN സ്വീകരിക്കപ്പെടുകയും ചെയ്തിട്ടും പ്രാമാണീകരണം പരാജയപ്പെടുന്നുവെങ്കിൽ, URI ട്യൂൺ ചെയ്യുന്നത് നിർത്തുക. ഗേറ്റ്വേയുടെ സ്വന്തം പിശക് വായിക്കുക, കാരണം അടുത്ത പരാജയം ടോക്കണിന് മുകളിലാണ്.

URI പ്രശ്നങ്ങളായി മാത്രം തോന്നുന്ന പരാജയങ്ങൾ

മറ്റൊരു പ്രോട്ടോക്കോൾ സംസാരിക്കുന്ന ഗേറ്റ്വേ, നിങ്ങളുടെ URI ശരിയായാലും തെറ്റായാലും ഒരേപോലെ പരാജയപ്പെടും. OpenConnect പഴയ vpnc ക്ലയന്റിനെ ഒരു കാരണത്താൽ മാറ്റി, കാർഡ് പിന്തുണ അനുയോജ്യമല്ലാത്ത ഗേറ്റ്വേ പ്രോട്ടോക്കോളിനെ അനുയോജ്യമാക്കുന്നില്ല. വസ്തുവിന്റെ ഗുണങ്ങളിൽ മറ്റൊരു മണിക്കൂർ ചെലവഴിക്കുന്നതിന് മുൻപ് സെർവറിന്റെ പ്രതീക്ഷിത പ്രോട്ടോക്കോളും പ്രാമാണീകരണ ക്രമവും സ്ഥിരീകരിക്കുക.

സെർവറിന്റെ ഐഡന്റിറ്റി സാധൂകരണവും വേറിട്ട പാളിയാണ്. ക്ലയന്റ് ഗേറ്റ്വേ സർട്ടിഫിക്കറ്റ് തന്റെ വിശ്വാസ സംഭരണിയുമായി പരിശോധിക്കുന്നു, ആ പരിശോധന കാർഡ് തന്റെ ഭാഗം ഇതിനകം ചെയ്തതിന് ശേഷമാണ് നടക്കുന്നത്. റീഡർ അനുമതികളും നിർത്തിയ pcscd സേവനവും ഒരേ ബാഹ്യ ലക്ഷണം സൃഷ്ടിക്കുന്നു, വായിക്കാനാകാത്ത ടോക്കൺ, പക്ഷേ പരിഹാരം വളരെ ലളിതമാണ്.

വസ്തുവിൽ നിന്ന് പുറത്തേക്ക് പ്രവർത്തിക്കുക: p11tool ടോക്കൺ കാണുന്നുണ്ടോ, സർട്ടിഫിക്കറ്റും കീയും കാണുന്നുണ്ടോ, OpenConnect URI സ്വീകരിക്കുന്നുണ്ടോ, എന്നിട്ട് മാത്രം ഗേറ്റ്വേ ഐഡന്റിറ്റി സ്വീകരിക്കുന്നുണ്ടോ എന്ന് ചോദിക്കുക. ഓരോ ഘട്ടത്തിനും സ്വന്തം പിശക് സന്ദേശമുണ്ട്, ഓരോന്നും അടുത്തതിനെക്കാൾ പരിശോധിക്കാൻ വിലകുറഞ്ഞതാണ്.