OpenVPN ഡൈജസ്റ്റുകളെക്കുറിച്ചുള്ള മിക്ക ചർച്ചകളും തുടങ്ങുന്നത് തെറ്റായ പാക്കറ്റിൽ നിന്നാണ്. auth SHA256 “SHA256 വാഗ്ദാനം ചെയ്യുന്ന പിയറുകളെ മാത്രം സ്വീകരിക്കുക” എന്ന് വായിക്കുന്നതാണ് ആദ്യം മറക്കേണ്ടത്. ഓപ്ഷൻ ചില പാക്കറ്റുകൾക്കായി ഒരു ഡൈജസ്റ്റ് പേരു നൽകുന്നു, ആ പാക്കറ്റുകൾ ഏതാണെന്നത് ചാനലിനെയും ആ ചാനൽ AEAD ആണോ എന്നതിനെയും ആശ്രയിച്ചിരിക്കുന്നു. താഴെയുള്ള നാല് ചോദ്യങ്ങൾ ക്രമത്തിൽ പരിശോധിക്കുക; ഓരോന്നും നിങ്ങളുടെ വിന്യാസത്തിൽ ഈ ക്രമീകരണത്തിന് എന്തർഥമുണ്ടാകാം എന്നത് ചുരുക്കുന്നു.

ക്രമീകരണം സംരക്ഷിക്കേണ്ട ചാനൽ പേരിടുക

OpenVPN ന് TLS ഹാൻഡ്ഷേക്ക് ട്രാഫിക് കൊണ്ടുപോകുന്ന ഒരു നിയന്ത്രണ ചാനലും ടണലിന്റെ പേലോഡ് കൊണ്ടുപോകുന്ന ഒരു ഡാറ്റ ചാനലും ഉണ്ട്. auth ഡൈജസ്റ്റിന് രണ്ടിലും പങ്കുണ്ട്, പക്ഷേ ഒരേ പങ്കല്ല, പ്രൊഫൈൽ വ്യത്യാസം അപൂർവമായി മാത്രം കാണുന്നതാക്കുന്നു. കോൺഫിഗ് ഫയൽ തൊടുന്നതിന് മുമ്പ് രണ്ടിൽ ഏതിനെയാണ് നിയന്ത്രിക്കാൻ ശ്രമിക്കുന്നതെന്ന് എഴുതിവയ്ക്കുക.

താഴെയുള്ള പട്ടിക അതേ ഓപ്ഷൻ ഓരോ സന്ദർഭത്തിലും എങ്ങനെ എത്തുന്നു എന്നതിന്റെ ചുരുക്കരൂപമാണ്.

ContextWhat the auth digest does
Data channel without AEADSelects the HMAC digest that authenticates each data packet
Data channel with AEAD, such as GCMUnused for the data channel; the cipher authenticates its own packets
Control channel protected by tls-authSelects the HMAC digest for that protection, even when data is AEAD

അതിനെ ആശ്രയിക്കുന്നതിന് മുമ്പ് ഡാറ്റ ചാനൽ AEAD ആണോ എന്ന് പരിശോധിക്കുക

സമ്മതിച്ച ഡാറ്റ സൈഫർ AES-GCM അല്ലെങ്കിൽ CHACHA20-POLY1305 ആണെങ്കിൽ, ഡാറ്റ ചാനൽ സ്വയം പ്രാമാണീകരിക്കുന്നു, വേറിട്ട ഡൈജസ്റ്റ് നിങ്ങൾ സങ്കൽപ്പിക്കുന്ന ജോലി ചെയ്യുന്നില്ല. രണ്ടും AEAD നിർമ്മിതികളാണ്, അതിനാൽ പേലോഡ് എൻക്രിപ്റ്റ് ചെയ്യുന്ന അതേ പ്രവർത്തനത്തിലൂടെയാണ് അഖണ്ഡത ഉണ്ടാകുന്നത്. ഇത് നിലവാരത്തിന്റെ കുറവല്ല, പക്ഷേ “ഓരോ ഡാറ്റ പാക്കറ്റും HMAC-SHA256 ആണ്” എന്ന ന്യായീകരണമുള്ള നയം ആ ടണലിൽ വസ്തുതാപരമായി തെറ്റാണ് എന്ന് അർഥം. നയം വീണ്ടും എഴുതുന്നതിന് മുമ്പ് സർവറിന്റെ ലോഗിലോ ക്ലയന്റ് സ്റ്റാറ്റസ് ഔട്ട്പുട്ടിലോ സമ്മതിച്ച മൂല്യം സ്ഥിരീകരിക്കുക.

