QGIS PostGIS SSH ടണൽ: TLS-നായി സർവർ നാമം സൂക്ഷിക്കുക

ടണൽ ഉയരുന്നു, QGIS കണക്ട് ചെയ്യുന്നു, എന്നാൽ ഡാറ്റാബേസ് ഹോസ്റ്റിനു പകരം 127.0.0.1 പേര് നൽകുന്ന സർട്ടിഫിക്കറ്റ് പിശകോടെ ലോഗിൻ മരിക്കുന്നു. അടുത്ത പ്രലോഭനീയ നടപടി sslmode അയച്ചുവിടുകയാണ്, അത് പരിശോധന നിശബ്ദമാക്കുകയും നിങ്ങൾ ആദ്യം മുതൽ ആഗ്രഹിച്ച ഐഡന്റിറ്റി ഉറപ്പ് എറിഞ്ഞുകളയുകയും ചെയ്യുന്നു. യഥാർത്ഥ പ്രശ്നം ലോക്കൽ പോർട്ടും സർവറിന്റെ പേരും ഒരേ ഫീൽഡിൽ സൂക്ഷിക്കുന്നു എന്നതാണ്. libpq സേവന എൻട്രി അവയെ വേർതിരിക്കുന്നു, അതിനാൽ സോക്കറ്റ് ഫോർവേഡ് ചെയ്ത പോർട്ടിലേക്ക് പോകുന്നു, TLS ഇപ്പോഴും സർട്ടിഫിക്കറ്റിൽ അച്ചടിച്ച പേര് പരിശോധിക്കുന്നു.

ക്ലയന്റ് എന്തിനോടാണ് കണക്ട് ചെയ്യുന്നതെന്ന് കരുതുന്നത്

sslmode=verify-full എന്നതിന് കീഴിൽ libpq സർവർ നൽകുന്ന സർട്ടിഫിക്കറ്റിനെ ആവശ്യപ്പെട്ട ഹോസ്റ്റ് നാമവുമായി താരതമ്യം ചെയ്യുന്നു. ആ പേര് loopback വിലാസമാണെങ്കിൽ, സർട്ടിഫിക്കറ്റ് യഥാർത്ഥ ഡാറ്റാബേസ് ഹോസ്റ്റിന് സാധുവാണെങ്കിലും താരതമ്യം പരാജയപ്പെടുന്നു. SSH ഫോർവേഡിംഗ് മാറ്റുന്നത് ഏത് സോക്കറ്റ് ബൈറ്റുകൾ വഹിക്കുന്നു എന്നതാണ്, ക്ലയന്റ് പ്രതീക്ഷിക്കേണ്ട ഐഡന്റിറ്റിയല്ല. ഈ രണ്ട് ആശയങ്ങൾ വേർതിരിഞ്ഞാൽ, പിശക് ഇനി TLS തകരാറായി തോന്നില്ല.

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

ഫോർവേഡിംഗ് loopback-ലേക്ക് മാത്രം ബന്ധിക്കുക

ശ്രോതാവ് QGIS മെഷീനിൽ മാത്രം ഉണ്ടായിരിക്കണം, മറ്റെവിടെയും അല്ല. 127.0.0.1 വ്യക്തമായി പേര് നൽകുന്നത് അതിനെ മറ്റ് ഇന്റർഫേസുകളിൽ നിന്ന് അകറ്റി നിർത്തുന്നു, എന്നാൽ ബൈൻഡ് വിലാസം ഒഴിവാക്കിയാൽ SSH ക്ലയന്റിന്റെ ഗേറ്റ്വേ ക്രമീകരണങ്ങളെ ആശ്രയിച്ച് പോർട്ട് പുറത്തേക്ക് തുറക്കാം.

ssh -N -L 127.0.0.1:15432:127.0.0.1:5432 [email protected]

