VPN വഴി MySQL localhost: ഇപ്പോഴും പ്രാദേശിക പ്രക്രിയയെ സൂചിപ്പിക്കുന്നു

ഓഫീസ് സെർവറിലെ ആപ്പ് localhost-ൽ MySQL-ലേക്ക് കണക്റ്റ് ചെയ്യുന്നു, നിങ്ങൾ ആ ഹോസ്റ്റ്നെയിം ഡെസ്ക്ടോപ്പ് ക്ലയന്റിലേക്ക് പകർത്തുന്നു, കണക്ഷൻ ഒന്നുകിൽ പരാജയപ്പെടുന്നു അല്ലെങ്കിൽ മറ്റൊരു ഡാറ്റാബേസ് തുറക്കുന്നു. VPN വാക്കിന്റെ അർത്ഥത്തിൽ ഒന്നും മാറ്റിയില്ല: localhost ഇപ്പോഴും ക്ലയന്റ് പ്രവർത്തിപ്പിക്കുന്ന യന്ത്രത്തെയാണ് സൂചിപ്പിക്കുന്നത്. VPN പാക്കറ്റുകൾ നീക്കി, ഇന്റർഫേസുകളല്ല. ഏതെങ്കിലും റൂട്ടിൽ തൊടുന്നതിന് മുമ്പ് ലാപ്ടോപ്പ് ഏത് എൻഡ്പോയിന്റിലേക്ക് എത്തണമെന്ന് തീരുമാനിക്കുക.

ഘട്ടം 1: ലാപ്ടോപ്പ് ഏത് എൻഡ്പോയിന്റിലേക്ക് എത്തണമെന്ന് തീരുമാനിക്കുക

രണ്ട് രൂപകൽപ്പനകളും സാധുവാണ്, വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു. നേരിട്ടുള്ള പ്രവേശനം എന്നാൽ ടണൽ എത്തുന്ന സ്വകാര്യ വിലാസത്തിൽ ഡാറ്റാബേസ് കേൾക്കുന്നു, ലാപ്ടോപ്പ് ആ വിലാസത്തിലേക്ക് കണക്റ്റ് ചെയ്യുന്നു. ഫോർവേഡ് ചെയ്ത പ്രവേശനം എന്നാൽ ഡാറ്റാബേസ് loopback-ൽ തുടരുന്നു, ഒരു SSH സെഷൻ പോർട്ട് നിങ്ങളുടെ യന്ത്രത്തിലേക്ക് കൊണ്ടുപോകുന്നു. ഒന്ന് ബോധപൂർവം തിരഞ്ഞെടുക്കുക, കാരണം രണ്ടും കലർത്തിയാൽ തെറ്റായ കാരണത്താൽ പ്രവർത്തിക്കുന്ന കണക്ഷൻ ഉണ്ടാകും.

നേരിട്ടുള്ള പ്രവേശനത്തിന്, ഡാറ്റാബേസ് ഹോസ്റ്റിന്റെ സ്വന്തം സ്വകാര്യ നാമമോ വിലാസമോ അതിന്റെ പോർട്ടും അത് നിയന്ത്രിക്കുന്നവരിൽ നിന്ന് വാങ്ങുക. VPN ഗേറ്റ്വേയുടെ വിലാസം ഡാറ്റാബേസിന്റെ വിലാസമല്ല, അതേ യന്ത്രമല്ലെങ്കിൽ. തുടർന്ന് ശ്രോതാവ് യഥാർത്ഥത്തിൽ ആ ഇന്റർഫേസിലേക്ക് ബന്ധിച്ചിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുക, കാരണം ഒരു ഇന്റർഫേസിലേക്കുള്ള റൂട്ട് അതിൽ ശ്രോതാവിനെ സൃഷ്ടിക്കുന്നില്ല.

ഘട്ടം 2: ശ്രോതാവ് പ്രാദേശികമായി തുടരുമ്പോൾ മാത്രം പോർട്ട് ഫോർവേഡ് ചെയ്യുക

ഡാറ്റാബേസ് loopback-ൽ മാത്രം തുടരേണ്ടതുണ്ടെങ്കിൽ, അത് SSH വഴി ഫോർവേഡ് ചെയ്ത് പ്രാദേശിക അറ്റവും loopback-ലേക്ക് ബന്ധിക്കുക. ഇടതുവശത്തെ ബൈൻഡ് വിലാസം നിങ്ങളുടെ ലാപ്ടോപ്പിന്റേതാണ്; വലതുവശത്തെ ലക്ഷ്യം SSH സെർവറിന്റെ വശത്തുനിന്നാണ് വ്യാഖ്യാനിക്കുന്നത്, OpenSSH റഫറൻസ് വിവരിക്കുന്നതുപോലെ. ഈ രണ്ട് റോളുകൾ മറിച്ചിടുന്നതാണ് ഫോർവേഡ് പ്രവർത്തിക്കുന്നതായി തോന്നുകയും എന്നാൽ ഒന്നിലേക്കും കണക്റ്റ് ചെയ്യാതിരിക്കുകയും ചെയ്യുന്നതിന്റെ സാധാരണ കാരണം.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'

