VPN വഴി MariaDB: സർവർ ഏത് user@host കാണുന്നു?
അക്കൗണ്ട് ഉപയോക്താവും ഹോസ്റ്റും ഒരുമിച്ചാണ് തിരഞ്ഞെടുക്കുന്നത്. സർവർ കണ്ട ഉറവിടം കണ്ടെത്തി, CURRENT_USER() വായിച്ച്, എന്നിട്ട് ആ വരി നന്നാക്കുക, അനുമതിയല്ല.
ഒരേ ഉപയോക്തൃനാമം രണ്ട് വ്യത്യസ്ത വഴികളിലൂടെ നൽകുക, MariaDB നിങ്ങളെ രണ്ട് വ്യത്യസ്ത അക്കൗണ്ടുകളായി പ്രാമാണീകരിച്ചേക്കാം. അക്കൗണ്ടുകൾ ഉപയോക്താവും ഹോസ്റ്റും ഒരുമിച്ച് അടിസ്ഥാനമാക്കിയാണ്, അതിനാൽ 'reporter'@'localhost' ഉം 'reporter'@'10.90.0.23' ഉം വെവ്വേറെ പാസ്വേഡുകളും വെവ്വേറെ അനുമതികളുമുള്ള വെവ്വേറെ വരികളാണ്. VPN വഴി രസകരമായ ചോദ്യം ഉപയോക്താവ് ഏത് പേര് നൽകി എന്നതല്ല, മറിച്ച് സർവർ ഏത് ഉറവിട വിലാസം കണ്ടു എന്നതാണ്.
സർവർ യഥാർത്ഥത്തിൽ കാണുന്ന ഉറവിടം നിർണ്ണയിക്കുക
ലാപ്ടോപ്പിൽ നിന്നല്ല, ഡാറ്റാബേസ് ഹോസ്റ്റിൽ നിന്ന് പിന്നോട്ട് പ്രവർത്തിക്കുക. ക്ലയന്റിന് ഉണ്ടെന്ന് കരുതുന്ന വിലാസം പല സാധ്യതകളിൽ ഒന്ന് മാത്രമാണ്:
| Path | Source MariaDB sees |
|---|---|
| Routed tunnel, no translation | The client's inner VPN address |
| Gateway source translation | The gateway's translated address |
| SSH local forward | The SSH server's address |
| Public exit, no tunnel | Whatever the ISP handed out |
അത് തീരുമാനിക്കാൻ സർവർ വശത്തെ തെളിവുകൾ ഉപയോഗിക്കുക. കണക്ഷൻ ലോഗ്, സജീവ സെഷനുകളുടെ പട്ടിക അല്ലെങ്കിൽ പൊതു ലോഗിലെ താൽക്കാലിക എൻട്രി എന്നിവ സർവർ സ്വീകരിച്ച വിലാസം കാണിക്കുന്നു. ബ്രൗസറിൽ നിന്ന് ലാപ്ടോപ്പിന്റെ പൊതു IP മറ്റൊരു വസ്തുതയാണ്, പലപ്പോഴും തെറ്റിദ്ധരിപ്പിക്കുന്നതും.
MariaDB തിരഞ്ഞെടുത്ത അക്കൗണ്ട് ചേർച്ചപ്പെടുത്തുക
അക്കൗണ്ട് തിരഞ്ഞെടുപ്പ് അനുമതികളുടെ സംയോഗമല്ല, രേഖപ്പെടുത്തിയ ക്രമം പിന്തുടരുന്നു. കൃത്യമായ ഹോസ്റ്റ് ചേർച്ചയ്ക്ക് വൈൽഡ്കാർഡിനേക്കാൾ മുൻഗണനയുണ്ട്, അനോണിം ഉപയോക്താവിന്റെ വരികൾ പേര് മാത്രം തീരുമാനിക്കുന്നു എന്ന് കരുതുന്നവരെ അത്ഭുതപ്പെടുത്തുന്ന രീതിയിൽ ചേർച്ചയിൽ പങ്കെടുക്കുന്നു. സർവർ ഒരു വരി തിരഞ്ഞെടുക്കുന്നു; ഒരേ പേരുള്ള എല്ലാ വരികളുടെയും പ്രത്യേകാവകാശങ്ങൾ അത് ലയിപ്പിക്കുന്നില്ല. റഫറൻസ് ഒരിക്കൽ വായിക്കുന്നത് പകുതി ദിവസം ഊഹങ്ങൾ പരീക്ഷിക്കുന്നതിനേക്കാൾ മൂല്യമുള്ളതാണ്.
അർത്ഥം, സെഷൻ 'reporter'@'10.90.0.23' ആയി പ്രാമാണീകരിച്ചിട്ടുണ്ടെങ്കിൽ 'reporter'@'%' ലേക്ക് അനുമതി ചേർക്കുന്നത് ഒന്നും മാറ്റിയേക്കില്ല. തിരഞ്ഞെടുത്ത വരിയിൽ തന്നെ തിരുത്തൽ വീണേ പറ്റൂ, അതുകൊണ്ടാണ് അക്കൗണ്ട് തിരിച്ചറിയൽ അനുമതികൾ തിരുത്തുന്നതിന് മുമ്പ് വരുന്നത്.
സെഷൻ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന അക്കൗണ്ട് വായിക്കുക
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER() സെഷൻ പ്രാമാണീകരിച്ച അക്കൗണ്ട് പേര് നൽകുന്നു; USER() ക്ലയന്റ് ആവശ്യപ്പെട്ടത് റിപ്പോർട്ട് ചെയ്യുന്നു, വ്യത്യാസപ്പെടാം. ഇവ സാധാരണ ഉയർന്ന തലത്തിലുള്ള ക്വറിയായി പ്രവർത്തിപ്പിക്കുക, ഡിഫൈനർ സന്ദർഭമുള്ള സംഭരിച്ച റൂട്ടീനിൽ നിന്നല്ല, അല്ലെങ്കിൽ ഉത്തരങ്ങൾ നിങ്ങളുടെ സെഷനെയല്ല റൂട്ടീന്റെ ഉടമയെ വിവരിക്കും.
പരാജയപ്പെട്ട ലോഗിൻ ഇവയൊന്നും പ്രവർത്തിപ്പിക്കാൻ കഴിയില്ല, അപ്പോൾ അഡ്മിനിസ്ട്രേറ്റർ അക്കൗണ്ട് നിർവചനങ്ങളും സർവറിന്റെ കണക്ഷൻ തെളിവുകളും പരിശോധിക്കേണ്ട സന്ദർഭമാണിത്. അതിന് തയ്യാറാകുക: നിരസിക്കപ്പെട്ട ലോഗിൻ ഡീബഗ് ചെയ്യുന്നയാൾക്ക് സാധാരണയായി ചോദിക്കാൻ SQL സെഷൻ ഉണ്ടാകില്ല.
എത്തിച്ചേരാനുള്ള കഴിവ് പ്രാമാണീകരണത്തിൽ നിന്ന് വേർതിരിക്കുക
പിശക് വാചകം നിങ്ങൾ ഏത് പാളിയിലാണെന്ന് പറയുന്നു. നിരസിച്ച കണക്ഷൻ അല്ലെങ്കിൽ സമയപരിധി കഴിയൽ എന്നാൽ ക്ലയന്റ് ഒരിക്കലും ശ്രോതാവിനെ എത്തിയില്ല എന്നാണ്, അതിനാൽ അക്കൗണ്ടും അതിന്റെ പാസ്വേഡും ഇപ്പോഴും ചോദ്യചിഹ്നത്തിലല്ല. പ്രവേശനം നിരസിച്ചു എന്ന മറുപടി എന്നാൽ സർവർ ഉത്തരം നൽകി എന്നാണ്, അത് എത്തിച്ചേരൽ തെളിയിക്കുകയും അക്കൗണ്ട്, ഹോസ്റ്റ് ചേർച്ച അല്ലെങ്കിൽ ക്രെഡൻഷ്യലിലേക്ക് വിരൽ ചൂണ്ടുകയും ചെയ്യുന്നു.
നെറ്റ്വർക്ക് മുൻവ്യവസ്ഥകൾ അവയുടെ സ്വന്തം പട്ടികയാണ്: ലൂപ്പ്ബാക്കിലേക്ക് മാത്രമല്ല, ഉദ്ദേശിച്ച വിലാസത്തിലേക്ക് ബന്ധിപ്പിച്ച ശ്രോതാവ്, കോൺഫിഗർ ചെയ്ത പോർട്ടിലേക്ക് അനുവദിച്ച ട്രാഫിക്, മറുപടിക്കുള്ള തിരിച്ചുവരവ് പാത. ഓരോന്നും സ്വതന്ത്രമായി പരാജയപ്പെടാം, പ്രവർത്തിക്കുന്ന ടണൽ അവയൊന്നും അർത്ഥമാക്കുന്നില്ല. ലൂപ്പ്ബാക്കിലെ ശ്രോതാവ് പ്രാദേശിക കണക്ഷനുകൾ സ്വീകരിക്കുകയും ഓരോ ദൂരസ്ഥ കണക്ഷനും നിരസിക്കുകയും ചെയ്യുന്നു, ഇത് ഫയർവാൾ തടയൽ പോലെ തോന്നിക്കുന്ന നിരസിച്ച കണക്ഷൻ ഉണ്ടാക്കുന്നു.
നെറ്റ്വർക്ക് ടീമിനൊപ്പം ടിക്കറ്റ് തുറക്കുന്നതിന് മുമ്പ് ബൈൻഡ് വിലാസം പരിശോധിക്കുക. ഡാറ്റാബേസ് ഹോസ്റ്റിൽ ss -lntp ഏത് വിലാസവും പോർട്ടും യഥാർത്ഥത്തിൽ കേൾക്കുന്നു എന്ന് കാണിക്കുന്നു, ആ ഒരു വരി ഊഹങ്ങളുടെ ഒരു മുഴുവൻ വിഭാഗത്തെ ഒഴിവാക്കുന്നു.
ഇടുങ്ങിയതായി നന്നാക്കുക, പിന്നീട് രണ്ട് ദിശകളിലും വീണ്ടും പരീക്ഷിക്കുക
ഉദ്ദേശിച്ച ഹോസ്റ്റ്-യോഗ്യമായ അക്കൗണ്ട് സംഘടനയുടെ അംഗീകൃത പ്രക്രിയിലൂടെ സൃഷ്ടിക്കുക, ടിക്കറ്റിൽ ഒട്ടിച്ച പങ്കിട്ട ക്രെഡൻഷ്യലിന് പകരം പിന്തുണയ്ക്കുന്ന സ്റ്റോറിൽ നിന്നുള്ള ക്രെഡൻഷ്യലിനൊപ്പം. ടാസ്കിന് ആവശ്യമായ സ്കീമ പ്രവർത്തനങ്ങൾ മാത്രം നൽകുക. പരാജയപ്പെട്ട ദൂരസ്ഥ ലോഗിൻ root അക്കൗണ്ട്, എല്ലാം-നൽകൽ നയം അല്ലെങ്കിൽ സാർവത്രിക വൈൽഡ്കാർഡ് ഹോസ്റ്റ് ആക്കി മാറ്റുന്നത് പരീക്ഷണം വിജയിപ്പിക്കുകയും നിങ്ങൾ പരീക്ഷിച്ചിരുന്ന നിയന്ത്രണം നീക്കുകയും ചെയ്യുന്നു. തിരക്കിൽ ചേർത്ത അനുമതിയാണ് പിന്നീട് ആരും നീക്കാത്തത്.
ഉദ്ദേശിച്ച വഴിയിലൂടെ പുതിയ സെഷനുമായി വീണ്ടും പരീക്ഷിക്കുക, പിന്നീട് നെഗറ്റീവ് കേസുകൾ പരിശോധിക്കുക. തടയേണ്ട വഴി ഇപ്പോഴും തടയപ്പെടണം, നൽകാത്ത പ്രവർത്തനം ഇപ്പോഴും നിരസിക്കപ്പെടണം. ആ രണ്ട് പരിശോധനകളാണ് നന്നാക്കിയ അക്കൗണ്ടിനെ വിപുലീകരിച്ച അക്കൗണ്ടിൽ നിന്ന് വേർതിരിക്കുന്നത്.
അവസാനം, നിരീക്ഷിച്ച ഉറവിട വിലാസവും അക്കൗണ്ടിന്റെ പേരും ഒരുമിച്ച് രേഖപ്പെടുത്തുക. ടണൽ എത്തിച്ചേരൽ നൽകുന്നു; MariaDB ഇപ്പോഴും സ്വന്തം അക്കൗണ്ട് തിരഞ്ഞെടുക്കുകയും അനുവദിക്കുകയും ചെയ്യുന്നു, അടുത്തയാൾക്ക് നിങ്ങളുടെ ഫലം പുനർനിർമ്മിക്കാൻ രണ്ട് വസ്തുതകളും ആവശ്യമാണ്.