DH ഫയലോ tls-auth കീയോ? രണ്ട് OpenVPN ഫയലുകൾ വേർതിരിച്ചറിയൽ

രണ്ട് ഫയലുകൾ, രണ്ട് നിർദ്ദേശങ്ങൾ, ഒപ്പം അവ ക്രമീകരിക്കുന്ന കാര്യത്തിന്റെ പേരിൽ രണ്ടിനെയും വിളിക്കുന്ന ശീലം. അങ്ങനെ dh.pem tls-auth വരിയിൽ എത്തുന്നു, ക്ലയന്റ് അപ്രതീക്ഷിത കീ ഫോർമാറ്റിനെക്കുറിച്ചുള്ള സന്ദേശത്തോടെ പരാജയപ്പെടുന്നു. നിങ്ങളുടെ മുന്നിലുള്ള തീരുമാനം ഏത് ഫയലാണ് ശക്തമെന്നതല്ല. വിന്യാസത്തിന് യഥാർത്ഥത്തിൽ ഏത് പങ്കാണ് വേണ്ടതെന്നതാണ്, മൂന്ന് വ്യവസ്ഥകൾ അത് തീരുമാനിക്കുന്നു: നിങ്ങളുടെ TLS സ്റ്റാക്ക് ഏത് കീ കൈമാറ്റം ചർച്ച ചെയ്യും, നിയന്ത്രണ-ചാനൽ പ്രാമാണീകരണം നിങ്ങൾക്ക് വേണമോ, വസ്തു രഹസ്യമായി തുടരണമോ.

അവയ്ക്ക് ക്രമത്തിൽ ഉത്തരം നൽകുക, ഫയൽ ചോദ്യം സ്വയം ഉത്തരം നൽകും. അവ ഒഴിവാക്കിയാൽ നിർദ്ദേശങ്ങളുടെ പേരുകൾ പരസ്പരം മാറ്റാവുന്നതായി തോന്നിത്തുടങ്ങും, തെറ്റ് കൃത്യമായി ആ അവസ്ഥയിൽ നിന്നാണ് വരുന്നത്.

ഫയൽ പേരിന് മുമ്പ് ലേബൽ വായിക്കുക

ഫയലിന്റെ ആദ്യ വരി അതിന്റെ പേരിനെക്കാൾ വിവരപ്രദമാണ്, കാരണം പേര് മനുഷ്യരീതിയാണ്, ലേബൽ ഉപകരണം നിർമ്മിക്കുന്നതാണ്. Diffie-Hellman പാരാമീറ്ററുകൾ BEGIN DH PARAMETERS എന്ന PEM ലേബൽ വഹിക്കുന്നു. OpenVPN സ്ഥിര കീ തികച്ചും വ്യത്യസ്ത ഘടനയാണ്, അതിന്റേതായ ഹെഡറും ഹെക്സ് പേലോഡും ഉണ്ട്.

പേര് മാറ്റുന്നത് ഒന്നും പരിവർത്തനം ചെയ്യുന്നില്ല. ta.key എന്ന പേരിലുള്ള പാരാമീറ്റർ ഫയൽ ഇപ്പോഴും പാരാമീറ്ററുകളാണ്, dh.pem എന്ന പേരിലുള്ള സ്ഥിര കീ ഇപ്പോഴും സ്ഥിര കീയാണ്; പാർസർ ഉള്ളടക്കം വായിച്ച് പൊരുത്തക്കേട് നിരസിക്കുന്നു. പ്രൊഫൈൽ തിരുത്തുന്നതിന് മുമ്പ് പരിശോധിക്കുക:

head -n 1 dh.pem
head -n 1 ta.key

ഏത് ഫയൽ വേണമെന്ന് തീരുമാനിക്കുന്ന മൂന്ന് വ്യവസ്ഥകൾ

ആദ്യ വ്യവസ്ഥ കൈമാറ്റമാണ്. പരിമിത മണ്ഡലത്തിലെ Diffie-Hellman ഹാൻഡ്ഷേക്കിന് ഒരു ഗ്രൂപ്പ് വേണം, dh നിർദ്ദേശം സർവർ അതിനുള്ള പാരാമീറ്ററുകൾ പേരിടുന്ന സ്ഥലമാണ്. ദീർഘവൃത്ത വക്രത്തിന്റെ ഹാൻഡ്ഷേക്കിന് ആ ഫയൽ ആവശ്യമേയല്ല, കാരണം വക്രം തന്നെ പാരാമീറ്റർ ഗണമാണ്. നിങ്ങളുടെ സർവർ ECDHE സ്യൂട്ടുകൾ മാത്രം ചർച്ച ചെയ്യുന്നുവെങ്കിൽ, DH ഫയൽ അധിക ശക്തിയല്ല, മരിച്ച ഭാരമാണ്.

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

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

ഓരോ പങ്കിനും ശരിയായ വസ്തു നിർമ്മിക്കുക

