Ubuntu അപ്‌ഗ്രേഡിന് ശേഷം OpenVPN കണക്ട് ചെയ്യുന്നത് എന്തുകൊണ്ട് നിർത്തി?

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

ഏത് പാളി പരാജയപ്പെട്ടു: ഹാൻഡ്‌ഷേക്ക്, സൈഫർ, പാക്കേജ് അല്ലെങ്കിൽ ലൈബ്രറി

പ്രൊഫൈലിൽ സ്പർശിക്കുന്നതിന് മുമ്പ് ക്ലയന്റ് ലോഗ് വായിക്കുക. ഔട്ട്പുട്ടിലെ ആദ്യത്തെ പിശക് പാളിയെ തിരിച്ചറിയുന്നതാണ്; അതിന് ശേഷം അച്ചടിക്കുന്നതെല്ലാം സാധാരണയായി ആ ആദ്യ പരാജയത്തിന്റെ ഫലമാണ്. ക്ലയന്റ് തുടങ്ങുന്നേയില്ലെങ്കിൽ, VPN ലോഗ് തുറക്കാനുള്ള തെറ്റായ ഫയലാണ്.

സർട്ടിഫിക്കറ്റുകളെക്കുറിച്ചും ഒപ്പുകളെക്കുറിച്ചുമുള്ള പരാതികൾ, അല്ലെങ്കിൽ കീയുടെ നീളത്തെക്കുറിച്ചുള്ള സന്ദേശം, നിയന്ത്രണ ചാനലിൽ നിന്നും അതിനെ നിയന്ത്രിക്കുന്ന ലൈബ്രറി നയത്തിൽ നിന്നും വരുന്നു. എന്നാൽ DEPRECATED OPTION എന്ന് തുടങ്ങുന്ന മുന്നറിയിപ്പ് ഡാറ്റാ ചാനൽ ചർച്ചയിൽ പെടുന്നു.

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

ഹാൻഡ്‌ഷേക്ക് പരാജയപ്പെടുമ്പോൾ TLS നയം സർട്ടിഫിക്കറ്റ് നിരസിക്കുന്നു

Ubuntu 22.04 സിസ്റ്റത്തെ OpenSSL 3-ലേക്ക് മാറ്റി, ആ ശാഖയിലെ ഡിഫോൾട്ട് സുരക്ഷാ നിലവാരം സർട്ടിഫിക്കറ്റ് ഒപ്പുകളിലും കീ വലുപ്പങ്ങളിലും 20.04-നേക്കാൾ കർശനമാണ്. പഴയ ഡൈജസ്റ്റ് ഉപയോഗിച്ച് ഒപ്പിട്ട CA സർട്ടിഫിക്കറ്റോ നിലവിലെ പരിധിക്ക് താഴെയുള്ള കീയോ ഇപ്പോൾ ഹാൻഡ്‌ഷേക്കിനിടയിൽ പരാജയപ്പെടുന്നു. ഇതുവരെ ഒന്നും പ്രാമാണീകരിക്കാത്തതിനാൽ, പിശക് തെറ്റായ പാസ്‌വേഡ് അല്ലെങ്കിൽ മരിച്ച സെർവർ പോലെ വായിക്കപ്പെടുന്നു.

ഇടുങ്ങിയ പരിഹാരം ഈ കണക്ഷനോട് മാത്രം ഒരു സൈഫർ സ്ട്രിംഗ് ചേർക്കുന്നു. ഡെസ്ക്ടോപ്പ് എഡിറ്ററിൽ പ്രൊഫൈൽ തുറന്ന്, വിപുലമായ ക്രമീകരണങ്ങളിലേക്ക് പോയി, DEFAULT:@SECLEVEL=0 TLS സൈഫർ ഫീൽഡിൽ ഇടുക. NetworkManager കീ ഫയൽ [vpn] എന്നതിന് കീഴിൽ അതേ മൂല്യം എടുക്കുന്നു:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

