OpenVPN നിയന്ത്രണ പാക്കറ്റുകൾ ട്രേസ് ചെയ്യൽ: TLS-ന് മുമ്പ് tls-auth

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

എൻവലപ്പ് നിർമ്മിക്കുന്ന ക്രമത്തിൽ വായിക്കുക

നിയന്ത്രണ പാക്കറ്റ് സെഷൻ ഐഡന്റിഫയർ, ഐച്ഛിക tls-auth HMAC, ആവർത്തന-സ്വീകരണ വിവരങ്ങൾ, ഒപ്പം വിശ്വസനീയ സന്ദേശ ഐഡന്റിഫയർ എന്നിവ വഹിക്കുന്നു, അതിനുശേഷം സന്ദേശ തരത്തിന്റെ പേലോഡ് വരുന്നു. സന്ദേശം ഹാൻഡ്‌ഷേക്ക് സന്ദേശമാണെങ്കിൽ, പേലോഡ് TLS സൈഫർടെക്സ്റ്റ് ആയിരിക്കും. ബന്ധം ഇത്രമാത്രം: TLS വസ്തു എൻവലപ്പ് ഇതിനകം സംരക്ഷിക്കുന്ന ഒരു സന്ദേശത്തിനുള്ളിലൂടെ സഞ്ചരിക്കുന്നു. കാണുക OpenVPN നെറ്റ്‌വർക്ക് പ്രോട്ടോക്കോൾ റഫറൻസ് നിയന്ത്രണ ചാനലിന്റെ ഫീൽഡുകൾ അതേ ക്രമത്തിൽ പട്ടികപ്പെടുത്തുന്നു.

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

ഈ ഗ്രൂപ്പിംഗ് ആശയപരമായി നിലനിർത്തുക. ഇത് ബൈറ്റ് ക്രമ ചിത്രമല്ല, ടാഗ് കണക്കാക്കാൻ മതിയാകുന്നതുമല്ല, കാരണം HMAC-ൽ പ്രവേശിക്കുന്ന ഫീൽഡുകൾ നടപ്പാക്കലിനെയും പതിപ്പിനെയും മോഡിനെയും ആശ്രയിച്ചിരിക്കുന്നു.

പരിശോധന ഹാൻഡ്‌ഷേക്കിന് മുമ്പ് നടക്കുന്നുവെന്ന് കാണിക്കുക

പങ്കിട്ട കീ ഉള്ള സ്വീകർത്താവിന് HMAC പരിശോധിച്ച് വ്യാജ പാക്കറ്റ് ഉടനടി ഉപേക്ഷിക്കാം, ഹാൻഡ്‌ഷേക്ക് അവസ്ഥ അനുവദിക്കാതെയും പൊതു കീ ജോലി ചെയ്യാതെയും. സംരക്ഷണം ആദ്യകാല ഹാൻഡ്‌ഷേക്ക് പാക്കറ്റുകളെയും ഉൾക്കൊള്ളുന്നു, അതുകൊണ്ടാണ് തെറ്റായ കീ വൈകിയ പ്രാമാണീകരണ പിശകായി അല്ല, പരാജയപ്പെട്ട കണക്ഷനായി കാണുന്നത്.

ഡീമണിന്റെ വാചാലത വർദ്ധിപ്പിച്ച് tun ഉപകരണത്തിന് പകരം നിയന്ത്രണ ചാനൽ നിരീക്ഷിക്കുക:

openvpn --config /etc/openvpn/server.conf --verb 6

നിങ്ങൾ തിരയുന്നത് പാക്കറ്റ് തലത്തിൽ റിപ്പോർട്ട് ചെയ്യപ്പെടുന്ന നിയന്ത്രണ ചാനൽ HMAC പരിശോധനാ പരാജയമാണ്, ഏതെങ്കിലും TLS മുന്നറിയിപ്പിന് മുമ്പ്. ലോഗിൽ TLS മുന്നറിയിപ്പ് ഉണ്ടെങ്കിൽ എൻവലപ്പ് സ്വീകരിക്കപ്പെട്ടു, പരാജയം ഉള്ളിലേക്ക് നീങ്ങി എന്നാണ് അർത്ഥം, അത് വേറെ പരിഹാരമുള്ള വേറെ അന്വേഷണമാണ്.

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

ഇരു അറ്റങ്ങളിലും കീ, ദിശ, digest ഒപ്പിക്കുക

മൂന്ന് മൂല്യങ്ങൾ യോജിക്കണം, അവയിൽ ഒന്ന് മാത്രമാണ് ഫയൽ. സ്ഥിര കീയുടെ ഉള്ളടക്കം ഇരു അറ്റങ്ങളിലും സമാനമായിരിക്കണം, ദിശ വിപരീതമായിരിക്കണം, HMAC-ന് ഉപയോഗിക്കുന്ന digest യോജിക്കണം. കീ വസ്തുവിൽ തൊടുന്നതിന് മുമ്പ് കോൺഫിഗറേഷൻ പരിശോധിക്കുക, കാരണം ഒരു തലകീഴായ ദിശ കേടായ ഫയലിനേക്കാൾ കൂടുതൽ പരാജയങ്ങൾ വിശദീകരിക്കുന്നു:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

പങ്കിട്ട രഹസ്യം എഡിറ്ററിന് പകരം ഉപകരണം കൊണ്ട് സൃഷ്ടിക്കുക, അനുമതികൾ കർശനമായി നിലനിർത്തുക:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

