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

പിശക് ഗേറ്റ്വേയ്ക്ക് മുമ്പേ വരുന്നു

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

അതിനാൽ ആദ്യ ചോദ്യം ഏത് അക്ഷരങ്ങളാണ് അനുവദനീയം എന്നതല്ല, ശ്രമം എവിടെ നിന്നു എന്നതാണ്. ഒരിക്കലും കണക്ഷൻ തുറക്കാത്ത ക്ലയന്റിനെ ആരും നിരസിച്ചിട്ടില്ല. നിരീക്ഷിച്ച ഘട്ടം എഴുതി വയ്ക്കുക, കാരണം തുടർന്നുള്ള ഓരോ ഘട്ടവും ആ വർഗ്ഗീകരണത്തെ ആശ്രയിച്ചിരിക്കുന്നു.

ഈ വ്യത്യാസം അത് ആര് പരിഹരിക്കുന്നു എന്നതും മാറ്റുന്നു. കണ്ടെയ്നർ പ്രശ്നം ഉപകരണത്തിന്റെയും അതിന്റെ ഉടമയുടെയും ഭാഗമാണ്, അതേസമയം അക്കൗണ്ട് നിരസിക്കൽ പ്രാമാണീകരണ ബാക്കെൻഡ് നടത്തുന്നവരുടേതാണ്.

അക്ഷരങ്ങളല്ല, കണ്ടെയ്നറുകൾ താരതമ്യം ചെയ്യുക

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

Where the value stopsWhat you seeWhat you checkWho owns the fix
GUI field or managed profileA validation message before any connection opensThe selected authentication mode and whether the field holds the secret or the usernameThe device owner or the profile author
Keychain or secret agentA prompt that keeps reappearing, or an agent errorWhether the agent is unlocked and holds an entry for this profileThe user who owns the keychain
Two-line credential fileA prompt for a password that was already suppliedLine count, line order and whether a trailing newline is presentWhoever generated the file
Shell argument or environmentWorks interactively but fails in automationWhether the shell expanded, trimmed or logged the valueWhoever wrote the automation

Community OpenVPN 2.6 ക്ലയന്റ് ഓപ്ഷനുകൾ auth-user-pass-നുള്ള ആ രണ്ട് വരി ഫയൽ വിവരിക്കുന്നു, പാസ്വേഡ് വരി ഇല്ലാത്തപ്പോഴുള്ള പെരുമാറ്റം ഉൾപ്പെടെ: അപ്പോൾ ക്ലയന്റ് ചോദിക്കുന്നു. ആ ഒരു വിശദാംശം "ഞാൻ ഇതിനകം നൽകിയ പാസ്വേഡ് ഇത് എന്തിന് ചോദിക്കുന്നു" എന്ന റിപ്പോർട്ടുകളുടെ ഒരു വിഭാഗത്തെ വിശദീകരിക്കുന്നു. ശൂന്യമായ രണ്ടാം വരി നിരുപദ്രവകരമായ ഫോർമാറ്റിംഗ് തിരഞ്ഞെടുപ്പല്ല, അർത്ഥവത്തായ അവസ്ഥയാണ് എന്നും അത് കാണിക്കുന്നു.

ഉദ്ധരണി മറ്റൊരു പാളിയാണ്: സാധാരണ ക്രെഡൻഷ്യൽ ഫയലിലെ ഉദ്ധരണികൾ ഡാറ്റയായി സംഭരിക്കപ്പെടുന്നു, എന്നാൽ പ്രോഗ്രാം എന്തെങ്കിലും കാണുന്നതിന് മുമ്പ് ഷെൽ അവ നീക്കം ചെയ്യുന്നു. ഒരേ അക്ഷരം ഒരിടത്ത് നിരുപദ്രവകരവും മറ്റൊരിടത്ത് ഘടനാപരവുമാണ്. നിങ്ങളുടെ ക്ലയന്റ് ഏത് കണ്ടെയ്നർ ഉപയോഗിച്ചു എന്ന് പട്ടിക പറയാൻ കഴിയില്ല, അതിനാൽ ഒരു വരി തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് ക്ലയന്റിന്റെ സ്വന്തം കോൺഫിഗറേഷൻ വായിക്കുക.

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