പ്രൊഫൈലിലെ പട്ടികയ്ക്ക് പകരം യഥാർഥത്തിൽ സമ്മതിച്ച സൈഫർ പരിശോധിക്കുക, കാരണം ചർച്ച സമുച്ചയത്തിലെ മറ്റൊരു അംഗത്തിൽ എത്താം. data-ciphers AES-256-GCM:AES-128-GCM ഒരു ചർച്ചാ പട്ടികയാണ്, രണ്ട് എൻട്രികളും AEAD ആണ്, അതിനാൽ അവയൊന്നും പേലോഡ് സംരക്ഷണത്തിന് auth ഡൈജസ്റ്റ് ഉപയോഗിക്കുന്നില്ല.

നിയന്ത്രണ-ചാനൽ സംരക്ഷണം പ്രത്യേക തീരുമാനമായി കാണുക

tls-auth നിയന്ത്രണ-ചാനൽ പാക്കറ്റുകളിൽ HMAC ചേർക്കുകയും അതിന്റെ ഡൈജസ്റ്റ് auth ക്രമീകരണത്തിൽ നിന്ന് എടുക്കുകയും ചെയ്യുന്നു, അതുകൊണ്ട് AEAD ടണലിൽ പോലും അർഥവത്തായ ഡൈജസ്റ്റ് ക്രമീകരിക്കാം. tls-crypt സ്വന്തം സ്ഥിര സംരക്ഷണമുള്ള മറ്റൊരു ക്രമീകരണമാണ്, അതിനാൽ അത് tls-auth ന്റെ എല്ലാ സ്വഭാവവും പാരമ്പര്യമായി കിട്ടുന്നു എന്ന് കരുതരുത്. അനുമാനങ്ങൾ പരസ്പരം കൈമാറുന്നതിന് പകരം തിരഞ്ഞെടുത്ത സംവിധാനത്തിന്റെ ഡോക്യുമെന്റേഷൻ വായിക്കുക.

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

auth സൈഫർ ചർച്ചകളിൽ നിന്നും സർട്ടിഫിക്കറ്റുകളിൽ നിന്നും വേർതിരിച്ചിടുക

മൂന്ന് ക്രമീകരണങ്ങൾ നിരന്തരം കൂടിക്കലരുന്നു: auth ഡൈജസ്റ്റ്, ഡാറ്റ-സൈഫർ പട്ടിക, സർട്ടിഫിക്കറ്റിന്റെ ഒപ്പ് അൽഗോരിതം. ആദ്യത്തേത് മാറ്റുന്നത് സർട്ടിഫിക്കറ്റ് വീണ്ടും നൽകുന്നില്ല, അതിന്റെ ഒപ്പ് ഡൈജസ്റ്റ് തിരഞ്ഞെടുക്കുന്നില്ല, ഉപയോക്തൃ-പാസ്വേഡ് രീതി സൃഷ്ടിക്കുന്നുമില്ല. പ്രോട്ടോക്കോൾ ഓപ്ഷൻ നിർവചനങ്ങൾ OpenVPN 2.6 ഉറവിടങ്ങളിൽ ഓരോന്നിനെയും അതിന്റെ സ്വന്തം വിഭാഗത്തിൽ വിവരിക്കുന്നു, ഇവ സ്വതന്ത്ര നോബുകളാണ് എന്നതിന് ഇത് ഉപയോഗപ്രദമായ ഓർമ്മപ്പെടുത്തലാണ്.

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

നയം എഴുതി പ്രവർത്തിക്കുന്ന കോൺഫിഗുകളുമായി താരതമ്യം ചെയ്യുക

ഫ്ലീറ്റ് തലത്തിലുള്ള പ്രസ്താവന അനുവദനീയമായ ഡാറ്റ-ചാനൽ മോഡുകളും തിരഞ്ഞെടുത്ത നിയന്ത്രണ-ചാനൽ സംരക്ഷണവും ഒരേ വാക്യത്തിൽ വ്യക്തമായി പേരിടണം. ആ വാക്യം പരിശോധിക്കാവുന്നതാണ്; “ഞങ്ങൾ SHA256 ഉപയോഗിക്കുന്നു” അല്ല. പിന്നീട് അതിനെ റിപ്പോസിറ്ററിയിലെ ടെംപ്ലേറ്റുമായല്ല, ഫലപ്രദമായ സർവർ, ക്ലയന്റ് പ്രൊഫൈലുകളുമായി താരതമ്യം ചെയ്യുക.

ഓരോ ടണലും യഥാർഥത്തിൽ എന്താണ് സമ്മതിച്ചതെന്നും ഏത് സംവിധാനമാണ് അതിന്റെ പാക്കറ്റുകൾ പ്രാമാണീകരിച്ചതെന്നും രേഖപ്പെടുത്തി അവസാനിപ്പിക്കുക. പ്രൊഫൈലിൽ കാണുന്ന auth വരി കോൺഫിഗറേഷന്റെ ഉദ്ദേശ്യത്തിന്റെ തെളിവ് മാത്രമാണ്, ഉദ്ദേശ്യം പരിശോധനയുടെ ഏറ്റവും വിലകുറഞ്ഞ ഭാഗമാണ്.

അനുബന്ധ ലേഖനങ്ങൾ