0x അതോ 0s? ipsec.secrets-ലെ PSK ഫോർമാറ്റ് മനസ്സിലാക്കൽ

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

ലക്ഷണം സൈഫറുകളിലേക്കല്ല, എൻകോഡിംഗിലേക്കാണ് വിരൽ ചൂണ്ടുന്നത്

രണ്ട് അറ്റങ്ങളും വ്യത്യസ്ത ബൈറ്റുകൾ സൂക്ഷിക്കുമ്പോൾ, ചർച്ച വിജയിക്കുന്നു, തെളിവ് പിന്നീട് പരാജയപ്പെടുന്നു. അപ്പോൾ ലോഗ് അൽഗോരിതം പൊരുത്തക്കേടിന് പകരം സമഗ്രതയുടെയോ HMAC-ന്റെയോ പരാജയം രേഖപ്പെടുത്തുന്നു, കാരണം ഒരു നിർദ്ദേശം തിരഞ്ഞെടുക്കപ്പെട്ടു, പ്രാമാണീകരണ ഘട്ടം പൊരുത്തപ്പെട്ടില്ല. ആ വരി രഹസ്യത്തിന്റെ രൂപം ഒരിക്കലും പറയുന്നില്ല.

ഘട്ടമാണ് സൂചന. തിരഞ്ഞെടുത്ത നിർദ്ദേശത്തിന് ശേഷം വരുന്ന പരാജയം അർത്ഥമാക്കുന്നത് ഇരുവശവും കീ വസ്തുവൊഴികെ എല്ലാറ്റിലും യോജിച്ചു എന്നാണ്, എന്നാൽ «നിർദ്ദേശമൊന്നും തിരഞ്ഞെടുത്തില്ല» എന്നത് നയത്തിന്റെയോ സൈഫർ സെറ്റുകളുടെയോ കാര്യമാണ്. പാസ്വേഡ് ശരിയായി തോന്നുമ്പോൾ പരാജയപ്പെടുന്ന സമഗ്രതാ പരിശോധന എൻകോഡിംഗ് പൊരുത്തക്കേടിന്റെ ദൃശ്യമായ മുഖമാണ്.

ഒരു രഹസ്യം, ഫയലിന് അത് വായിക്കാനുള്ള മൂന്ന് വഴികൾ

നാല് ബൈറ്റ് മൂല്യത്തിന് key1 ഹെക്സാഡെസിമലും Base64-ഉം ഒരേ ബൈറ്റുകളുടെ രണ്ട് പുനർ-എൻകോഡിംഗുകളാണ്, ആദ്യ അക്ഷരങ്ങൾ മാത്രമാണ് പാഴ്സറിനോട് ഏതാണ് കൈവശമുള്ളതെന്ന് പറയുന്നത്. swanctl ക്രെഡൻഷ്യലുകൾ അതേ സമ്പ്രദായം പിന്തുടരുന്നു, അതിനാൽ രണ്ട് ഇന്റർഫേസുകൾക്കിടയിൽ മാറ്റിയ മൂല്യം അതിന്റെ പ്രിഫിക്സ് കൂടെ സഞ്ചരിച്ചാൽ മാത്രമേ അർത്ഥം നിലനിർത്തൂ.

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

ആ ബ്ലോക്കിലെ രണ്ട് വിശദാംശങ്ങളാണ് ഏറ്റവും സമയമെടുക്കുന്നത്. ഹെക്സാഡെസിമൽ അക്കങ്ങൾ രണ്ട് കേസുകളും സ്വീകരിക്കുന്നു, അതിനാൽ 0x6b657931 ഉം 0x6B657931 ഉം ഒരേ മൂല്യമാണ്, പക്ഷേ ഒറ്റസംഖ്യയിലുള്ള അക്ഷരങ്ങൾ നിരസിക്കപ്പെടാതെ നിശ്ശബ്ദമായി തെറ്റായി വായിക്കുന്നു, ഇത് മുറിക്കലിന് ശേഷമുള്ള ഓരോ ബൈറ്റും നീക്കുന്നു. Base64 പാഡിംഗ് മൂല്യത്തിന്റെ ഭാഗമാണ്, അതിനാൽ അവസാന = ചിഹ്നങ്ങളില്ലാതെ ഒട്ടിച്ച സ്ട്രിംഗ് ഉച്ചത്തിൽ പരാജയപ്പെടുന്നതിന് പകരം വ്യത്യസ്ത ബൈറ്റുകളായി ഡീകോഡ് ചെയ്യുന്നു.

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