NetworkManager വീണ്ടും ആരംഭിച്ച് വീണ്ടും കണക്ട് ചെയ്യുക, കാരണം ഡീമൺ പാഴ്സ് ചെയ്ത പ്രൊഫൈലുകൾ കാഷെ ചെയ്യുന്നു; അല്ലെങ്കിൽ ഇതിനകം കൈവശമുള്ള പകർപ്പ് തുടർന്നും ഉപയോഗിക്കും. വരി സൂക്ഷിക്കുന്നതിന് മുമ്പ് അത് എന്ത് ചെയ്യുന്നുവെന്ന് അറിയുക: ആ ക്രമീകരണം സൈഫറിന്റെ പേരല്ല, മറിച്ച് നിരവധി സർട്ടിഫിക്കറ്റ്, കീ പാരാമീറ്ററുകളിലുടനീളമുള്ള ഒരു പരിധിയാണ്, അതിനാൽ അത് താഴ്ത്തുന്നത് ഒറ്റ പ്രൊഫൈൽ സ്വീകരിക്കുന്ന പരിധി വിശാലമാക്കുന്നു. ഏത് സെർവറാണ് അത് ആവശ്യപ്പെട്ടതെന്ന് എഴുതിവെക്കുക, ഓപ്പറേറ്റർ നിലവിലെ മെറ്റീരിയൽ വീണ്ടും പുറപ്പെടുവിക്കുമ്പോൾ ക്രമീകരണം ഒഴിവാക്കുക. എന്നാൽ /etc/ssl/openssl.cnf മാറ്റുന്നത് ആ ഫയൽ വായിക്കുന്ന എല്ലാ പ്രോഗ്രാമിനും അതേ പരിധി എത്തിക്കുന്നു, അത് VPN-ന് വളരെ അപ്പുറമാണ്.

OpenVPN 2.6-ന് ചർച്ചയ്ക്കായി സൈഫർ ലിസ്റ്റ് ചെയ്യേണ്ടതുണ്ട്

Ubuntu 22.10 OpenVPN 2.6 കൊണ്ടുവന്നു, ആ പതിപ്പിൽ --cipher സ്വയം ഡാറ്റാ ചാനൽ തിരഞ്ഞെടുക്കുന്നത് നിർത്തുന്നു. സൈഫർ ചർച്ച ചെയ്ത data-ciphers ലിസ്റ്റിലും ഉണ്ടായിരിക്കണം, അല്ലെങ്കിൽ ക്ലയന്റ് കാലഹരണ മുന്നറിയിപ്പ് അച്ചടിച്ച് പിന്നീട് ടണൽ ഉയർത്താൻ പരാജയപ്പെടുന്നു.

അതേ കാലയളവിലെ NetworkManager പ്ലഗിൻ ഇപ്പോഴും പഴയ നിർദ്ദേശം മാത്രമാണ് എഴുതിയിരുന്നത്. ഈ വിശദാംശം രോഗനിർണയത്തെ വിഭജിക്കുന്നു, കാരണം കൈകൊണ്ട് തിരുത്തിയ പ്രൊഫൈൽ ഷെല്ലിൽ നിന്ന് കണക്ട് ചെയ്യാം, എന്നിട്ടും ഡെസ്ക്ടോപ്പ് ആപ്‌ലെറ്റിൽ നിന്ന് പരാജയപ്പെടാം. ലിസ്റ്റ് കണക്ഷൻ ഫയലിൽ [vpn] എന്നതിന് കീഴിൽ ചേർക്കുക:

data-ciphers=AES-256-CBC

നിങ്ങൾ ഓർക്കുന്നതല്ല, സെർവർ പ്രഖ്യാപിക്കുന്ന മൂല്യം ഉപയോഗിക്കുക; AES-256-GCM വാഗ്ദാനം ചെയ്യുന്ന സെർവർ CBC മാത്രം പേരെടുത്ത് പറയുന്ന ക്ലയന്റ് ലിസ്റ്റുമായി ചർച്ച നടത്തില്ല. മാനേജർ വീണ്ടും ആരംഭിച്ച് വീണ്ടും കണക്ട് ചെയ്യുക, തുടർന്ന് ഷെല്ലിൽ നിന്ന് ശ്രമം ആവർത്തിക്കുക, സൈഫർ ചർച്ചയ്ക്കും ഫാൾബാക്കിനും വ്യക്തമായി നൽകി:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

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

