OpenVPN പ്രൊഫൈലിൽ മൂന്ന് സർട്ടിഫിക്കറ്റ് ബ്ലോക്കുകൾ ഉണ്ട്: ഏതാണ് രഹസ്യം?

ഒരു വരി മാറ്റാൻ നിങ്ങൾ .ovpn ഫയൽ തുറക്കുമ്പോൾ, എല്ലാം ലോഗിൻ വിവരങ്ങളെപ്പോലെ തോന്നുന്ന മൂന്ന് base64 ബ്ലോക്കുകൾ കാണാം. ഒന്ന് പ്രസിദ്ധീകരിക്കാൻ സുരക്ഷിതമാണ്, മറ്റൊന്ന് പാസ്വേഡ് പോലെ സംവേദനക്ഷമമാണ്, മൂന്നാമത്തേത് അതിന്റെ ജോഡിയുമായി മറ്റെന്തെങ്കിലും ഒപ്പിട്ടില്ലെങ്കിൽ ഒന്നും അർഥമാക്കാത്ത പൊതു കീയാണ്. ബ്ലോക്കുകൾ പരസ്പരം മാറ്റാവുന്നതുപോലെ തോന്നുന്നതിനാൽ ജനങ്ങൾ മുഴുവൻ ഫയലും സഹായ ത്രെഡിൽ ഒട്ടിക്കുന്നു, അങ്ങനെ ക്ലൈന്റ് കീ പൊതു ആർക്കൈവിൽ എത്തുന്നു. ഏത് ബ്ലോക്ക് എന്ത് ചെയ്യുന്നു എന്ന് വേർതിരിക്കുന്നത് ഈ പ്രൊഫൈലുകളെ ചുറ്റിപ്പറ്റിയുള്ള മിക്ക ആശയക്കുഴപ്പവും വിശദീകരിക്കുന്നു, കൂടാതെ ഏത് തകരാറുകൾ നിങ്ങൾ തന്നെ പരിഹരിക്കണമെന്നും അത് പറയുന്നു.

ഒരു ഫയൽ, മൂന്ന് ബ്ലോക്ക്, വ്യത്യസ്ത ജോലികൾ

സാധാരണ പ്രൊഫൈൽ BEGIN, END അടയാളങ്ങൾക്കിടയിൽ ca ബ്ലോക്ക്, cert ബ്ലോക്ക്, key ബ്ലോക്ക് എന്നിവ ഉൾപ്പെടുത്തുന്നു, അല്ലെങ്കിൽ അവയെ വെവ്വേറെ ഫയലുകളായി ചൂണ്ടിക്കാണിക്കുന്നു. ചില പ്രൊഫൈലുകൾ tls-auth അല്ലെങ്കിൽ tls-crypt കീയ്ക്കായി നാലാമത്തെ ബ്ലോക്ക് ചേർക്കുന്നു, അത് സർട്ടിഫിക്കറ്റല്ല, പങ്കിട്ട രഹസ്യമാണ്. ക്ലൈന്റ് ഓരോ ബ്ലോക്കും അതിനെ പേരിടുന്ന നിർദ്ദേശത്തിന് അനുസരിച്ച് വായിക്കുന്നു, അതിനാൽ ലേബലുകൾ അവ കാണുന്ന ക്രമത്തേക്കാൾ പ്രധാനമാണ്.

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

ബ്ലോക്കുകൾക്ക് ചുറ്റുമുള്ള നിർദ്ദേശങ്ങൾ അവ എങ്ങനെ ഉപയോഗിക്കുന്നു എന്ന് തീരുമാനിക്കുന്നു. ca മാറ്റിയാൽ ക്ലൈന്റ് മറ്റൊരു അധികാരിയെ വിശ്വസിക്കുന്നു; key മാറ്റാതെ cert മാറ്റിയാൽ വിശ്വാസവുമായി യാതൊരു ബന്ധവുമില്ലാത്ത പൊരുത്തക്കേടിൽ ഹാൻഡ്ഷേക്ക് പരാജയപ്പെടുന്നു.