tls-auth-നെ tls-crypt-മായി കൂട്ടിക്കുഴയ്ക്കരുത്. രണ്ടും നിയന്ത്രണ ചാനൽ സംരക്ഷിക്കുന്നു, പക്ഷേ tls-crypt അത് എൻക്രിപ്റ്റ് ചെയ്യുകയും ഹാൻഡ്‌ഷേക്ക് നിരീക്ഷകരിൽ നിന്ന് മറയ്ക്കുകയും ചെയ്യുന്നു, ഒപ്പം ദിശ വിഭജനത്തെ സ്വന്തം കീ കൈകാര്യം കൊണ്ട് മാറ്റിസ്ഥാപിക്കുന്നു. ഒന്ന് ഉപയോഗിക്കുന്ന പ്രൊഫൈൽ മറ്റേതിനായി ക്രമീകരിച്ച പങ്കാളിയുമായി പ്രവർത്തിക്കില്ല, ഏതെങ്കിലും digest ട്യൂണിംഗ് ആ വിടവ് അടയ്ക്കുന്നുമില്ല.

യഥാർത്ഥ ഫോർമാറ്റിൽ നിന്ന് മാത്രം ടാഗ് പുനർനിർമ്മിക്കുക

ബൈറ്റ്-കൃത്യമായ പുനർനിർമ്മാണം VPN പ്രവർത്തിപ്പിക്കുന്നതിൽ നിന്ന് വേറിട്ട ജോലിയാണ്, അത് യഥാർത്ഥ ഇൻപുട്ടുകൾ കൊണ്ട് മാത്രം പ്രവർത്തിക്കുന്നു: പാക്കറ്റ് നിർമ്മിച്ച നടപ്പാക്കലും പതിപ്പും, തിരഞ്ഞെടുത്ത digest, ദിശ, സെഷൻ ഐഡന്റിഫയറും സ്വീകരണ അറേയും ഉൾപ്പെടെ യഥാർത്ഥ ബൈറ്റുകൾ. ഫീൽഡ് പട്ടികയുടെ പാഠനിർബന്ധമായ അവതരണം ആ ബൈറ്റുകളല്ല.

ടാഗിന്റെ നീളം digest-ൽ നിന്ന് വരുന്നു, അതിനാൽ സ്ഥിര നീളമെന്ന ഊഹം ആരെങ്കിലും അത് മാറ്റുന്ന നിമിഷത്തിൽ തകരുന്നു. ബ്ലോഗ് പോസ്റ്റിലെ പട്ടിക അവതരിപ്പിക്കുന്ന രീതിയിലല്ല, നടപ്പാക്കൽ ചെയ്യുന്ന രീതിയിൽ പാക്കറ്റ് ഹാഷ് ചെയ്യുക, കൈകൊണ്ട് കണ്ടെത്തിയ പ്രതീക്ഷയല്ല, അതേ പങ്കാളിയിൽ നിന്ന് എടുത്ത ക്യാപ്ചറുമായി താരതമ്യം ചെയ്യുക.

ഈ അഭ്യാസം ഉത്പാദന പ്രൊഫൈലുകളിൽ നിന്ന് അകറ്റി നിർത്തുക. ടാഗ് പുനർനിർമ്മിക്കുന്നതിൽ ഒരു വിന്യാസം സംരക്ഷണം സജീവമാക്കണമോ എന്ന് ഒന്നും പറയുന്നില്ല.

സംരക്ഷണം നീക്കാതെ പൊരുത്തക്കേട് പിൻവലിക്കുക

പ്രലോഭിപ്പിക്കുന്ന പരീക്ഷ tls-auth ഇല്ലാതാക്കി, കണക്ഷൻ വിജയിക്കുന്നത് കണ്ട്, കീ തെറ്റായിരുന്നു എന്ന് അനുമാനിക്കുകയാണ്. ആ ഉത്തരം സംരക്ഷണം നഷ്ടപ്പെടുത്തുകയും മൂന്നിൽ ഏത് മൂല്യമാണ് പൊരുത്തപ്പെടാതിരുന്നത് എന്ന് ഒന്നും പഠിപ്പിക്കുകയും ചെയ്യുന്നില്ല. പകരം സെർവർ ഭാഗത്തുനിന്ന് അംഗീകൃതമായ പൊരുത്തമുള്ള കോൺഫിഗറേഷൻ വാങ്ങി അതുമായി താരതമ്യം ചെയ്യുക.

മാറ്റം പിൻവലിക്കാവുന്ന വിധത്തിൽ തയ്യാറാക്കുക. മുൻ സെർവർ കോൺഫിഗറേഷനും കീ ഫയലും സൂക്ഷിക്കുക, തിരുത്തിയ ജോഡി പ്രയോഗിക്കുക, ഒരു ക്ലയന്റ് ഹാൻഡ്‌ഷേക്ക് പൂർത്തിയാക്കുന്നുവെന്ന് പരിശോധിക്കുക, അതിനുശേഷം മാത്രം ബാക്കപ്പ് നീക്കുക. മാറ്റത്തിനുശേഷം ക്ലയന്റുകൾ പരാജയപ്പെട്ടാൽ, തടസ്സ സമയത്ത് മൂന്നാമതൊരു വകഭേദം കെട്ടിച്ചമയ്ക്കാതെ മുൻ ഫയലുകൾ പുനഃസ്ഥാപിക്കുക. പുനഃസ്ഥാപനം തുടങ്ങുന്നതിന് മുമ്പേ നിങ്ങൾക്ക് അറിയാവുന്ന ഒരു കമാൻഡ് ആയിരിക്കണം.

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