OpenVPN പ്രൊഫൈലിൽ നിന്ന് key-method നീക്കിയാൽ ഒന്നും മാറുന്നില്ല

വർഷങ്ങളായി പ്രവർത്തിച്ച ഒരു പ്രൊഫൈൽ പെട്ടെന്ന് തുടങ്ങാൻ വിസമ്മതിക്കുന്നു, സന്ദേശം ആരും ചേർത്തതായി ഓർക്കാത്ത ഒരു നിർദ്ദേശത്തിന്റെ പേര് പറയുന്നു: key-method. അടുത്ത തിരയൽ ഫലം അനുയോജ്യതയ്ക്കായി key-method 2 ചേർക്കാൻ നിർദ്ദേശിക്കുന്നു, അത് മറ്റൊരു കാലഘട്ടത്തിലെ ഉപദേശമാണ്. വരി നിരസിച്ച പാഴ്സർ നിലവിലുള്ളതാണ്, അതിൽ അത്തരം ഓപ്ഷൻ തന്നെയില്ല. വരി നീക്കുന്നത് തുടക്കം ശരിയാക്കുന്നു, രണ്ട് കക്ഷികൾ സെഷൻ എങ്ങനെ സംരക്ഷിക്കുന്നു എന്നതിൽ ഒന്നും മാറ്റുന്നുമില്ല.

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

രോഗലക്ഷണം പാഴ്സ് പിശകാണ്, ഹാൻഡ്ഷേക്ക് പരാജയമല്ല

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

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

സന്ദേശം നിർദ്ദേശത്തിന്റെ പേര് പറഞ്ഞാൽ, രോഗനിർണയം കഴിഞ്ഞു: ഈ ബിൽഡ് സ്വീകരിക്കാത്ത എന്തോ ഫയലിലുണ്ട്. സന്ദേശം പകരം ഒരു ഫയൽ പാത്ത് പറഞ്ഞാൽ, പ്രശ്നം കാണാത്ത include അല്ലെങ്കിൽ കീയാണ്, അത് അതേ തുടക്ക ഘട്ടത്തിന്റെ മറ്റൊരു ഭാഗമാണ്.

നിങ്ങൾ അനുമാനിക്കരുതാത്തത് എന്തെന്നാൽ ക്ലയന്റിനോ സെർവറിനോ പഴയ പ്രോട്ടോക്കോൾ മോഡ് ആവശ്യമാണ് എന്നതാണ്. പാഴ്സ് പരാജയം നിങ്ങളുടെ ഫയലും ബൈനറിയും തമ്മിലുള്ള പദസമ്പത്ത് പ്രശ്നമാണ്, ഈ സാഹചര്യത്തിൽ ബൈനറി തന്റെ പദസമ്പത്തിൽ നിന്ന് ഒരു വാക്ക് മാത്രം ഒഴിവാക്കി.

നിർദ്ദേശവും ട്രാൻസ്മിഷൻ ഫോർമാറ്റും രണ്ട് വ്യത്യസ്ത കാര്യങ്ങളാണ്

പഴയ key-method ഓപ്ഷൻ TLS കീ-കൈമാറ്റം എങ്ങനെ ഫ്രെയിം ചെയ്യണം എന്ന് തിരഞ്ഞെടുത്തിരുന്നു, ആധുനിക കൈമാറ്റം ആ ഓപ്ഷൻ ഒരിക്കൽ ആവശ്യപ്പെട്ടിരുന്ന ബഹു-പാക്കറ്റ് രീതിയാണ്. ഓപ്ഷൻ പോയി കാരണം അത് ഇനി ഒന്നും തിരഞ്ഞെടുത്തിരുന്നില്ല; അത് പേരിട്ട ഫോർമാറ്റ് ഏകമായി. അതിനാൽ വരി നീക്കുന്നത് സെഷനെ മുമ്പത്തേതിന് സമാനമായ ഫ്രെയിമിംഗിൽ തന്നെ നിലനിർത്തുന്നു. വാചക തിരുത്തലിന് അത് ഏത് ദിശയിലും മാറ്റാൻ കഴിയില്ല.

അതുകൊണ്ടാണ് “രീതി 2 പുനഃസ്ഥാപിക്കാൻ” പഴയ ബൈനറി തിരികെ കൊണ്ടുവരുന്നത് തെറ്റായ അറ്റകുറ്റപ്പണിയാകുന്നത്. പഴയ ഡിഫോൾട്ടുകളുള്ള പഴയ പാഴ്സർ അല്ലാതെ അത് ഒന്നും പുനഃസ്ഥാപിക്കുന്നില്ല, അതിന് ശേഷം വന്ന തിരുത്തലുകൾ നിങ്ങൾക്ക് നഷ്ടപ്പെടുത്തുന്നു. സർട്ടിഫിക്കറ്റ് പരിശോധനയോ സൈഫർ പട്ടികയോ ദുർബലമാക്കുന്നതിനും ഇതേ യുക്തി ബാധകമാണ്, കണക്ഷൻ തിരികെ വരുമെന്ന പ്രതീക്ഷയിൽ.