CA ബ്ലോക്ക് പൊതുവാണ്, CA കീ ഒരിക്കലുമല്ല

സർട്ടിഫിക്കറ്റ് അധികാരി പൊതു കീയെ ഒരു ഐഡന്റിറ്റിയുമായി ബന്ധിപ്പിക്കുന്ന സർട്ടിഫിക്കറ്റുകളിൽ ഒപ്പിടുന്നു, അതിന്റെ സ്വന്തം സർട്ടിഫിക്കറ്റാണ് ചങ്ങല വിശ്വസനീയമാണോ എന്ന് ക്ലൈന്റ് തീരുമാനിക്കുന്ന ആധാരം. ആ സർട്ടിഫിക്കറ്റ് രൂപകൽപ്പനയാൽ പൊതുവാണ്: അത് ഓരോ പ്രൊഫൈലിനുള്ളിലും അയയ്ക്കുന്നത് സാധാരണമാണ്, അതുകൊണ്ടുതന്നെ സ്വയം ഒപ്പിട്ട വിന്യാസത്തിന് വാണിജ്യ അധികാരിയില്ലാതെ പ്രവർത്തിക്കാനാകുന്നു.

ക്ലൈന്റ് പ്രൊഫൈലിൽ ഒരിക്കലും കാണരുതാത്തത് അധികാരിയുടെ സ്വകാര്യ ഒപ്പ് കീയാണ്. ഒന്നും പരിശോധിക്കാൻ ക്ലൈന്റിന് അത് ആവശ്യമില്ല, അതിന്റെ സാന്നിധ്യം എന്നാൽ പ്രൊഫൈൽ ഉള്ള ആർക്കും മുഴുവൻ വിന്യാസത്തിനും പുതിയ ഐഡന്റിറ്റികൾ സൃഷ്ടിക്കാമെന്നാണ്.

അധികാരിയെ വിശ്വസിക്കുന്നതും കേൾക്കുന്നതിലും ഇടുങ്ങിയതാണ്. CA ഒപ്പിട്ട ഏത് സർട്ടിഫിക്കറ്റും സ്വീകരിക്കുന്ന ക്ലൈന്റ് അതേ CAയിൽ മറ്റൊരു സേവനത്തിന് നൽകിയ സർട്ടിഫിക്കറ്റും സ്വീകരിക്കും. പ്രതീക്ഷിക്കുന്ന സർവർ റോളോ പേരോ പിൻ ചെയ്യുന്ന ഓപ്ഷനുകൾ ആ വിടവ് അടയ്ക്കുന്നു, കൂടാതെ TLS ഓപ്ഷൻ റഫറൻസ് അത് ചെയ്യുന്ന പരിശോധനാ നിർദ്ദേശങ്ങൾ പട്ടികപ്പെടുത്തുന്നു.

സർവർ, ക്ലൈന്റ് സർട്ടിഫിക്കറ്റുകൾ വിപരീത ദിശകളിലേക്ക് ചൂണ്ടുന്നു

സർവറിന്റെ സർട്ടിഫിക്കറ്റാണ് ശരിയായ അന്തിമ പോയിന്റിൽ എത്തിയെന്ന് ഉറപ്പാക്കാൻ ക്ലൈന്റ് പരിശോധിക്കുന്നത്. നിങ്ങളുടെ ക്ലൈന്റ് സർട്ടിഫിക്കറ്റ് മറിച്ചാണ് പ്രവർത്തിക്കുന്നത്: ഈ ഉപകരണമോ ഉപയോക്താവോ താൻ രജിസ്റ്റർ ചെയ്തതാണെന്ന് തീരുമാനിക്കാൻ സർവർ അത് ഉപയോഗിക്കുന്നു. ഒരേ ഫോർമാറ്റ്, വിപരീത വിശ്വാസ ദിശ.