ഷെൽ കേടുപാടില്ലാതെ ക്രെഡൻഷ്യൽ ഫയൽ നിർമ്മിക്കുക

ഏറ്റവും സുരക്ഷിതമായ പ്രാദേശിക വഴി രഹസ്യത്തെ ഷെൽ ചരിത്രത്തിനും പ്രോസസ് ആർഗ്യുമെന്റ് പട്ടികയ്ക്കും പുറത്ത് നിർത്തുന്നു. രണ്ട് ഫീൽഡുകളും സംവേദനാത്മകമായി വായിച്ച ശേഷം ക്ലയന്റ് പ്രതീക്ഷിക്കുന്ന രണ്ട് വരികൾ എഴുതുക. ബാക്കിയെല്ലാം പരിശോധിക്കാൻ എളുപ്പമുള്ള ഒരു കോൺഫിഗറേഷൻ ഫയലിൽ നിൽക്കാം.

read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/creds

ആദ്യ രണ്ട് കമാൻഡുകൾ ഉപയോക്തൃനാമവും തുടർന്ന് പാസ്വേഡും പ്രതിധ്വനിക്കാതെ വായിക്കുന്നു, മൂന്നാമത്തേത് രണ്ട് വരികളും എഴുതുന്നു, നാലാമത്തേത് ഫയൽ അനുമതികൾ പരിമിതപ്പെടുത്തുന്നു, അവസാനത്തേത് ആ ഫയലുമായി ക്ലയന്റ് ആരംഭിക്കുന്നു. read -r ബാക്ക്സ്ലാഷുകൾ സംരക്ഷിക്കുന്നു എന്നത് ശ്രദ്ധിക്കുക, അത് വിട്ടുപോയാൽ പ്രവർത്തിച്ചിരുന്ന ഒരു പാസ്വേഡ് പരാജയപ്പെടുന്ന തരത്തിലുള്ള വിശദാംശമാണിത്.

ഉദ്ധരിക്കാത്ത ഒരു വേരിയബിളോ ഷെൽ വിപുലീകരണങ്ങൾ നിറഞ്ഞ here-document ഉപയോഗിച്ചോ ഫയൽ നിർമ്മിക്കരുത്. രണ്ടും അക്ഷരങ്ങളെ ഫയലിൽ എത്തുന്നതിന് മുമ്പ് രൂപാന്തരപ്പെടുത്താം, തത്ഫലമായ പരാജയം VPN നിരസിക്കൽ പോലെ തോന്നും, കാരണം ഡിസ്കിലെ പാസ്വേഡ് നിങ്ങൾക്ക് അറിയാവുന്നതിൽ നിന്ന് യഥാർത്ഥത്തിൽ വ്യത്യസ്തമാണ്. സംശയമുണ്ടെങ്കിൽ രഹസ്യം അച്ചടിക്കാതെ ഫയലിന്റെ ബൈറ്റ് നീളം പ്രതീക്ഷിത മൂല്യവുമായി താരതമ്യം ചെയ്യുക. ഒന്നോ രണ്ടോ ബൈറ്റ് വ്യത്യാസം ഉദ്ധരണി അപകടത്തിന്റെ ഒപ്പമാണ്.

ആദ്യ പിശകിൽ നിന്ന് ഘട്ടം വായിക്കുക

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

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

അംഗീകൃത മൂല്യം അക്ഷരങ്ങളിലേക്കും അക്കങ്ങളിലേക്കും ചുരുക്കുന്നതിന് പകരം ശരിയായ സംവിധാനത്തിലൂടെ പുനഃസ്ഥാപിക്കുക. പാസ്വേഡ് നയം ഓപ്പറേറ്ററുടേതാണ്, അതിനെ നിശ്ശബ്ദമായി തോൽപ്പിക്കുന്ന ഒരു പരിഹാരം പരിഹാരമല്ല. അത് അടുത്ത വ്യക്തിയിൽ നിന്ന് യഥാർത്ഥ വൈകല്യം മറയ്ക്കുകയും ചെയ്യുന്നു, അയാൾ ദുർബലമായ പാസ്വേഡുമായി അതേ പിശക് നേരിടും.

അനുബന്ധ ലേഖനങ്ങൾ