OpenVPN tls-ciphersuites vs tls-version-min: ഓരോന്നും എന്താണ് നിർബന്ധമാക്കുന്നത്

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

ഏതെങ്കിലും ലിസ്റ്റ് വായിക്കുന്നതിന് മുമ്പ് ബിൽഡ് പരിശോധിക്കുക

പ്രോട്ടോക്കോൾ പിന്തുണയില്ലാത്ത ബൈനറിയിലേക്ക് കോൺഫിഗറേഷൻ നിർദ്ദേശത്തിന് അത് ചേർക്കാൻ കഴിയില്ല. കോംപൈൽ ചെയ്ത ക്രിപ്റ്റോ ലൈബ്രറി പേര് നൽകുന്ന പതിപ്പ് ബാനറിൽ തുടങ്ങുക:

openvpn --version

OpenSSL-മായി ലിങ്ക് ചെയ്ത 2.6 ബിൽഡ് tls-cipher, tls-ciphersuites എന്നിവ രണ്ടും സ്വീകരിക്കുന്നു. mbed TLS-ഉള്ള ബിൽഡിൽ TLS 1.3 സ്യൂട്ട് തിരഞ്ഞെടുപ്പ് അശേഷമില്ല, 2.6 മാനുവൽ tls-ciphersuites OpenSSL ഓപ്ഷനായി അടയാളപ്പെടുത്തുന്നു. സെർവർ മറ്റൊരു ബാക്കെൻഡുമായി പുനർനിർമ്മിച്ചാൽ, അതേ പ്രൊഫൈലിന് കോൺഫിഗറേഷന്റെ ഒരു വരിപോലും മാറ്റാതെ പെരുമാറ്റം മാറാം.

ഇവിടെയുള്ളപ്പോൾ openvpn --show-tls പ്രവർത്തിപ്പിച്ച് ഔട്ട്പുട്ട് സൂക്ഷിക്കുക. അതാണ് പിന്നീട് താരതമ്യം ചെയ്യുന്ന ഇൻവെന്ററി, ആരും പ്രൊഫൈലുകൾ എഡിറ്റ് ചെയ്യാൻ തുടങ്ങുന്നതിന് മുമ്പ് അത് പിടിച്ചെടുക്കുന്നത് വിലകുറഞ്ഞതാണ്.

ബാനറും ലിസ്റ്റും ചാറ്റ് വിൻഡോയിലല്ല, മാറ്റ ടിക്കറ്റിൽ എഴുതുക. ആറ് ആഴ്ചയ്ക്ക് ശേഷം ഒരു ക്ലയന്റിന് സ്യൂട്ട് നൽകാൻ കഴിയുമോ എന്നതിനെക്കുറിച്ച് രണ്ട് പേർ തർക്കിക്കുമ്പോൾ, പിടിച്ചെടുത്ത ഔട്ട്പുട്ട് അത് ഒരു വരിയിൽ തീർപ്പാക്കുന്നു.

പതിപ്പ് പരിധികൾ സൈഫർ ലിസ്റ്റുകളിൽ നിന്ന് വേർതിരിച്ച് സൂക്ഷിക്കുക

2.6 മാനുവലിൽ ഇവ ഒന്നല്ല, മൂന്ന് നിയന്ത്രണങ്ങളാണ്:

• tls-cipher TLS 1.2-നും മുൻപുള്ള പതിപ്പുകൾക്കും സൈഫർ നയം നിശ്ചയിക്കുന്നു, OpenSSL-ന്റെ സൈഫർ ലിസ്റ്റിലേക്ക് കൈമാറുന്നു;
• tls-ciphersuites TLS 1.3 സ്യൂട്ടുകൾ തിരഞ്ഞെടുക്കുന്നു;
• tls-version-min, tls-version-max എന്നിവ കണക്ഷന് ഉപയോഗിക്കാവുന്ന പ്രോട്ടോക്കോൾ പതിപ്പുകൾ പരിമിതപ്പെടുത്തുന്നു.

അതിനാൽ സൂക്ഷ്മമായി വെട്ടിയൊതുക്കിയ TLS 1.3 സ്യൂട്ട് ലിസ്റ്റ് പഴയ പതിപ്പ് ഇപ്പോഴും അനുവദനീയമാണ് എന്നതിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. ആവശ്യകത «TLS 1.3 മാത്രം» ആണെങ്കിൽ, അതിനെ താങ്ങുന്നത് പതിപ്പിന്റെ താഴ്ന്ന പരിധിയാണ്, സ്യൂട്ട് ലിസ്റ്റ് ആ പരിധിക്കുള്ളിലെ തിരഞ്ഞെടുപ്പുകൾ ചുരുക്കുക മാത്രം ചെയ്യുന്നു:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