വിലാസം ഐഡന്റിറ്റിയല്ല. ശരിയായ IP ലഭിക്കുന്നത് ആരാണ് ഉത്തരം നൽകിയതെന്ന് ഒന്നും തെളിയിക്കുന്നില്ല, അതിനാൽ ഹോസ്റ്റ്നെയിമോ സർട്ടിഫിക്കറ്റ് പേരോ പരിശോധിക്കുന്നത് ഇപ്പോഴും പ്രൊഫൈലിൽ ഉണ്ട്. അക്കൗണ്ട് പാസ്വേഡും ആവശ്യമായ ക്ലൈന്റ് സർട്ടിഫിക്കറ്റിനെ നിശബ്ദമായി പകരം വയ്ക്കുന്നില്ല, കാരണം രണ്ടും വ്യത്യസ്ത ഘട്ടങ്ങളിൽ പരിശോധിക്കുന്നു, വിന്യാസം രണ്ടും ആവശ്യപ്പെടാം.

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

ഒരുപോലെ തോന്നുന്ന, എന്നാൽ ഒരുപോലെയല്ലാത്ത രണ്ട് അഭ്യർഥനകൾ

എൻക്രിപ്റ്റ് ചെയ്ത രൂപത്തിൽ സൂക്ഷിച്ച കീ ക്ലൈന്റിന് ഉപയോഗിക്കാൻ പാസ്ഫ്രെയ്സ് ആവശ്യപ്പെടുന്നു. VPN സേവനം വെവ്വേറെ അക്കൗണ്ട് പാസ്വേഡ് ആവശ്യപ്പെടാം, രണ്ട് അഭ്യർഥനകളും ഏതാണ്ട് ഒരേ വാക്കുകളിൽ കുറച്ച് സെക്കൻഡുകൾ വ്യത്യാസത്തിൽ വരാം. പാസ്ഫ്രെയ്സ് നിങ്ങളുടെ ഡിസ്കിലെ ഫയൽ സംരക്ഷിക്കുന്നു; പാസ്വേഡ് സർവറിനോട് അക്കൗണ്ട് തെളിയിക്കുന്നു. രണ്ടും കൂട്ടിക്കുഴയ്ക്കുന്നത് സഹായിക്കാനാകാത്ത പാസ്വേഡ് റീസെറ്റുകളിലേക്ക് ആളുകളെ അയയ്ക്കുന്നു.

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

സർട്ടിഫിക്കറ്റ് യഥാർഥത്തിൽ കാലഹരണപ്പെട്ടാൽ, പകരം നൽകിയവരിൽ നിന്നുതന്നെ വരണം. മറ്റൊരാളുടെ കീ പുതുക്കലിന്റെ വഴിയല്ല, സഹപ്രവർത്തകനിൽ നിന്ന് പ്രവർത്തിക്കുന്ന പ്രൊഫൈൽ കടം വാങ്ങുന്നതും അല്ല.

വ്യക്തമായ ഹാൻഡ്ഷേക്ക് എന്ത് തെളിയിക്കുന്നു, എന്ത് തെളിയിക്കുന്നില്ല

പൂർത്തിയായ TLS ഹാൻഡ്ഷേക്കിൽ എത്തുന്നു എന്നത് ക്രമീകരിച്ച ഐഡന്റിറ്റി ബന്ധം നിലനിന്നു എന്നാണ്: സർവർ സർട്ടിഫിക്കറ്റ് നിങ്ങളുടെ CAയിലേക്ക് ചേർന്നു, നിങ്ങളുടെ സർട്ടിഫിക്കറ്റ് സ്വീകരിച്ചു. ഇത് ഓപ്പറേറ്ററുടെ ലോഗിംഗ് നയത്തെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, ടണൽ ഉയർന്നശേഷം നിങ്ങളുടെ ആപ്പുകൾ പ്രവർത്തിക്കുമോ എന്നും പറയുന്നില്ല.

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