പാസ്വേഡ് മാത്രമുള്ള OpenVPN പ്രൊഫൈലിൽ ഏത് CA ഫയലാണ് പോകുന്നത്?
CA ഫീൽഡ് സർവർ പരിശോധിക്കുന്നു, ഉപയോക്താവിനെയല്ല. പ്രൊഫൈലിൽ ഇതിനകം എന്തുണ്ടെന്ന് നോക്കുക, നാല് തരം വസ്തുക്കൾ വേർതിരിക്കുക, അടുത്ത പിശക് വായിക്കുക.
നാല് ചോദ്യങ്ങൾ ക്രമത്തിൽ നടത്തുക, അപ്പോൾ CA സംവാദം അവ്യക്തമല്ലാതാകും. ഓപ്പറേറ്റർ യഥാർത്ഥത്തിൽ ഏത് വസ്തുവാണ് നൽകിയത്, പ്രൊഫൈലിൽ ഇതിനകം എന്തുണ്ട്, ഏത് ഫീൽഡാണ് ചോദിക്കുന്നത്, ഫയൽ ലോഡ് ചെയ്ത ശേഷം എന്ത് സംഭവിക്കുന്നു? ഓപ്പറേറ്ററുടെ സ്വന്തം നിർദ്ദേശങ്ങളിൽ നിന്ന് ഉത്തരം നൽകാനാകാത്ത ആദ്യ ചോദ്യത്തിൽ നിർത്തുക, കാരണം അതിനപ്പുറം ഊഹിക്കുന്നതാണ് പൊതു CA സർട്ടിഫിക്കറ്റ് സർവറിൽ നിന്ന് ഒരിക്കലും പുറത്തുപോകാനാകാത്ത സ്വകാര്യ കീയുമായി ചേരുന്ന വഴി.
ക്രമം പ്രധാനമാണ്: അവസാന രണ്ട് ചോദ്യങ്ങൾ ഏത് വസ്തു ഉണ്ടായിരിക്കണമെന്ന് അറിഞ്ഞ ശേഷം മാത്രമേ അർത്ഥവത്താകൂ.
പ്രൊഫൈലിൽ ഇതിനകം ഉള്ളതിൽ നിന്ന് തുടങ്ങുക
പ്രൊഫൈൽ ഒരു ടെക്സ്റ്റ് എഡിറ്ററിൽ തുറന്ന് ഫയൽ തിരയുന്നതിന് മുമ്പ് ca ബ്ലോക്ക് തിരയുക. ഓപ്പറേറ്ററുടെ പൊതു CA ഉള്ള ഇൻലൈൻ ca ബ്ലോക്ക് എന്നാൽ പ്രൊഫൈൽ സ്വയംപര്യാപ്തമാണ്, ഇപ്പോഴും CA ഫയൽ ആവശ്യപ്പെടുന്ന ക്ലയന്റ് മറ്റൊരു പ്രൊഫൈലോ അപൂർണ്ണമായ ഇംപോർട്ടോ വായിക്കുന്നുണ്ടാകാം. പ്രൊഫൈലിൽ പകരം പാതയിലേക്ക് ചൂണ്ടുന്ന ca വരി ഉണ്ടെങ്കിൽ, ആ പാത ചില ഇന്റഗ്രേഷനുകളിൽ ക്ലയന്റിന്റെ പ്രവർത്തന ഡയറക്ടറിയുമായി ബന്ധപ്പെട്ടതും മറ്റുള്ളവയിൽ കേവലവുമാണ്. എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ഏത് രൂപമാണ് നിങ്ങൾക്കുള്ളതെന്ന് കുറിക്കുക.
ca /absolute/path/operator-ca.crt auth-user-pass remote-cert-tls server
പ്രൊഫൈൽ പരാമർശിക്കുന്ന ഫയലുകൾക്കായി നൽകിയ പാക്കേജ് പരിശോധിക്കുക: ഒരു CA സർട്ടിഫിക്കറ്റ്, ചിലപ്പോൾ വേറിട്ട ക്ലയന്റ് സർട്ടിഫിക്കറ്റും കീയും, ഒപ്പം tls-auth അല്ലെങ്കിൽ tls-crypt ഫയലും. നാല് ഫയലുകൾ പരാമർശിച്ച് രണ്ടെണ്ണവുമായി വരുന്ന പ്രൊഫൈൽ അപൂർണ്ണമാണ്, ഫീൽഡുകളിലേക്ക് ചൂണ്ടുന്നതിന്റെ ഒരു അളവും അത് ശരിയാക്കില്ല. യാദൃശ്ചികമായി കൈവശമുള്ള സർട്ടിഫിക്കറ്റ് പകരം വയ്ക്കുന്നതിന് പകരം ഓപ്പറേറ്ററോട് കാണാത്ത ഭാഗം ആവശ്യപ്പെടുക.
നാല് തരം വസ്തുക്കൾ വേർതിരിക്കുക
CA സർട്ടിഫിക്കറ്റ് സർവറിന്റെ ഐഡന്റിറ്റി പരിശോധിക്കാൻ ഉപയോഗിക്കുന്ന പൊതു വസ്തുവാണ്. ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് ഉപയോക്താവിനെയോ ഉപകരണത്തെയോ സർവറിന് തിരിച്ചറിയിക്കുന്നു. സ്വകാര്യ കീ ആ ക്ലയന്റ് സർട്ടിഫിക്കറ്റിന്റെ രഹസ്യ പകുതിയാണ്, അത് ഒരിക്കലും CA-യുടെ ഒപ്പിടൽ കീയോ സർവർ കീയോ ആകരുത്. tls-auth അല്ലെങ്കിൽ tls-crypt വസ്തു നിയന്ത്രണ ചാനൽ സംരക്ഷിക്കുന്ന വേറിട്ട പങ്കിട്ട രഹസ്യമാണ്. ഈ നാലും പരസ്പരം മാറ്റാനാകുന്നതല്ല, CA ഫീൽഡ് ഒരു ക്ലയന്റ് സർട്ടിഫിക്കറ്റിലേക്ക് ചൂണ്ടിക്കാണിച്ചാൽ വിശ്വാസ പ്രശ്നം പോലെ തോന്നുന്ന പരിശോധനാ പരാജയം ഉണ്ടാകും.
പാസ്വേഡ് മാത്രമുള്ള പ്രാമാണീകരണം നാലിൽ ഏതാണ് നിങ്ങൾക്ക് വേണ്ടതെന്ന് മാറ്റുന്നു, അവയുടെ അർത്ഥമല്ല. auth-user-pass, remote-cert-tls server എന്നിവയുണ്ടായാലും ക്ലയന്റ് ഇപ്പോഴും CA-യ്ക്കെതിരെ സർവർ പരിശോധിക്കുന്നു, അതിനാലാണ് ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് ഇല്ലാത്തപ്പോഴും CA ഫീൽഡ് കാണുന്നത്. ക്ലയന്റ് സർട്ടിഫിക്കറ്റും ആവശ്യമാണോ എന്ന് ഓപ്പറേറ്ററുടെ നയമാണ് തീരുമാനിക്കുന്നത്, ഒരു സംവാദത്തിനും അത് നിങ്ങളോട് പറയാനാകില്ല.
ക്ലയന്റിനെ വിശ്വാസ ഫയലിലേക്ക് ചൂണ്ടിക്കാണിക്കുക
CA സർട്ടിഫിക്കറ്റ് ഫയൽ തന്നെ തിരഞ്ഞെടുക്കുക, അത് ഉൾക്കൊള്ളുന്ന ഫോൾഡറല്ല, ക്ലയന്റ് ഐഡന്റിറ്റി ഉൾക്കൊള്ളുന്ന .p12 ബണ്ടിലല്ല. Windows-ൽ പാതയുടെ വാക്യഘടനയും ഫയൽ തിരഞ്ഞെടുക്കലും മിക്ക ഗൈഡുകളിലെ Linux ഉദാഹരണങ്ങളിൽ നിന്ന് വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു, അതിനാൽ ഇൻസ്റ്റാൾ ചെയ്ത ക്ലയന്റ് സ്വീകരിക്കുന്നത് ഉപയോഗിക്കുകയും അത് പ്രവർത്തിപ്പിക്കുന്ന അക്കൗണ്ടിന് ഫയൽ വായിക്കാനാകുമെന്ന് ഉറപ്പാക്കുകയും ചെയ്യുക. അനുമതി പ്രശ്നവും ഇല്ലാത്ത ഫയലും സംവാദത്തിൽ ഒരുപോലെ കാണാമെങ്കിലും വ്യത്യസ്ത ലോഗ് വരികൾ ഉണ്ടാക്കുന്നു. തിരഞ്ഞെടുത്ത ശേഷം ക്ലയന്റ് തിരഞ്ഞെടുപ്പ് നിലനിർത്തിയെന്ന് ഉറപ്പാക്കാൻ പ്രൊഫൈൽ ക്രമീകരണങ്ങൾ വീണ്ടും തുറക്കുക.
<ca> -----BEGIN CERTIFICATE----- ...operator-provided public CA... -----END CERTIFICATE----- </ca>
ക്ലയന്റ് ഇൻലൈൻ ബ്ലോക്കുകൾ പിന്തുണച്ചാൽ, കൈകൊണ്ട് കൂട്ടിയ പ്രൊഫൈലിനേക്കാൾ ഓപ്പറേറ്ററുടെ ഇൻലൈൻ പ്രൊഫൈലിന് മുൻഗണന നൽകുക. ഇൻലൈൻ വസ്തു പ്രൊഫൈലിനൊപ്പം യാത്ര ചെയ്യുന്നു, വീണ്ടും ഇംപോർട്ട് ചെയ്യുമ്പോഴും നിലനിൽക്കുന്നു, എന്നാൽ കേവല പാത പ്രൊഫൈൽ മറ്റൊരു മെഷീനിലേക്ക് മാറുന്ന നിമിഷം തകരുന്നു.
അതേ പിശകല്ല, അടുത്ത പിശക് വായിക്കുക
ശരിയായ CA നൽകുന്നതിന്റെ ഉദ്ദേശ്യം പിശക് മാറ്റുകയാണ്, അത് മായ്ച്ചുകളയുകയല്ല. CA ലോഡ് ചെയ്ത ശേഷമുള്ള സർവർ ഐഡന്റിറ്റി പരാജയം എന്നാൽ സർട്ടിഫിക്കറ്റ് പ്രതീക്ഷിച്ച പേരുമായോ remote-cert-tls പ്രതീക്ഷയുമായോ പൊരുത്തപ്പെട്ടില്ല, ഇത് പാസ്വേഡ് നിരസിക്കലിൽ നിന്ന് വ്യത്യസ്തമായ അറ്റകുറ്റപ്പണിയാണ്. പാസ്വേഡ് നിരസിക്കൽ എന്നാൽ TLS പാളി വിജയിച്ചു, ക്രെഡൻഷ്യൽ തെറ്റാണ്. ആദ്യ പുതിയ സന്ദേശം സൂക്ഷിക്കുക; അതാണ് ഉപയോഗപ്രദം.
ബന്ധിപ്പിക്കുന്നെങ്കിലും എങ്ങുമെത്താത്ത ക്ലയന്റ് വിശ്വാസം പൂർണ്ണമായി കടന്നുപോയി, ഇപ്പോൾ റൂട്ടിംഗ് അല്ലെങ്കിൽ DNS ചോദ്യം നേരിടുന്നു.
ആ സംവാദം കടക്കാൻ ഒരിക്കലും പരിശോധന നിർത്തരുത്. ഏത് സർട്ടിഫിക്കറ്റും സ്വീകരിക്കുന്ന ക്ലയന്റിന് CA ആവശ്യപ്പെടാൻ കാരണമില്ല, അത് നിർമ്മിക്കുന്ന ടണൽ ഓപ്പറേറ്റർ ഉദ്ദേശിച്ച ടണലല്ല.