ഈ ജോടി രണ്ട് ജോലി ചെയ്യുന്നു. ഒരു വരി മായ്ച്ചാൽ മറ്റേത് നിങ്ങൾ കരുതുന്നതിലും കുറച്ച് മാത്രം നിർബന്ധമാക്കുന്നു, ഈ പരിശോധന മുഴുവൻ ഉണ്ടാകാനുള്ള കാരണം അതേ പരാജയമാണ്.

ഡാറ്റാ ചാനൽ നാലാമത്തെ നിയന്ത്രണമാണ്. data-ciphers ടണലിനുള്ളിലെ സമമിത സൈഫർ ചർച്ച ചെയ്യുന്നു, അതിന്റെ ഫലം നിയന്ത്രണ ചാനലിന്റെ TLS പതിപ്പിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. സെഷൻ സംഗ്രഹത്തിൽ AES-256-GCM കാണുന്നത് ഏത് ദിശയിലും TLS 1.3-ന്റെ തെളിവല്ല.

show-tls പ്രാദേശിക ഇൻവെന്ററിയായി വായിക്കുക

--show-tls ഈ ബൈനറി ലിങ്ക് ചെയ്തിരിക്കുന്ന ക്രിപ്റ്റോ ലൈബ്രറി പിന്തുണയ്ക്കുന്ന സ്യൂട്ടുകൾ മുൻഗണനാ ക്രമത്തിൽ പട്ടികപ്പെടുത്തുന്നു. ഇത് ഗേറ്റ്വേയിൽ നിന്നുള്ള റിപ്പോർട്ടല്ല. ലിസ്റ്റ് പ്രാദേശിക ലൈബ്രറിയിൽ നിന്നാണ് വരുന്നതെന്ന് മാനുവൽ വ്യക്തമായി പറയുന്നു, അതായത് OpenSSL 3.x ഉള്ള ലാപ്ടോപ്പും പഴയ ബിൽഡുള്ള റൗട്ടറും ഒരേ സെർവറുമായി സംസാരിക്കുമ്പോൾ വ്യത്യസ്ത ലിസ്റ്റുകൾ പ്രിന്റ് ചെയ്യും.

ഒരു ക്ലയന്റ് A, B, C സ്യൂട്ടുകൾ പിന്തുണയ്ക്കുന്നു, ഒരു സെഷൻ B തിരഞ്ഞെടുക്കുന്നു എന്ന് കരുതുക. സെർവർ A അല്ലെങ്കിൽ C അനുവദിക്കുന്നുണ്ടോ, B അതിന്റെ ഏക അനുവദനീയ തിരഞ്ഞെടുപ്പാണോ എന്നതിനെക്കുറിച്ച് അത് ഒന്നും സ്ഥാപിക്കുന്നില്ല. മൂന്ന് വരികൾ വേർതിരിച്ച് സൂക്ഷിക്കുക, ആശയക്കുഴപ്പമുള്ള TLS ചർച്ചകളിൽ മിക്കതും സ്വയം പരിഹരിക്കപ്പെടും.

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

ഗേറ്റ്വേയോട് അതിന് ഉത്തരം നൽകാൻ കഴിയുന്ന ഒന്ന് ചോദിക്കുക

നിങ്ങൾ സേവനം നിയന്ത്രിക്കുന്നുവെങ്കിൽ, ഡിസ്കിലെ ഫയലല്ല, പ്രവർത്തിക്കുന്ന ഇൻസ്റ്റൻസിന്റെ ഫലപ്രദമായ കോൺഫിഗറേഷൻ പരിശോധിക്കുക. OpenVPN മറ്റൊരു --config പാതയിൽ ആരംഭിച്ചിരിക്കാം, ഉൾപ്പെടുത്തലുകൾ വലിച്ചിട്ടുണ്ടാകാം, എഡിറ്റിന് ശേഷം പുനരാരംഭിച്ചിട്ടുണ്ടാകണമെന്നില്ല. ക്ലയന്റുകൾ നേരിടുന്നത് പ്രവർത്തിക്കുന്ന ഡീമണിന്റെ നയമാണ്.

