tls-auth vs tls-crypt: OpenVPN-ൽ ഓരോന്നും എന്താണ് സംരക്ഷിക്കുന്നത്

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

ഒരു പ്രൊഫൈലിന് കണക്റ്റ് ചെയ്യാനാകാത്തപ്പോൾ, സുരക്ഷാ അവലോകനം കീ എന്തിനെ സംരക്ഷിക്കുന്നു എന്ന് ചോദിക്കുമ്പോൾ, അധിക ഫയൽ ടണലിനെ ഏതോ അവ്യക്തമായ രീതിയിൽ എൻക്രിപ്റ്റ് ചെയ്യുന്നു എന്ന് ആരെങ്കിലും കരുതുമ്പോൾ ഈ വ്യത്യാസം പ്രധാനമാണ്.

പങ്കിട്ട കീ യഥാർത്ഥത്തിൽ എന്തിനെ സംരക്ഷിക്കുന്നു

ഈ ഓപ്ഷനുകൾ ഉപയോഗിക്കുന്ന കീ നിയന്ത്രണ ചാനലിന്റേതാണ്: പാരാമീറ്ററുകൾ ചർച്ച ചെയ്യുന്ന, ഐഡന്റിറ്റികൾ തെളിയിക്കുന്ന, ഡാറ്റ കീകൾ ഉരുത്തിരിയുന്ന കൈമാറ്റം. ഹാൻഡ്ഷേക്ക് തുടരുന്നതിന് മുമ്പ് ഇരു അറ്റങ്ങളും വേണ്ടതായ മുൻകൂട്ടി പങ്കിട്ട രഹസ്യമാണിത്. ഐഡന്റിറ്റി പരിശോധനകൾക്ക് മുമ്പ് ഇത് നിൽക്കുന്നതിനാൽ, തെറ്റായ കീ തെറ്റായ പാസ്വേഡിനേക്കാൾ നേരത്തെ സംഭാഷണം നിർത്തുന്നു. ആ ക്രമമാണ് പരാജയരീതി ഇത്ര നിശ്ശബ്ദമാകാനുള്ള കാരണം.

tls-auth ആ രഹസ്യം ഉപയോഗിച്ച് നിയന്ത്രണ പാക്കറ്റുകളിൽ HMAC കണക്കാക്കുന്നു. സാധുവായ ഒപ്പില്ലാത്ത പാക്കറ്റ് ചെലവേറിയ TLS സംസ്കരണത്തിൽ എത്തുന്നതിന് മുമ്പ് തന്നെ ഒഴിവാക്കപ്പെടുന്നു, അതിനാൽ ഈ ഓപ്ഷനെ TLS-ന്റെ പകരമല്ല, ആദ്യ ഫിൽട്ടർ എന്നാണ് വിശേഷിപ്പിക്കുന്നത്.

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

ഒരു സംവിധാനവും ഐഡന്റിറ്റികൾ നൽകുന്നില്ല. പങ്കിട്ട കീ ഒരു ഗ്രൂപ്പ് രഹസ്യമാണ്, അതുള്ള ആർക്കും പരിശോധനയുടെ ആ പാളി പാലിക്കാനാകും.

രണ്ട് ഓപ്ഷനുകൾ വ്യത്യാസപ്പെടുന്നിടം

കാണാവുന്ന വ്യത്യാസം നിരീക്ഷകൻ എന്ത് കാണുന്നു എന്നതാണ്. tls-auth ഉപയോഗിക്കുമ്പോൾ ഹാൻഡ്ഷേക്ക് കാണാം, പക്ഷേ കീയില്ലാതെ പരിശോധിക്കാനാകില്ല. tls-crypt ഉപയോഗിക്കുമ്പോൾ കീയില്ലാത്ത ആർക്കും ഹാൻഡ്ഷേക്ക് അവ്യക്തമാണ്.

കോൺഫിഗറേഷനും വ്യത്യസ്തമാണ്. tls-auth ദിശാ മൂല്യത്തോടെ ഉപയോഗിക്കുന്നു, അതിനാൽ ഒരു വശം കീ മെറ്റീരിയലിന്റെ ഒരു പകുതി ഉപയോഗിക്കുന്നു, മറുവശം മറ്റേ പകുതിയും. tls-crypt രണ്ട് ദിശകളിലും ഒരൊറ്റ കീ ഉപയോഗിക്കുന്നു, അതിനാൽ ദിശാ നിർദ്ദേശം അതിന്റെ ഘടനയുടെ ഭാഗമല്ല.

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

