VPN വഴി MySQL: എൻക്രിപ്ഷൻ മാത്രമല്ല, സെർവർ പരിശോധിക്കുക
തെറ്റായ ഹോസ്റ്റിലേക്കുള്ള എൻക്രിപ്ഷനും തെറ്റാണ്. ssl-mode മൂല്യങ്ങൾ താരതമ്യം ചെയ്യുക, തുടർന്ന് നിങ്ങൾ ഉദ്ദേശിച്ച സെർവറിനെ പേരെടുത്ത് പറയുന്നതും അത് തെളിയിക്കുന്നതുമായ ഒരു കണക്ഷൻ പ്രവർത്തിപ്പിക്കുക.
നിങ്ങൾ 10.20.4.15 ലേക്കുള്ള കണക്ഷൻ സംരക്ഷിക്കുന്നു, VPN വീഴുന്നു, എന്നിട്ടും ക്ലയന്റ് കണക്ട് ചെയ്യുന്നു. അത് നല്ല വാർത്തയല്ല. സ്വകാര്യ വിലാസം നിങ്ങൾ ഏത് റൂട്ടിംഗ് സന്ദർഭത്തിലായാലും അതിനുള്ളിലെ ഒരു സ്ഥലമാണ്, ഒരേ ശ്രേണികൾ പല നെറ്റ്വർക്കുകളും ഉപയോഗിക്കുന്നു. ക്ലയന്റ് ഒരു MySQL സെർവറിലെത്തി, പക്ഷേ ഒരുപക്ഷേ നിങ്ങളുടേതല്ല.
പരിഹാരത്തിന് രണ്ട് പകുതികളുണ്ട്, അവയിൽ ഒന്ന് മാത്രമാണ് നെറ്റ്വർക്കിനെക്കുറിച്ച്. കണക്ഷനെ അതിന്റെ ഉദ്ദേശിച്ച പാതയിൽ നിർത്തുക, ക്ലയന്റ് സംസാരിക്കുന്ന സെർവറിനെ ആധികാരികമാക്കാൻ പ്രേരിപ്പിക്കുക. ആദ്യ പകുതിയാണ് VPN സഹായിക്കുന്നിടം; രണ്ടാം പകുതി കോൺഫിഗർ ചെയ്യണം.
കൃത്യമായി എന്തിലേക്കാണ് എൻക്രിപ്റ്റ് ചെയ്തിരിക്കുന്നത്?
TLS സംഭാഷണത്തെ നടുവിലുള്ള ആരിൽ നിന്നും സംരക്ഷിക്കുന്നു, ക്ലയന്റ് പരിശോധിക്കുന്നില്ലെങ്കിൽ എൻഡ്പോയിന്റ് താൻ ആരാണെന്ന് അവകാശപ്പെടുന്നു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. വിശ്വസനീയമായ അധികാരിയുമായി സാധുതയുള്ള സർട്ടിഫിക്കറ്റ്, സർട്ടിഫിക്കറ്റ് ആ അധികാരിയിൽ നിന്നാണെന്ന് തെളിയിക്കുന്നു. നിങ്ങൾ എത്താൻ ഉദ്ദേശിച്ച ഹോസ്റ്റ്നാമത്തിന് സർട്ടിഫിക്കറ്റ് നൽകിയെന്ന് അത് തെളിയിക്കുന്നില്ല, ഇവ വ്യത്യസ്ത ചോദ്യങ്ങളാണ്.
ഇത് സൈദ്ധാന്തിക വിടവല്ല. ക്യാപ്റ്റീവ് പോർട്ടലുകൾ, തെറ്റായ VRF പിശകുകൾ, ഒന്നുമേലെ വരുന്ന വിലാസ പ്ലാനുകൾ എന്നിവയെല്ലാം നിങ്ങളോട് TLS ചർച്ച ചെയ്യാൻ പൂർണ്ണമായി തയ്യാറായ സെർവർ സൃഷ്ടിക്കുന്നു. ക്ലയന്റ് എൻക്രിപ്ഷൻ മാത്രം ആവശ്യപ്പെടുന്നുവെങ്കിൽ, സെഷൻ സ്വകാര്യമാണ്, പക്ഷേ തെറ്റായ ഡാറ്റാബേസിലേക്കാണ്.
അതിനാൽ പ്രസക്തമായ ചോദ്യം കണക്ഷൻ എൻക്രിപ്റ്റ് ചെയ്തിട്ടുണ്ടോ എന്നല്ല, നിങ്ങൾ ഉദ്ദേശിച്ച ഐഡന്റിറ്റിയിലേക്കാണോ എന്നാണ്. MySQL ക്ലയന്റിൽ, ആ വ്യത്യാസം പൂർണ്ണമായും ssl-mode ക്രമീകരണത്തിലാണ് കഴിയുന്നത്.
പ്രായോഗികമായി അഞ്ച് ssl-mode മൂല്യങ്ങൾ
അഞ്ച് മൂല്യങ്ങളുണ്ട്, അവയിൽ ഒന്ന് മാത്രമാണ് ഈ കൈപ്പുസ്തകത്തിന്റെ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നത്. പട്ടിക ഓരോന്നിന്റെയും പേര് സൂചിപ്പിക്കുന്നതല്ല, യഥാർത്ഥത്തിൽ എന്ത് ഉറപ്പുനൽകുന്നു എന്ന് പട്ടികപ്പെടുത്തുന്നു.
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates the CA and checks that the certificate names the host the client used |
ഈ ലേഖനത്തിലെ ചോദ്യത്തിന് അവസാന വരി മാത്രമാണ് ഉത്തരം നൽകുന്നത്. PREFERRED അതിൽത്തന്നെ ശ്രദ്ധിക്കപ്പെടേണ്ടതാണ്, കാരണം നിശബ്ദമായി സാധാരണ ടെക്സ്റ്റിലേക്ക് വീഴുന്ന ക്ലയന്റ് നിരസിക്കുന്നതിനേക്കാൾ മോശമാണ്: എൻക്രിപ്ഷൻ ഉണ്ടെന്ന് നിങ്ങൾ വിശ്വസിക്കുന്നു, പക്ഷേ പാക്കറ്റ് ക്യാപ്ചർ അതിനോട് യോജിക്കുന്നില്ല.
ഇന്ന് പ്രവർത്തിപ്പിക്കാവുന്ന ഒരു കണക്ഷൻ
താഴെയുള്ള കമാൻഡ് ഉപയോഗിക്കേണ്ട രൂപമാണ്, രണ്ട് പ്ലേസ്ഹോൾഡറുകളോടെ: അംഗീകരിച്ച ഡാറ്റാബേസ് പേരും അംഗീകരിച്ച ചാനലിലൂടെ ലഭിച്ച CA ഫയലും. രണ്ടും സെർവർ ആദ്യ സമ്പർക്കത്തിൽ വാഗ്ദാനം ചെയ്യുന്നതിൽ നിന്ന് എടുക്കരുത്.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password മൂല്യമില്ലാതെ ഇൻപുട്ട് ആവശ്യപ്പെടുന്നു, ഇത് രഹസ്യത്തെ പ്രോസസ് പട്ടികയിൽ നിന്നും നിങ്ങളുടെ ഷെൽ ചരിത്രത്തിൽ നിന്നും പുറത്ത് നിർത്തുന്നു. പങ്കിട്ട ജമ്പ് ഹോസ്റ്റുകളിൽ വലിയ നേട്ടമുള്ള ചെറിയ ശീലമാണിത്, അവിടെ കമാൻഡ് ലൈൻ മറ്റ് ഉപയോക്താക്കൾക്ക് കാണാം.
ഇത് പരാജയപ്പെടുമ്പോൾ, പിശക് ടെക്സ്റ്റ് കേസുകളെ അന്തർജ്ഞാനത്തേക്കാൾ നന്നായി വേർതിരിക്കുന്നു. CA പരാജയം എന്നാൽ ചെയിൻ സാധുതയുള്ളതല്ല, സെർവർ സർട്ടിഫിക്കറ്റിൽ ഏത് CA ആണ് ഒപ്പിട്ടതെന്ന് നോക്കണം. ഹോസ്റ്റ്നാമ പരാജയം എന്നാൽ ചെയിൻ കൃത്യമാണ്, പേര് പൊരുത്തപ്പെടുന്നില്ല, സാധാരണയായി ഇത് തെറ്റായ സെർവറിലേക്കല്ല, ശരിയായ സെർവറിലേക്ക് തെറ്റായ പേരിൽ കണക്ട് ചെയ്തു എന്നാണ് അർത്ഥം.
പ്രോംപ്റ്റ് കാണുന്നത് പാസ്വേഡ് ഇതിനകം അയച്ചു എന്നതിന് തെളിവല്ല, പരാജയപ്പെട്ട കണക്ഷൻ ക്ലയന്റിൽ നിന്ന് ഒന്നും പുറത്തുപോയില്ലെന്ന് തെളിയിക്കുന്നുമില്ല. കഴിഞ്ഞ സംഭവം പുനർനിർമ്മിക്കുകയാണെങ്കിൽ, ക്ലയന്റ്, അതിന്റെ കോൺഫിഗറേഷൻ, ഓതന്റിക്കേഷൻ പ്ലഗിൻ, പരാജയപ്പെട്ട ഘട്ടം എന്നിവ തിരിച്ചറിയുക. അവസാന പിശക് സന്ദേശത്തിൽ നിന്ന് എക്സ്പോഷർ കണക്കാക്കുന്നത് ഊഹമാണ്.
പേര് ഒരു ടണലിൽ നിന്ന് വരുമ്പോൾ
ലോക്കൽ പോർട്ട് ഫോർവേഡിംഗ് ആളുകളെ അമ്പരപ്പിക്കുന്ന രീതിയിൽ ഐഡന്റിറ്റി പരിശോധന തകർക്കുന്നു. ഒരു ലോക്കൽ പോർട്ട് ഡാറ്റാബേസിലേക്ക് ഫോർവേഡ് ചെയ്ത് localhost ലേക്ക് കണക്ട് ചെയ്താൽ, ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് localhost എന്നതിനെതിരെ സാധുതയുള്ളതാക്കുന്നു, ആ പേരിന് സർട്ടിഫിക്കറ്റ് നൽകിയിട്ടില്ല. കണക്ഷൻ പൂർണ്ണമായും സുരക്ഷിതമായിരിക്കാം, പരിശോധന എന്നിട്ടും പരാജയപ്പെടും, അതാണ് പരിശോധന ഉദ്ദേശിച്ചതുപോലെ പ്രവർത്തിക്കുന്നത്.
രണ്ട് സത്യസന്ധമായ ഉത്തരങ്ങളുണ്ട്. ഫോർവേഡ് ചെയ്ത എൻഡ്പോയിന്റിന് ലൂപ്പ്ബാക്ക് വിലാസത്തിലേക്ക് പരിഹരിക്കുന്നതും സെർവർ സർട്ടിഫിക്കറ്റിൽ കാണുന്നതുമായ ഒരു പേര് നൽകുക, അല്ലെങ്കിൽ ക്ലയന്റ് യഥാർത്ഥ ഐഡന്റിറ്റി പരിശോധിക്കാൻ ഹോസ്റ്റ്നാമം തുടക്കം മുതൽ അവസാനം വരെ ഉപയോഗിക്കുക. ആദ്യത്തേത് ഡെവലപ്പർമാർക്ക് സൗകര്യപ്രദവും സർട്ടിഫിക്കറ്റ് ജോലി ആവശ്യവുമാണ്; രണ്ടാമത്തേത് ചിന്തിക്കാൻ എളുപ്പവും ഓട്ടോമേഷന് ശരിയായ ഡിഫോൾട്ട് ആയിരിക്കും. ഫോർവേഡിംഗ് പ്രവർത്തിക്കാൻ പരിശോധന പ്രവർത്തനരഹിതമാക്കുന്നത് നിങ്ങൾ ചേർക്കാൻ ശ്രമിച്ച സ്വഭാവം വലിച്ചെറിയുന്നു.
സ്വീകാര്യത മൂന്ന് നിബന്ധനകളാണ്
സ്വീകാര്യതാ പരിശോധന മൂന്ന് വേറിട്ട പ്രസ്താവനകളായി എഴുതുക: കണക്ഷൻ ഉദ്ദേശിച്ച പാത ഉപയോഗിച്ചു, എൻക്രിപ്ഷൻ മുൻഗണനയല്ല, നിർബന്ധമായിരുന്നു, സെർവറിന്റെ ഐഡന്റിറ്റി വിശ്വസനീയമായ വസ്തുവിനെതിരെ പരിശോധിച്ചു. പച്ച VPN ഐക്കൺ അവയിൽ ഒന്നും സ്ഥാപിക്കുന്നില്ല.
GUI ക്ലയന്റുകൾക്കും MariaDB-യ്ക്കും, ഫ്ലാഗിന്റെ അക്ഷരവിന്യാസം അതേപടി ബാധകമാണെന്ന് അനുമാനിക്കുന്നതിനുപകരം വിൽപ്പനക്കാരന്റെ സ്വന്തം ഡോക്യുമെന്റേഷൻ പരിശോധിക്കുക. MySQL എൻക്രിപ്റ്റഡ് കണക്ഷൻ ഡോക്യുമെന്റേഷൻ മോഡുകൾ തമ്മിലുള്ള വ്യത്യാസങ്ങളും CA വിതരണ ആവശ്യകതയും ഉൾക്കൊള്ളുന്നു, ഉൽപ്പാദന കണക്ഷൻ സ്ട്രിംഗ് മാറ്റുന്നതിന് മുമ്പ് പരിശോധിക്കേണ്ട റഫറൻസ് ഇതാണ്.