ഉപയോഗപ്രദമായ പരിശോധന പതിപ്പും പാഴ്സ് ചെയ്ത കോൺഫിഗറേഷനുമാണ്, ഫയലിൽ പദത്തിന്റെ സാന്നിധ്യമല്ല:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

എന്ത് നീക്കണം, ഏത് ഫയലിൽ നിന്ന്

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

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

തുടർന്ന് ഉദ്ദേശിച്ച ഇൻസ്റ്റൻസ് തുടങ്ങി അതിന്റെ തുടക്ക ഔട്ട്‌പുട്ട് വായിക്കുക. ശ്രോതാവ് ഉള്ളപ്പോഴുള്ള വൃത്തിയുള്ള തുടക്കമാണ് ഈ ഘട്ടം പൂർത്തിയായതിന്റെ സ്ഥിരീകരണം; അതിന് ശേഷമുള്ള ക്ലയന്റ് പരിശോധന മറ്റൊരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു.

നിരസിക്കപ്പെട്ട പ്രൊഫൈലും നിരസിക്കപ്പെട്ട ക്ലയന്റും ഒരുപോലെ കാണപ്പെടുന്നു

രണ്ട് പരാജയങ്ങൾ സമാനമായ പിന്തുണ ത്രെഡുകൾ സൃഷ്ടിക്കുന്നു, വ്യത്യസ്തമായ തെളിവുകൾ വേണം. സ്വന്തം കോൺഫിഗറേഷൻ നിരസിക്കുന്ന സെർവർ ഒരിക്കലും തുടങ്ങുന്നില്ല, അതിനാൽ ഒരു ക്ലയന്റിനും അതിലേക്ക് ബന്ധിപ്പിക്കാനാകില്ല. നന്നായി തുടങ്ങി ഒരു ക്ലയന്റിനെ നിരസിക്കുന്ന സെർവർ പ്രവർത്തിക്കുന്നു, അതിന്റെ ലോഗിൽ കാരണമുണ്ട്: സർട്ടിഫിക്കറ്റ് പ്രശ്നം, ക്ലയന്റ് സ്വീകരിക്കാത്ത തള്ളിയ ഓപ്ഷൻ, സൈഫർ പൊരുത്തക്കേട്.

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

ആ വരി ഒരിക്കലും ഉത്തരം നൽകാത്ത അനുയോജ്യതാ ചോദ്യങ്ങൾ

ഈ നിർദ്ദേശത്തോടെ കറങ്ങുന്ന പ്രൊഫൈലുകൾ സാധാരണയായി ഒരു നിർദ്ദിഷ്ട പ്ലാറ്റ്ഫോമിനെക്കുറിച്ചുള്ള ഒരു കഥ വഹിക്കുന്നു, ആ കഥ സാങ്കേതിക കാരണത്തേക്കാൾ കൂടുതൽ കാലം നിലനിൽക്കുന്നു. മൊബൈൽ അല്ലെങ്കിൽ ഡെസ്ക്ടോപ്പ് ക്ലയന്റിന് ഇപ്പോഴും പൂർണ്ണമായി പിന്തുണയ്ക്കുന്ന പ്രൊഫൈൽ ആവശ്യമാണ്: വിശ്വസനീയമായ സർട്ടിഫിക്കറ്റ് ശൃംഖല, ഇരു അറ്റങ്ങളും സ്വീകരിക്കുന്ന ഡാറ്റ സൈഫർ, ഇരു അറ്റങ്ങളും നടപ്പാക്കുന്ന നിയന്ത്രണ-ചാനൽ മോഡ്, ക്ലയന്റിന്റെ ബിൽഡ് നിരസിക്കാത്ത നിർദ്ദേശങ്ങളുടെ അഭാവം. ഇവയൊന്നും പഴയ key-method വരിയുടെ സാന്നിധ്യമോ അഭാവമോ കൊണ്ട് തീരുമാനിക്കപ്പെടുന്നില്ല.

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

നിങ്ങൾ എന്ത് നീക്കി, എന്തുകൊണ്ട് എന്നതിന്റെ ഒരു ചെറിയ രേഖ സൂക്ഷിക്കുക: ഓപ്ഷൻ, അത് നിരസിച്ച പതിപ്പ്, പിശക് കാണിച്ച കമാൻഡ്. പ്രൊഫൈൽ അനന്തരാവകാശമായി ലഭിക്കുന്ന അടുത്ത വ്യക്തിക്ക് കൃത്യമായി ആ മൂന്ന് വസ്തുതകൾ വേണ്ടിവരും, അവ ഇപ്പോൾ എഴുതുന്നത് പിന്നീട് പുനർനിർമ്മിക്കുന്നതിനേക്കാൾ വിലകുറഞ്ഞതാണ്.