പുതിയൊരു വകഭേദം, tls-crypt-v2, ഓരോ ക്ലയന്റിനെയും അതിന്റെ സ്വന്തം പൊതിഞ്ഞ കീയിലേക്ക് ബന്ധിക്കുന്നു, അതിനാൽ ഒരു ക്ലയന്റ് റദ്ദാക്കാൻ ഗ്രൂപ്പ് കീ വീണ്ടും നൽകേണ്ടതില്ല. ഇത് അറിയുന്നത് നല്ലതാണ്, പക്ഷേ ഇത് മറ്റൊരു ഓപ്ഷനാണ്, ഇവിടെയുള്ള രണ്ടിനും പര്യായമല്ല.

പൊരുത്തക്കേട് എന്തും സംഭവിക്കാത്തതുപോലെ തോന്നുന്നതെന്തുകൊണ്ട്

പങ്കിട്ട മെറ്റീരിയൽ പൊരുത്തപ്പെടാത്തപ്പോൾ, എതിർവശം അയച്ചയാൾക്ക് കാരണം പറയാതെ പാക്കറ്റുകൾ വലിച്ചെറിയുന്നു. വായിക്കാൻ ഒരു ആധികാരികതാ പിശകുമില്ല, കാരണം പാക്കറ്റ് അത് സൃഷ്ടിക്കുന്ന പാളിയിൽ എത്തിയിട്ടേയില്ല.

ക്ലയന്റ് വീണ്ടും ശ്രമിക്കുന്നു, സർവർ ഒന്നും പറയുന്നില്ല, ലക്ഷണം നെറ്റ്വർക്ക് പ്രശ്നം പോലെ തോന്നുന്നു. തുടർന്ന് ആളുകൾ സേവനം പുനരാരംഭിക്കുന്നു, അക്കൗണ്ട് പാസ്വേഡ് വീണ്ടും നൽകുന്നു, അല്ലെങ്കിൽ «പരിശോധിക്കാൻ» സംരക്ഷണ നിർദ്ദേശം നീക്കുന്നു, ഇത് രോഗനിർണയത്തിന് പകരം വിന്യാസം മാറ്റുന്നു.

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

നിർദ്ദേശം നീക്കുന്നത് സുരക്ഷിതമായ അറ്റകുറ്റപ്പണിയല്ല. അത് ഓരോ ക്ലയന്റിനും ഒരു സംരക്ഷണ പാളി ഓഫ് ചെയ്യുന്നു, പിന്നീട് പ്രവർത്തിക്കുന്ന ടണൽ ആ പാളിയായിരുന്നു പൊരുത്തക്കേട് എന്ന് മാത്രം തെളിയിക്കുന്നു.

ഇനിയും വേർതിരിച്ച് കോൺഫിഗർ ചെയ്യേണ്ടത്

ഈ ഓപ്ഷനുകൾ എതിർവശം ആരാണെന്ന് പരിശോധിക്കുന്നില്ല. സർട്ടിഫിക്കറ്റ് സാധുത പരിശോധന, വിശ്വാസ അടിത്തറ, പ്രതീക്ഷിക്കുന്ന സർവർ നാമം എന്നിവ വെവ്വേറെ ആവശ്യകതകളായി തുടരുന്നു, പങ്കിട്ട കീ ഉള്ളതുകൊണ്ട് അവയൊന്നും ഐച്ഛികമാകുന്നില്ല.

അവ ഡാറ്റ സൈഫറും തിരഞ്ഞെടുക്കുന്നില്ല. അത് ഇരു അറ്റങ്ങളുടെയും ഡാറ്റ-ചാനൽ ക്രമീകരണങ്ങൾ നിയന്ത്രിക്കുന്ന വേറെ ചർച്ചയാണ്, കൂടാതെ tls-crypt ഉപയോഗിച്ച് സംരക്ഷിച്ച ടണലിനും നിങ്ങൾ ഉദ്ദേശിക്കാത്ത ഒരു സൈഫർ ഉപയോഗിക്കാം.

അവസാനമായി, പങ്കിട്ട കീയ്ക്ക് തന്നെ പരിചരണം ആവശ്യമാണ്. അതിനെ ഒരു രഹസ്യമായി കാണുക, അംഗീകൃത ചാനലിലൂടെ വിതരണം ചെയ്യുക, അതുള്ള ആരെങ്കിലും പോകുമ്പോൾ മാറ്റിസ്ഥാപിക്കുക. അത് പങ്കിട്ടതായതിനാൽ, അതിന്റെ വെളിപ്പെടൽ അത് ഉപയോഗിക്കുന്ന ഓരോ അറ്റത്തിന്റെയും വെളിപ്പെടലാണ്.