AES-256-GCM കണ്ടെത്തിയില്ല: ക്ലയന്റിന്റെ കഴിവോ ചർച്ചയോ?

മറ്റൊരിടത്ത് പ്രവർത്തിക്കുന്ന OpenVPN പ്രൊഫൈൽ AES-256-GCM കണ്ടെത്തിയില്ലെന്നോ കക്ഷികൾക്ക് പൊതു സൈഫർ ഇല്ലെന്നോ റിപ്പോർട്ട് ചെയ്യുമ്പോൾ, ആദ്യ പ്രവണത പ്രൊഫൈൽ തിരുത്തുകയാണ്. ഈ രണ്ട് സന്ദേശങ്ങളും വ്യത്യസ്ത പരാജയങ്ങളെ വിവരിക്കുന്നു. ഒന്ന് പറയുന്നത് പ്രാദേശിക പ്രോഗ്രാമിൽ അത്തരം അൽഗോരിതം ഇല്ലെന്നാണ്; മറ്റൊന്ന് പറയുന്നത് ഇരുവശത്തും അൽഗോരിതങ്ങളുണ്ട് എന്നാൽ പൊതുവായ തിരഞ്ഞെടുപ്പില്ല എന്നാണ്. ഏതാണ് നിങ്ങൾക്കുള്ളതെന്ന് അറിയുന്നതുവരെ പ്രൊഫൈൽ തിരുത്തൽ ഒന്നിനെയും പരിഹരിക്കുന്നില്ല.

കൃത്യമായ പിശക് പാഠവും അത് സൃഷ്ടിച്ച പ്രോഗ്രാമും വായിക്കുക.

ഏത് പിശകാണെന്ന് തീരുമാനിക്കുക

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

വ്യത്യാസം പ്രധാനമാണ് കാരണം ഒന്ന് സോഫ്റ്റ്വെയർ പതിപ്പിന്റെ പ്രശ്നവും മറ്റൊന്ന് കോൺഫിഗറേഷന്റെ പ്രശ്നവുമാണ്. ആദ്യത്തേത് പതിപ്പ് നമ്പർ കൊണ്ട് തീരുമാനിക്കുന്നു. രണ്ടാമത്തേത് രണ്ട് പട്ടികകൾ താരതമ്യം ചെയ്ത് തീരുമാനിക്കുന്നു.

പ്രാദേശിക കഴിവിലെ വിടവ്

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

openvpn --version
openvpn --show-ciphers | grep -i gcm
openvpn --show-tls | head -5

ആ പട്ടികയിൽ AES-256-GCM ഇല്ലെങ്കിൽ ഏതെങ്കിലും പ്രൊഫൈൽ വരി അത് ചേർക്കില്ല. പരിഹാരം പുതിയ ക്ലയന്റോ മറ്റൊരു ബിൽഡോ ആണ്, പഴയ കക്ഷിയുടെ പരിധികൾ വേറിട്ട രൂപകൽപ്പന ചോദ്യമായി മാറുന്നു.

OpenVPN 3 അടിസ്ഥാനമാക്കിയ ക്ലയന്റുകളിൽ എഞ്ചിനും സ്വീകരിക്കുന്ന നിർദ്ദേശങ്ങളും കമ്മ്യൂണിറ്റി 2.x വരിയിൽ നിന്ന് വ്യത്യസ്തമാണ്, അതിനാൽ അതേ പ്രൊഫൈൽ പാഠം സൈഫർ പട്ടികയുമായി ബന്ധമില്ലാത്ത കാരണങ്ങളാൽ പരാജയപ്പെടാം.

ചർച്ചയിലെ വിടവ്

