tls-auth key-direction: 0-ഉം 1-ഉം വ്യത്യസ്തമായിരിക്കണം, ഒരുപോലെയല്ല
tls-auth-ൽ ഇരുവശത്തും വിപരീത ദിശകൾ വേണം, 0-ഉം 1-ഉം, അല്ലെങ്കിൽ രണ്ടും ക്രമീകരണം ഒഴിവാക്കണം. ഒരേ സംഖ്യ പരാജയപ്പെടുന്നു, tls-crypt അത് ഒരിക്കലും ഉപയോഗിക്കുന്നില്ല.
ടണലിന്റെ ഒരു വശം മറുവശം ഒരിക്കലും പരിശോധിക്കാത്ത ഒരു കീ സ്ലോട്ട് ഉപയോഗിച്ച് നിയന്ത്രണ ചാനലിൽ ഒപ്പിടുന്നു, ഒരു സർട്ടിഫിക്കറ്റ് പോലും കൈമാറുന്നതിന് മുമ്പ് കണക്ഷൻ ഓതന്റിക്കേഷൻ പിശകിൽ മരിക്കുന്നു. tls-auth-ന്റെ ദിശ പൊരുത്തക്കേട് ഇങ്ങനെയാണ്, അത് നിർണ്ണായകമാണ്: അതേ രണ്ട് ഫയലുകളും ഓരോ ശ്രമത്തിലും, ഏത് നെറ്റ്വർക്കിൽ നിന്നും പരാജയപ്പെടുന്നു. നിങ്ങൾ തിരയുന്ന ഓപ്ഷന്റെ പേര് ലോഗിൽ ഇല്ല, അതുകൊണ്ട് ആളുകൾ ഒരിക്കലും തകരാത്ത കീകൾ വീണ്ടും നിർമ്മിക്കുകയും സർട്ടിഫിക്കറ്റുകൾ വീണ്ടും നൽകുകയും ചെയ്യുന്നു. പരിഹാരം ഇരുവശത്തെയും പൂരകമാക്കുകയോ രണ്ടിനെയും ഇരുദിശയായി വിടുകയോ ചെയ്യുകയാണ്, പരിശോധന ദുർബലമാക്കുന്നതല്ല.
പരാജയം സർട്ടിഫിക്കറ്റുകൾക്ക് മുമ്പ് സംഭവിക്കുന്നു
tls-auth-ൽ ഇരു പീറുകളും ഒരേ പങ്കിട്ട കീ കൈവശം വയ്ക്കുന്നു, ഓരോന്നും അതിൽ നിന്ന് ഉരുത്തിരിഞ്ഞ രണ്ട് സ്ലോട്ടുകളിൽ ഒന്ന് ഉപയോഗിക്കുന്നു: ഒരു സ്ലോട്ട് പുറത്തേക്കുള്ള നിയന്ത്രണ പാക്കറ്റുകളിൽ ഒപ്പിടുന്നു, മറ്റൊന്ന് അകത്തേക്കുള്ളവ പരിശോധിക്കുന്നു. ദിശ 0-ഉം ദിശ 1-ഉം ഈ റോളുകൾ വിപരീത ക്രമത്തിൽ നൽകുന്നു, അതിനാൽ HMAC പരിശോധനകൾ പൊരുത്തപ്പെടാൻ ജോഡി പൂരകമായിരിക്കണം. ഒരു വശത്ത് അനുവദനം തലകീഴായാൽ, സ്വീകർത്താവ് തെറ്റായ സ്ലോട്ടിൽ ഒപ്പ് തിരയുകയും പാക്കറ്റ് നിരസിക്കുകയും ചെയ്യുന്നു. സെഷൻ അവിടെ അവസാനിക്കുന്നു, അതിനാൽ പിശക് പാക്കറ്റ് ഓതന്റിക്കേഷനെക്കുറിച്ചാണ്, സർട്ടിഫിക്കറ്റ് സ്റ്റോർ ഉണ്ടാക്കുന്നതിനെക്കുറിച്ചല്ല.
നിർണ്ണായകത രോഗനിർണ്ണയത്തിന് പ്രധാനമാണ്, കാരണം സമയമോ പാതയോ ഉള്ള പ്രശ്നം വേറെ അടയാളം വിടുന്നു: ഇടവിട്ടുള്ള വിച്ഛേദങ്ങൾ, ഒരു ദിശയുടെ പരാജയം, അല്ലെങ്കിൽ ഒരു പ്രത്യേക നെറ്റ്വർക്കിൽ മാത്രം മരിക്കുന്ന സെഷൻ. ദിശ പൊരുത്തക്കേട് ഓരോ തവണയും ആദ്യ ഹാൻഡ്ഷേക്കിൽ പരാജയപ്പെടുന്നു, അതേ രണ്ട് ഫയലുകളുള്ള മറ്റൊരു യന്ത്രത്തിലും അതേപോലെ പരാജയപ്പെടുന്നു. --verb 4-ൽ ലോഗ് വായിച്ച് അവസാന വരിക്ക് പകരം ആദ്യം നിരസിച്ച പാക്കറ്റ് കണ്ടെത്തുക. ആ നിരസിക്കൽ ഏതെങ്കിലും സർട്ടിഫിക്കറ്റ് കൈമാറ്റത്തിന് മുമ്പ് സംഭവിച്ചാൽ, പങ്കിട്ട കീയും അതിന്റെ ദിശയുമാണ് പരിശോധിക്കാൻ യോഗ്യമായ രണ്ട് കാര്യങ്ങൾ.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
സംഖ്യ എവിടെ താമസിക്കുന്നു
OpenVPN 2.6 കൈപ്പുസ്തകം ദിശയ്ക്ക് രണ്ട് സ്ഥലങ്ങൾ രേഖപ്പെടുത്തുന്നു: കീ പ്രത്യേക ഫയലിൽ ആകുമ്പോൾ tls-auth-ന്റെ രണ്ടാം ആർഗ്യുമെന്റ്, കീ പ്രൊഫൈലിൽ ഇൻലൈൻ ആകുമ്പോൾ സ്വതന്ത്ര key-direction വരി. രണ്ടും ഒരേ മൂല്യം സജ്ജമാക്കുന്നു, അതിനാൽ പ്രൊഫൈൽ ഒരു രൂപമോ മറ്റൊന്നോ ഉപയോഗിക്കണം, ഒരിക്കലും രണ്ടും അല്ല. ഒഴിവാക്കലും ഒരു തിരഞ്ഞെടുപ്പാണ്, അത് ഇരു പീറുകളെയും ഇരുദിശാ ക്രമീകരണത്തിൽ ഇടുന്നു, ഏതെങ്കിലും വശം ദിശ പറയാത്തപ്പോൾ അത് പ്രവർത്തിക്കുന്നു. ഒരേ സംഖ്യയുള്ള രണ്ട് പീറുകൾ ആ ക്രമീകരണത്തിലില്ല: ഓരോന്നും ഒരു സ്ലോട്ടിൽ ഒപ്പിടാനും മറ്റൊന്നിൽ പരിശോധിക്കാനും പ്രതീക്ഷിക്കുന്നു, രണ്ടും അത് ഒരേ രീതിയിൽ ചെയ്യുന്നു.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
ഇൻലൈൻ രൂപം സ്വന്തം വരിയിലുള്ള ഒരു നിർദ്ദേശമാണ്, കീ ബ്ലോക്കിന്റെ തുറക്കുന്ന ടാഗിലെ ആട്രിബ്യൂട്ടല്ല, ആ ടാഗിലേക്ക് ആർഗ്യുമെന്റ് ചേർക്കുന്നത് പിശകാണ്, ദിശ മാറ്റമല്ല. സ്ഥാനവും പ്രധാനമാണ്: നിർദ്ദേശം അതിന്റെ ബ്ലോക്കിന് പുറത്താണ്, അതിനാൽ ബ്ലോക്കിനുള്ളിൽ എഴുതിയ മൂല്യം കീ മെറ്റീരിയലായി വായിക്കപ്പെടുന്നു. ജോഡി കെട്ടിച്ചമയ്ക്കാതെ പ്രൊഫൈൽ വിതരണക്കാരൻ ഉദ്ദേശിച്ച ക്രമീകരണം പകർത്തുക, കാരണം ഒരു സെർവറിനെതിരെ പ്രവർത്തിക്കുന്ന പ്രൊഫൈൽ മറുവശത്ത് ഇതിനകം പ്രതിഫലിപ്പിച്ചിരിക്കാം.
ഓപ്ഷൻ എന്തിനെ തൊടാതെ വിടുന്നു
ഇത് അപ്ലിക്കേഷൻ ട്രാഫിക് എൻക്രിപ്റ്റ് ചെയ്യുന്നില്ല. tls-auth നിയന്ത്രണ ചാനലിന്റെ പാക്കറ്റുകൾക്ക് ചുറ്റും HMAC ഇടുന്നു, ഡാറ്റ ചാനൽ ഹാൻഡ്ഷേക്കിൽ ചർച്ച ചെയ്ത സെഷൻ കീകളാൽ സംരക്ഷിക്കപ്പെടുന്നു, അതിനാൽ ത്രൂപുട്ട് അല്ലെങ്കിൽ സൈഫർ ചോദ്യത്തിന് ദിശ സംഖ്യയുമായി യാതൊരു ബന്ധവുമില്ല. ക്രമീകരണം രണ്ടാം എൻക്രിപ്ഷൻ പാളിയും ചേർക്കുന്നില്ല, ആ ധാരണയാണ് ആളുകളെ നീളമുള്ള കീ തിരയാൻ അയയ്ക്കുന്നത്.
ഇത് tls-crypt-ന് ബാധകമല്ല, സ്വന്തം ഓപ്ഷനുകളും കീ കൈകാര്യം ചെയ്യലുമുള്ള മറ്റൊരു നിയന്ത്രണ ചാനൽ സംവിധാനം, ഏതെങ്കിലും പീറിന്റെ സർട്ടിഫിക്കറ്റ് ഐഡന്റിറ്റിയെക്കുറിച്ച് ഒന്നും പറയുന്നുമില്ല. അതിനാൽ പ്രവർത്തിക്കുന്ന ദിശ പൊരുത്തം ഇരുവശവും നിയന്ത്രണ ചാനൽ എങ്ങനെ ഓതന്റിക്കേറ്റ് ചെയ്യണം എന്നതിൽ യോജിക്കുന്നു എന്ന് മാത്രം തെളിയിക്കുന്നു, വിശ്വാസ ശൃംഖല സാധുതയുള്ളതായി സ്ഥിരീകരിച്ചു എന്നല്ല.
ജോഡി വിന്യസിച്ച് വീണ്ടും ബന്ധിപ്പിക്കുക
ഏതെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് രണ്ട് കോൺഫിഗറേഷനുകളും താരതമ്യം ചെയ്യുക, കാരണം ഇതിനകം ശരിയായ വശം എഡിറ്റ് ചെയ്യുന്നത് ജോലി ഇരട്ടിയാക്കുന്നു. താഴെയുള്ള grep ഓരോ ഫയലും ഏത് സംവിധാനം തിരഞ്ഞെടുക്കുന്നു എന്ന് കാണിക്കുന്നു; വിശദമായ റൺ നിയന്ത്രണ ചാനൽ ഓതന്റിക്കേറ്റ് ചെയ്തോ എന്ന് കാണിക്കുന്നു. രണ്ട് ഔട്ട്പുട്ടുകളും സൂക്ഷിക്കുക, അടുത്ത മാറ്റം അറിയപ്പെടുന്ന അവസ്ഥയുമായി താരതമ്യം ചെയ്യാം.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
ഏതെങ്കിലും മാറ്റത്തിന് ശേഷം രണ്ട് പീറുകളും വീണ്ടും ആരംഭിക്കുക, കാരണം ഈ ഓപ്ഷനുകൾ ആരംഭിക്കുമ്പോൾ ഒരിക്കൽ വായിക്കപ്പെടുന്നു, ഒരു വശം വീണ്ടും ലോഡ് ചെയ്യുന്നത് പഴയ സെഷന്റെ മുഴുവൻ ആയുസ്സിലും ജോഡിയെ അസ്ഥിരമായി വിടുന്നു. വിന്യാസം ഇപ്പോൾ ദിശ ക്രമീകരിക്കാതെ പ്രവർത്തിക്കുന്നുവെങ്കിൽ, ഒരു പീറിൽ ക്രമീകരണം ചേർക്കുന്നത് നിങ്ങൾ തുടങ്ങിയ പരാജയം പുനർനിർമ്മിക്കുന്നു; ഒന്നുകിൽ രണ്ടിനെയും വിടുക അല്ലെങ്കിൽ രണ്ടിനെയും ക്രമീകരിക്കുക. ഒരു സമയത്ത് ഒരു അറ്റം മാറ്റി മുമ്പത്തെ ഫയൽ സൂക്ഷിക്കുക, റിഗ്രഷൻ പുനർനിർമ്മാണമല്ല, രണ്ട് മിനിറ്റ് പിൻവലിക്കലായിരിക്കട്ടെ.
ഓരോ അറ്റത്തിനും സംവിധാനം, കീ ഫയൽ, ദിശ എന്നിവ വിന്യാസ കുറിപ്പുകളിൽ രേഖപ്പെടുത്തുക, അല്ലെങ്കിൽ അടുത്ത വ്യക്തി രണ്ട് സമാന ഫയലുകൾ വായിച്ച് സംഖ്യകൾ പരസ്പരം പൊരുത്തപ്പെടണമെന്ന് കരുതും. ദിശ ഏകോപന വിശദാംശമാണ്, സുരക്ഷാ മെച്ചപ്പെടുത്തലല്ല: അത് നിയന്ത്രണ ചാനലിന്റെ രണ്ട് ദിശകൾ വേർതിരിക്കുന്നു, മറ്റൊന്നും ചെയ്യുന്നില്ല.