പാക്കേജ്, പ്ലഗിൻ തകരാറുകൾ VPN തകരാറുകൾ പോലെ തോന്നുന്നു

അപ്‌ഗ്രേഡിന് ശേഷമുള്ള എല്ലാ പരാജയവും ക്രിപ്റ്റോഗ്രാഫിക് അല്ല. റിലീസ് ഉപയോഗിക്കാത്ത കോഡ്നെയ്മിന് കീഴിൽ ചേർത്ത OpenVPN റിപ്പോസിറ്ററി ഒരിക്കലും ഇൻസ്റ്റാൾ ചെയ്യാത്ത പാക്കേജ് നൽകുന്നു, അതിനാൽ lsb_release -a എന്താണ് റിപ്പോർട്ട് ചെയ്യുന്നതെന്ന് നിങ്ങൾ ചേർത്ത ലിസ്റ്റ് ഫയലുമായി താരതമ്യം ചെയ്യുക. കാണാത്ത universe ഘടകമോ സുരക്ഷാ പോക്കറ്റോ ഒട്ടും കണ്ടെത്താൻ കഴിയാത്ത പാക്കേജ് നൽകുന്നു. രണ്ട് സന്ദർഭങ്ങളിലും പ്രൊഫൈൽ അസ്പർശിതവും ടണൽ അസാദ്ധ്യവുമായി തുടരുന്നു.

VPN ലോഗിന് മുമ്പ് പാക്കേജ് മാനേജറുടെ പിശക് വായിക്കുക. ക്ലയന്റ് ഒരിക്കലും ഇൻസ്റ്റാൾ ചെയ്തിട്ടില്ലെങ്കിൽ, എത്ര പ്രൊഫൈൽ തിരുത്തിയാലും ഹാൻഡ്‌ഷേക്ക് ഉണ്ടാകില്ല.

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

വെണ്ടർ ലൈബ്രറിക്ക് നയ പിശകിന് പിന്നിൽ ഒളിക്കാം

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

VPN പാക്കേജ് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നത് ഏത് ലൈബ്രറിയാണ് ആദ്യം കണ്ടെത്തുന്നതെന്ന് മാറ്റുന്നില്ല, TLS നിലവാരം താഴ്ത്തുന്നത് സിസ്റ്റത്തിൽ നിന്ന് ഒരിക്കലും വരാത്ത ലൈബ്രറിയിലേക്ക് എത്തുന്നുമില്ല. ബൈനറി യഥാർത്ഥത്തിൽ ഏത് ക്രിപ്റ്റോ ഒബ്ജക്റ്റുകളാണ് പരിഹരിക്കുന്നതെന്ന് ലോഡറിനോട് ചോദിക്കുക:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

വെണ്ടർ പകർപ്പ് നീക്കം ചെയ്യുകയോ വീണ്ടും വിരിയിക്കുകയോ ചെയ്ത്, അതേ പരിശോധന വീണ്ടും നടത്തുക. പ്രൊഫൈലിലേക്ക് മടങ്ങുന്നതിന് മുമ്പ് പ്രതീക്ഷിച്ച പതിപ്പ് ഉപയോഗത്തിലുള്ളതായിരിക്കണം.

പഴയ ക്ലയന്റ് പിൻ ചെയ്യുന്നത് സമയം വാങ്ങുന്നു, പരിഹാരമല്ല

മുൻ ക്ലയന്റ് പതിപ്പ് നിലനിർത്തുന്നത് നിലനിർത്തൽ നീണ്ടുനിൽക്കുന്ന കാലത്തോളം ടണൽ പുനഃസ്ഥാപിക്കുന്നു. അത് ആ പാക്കേജിന്റെ സുരക്ഷാ അപ്‌ഡേറ്റുകൾ ഫ്രീസ് ചെയ്യുകയും അടുത്ത അപ്‌ഗ്രേഡിന് അതേ തകർച്ച തീരുമാനിക്കുകയും ചെയ്യുന്നു, അതിനാൽ ഇതിനെ പരിഹാരമല്ല, തീയതിയുള്ള താൽക്കാലിക നടപടിയായി കാണുക.

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

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