ഇരു കക്ഷികളും അൽഗോരിതം ലിസ്റ്റ് ചെയ്യുമ്പോൾ, ഏത് പട്ടിക ഏത് വശം നൽകുന്നു എന്നതാണ് ശേഷിക്കുന്ന ചോദ്യം. കമ്മ്യൂണിറ്റി OpenVPN ചർച്ചാ നിർദ്ദേശത്തിന്റെ പേര് മാറ്റി: 2.4-ലെ ncp-ciphers 2.5-ൽ data-ciphers ആയി, 2.6-ൽ പഴയ cipher വരി പ്രധാനമായും പൊരുത്തത്തിനും പിൻവാങ്ങലിനും സേവിക്കുന്നു, ചർച്ച ചെയ്ത ഗണത്തെ നിർവചിക്കാനല്ല.

അതിനാൽ പഴയ cipher വരി മാത്രം മാറ്റിയാൽ ചർച്ചാ പട്ടിക തൊടാതെ നിൽക്കാം. പഴയ വരി പിൻവാങ്ങലിന് ഇപ്പോഴും പ്രധാനമാണ്, അത് വേറിട്ട ജോലിയാണ്. രണ്ടും കൂട്ടിക്കലർത്തിയാൽ കാണാവുന്നതൊന്നും മാറ്റാത്ത തിരുത്തലുകളാകും.

openvpn --version | head -2
grep -n -E '^(data-ciphers|ncp-ciphers|cipher|tls-cipher)' server.conf client.ovpn

ഇരു അറ്റങ്ങളിലെയും പട്ടികകളും സെർവറിന്റെ നിരസന സന്ദേശവും താരതമ്യം ചെയ്യുക. വിഭജനം ശൂന്യമാണെങ്കിൽ, മറ്റൊരു പതിപ്പിനായി എഴുതിയ ലേഖനത്തിൽ നിന്ന് മൂല്യം പകർത്തുന്നതിന് പകരം പട്ടികകൾ ബോധപൂർവം ഒരുമിപ്പിക്കുക. വളരെ വിശാലമായ പട്ടിക ഓരോ കണക്ഷനെയും നിശബ്ദമായി ദുർബലമാക്കുന്നു. വളരെ ഇടുങ്ങിയ പട്ടിക നിങ്ങൾ നിലനിർത്താൻ ആഗ്രഹിച്ച കക്ഷിയെ ഒഴിവാക്കുന്നു.

പൊരുത്തം വ്യക്തമായി നിലനിർത്തുക

ഒരു പഴയ കക്ഷിക്കുള്ള പിൻവാങ്ങൽ ചെലവുള്ള തീരുമാനമാണ്: ഒരു ഉപകരണത്തിന് കണക്ട് ചെയ്യാൻ മുഴുവൻ വിന്യാസവും ദുർബലമായ ഓപ്ഷൻ സ്വീകരിക്കുന്നു. അത് അങ്ങനെ എഴുതി സൂക്ഷിക്കുക, അത് ആവശ്യമുള്ള കക്ഷിയിൽ മാത്രം പരിമിതപ്പെടുത്തുക.

രണ്ട് വ്യവസ്ഥകൾ ഫലം തീരുമാനിക്കുന്നു. പിശക് പ്രാദേശികമാണെങ്കിൽ ബിൽഡ് മാറ്റുക. പിശക് ചർച്ചയിലാണെങ്കിൽ ഇരു അറ്റത്തും പട്ടികകൾ ഒരുമിപ്പിച്ച് ഏത് പതിപ്പുകൾ പിന്തുണയ്ക്കുന്നു എന്ന് എഴുതുക.

ശേഷം പതിപ്പിന്റെയും കഴിവിന്റെയും ഔട്ട്പുട്ട് അറ്റാച്ച് ചെയ്ത് കൃത്യമായ പിശക് റിപ്പോർട്ട് ചെയ്യുക. ഈ ജോടി കാണാത്ത അൽഗോരിതത്തെ അഭിപ്രായവ്യത്യാസത്തിൽ നിന്ന് വേർതിരിക്കുന്നു, അടുത്ത ഊഹാപോഹ തിരുത്തൽ റൗണ്ട് തുടങ്ങുന്നതിന് മുൻപ് നിർത്തുന്നു.