രണ്ടാമത്തെ കോളണിന് ശേഷമുള്ള ലക്ഷ്യസ്ഥാനം SSH സർവറിന്റെ ഭാഗത്ത് നിന്നാണ് പരിഹരിക്കുന്നത്, അതിനാൽ ഈ ഉദാഹരണം PostgreSQL sshd ഉള്ള അതേ ഹോസ്റ്റിലാണെന്ന് അനുമാനിക്കുന്നു; മറ്റൊരു മെഷീനിലെ ഡാറ്റാബേസിന് ആ വിലാസവും അതിന്റെ അനുമതികളും ആവശ്യമാണ്. സെഷൻ -N ഉപയോഗിച്ച് ആരംഭിക്കുക, അപ്പോൾ ഒരു ഷെല്ലും തുറക്കില്ല, ഹോസ്റ്റ്-കീ പരിശോധന കൈകാര്യം ചെയ്യരുത്, QGIS-നെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ശ്രോതാവ് പ്രത്യക്ഷപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക. പോർട്ട് ഇതിനകം ഉപയോഗത്തിലാണെങ്കിൽ, ഫോർവേഡിംഗ് ക്വറിയുടെ സമയത്തല്ല, തുടക്കത്തിൽ തന്നെ പരാജയപ്പെടുന്നു.

പേരും സോക്കറ്റും ഒരു സേവന എൻട്രിയിൽ ഇടുക

ഒരു സേവന ഫയൽ ഒരേ കണക്ഷന് ഒരു പരിശോധനാ നാമവും വേറിട്ട സോക്കറ്റ് ലക്ഷ്യവും വഹിക്കാൻ അനുവദിക്കുന്നു. libpq സേവനങ്ങൾ അന്വേഷിക്കുന്നിടത്ത് എൻട്രി സംരക്ഷിക്കുക, അല്ലെങ്കിൽ PGSERVICEFILE അതിലേക്ക് ചൂണ്ടുക.

[gis-via-ssh]
host=db.geo.example
hostaddr=127.0.0.1
port=15432
dbname=gisdb
user=gis_reader
sslmode=verify-full
gssencmode=disable
sslrootcert=/path/to/approved-root.crt

ഇവിടെ host സർട്ടിഫിക്കറ്റ് പരിശോധനകൾക്ക് ഉപയോഗിക്കുന്ന ഐഡന്റിറ്റി നിലനിർത്തുന്നു, അതേസമയം hostaddr പാക്കറ്റുകൾ ഫോർവേഡ് ചെയ്ത loopback പോർട്ടിലേക്ക് അയക്കുന്നു, ഈ ക്രമീകരണം പ്രവർത്തിക്കാൻ രണ്ടും വേണം. gssencmode=disable അല്ലാത്തപക്ഷം ആദ്യം GSSAPI എൻക്രിപ്ഷൻ ചർച്ച ചെയ്യുന്ന ബിൽഡുകളിൽ പ്രധാനമാണ്, കാരണം ആ പാത ഇപ്പോൾ സജ്ജീകരിച്ച TLS ക്രമീകരണങ്ങൾ അവഗണിക്കുന്നു. QGIS-ന്റെ PostgreSQL കണക്ഷൻ ഡയലോഗിൽ നിന്ന് പേര് ഉപയോഗിച്ച് സേവനത്തെ റഫർ ചെയ്യുക, പാസ്വേഡ് പങ്കിട്ട ഫയലിനുള്ളിൽ അല്ല, സാധാരണ പ്രോംപ്റ്റിലൂടെ നൽകുക. മുകളിലെ പേരുകളും പാതകളും പ്ലേസ്ഹോൾഡറുകളാണ്; അവ നിങ്ങളുടെ സ്വന്തം അംഗീകൃത മൂല്യങ്ങൾ കൊണ്ട് മാറ്റുക.

ടണലിന് ശേഷം PostgreSQL ഇപ്പോഴും പരിശോധിക്കുന്നത്

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

psql "service=gis-via-ssh" -c "select inet_server_addr(), current_user"

ജോലി തീരുമ്പോൾ ഫോർവേഡിംഗ് സെഷൻ അടയ്ക്കുക; ലോക്കൽ എൻട്രി അപ്പോൾ പ്രവർത്തിക്കുന്നത് നിർത്തുന്നു, മറ്റൊന്നും മാറുന്നില്ല. ഡാറ്റാബേസിലേക്കുള്ള ഒരു പാത മുഴുവൻ GIS ക്ലയന്റിനും VPN അല്ല, അതിനെ VPN ആയി കണക്കാക്കുന്നതാണ് അടുത്ത കണക്ഷൻ തെറ്റായി രോഗനിർണയം ചെയ്യപ്പെടാനുള്ള കാരണം.