SSH ഡാറ്റാബേസ് ഹോസ്റ്റിനുപകരം ഒരു ജംപ് ഹോസ്റ്റിൽ ഇറങ്ങിയാൽ, വലതുവശത്തെ loopback ജംപ് ഹോസ്റ്റിനെ സൂചിപ്പിക്കുന്നു, ലക്ഷ്യം ആ ഹോസ്റ്റ് എത്തുന്ന വിലാസത്തിലേക്ക് മാറ്റണം. ExitOnForwardFailure ഫോർവേഡ് സ്ഥാപിക്കുന്നതിലെ പരാജയം പിടിക്കുന്നു, പക്ഷേ ലക്ഷ്യത്തിലേക്കുള്ള പിന്നീടുള്ള കണക്ഷനുകൾ വിജയിക്കുമെന്ന് തെളിയിക്കുന്നില്ല. ഹോസ്റ്റ്-കീ പരിശോധന ഓണാക്കി വയ്ക്കുക, ഫോർവേഡിംഗ് പോർട്ട് എല്ലാ ഇന്റർഫേസുകളിലേക്കും ബന്ധിച്ച് നിങ്ങളുടെ മുഴുവൻ LAN-നും നൽകരുത്.

ഡാറ്റാബേസ് loopback-ൽ മാത്രം തുടരേണ്ടതുണ്ടെങ്കിൽ, SSH ഉപയോഗിക്കാൻ കഴിയില്ലെങ്കിൽ നിർത്തുക. അപ്പോൾ നേരിട്ടുള്ള പ്രവേശനം തെറ്റായ രൂപകൽപ്പനയാണ്, അടിച്ചേൽപ്പിക്കേണ്ട കോൺഫിഗറേഷനല്ല.

ഘട്ടം 3: ക്ലയന്റിനെ TCP-യിലേക്ക് നിർബന്ധിക്കുക

Unix-ൽ localhost നൽകിയ MySQL ക്ലയന്റ് സ്വതവേ Unix സോക്കറ്റ് തിരഞ്ഞെടുക്കുന്നു, അതിനാൽ പോർട്ട് മാത്രം മാറ്റിയാൽ നിങ്ങളുടെ ഫോർവേഡുമായി ബന്ധമില്ലാത്ത ഒരു സോക്കറ്റ് തിരയാൻ അത് ഇടയാകും. വ്യക്തമായ TCP പ്രോട്ടോക്കോളും loopback വിലാസവും ഉപയോഗിച്ച് ക്ലയന്റ് നിങ്ങളുടെ ഫോർവേഡിംഗ് പോർട്ടിലേക്ക് ഒരു കണക്ഷൻ തുറക്കാൻ പ്രേരിപ്പിക്കുക.

mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password

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

ഉപകരണത്തെ TCP-യിലേക്ക് നിർബന്ധിക്കാൻ കഴിയില്ലെങ്കിൽ നിർത്തുക. അപ്പോൾ മറ്റൊരു ക്ലയന്റ് ഉപയോഗിക്കുക, അല്ലെങ്കിൽ സ്വകാര്യ ശ്രോതാവിലേക്ക് നേരിട്ടുള്ള പ്രവേശനം ഉപയോഗിക്കുക.

ഘട്ടം 4: യഥാർത്ഥത്തിൽ ഏത് എൻഡ്പോയിന്റിലേക്ക് എത്തിയെന്ന് തെളിയിക്കുക

കണക്ഷൻ എന്താണെന്ന് സെർവർ കരുതുന്നുവെന്ന് ചോദിക്കുക. ഹോസ്റ്റ്നെയിം, പോർട്ട്, സോക്കറ്റ് വേരിയബിളുകൾ നിങ്ങൾ TCP വഴി വന്നോയെന്നും ഏത് ശ്രോതാവ് ഉത്തരം നൽകിയെന്നും പറയുന്നു, കണക്ഷനുകളുടെ പട്ടിക സെർവർ രേഖപ്പെടുത്തിയ ഉറവിട വിലാസം കാണിക്കുന്നു. ആ തെളിവ് മറ്റൊരു റൂട്ട് മാറ്റത്തെക്കാൾ ഉപയോഗപ്രദമാണ്.

mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"

നിങ്ങൾ ഏത് എൻഡ്പോയിന്റ് ശ്രമിച്ചുവെന്ന് രേഖപ്പെടുത്തുക: പ്രാദേശിക Unix സോക്കറ്റ്, നിങ്ങളുടെ ഫോർവേഡിംഗ് പോർട്ട് അല്ലെങ്കിൽ സ്വകാര്യ ശ്രോതാവ്. ഈ മൂന്ന് പരാജയങ്ങൾക്ക് വ്യത്യസ്ത പരിഹാരങ്ങളാണ്, ക്ലയന്റ് ഇപ്പോഴും തെറ്റായ localhost-നോട് സംസാരിക്കുമ്പോൾ VPN റൂട്ട് മാറ്റുന്നത് പാഴ്വേലയാണ്. കുറിപ്പുകളിൽ SSH പ്രാമാണീകരണവും ഡാറ്റാബേസ് പ്രാമാണീകരണവും വേർതിരിച്ച് സൂക്ഷിക്കുക, കാരണം ഡെസ്ക്ടോപ്പ് ക്ലയന്റിൽ നിന്ന് ഒന്നിലെ പരാജയം മറ്റൊന്നിലെ പരാജയം പോലെ തോന്നുന്നു. തുടർന്ന് ജോലി കഴിഞ്ഞാൽ ഫോർവേഡ് നീക്കം ചെയ്യുക.

എൻഡ്പോയിന്റ്, ക്ലയന്റ് പ്രോട്ടോക്കോൾ, സെർവർ കണ്ട ഉറവിട വിലാസം, അത് അനുവദിച്ച അനുമതി എന്നിവ പേരെടുത്ത് പറയാൻ കഴിയുമ്പോൾ ചെക്ക്ലിസ്റ്റ് അവസാനിക്കുന്നു. നാല് വസ്തുതകൾ, അടുത്ത കണക്ഷൻ പ്രശ്നം ഒരു ഉച്ചയ്ക്കുപകരം മിനിറ്റുകൾ എടുക്കുന്നു.