remote-cert-tls server: OpenVPN പ്രൊഫൈലിൽ അത് എന്താണ് പരിശോധിക്കുന്നത്
ഈ നിർദ്ദേശം എതിർകക്ഷിയുടെ സർട്ടിഫിക്കറ്റിൽ എൻകോഡ് ചെയ്ത പങ്ക് പരിശോധിക്കുന്നു, അതിന്റെ പേരല്ല. എന്തെങ്കിലും നിർജ്ജീവമാക്കുന്നതിന് മുമ്പ് പങ്ക്, വിശ്വാസ ആങ്കർ, ഹോസ്റ്റ്നാം പരിശോധന എന്നിവ താരതമ്യം ചെയ്യുക.
OpenVPN പ്രൊഫൈലിന്റെ മൂന്ന് വ്യത്യസ്ത ഭാഗങ്ങൾ മൂന്ന് വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു, അവ കൂട്ടിക്കലർത്തുന്നതാണ് ആളുകൾ പ്രവർത്തിച്ചിരുന്ന ഒരു പരിശോധന ഓഫാക്കുന്നതിന് കാരണമാകുന്നത്. എതിർകക്ഷിയുടെ സർട്ടിഫിക്കറ്റ് ഞാൻ വിശ്വസിക്കുന്ന അധികാരിയാണോ ഒപ്പിട്ടത്? ആ സർട്ടിഫിക്കറ്റ് TLS സെർവർ പങ്ക് പ്രഖ്യാപിക്കുന്നുണ്ടോ? ഞാൻ എത്താൻ ഉദ്ദേശിച്ച അതേ സെർവർ തന്നെയാണോ? remote-cert-tls server മധ്യത്തിലുള്ള ചോദ്യത്തിന് മാത്രം ഉത്തരം നൽകുന്നു, അത് സർട്ടിഫിക്കറ്റിനുള്ളിലെ എക്സ്റ്റൻഷനുകൾ വായിച്ചാണ് ചെയ്യുന്നത്.
തലയിൽ കൂട്ടിക്കലർത്താൻ എളുപ്പമുള്ള മൂന്ന് പരിശോധനകൾ
വിശ്വാസ ആങ്കർ ca നിർദ്ദേശത്തിലാണ്. പങ്ക് പരിശോധന remote-cert-tls നിർദ്ദേശത്തിനുള്ളതാണ്. ഐഡന്റിറ്റി പരിശോധന verify-x509-name നിർദ്ദേശത്തിനുള്ളതാണ്, പ്രൊഫൈൽ അത് ഉപയോഗിക്കുമ്പോൾ, അല്ലെങ്കിൽ വിന്യാസം ചേർക്കുന്ന ഏത് പേര് പരിശോധനയ്ക്കും.
അവ വ്യത്യസ്ത പരാജയങ്ങൾ ഉൾക്കൊള്ളുന്നു:
| Question | Directive | Failure it catches |
|---|---|---|
| Who signed this? | ca | Certificate from an unrelated authority |
| Is this a server? | remote-cert-tls | Client certificate presented by a peer |
| Is this my server? | verify-x509-name | Another valid server from the same CA |
പ്രൊഫൈലിൽ മൂന്നും ഉണ്ടാകാം, CA വളരെ വിശാലമായി പങ്കിട്ടാൽ അത് ദുർബലമായി തുടരാം, ഇത് നിർദ്ദേശത്തിന്റെയല്ല, കീ നിർവ്വഹണത്തിന്റെ ചോദ്യമാണ്.
പങ്ക് പരിശോധന എന്താണ് വായിക്കുന്നത്
നിർദ്ദേശം ഒരു മാക്രോയാണ്. അത് കീ ഉപയോഗ ആവശ്യകതയിലേക്കും TLS വെബ് സെർവർ പങ്ക് പേരിടുന്ന വിപുലീകൃത കീ ഉപയോഗ ആവശ്യകതയിലേക്കും വികസിക്കുന്നു, അതിനാൽ എതിർകക്ഷിയുടെ സർട്ടിഫിക്കറ്റ് ആ ഉദ്ദേശ്യം യഥാർത്ഥത്തിൽ പ്രഖ്യാപിക്കണം. ക്ലയന്റ് പ്രാമാണീകരണത്തിനായി പുറപ്പെടുവിച്ച സർട്ടിഫിക്കറ്റ് അത് തൃപ്തിപ്പെടുത്തുന്നില്ല, അതേ അധികാരി രണ്ടും ഒപ്പിട്ടാലും.
ഇത് പ്രധാനമാണ് കാരണം ചെറിയ വിന്യാസങ്ങളിൽ പങ്കിട്ട CA സാധാരണമാണ്. ഒരു അധികാരി എല്ലാ ക്ലയന്റിനും സെർവറിനും ഒപ്പിടുന്നു, പങ്ക് പരിശോധന ഇല്ലാതെ ആ സർട്ടിഫിക്കറ്റുകളിൽ ഏതെങ്കിലും ഹാൻഡ്ഷേക്കിന്റെ സെർവർ ഭാഗം പൂർത്തിയാക്കാമായിരുന്നു. പരിശോധന ആ സാഹചര്യം അസാധ്യമാക്കുന്നില്ല, പക്ഷേ അതിന്റെ നിസ്സാര പതിപ്പ് നീക്കം ചെയ്യുന്നു.
നിർദ്ദേശം രൂപകൽപ്പനയിൽ അസമമാണ്: ക്ലയന്റുകൾ remote-cert-tls server വഹിക്കുന്നു, സെർവറുകൾ remote-cert-tls client വഹിക്കുന്നു. അവ മാറ്റിസ്ഥാപിക്കുക, എല്ലാ കണക്ഷനും തകർന്ന സർട്ടിഫിക്കറ്റ് പോലെ തോന്നിക്കുന്ന പങ്ക് പിശകിനാൽ പരാജയപ്പെടും.
പഴയ പ്രൊഫൈലുകൾ ചിലപ്പോൾ അതേ ആവശ്യത്തിന് ns-cert-type ഉപയോഗിക്കുന്നു. നിലവിലെ മാനുവൽ പേജുകൾ ആ ഓപ്ഷനെ മാറ്റിസ്ഥാപിച്ചതായി കണക്കാക്കുന്നു, അതിനാൽ ഇപ്പോഴും അതിനെ ആശ്രയിക്കുന്ന പ്രൊഫൈൽ ഡീബഗ് ചെയ്യുന്നതിനേക്കാൾ മാറ്റേണ്ടത് വിലപ്പെട്ടതാണ്.
അത് നിർജ്ജീവമാക്കുന്നത് പരിഹാരമായി തോന്നുന്നത് എന്തുകൊണ്ട്
പങ്ക് പരിശോധന പരാജയപ്പെടുമ്പോൾ, കണക്ഷൻ പരിശോധന പിശകിനാൽ നിലയ്ക്കുന്നു, വ്യക്തമായ അടുത്ത ഘട്ടം വരി ഇല്ലാതാക്കുന്നതാണ്. തുടർന്ന് കണക്ഷൻ ഉയരുന്നു, ഇത് പുരോഗതിയായി തോന്നുന്നു, യഥാർത്ഥത്തിൽ നിർദ്ദേശം തടയാൻ നിലനിൽക്കുന്ന പരാജയ മോഡാണ്. ഇപ്പോൾ ആ പങ്കിനായി ഒരിക്കലും ഉദ്ദേശിക്കാത്ത സർട്ടിഫിക്കറ്റുള്ള എതിർകക്ഷിയെ നിങ്ങൾ സ്വീകരിക്കുന്നു.
പകരം പിശക് വായിക്കുക. അത് പരാജയപ്പെട്ട പരിശോധനയെ പേരിടുന്നു, മറുവശത്തുള്ള സർട്ടിഫിക്കറ്റ് പരിശോധിച്ച് അത് യഥാർത്ഥത്തിൽ ഏത് എക്സ്റ്റൻഷനുകൾ വഹിക്കുന്നു എന്ന് കാണാം. രണ്ട് മിനിറ്റ് വായന തകരാർ പുറപ്പെടുവിക്കലിലാണോ കോൺഫിഗറേഷനിലാണോ എന്ന് തീരുമാനിക്കുന്നു. ഊഹിക്കൽ ഒരു ഉച്ചയ്ക്കുശേഷം എടുക്കുന്നു, സാധാരണയായി ദുർബലമായ പ്രൊഫൈലിൽ അവസാനിക്കുന്നു. വിപുലീകൃത കീ ഉപയോഗം നഷ്ടപ്പെട്ട പുതുക്കിയ സെർവർ സർട്ടിഫിക്കറ്റ് പുതുക്കലിലെ യഥാർത്ഥ തകരാറാണ്, ക്ലയന്റിനെ അയയ്ക്കാനുള്ള കാരണമല്ല.
പേര് പരിശോധന പ്രത്യേക നിർദ്ദേശമാണ്
പങ്ക് പരിശോധന തൃപ്തിപ്പെടുത്തുന്നത് എതിർകക്ഷി നിങ്ങളുടെ അധികാരി ഒപ്പിട്ട ഏതോ സെർവറാണ് എന്നാണ്. ഏതാണെന്ന് അത് ഒന്നും പറയുന്നില്ല, അതേ CA നിരവധി ഗേറ്റ്വേകൾക്ക് സർട്ടിഫിക്കറ്റുകൾ നൽകുകയും അവയിലൊന്ന് വിട്ടുവീഴ്ച ചെയ്യപ്പെടുകയോ പുനരുദ്ദേശിക്കപ്പെടുകയോ ചെയ്യുമ്പോൾ ഇത് പ്രധാനമാണ്.
verify-x509-name സർട്ടിഫിക്കറ്റ് വിഷയത്തെ നിങ്ങൾ കോൺഫിഗർ ചെയ്ത മൂല്യവുമായി താരതമ്യം ചെയ്യുന്നു, കൃത്യമായ വിഷയം, പ്രിഫിക്സ് അല്ലെങ്കിൽ ഒരു ഫീൽഡ് എന്നിവയ്ക്കുള്ള പൊരുത്ത മോഡുകളോടെ. ഗേറ്റ്വേയെ യഥാർത്ഥത്തിൽ തിരിച്ചറിയുന്ന ഫീൽഡ് ഉപയോഗിക്കുക, പേര് മാറുമ്പോൾ അത് ബോധപൂർവ്വം അപ്ഡേറ്റ് ചെയ്യുമെന്ന് പ്രതീക്ഷിക്കുക.
ഏത് നിർദ്ദേശവും നല്ല കീ കൈകാര്യം ചെയ്യുന്നതിന് പകരമാകുന്നില്ല. ക്ലയന്റ് കീ ഫയൽ പ്രൊഫൈലിനൊപ്പം പകർത്തിയാൽ, എതിർകക്ഷിയുടെ ഐഡന്റിറ്റി വിതരണ പട്ടികയോളം മാത്രമേ ശക്തമാകൂ.
പ്രൊഫൈൽ തിരുത്തുന്നതിന് മുമ്പ് സർട്ടിഫിക്കറ്റ് പരിശോധിക്കുക
എതിർകക്ഷിയുടെ സർട്ടിഫിക്കറ്റും ക്ലയന്റ് ലോഗും ആ ക്രമത്തിൽ വായിക്കുക. സർട്ടിഫിക്കറ്റ് ഏത് പങ്കുകൾ പ്രഖ്യാപിക്കുന്നു എന്ന് പറയുന്നു; ലോഗ് ഏത് പരിശോധന അത് നിരസിച്ചു എന്ന് പറയുന്നു.
ഈ കമാൻഡുകൾ വിശദമായ കണക്ഷനിൽ നിന്ന് ഉപയോഗ എക്സ്റ്റൻഷനുകളും പരിശോധന വരികളും അച്ചടിക്കുന്നു:
openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verifyഎക്സ്റ്റൻഷനുകൾ സെർവർ പങ്ക് കാണിക്കുകയും ലോഗ് ഇപ്പോഴും പങ്ക് പരാജയം റിപ്പോർട്ട് ചെയ്യുകയും ചെയ്താൽ, പ്രൊഫൈൽ മോശം സർട്ടിഫിക്കറ്റിനേക്കാൾ തെറ്റായ സർട്ടിഫിക്കറ്റ് ഫയലിലേക്ക് ചൂണ്ടുന്നു. എക്സ്റ്റൻഷനുകൾ ക്ലയന്റ് പ്രാമാണീകരണം മാത്രം കാണിക്കുന്നുവെങ്കിൽ, ക്ലയന്റിനെ നോക്കുന്നത് നിർത്തി പുറപ്പെടുവിക്കൽ ശരിയാക്കുക. ഏത് സാഹചര്യത്തിലും, കണക്ഷനെ ആരോഗ്യകരമെന്ന് വിളിക്കുന്നതിന് മുമ്പ് പരിശോധന പുനഃസ്ഥാപിക്കുക, കാരണം പരിശോധന നീക്കിയതിന് ശേഷമുള്ള വിജയകരമായ ഹാൻഡ്ഷേക്ക് അത് മാറ്റിസ്ഥാപിച്ച പിശകിനേക്കാൾ കുറഞ്ഞത് മാത്രമേ തെളിയിക്കുന്നുള്ളൂ.