നിർദ്ദേശം പ്രതീക്ഷിക്കുന്ന ഫോർമാറ്റ് നിർമ്മിക്കുന്ന ഉപകരണം ഉപയോഗിക്കുക, അവയ്ക്കിടയിൽ പരിവർത്തനം ചെയ്യുന്നതിനുപകരം. OpenVPN 2.6-ലെ പങ്കിട്ട കീയ്ക്ക് ജനറേറ്ററിന്റെ ടൈപ്പ് ചെയ്ത രൂപം ഉദ്ദേശ്യം വ്യക്തമായി പറയുന്നു.

openvpn --genkey tls-auth ta.key

ആ കമാൻഡ് പുതിയ രഹസ്യ വസ്തു സൃഷ്ടിക്കുന്നു; അത് നിലവിലുള്ള കീ നന്നാക്കുന്നതോ പരിശോധിക്കുന്നതോ അല്ല, വീണ്ടും പ്രവർത്തിപ്പിച്ചാൽ മറ്റ് പക്ഷങ്ങളുടെ പക്കലില്ലാത്ത മറ്റൊരു കീ ലഭിക്കും. ഫലമായ ഫയൽ ആവശ്യമുള്ള പക്ഷങ്ങളിലേക്ക് ഏതെങ്കിലും പങ്കിട്ട രഹസ്യത്തിന് ഉപയോഗിക്കുന്ന ചാനലിലൂടെ പകർത്തുക, ദിശാ സമ്പ്രദായം സ്ഥിരമായി നിലനിർത്തുക: tls-auth-ൽ ഒരു വശം key-direction 0, മറുവശം key-direction 1 ഉപയോഗിക്കുന്നു.

DH പാരാമീറ്ററുകൾ ആവശ്യമുള്ളപ്പോൾ പാരാമീറ്റർ നിർമ്മാണത്തിൽ നിന്നാണ് വരുന്നത്, കീ ജനറേറ്ററിൽ നിന്നല്ല, ഫലം പൊതുവായാലും അവയുടെ ഉത്ഭവം പ്രധാനമാണ്. അജ്ഞാതമായ ഉറവിടത്തിൽ നിന്ന് എടുത്ത ഗ്രൂപ്പ് പൊതുവായതുകൊണ്ട് വിശ്വസനീയമാകുന്നില്ല; അത് ഇപ്പോഴും നിങ്ങളുടെ പക്ഷങ്ങൾ യോജിക്കുന്ന ഗ്രൂപ്പായിരിക്കണം, അതിന്റെ വലിപ്പമോ നിർമ്മാണമോ ദുർബലമാക്കാത്തതുമായിരിക്കണം.

dh none എന്താണ് അർത്ഥമാക്കുന്നത്, എന്തല്ല

dh none ഇടുങ്ങിയ അർത്ഥമുള്ള യഥാർത്ഥ നിർദ്ദേശമാണ്: പരിമിത മണ്ഡലത്തിലെ പാരാമീറ്റർ ഫയലൊന്നും ലോഡ് ചെയ്യപ്പെടില്ല, കാരണം ഹാൻഡ്ഷേക്ക് ദീർഘവൃത്ത വക്ര Diffie-Hellman ഉപയോഗിക്കുന്നു. എന്തെങ്കിലും ദുർബലമാക്കുക എന്ന അർത്ഥത്തിൽ “DH ഘട്ടം ഒഴിവാക്കുക” എന്ന ചുരുക്കമല്ല അത്, OpenVPN-നോട് മറ്റൊരു ഫയൽ പകരമായി സ്വീകരിക്കാൻ പറയുന്നതുമില്ല.

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

തെറ്റായ ഫയൽ ഇതിനകം വിന്യസിച്ചിട്ടുണ്ടെങ്കിൽ

പ്രൊഫൈൽ ഉടമയിൽ നിന്ന് ഉദ്ദേശിച്ച രഹസ്യം പുനഃസ്ഥാപിക്കുക, അത് ചെയ്യുമ്പോൾ സർട്ടിഫിക്കറ്റ് പരിശോധനയിൽ തൊടരുത്. പരാജയം ഫോർമാറ്റ് പൊരുത്തക്കേടാണ്, വിശ്വാസ പരാജയമല്ല, പിശക് ഒഴിവാക്കാൻ പരിശോധന ഓഫ് ചെയ്യുന്നത് സ്റ്റാർട്ടപ്പ് പ്രശ്നത്തെ നിശ്ശബ്ദ പ്രശ്നമാക്കി മാറ്റുന്നു.

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

അഞ്ച് മിനിറ്റ് പരിശോധന നിങ്ങൾ ഏത് അവസ്ഥയിലാണെന്ന് തീരുമാനിക്കുന്നു: ഓരോ ഫയലിന്റെയും ആദ്യ വരി വായിക്കുക, അതിനെ പരാമർശിക്കുന്ന നിർദ്ദേശം സ്ഥിരീകരിക്കുക, ഫയലിന്റെ വിതരണം വസ്തുവിന്റെ ആവശ്യവുമായി പൊരുത്തപ്പെടുന്നുവെന്ന് സ്ഥിരീകരിക്കുക. പ്രവർത്തിക്കുന്ന PKI വീണ്ടും നിർമ്മിക്കുന്നതിനേക്കാൾ ചെറിയ ജോലിയാണിത്, മൂന്ന് വ്യവസ്ഥകൾ എപ്പോഴും ചൂണ്ടിയതും ഇതിലേക്കാണ്.