Base64 പാഠം എവിടെ നിന്ന് വരുന്നു

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

രണ്ട് ദിശകളും ഓരോന്ന് ഓരോ കമാൻഡാണ്, സംഭരിച്ച മൂല്യം സൃഷ്ടിച്ച കൃത്യമായ പ്രവർത്തനമായി അവ ടിക്കറ്റിൽ സൂക്ഷിക്കുന്നത് ഉചിതമാണ്. ഈ ക്രമത്തിൽ അവ പ്രവർത്തിപ്പിക്കുക:

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

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

ഓരോ സഹപ്രവർത്തകനും യഥാർത്ഥത്തിൽ ഏത് ബൈറ്റുകളാണ് ഉപയോഗിക്കുന്നതെന്ന് സ്ഥിരീകരിക്കുക

പിശക് സ്ട്രിംഗിൽ നിന്ന് കാരണം ഊഹിക്കുന്നതിന് പകരം ആദ്യം ഡീമണിന്റെ കണക്ഷനെക്കുറിച്ചുള്ള കാഴ്ചയും പിന്നീട് പ്രാമാണീകരണ ഫലവും വായിക്കുക. സംഭരിച്ച നീളം താരതമ്യം ചെയ്യുന്നത് വേഗത്തിലുള്ള യുക്തിസഹതാ പരിശോധനയാണ്, കാരണം എൻകോഡ് ചെയ്ത പാഠം അത് പ്രതിനിധീകരിക്കുന്ന ബൈറ്റുകളേക്കാൾ നീളമുള്ളതാണ്. തുടർന്ന് ഏത് ഐഡന്റിറ്റി വരിയാണ് പൊരുത്തപ്പെട്ടതെന്ന് സ്ഥിരീകരിക്കുക, കാരണം തെറ്റായ സഹപ്രവർത്തകന്റെ കീഴിൽ സൂക്ഷിച്ച ശരിയായ രഹസ്യം തെറ്റായത് പോലെ തന്നെ പരാജയപ്പെടുന്നു. വരികളുടെ ക്രമമാണ് അത് തീരുമാനിക്കുന്നത്: ആദ്യ പൊരുത്തം വിജയിക്കുന്നു, അതിനാൽ മുകളിലോട്ട് അടുത്തുള്ള വിശാലമായ %any വരി നിങ്ങൾ ഇപ്പോൾ എഡിറ്റ് ചെയ്ത നിർദ്ദിഷ്ട വരിയെ നിശ്ശബ്ദമായി മാറ്റിസ്ഥാപിക്കുന്നു.

ഫയൽ ശരിയായാൽ വീണ്ടും ആരംഭിക്കുന്നതിന് പകരം വീണ്ടും ലോഡ് ചെയ്യുക. ipsec rereadsecrets IKE ഡീമണിന്റെ പകർപ്പ് പുതുക്കുന്നു, swanctl ക്രമീകരണം സ്വന്തം കമാൻഡിലൂടെ ക്രെഡൻഷ്യലുകൾ ലോഡ് ചെയ്യുന്നു. വീണ്ടും ആരംഭിക്കുന്നത് സ്ഥാപിതമായ ഓരോ അസോസിയേഷനും ഉപേക്ഷിക്കുകയും നിങ്ങൾ ചെയ്യാൻ ശ്രമിച്ച താരതമ്യം നശിപ്പിക്കുകയും ചെയ്യുന്നു.

ഈ പരിശോധനകളിൽ ഒന്നും രഹസ്യം വെളിപ്പെടുത്താൻ ആവശ്യപ്പെടുന്നില്ല. നീളം, ഐഡന്റിറ്റി സെലക്ടർ, വരിയുടെ സ്ഥാനം എന്നിവ ഇത്തരം മിക്ക പരാജയങ്ങളും വിശദീകരിക്കുന്നു, ആർക്കെങ്കിലും ഹെക്സ് ഡമ്പ് ആവശ്യമാകുന്നതിന് മുമ്പ്.

ഫലം മറയ്ക്കാതെ ഫയൽ മാറ്റുക

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

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