നിങ്ങൾ അത് നിയന്ത്രിക്കുന്നില്ലെങ്കിൽ, ഓപ്പറേറ്ററോട് പിന്തുണയുള്ള ക്ലയന്റ് ആവശ്യകതകളോ പരിമിതമായ സ്വീകരണ പരിശോധനയോ ആവശ്യപ്പെടുക. നിരസിക്കപ്പെട്ട ശ്രമം സ്വയമേവ നിരസിക്കപ്പെട്ട സ്യൂട്ടല്ല: പതിപ്പിന്റെ താഴ്ന്ന പരിധി, remote-cert-tls പോലുള്ള സർട്ടിഫിക്കറ്റ് ഐഡന്റിറ്റി പരിശോധനകൾ, അല്ലെങ്കിൽ tls-auth, tls-crypt എന്നിവ തമ്മിലുള്ള പൊരുത്തക്കേട് എന്നിവ സ്യൂട്ട് തിരഞ്ഞെടുപ്പ് പ്രസക്തമാകുന്നതിന് മുമ്പേ കൈമാറ്റം അവസാനിപ്പിക്കാം. ക്ലയന്റിന്റെ ലിസ്റ്റ് മാറ്റുന്നതിന് മുമ്പ് സെർവറിന്റെ പിശക് വായിക്കുക, കാരണം «handshake failed» നാല് വ്യത്യസ്ത കാരണങ്ങളെ ഉൾക്കൊള്ളുന്നു, അവയിൽ ഒന്ന് മാത്രമാണ് സൈഫർ പൊരുത്തക്കേട്.

VPN പോർട്ടിലേക്ക് openssl s_client ചൂണ്ടുന്നതും ചോദ്യം പുനരാവിഷ്കരിക്കുന്നില്ല. നിയന്ത്രണ ചാനൽ OpenVPN-ന്റെ സ്വന്തം ഫ്രെയിമിംഗിനുള്ളിൽ പ്രവർത്തിക്കുന്നു, അതിനാൽ അസംസ്കൃത TLS പ്രോബ് മറ്റൊന്ന് പ്രതീക്ഷിക്കുന്ന പോർട്ടിൽ വേറെ പ്രോട്ടോക്കോൾ പരിശോധിക്കുന്നു. അതിൽ നിന്ന് ഉരുത്തിരിയുന്ന ഏത് നിഗമനവും പ്രോബിനെക്കുറിച്ചാണ്, ടണലിനെക്കുറിച്ചല്ല.

രണ്ട് ഫലങ്ങൾ രേഖപ്പെടുത്തി അവ വേർതിരിച്ച് സൂക്ഷിക്കുക

പുതിയതായി അനുവദിക്കപ്പെട്ട സെഷൻ പ്രോട്ടോക്കോൾ പതിപ്പും തിരഞ്ഞെടുത്ത സൈഫറും പേരിടുന്ന നിയന്ത്രണ ചാനൽ വരിയും, ടണലിന്റെ സൈഫർ പേരിടുന്ന വേറിട്ട ഡാറ്റാ ചാനൽ വരിയും സൃഷ്ടിക്കുന്നു. രണ്ടും ക്ലയന്റ് പതിപ്പിനും പ്രൊഫൈൽ പേരിനുമൊപ്പം പിടിച്ചെടുക്കുക, ഏത് സെർവർ ഇൻസ്റ്റൻസ് ഉത്തരം നൽകി എന്ന് കുറിക്കുക:

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

തുടർന്ന് ആ രണ്ട് വരികൾ ഓർമ്മയിൽ നിന്നല്ല, ആ ഫയലിൽ നിന്ന് വായിക്കുക. ജോടിയാണ് തെളിവ്; സ്യൂട്ട് പേര് മാത്രം ഒരു മുൻഗണനയാണ്, പതിപ്പ് പരിധി സെർവർ എന്ത് നിരസിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള വേറിട്ട പ്രസ്താവനയാണ്.

ഈ ക്രമത്തിൽ പരിശോധനകൾ നടത്തുക. --version ഉപയോഗിച്ച് ബിൽഡും ബാക്കെൻഡും സ്ഥിരീകരിക്കുക. എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് --show-tls പിടിച്ചെടുക്കുക. ആവശ്യമായ പതിപ്പ് താഴ്ന്ന പരിധി സ്യൂട്ട് ലിസ്റ്റിൽ നിന്ന് വേർതിരിച്ച് പറയുക. പ്രവർത്തിക്കുന്ന ഇൻസ്റ്റൻസിന്റെ ഫലപ്രദമായ നയം അതിന്റെ ഉടമയുമായി സ്ഥിരീകരിക്കുക. ഒരു അനുവദിക്കപ്പെട്ട സെഷനും, പദ്ധതി അനുവദിക്കുകയാണെങ്കിൽ പഴയ പതിപ്പുള്ള ഒരു നിരസിക്കപ്പെട്ട ശ്രമവും നിരീക്ഷിക്കുക. നിയന്ത്രണ ചാനൽ, ഡാറ്റാ ചാനൽ ഫലങ്ങൾ വേറിട്ട കണ്ടെത്തലുകളായി രേഖപ്പെടുത്തുക.

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