VPN വഴിയുള്ള PostgreSQL: pg_hba ഏത് ഉറവിട വിലാസം കാണും

PostgreSQL ഒരു ക്ലയന്റ് VPN-ലുണ്ടെന്ന് ഒരിക്കലും അറിയുന്നില്ല. ഒരു വിലാസത്തിൽ നിന്നുള്ള TCP കണക്ഷനും ഒരു കൂട്ടം ക്രെഡൻഷ്യലുകളും അത് സ്വീകരിച്ച്, അവയുമായി എന്ത് ചെയ്യണമെന്ന് തീരുമാനിക്കുന്നു. അതിനാൽ ടണലിനെ ആശ്രയിച്ച് പ്രവേശനം നിയന്ത്രിക്കുക എന്നാൽ മൂന്ന് വേറിട്ട തീരുമാനങ്ങൾ പരസ്പരം ഒത്തുപോകുന്ന വിധത്തിൽ ക്രമീകരിച്ച്, പിന്നീട് ഡയഗ്രാമിൽ വരച്ച വിലാസത്തിന് പകരം സെർവർ യഥാർത്ഥത്തിൽ കാണുന്ന ഒരേയൊരു വിലാസം പരിശോധിക്കുക എന്നാണ്.

കൂട്ടിച്ചേർക്കാൻ പാടില്ലാത്ത മൂന്ന് തീരുമാനങ്ങൾ

സെർവർ എവിടെ കേൾക്കുന്നു എന്നത് ഒരു തീരുമാനമാണ്. ഏത് ട്രാഫിക്കിന് ആ വിലാസത്തിൽ എത്താമെന്നത് രണ്ടാമത്തേതാണ്, അത് ഹോസ്റ്റ് ഫയർവാളും അതിന് മുന്നിലുള്ള ഏത് നെറ്റ്വർക്ക് അതിർത്തിയും എടുക്കുന്നു. ഏത് ഡാറ്റാബേസ് ഐഡന്റിറ്റിക്ക് ഏത് ഉറവിടത്തിൽ നിന്ന് പ്രാമാണീകരിക്കാമെന്നത് മൂന്നാമത്തേതാണ്, അത് pg_hba.conf ൽ എടുക്കുന്നു.

ഓരോന്നും വ്യത്യസ്ത ഘടകമാണ് നടപ്പാക്കുന്നത്, ഓരോന്നും വ്യത്യസ്ത സന്ദേശത്തോടെ പരാജയപ്പെടുന്നു. അവയെ ഒരു ചർച്ചയിൽ കൂട്ടിച്ചേർക്കുന്നതാണ് ആളുകൾ ഫയർവാൾ പ്രശ്നം പരിഹരിക്കാൻ HBA ഫയൽ തിരുത്താൻ തുടങ്ങുന്നതിന് കാരണം. അവയെ ക്രമത്തിൽ നിർത്തുക: ബന്ധിക്കാത്ത ലിസണറിൽ എത്താനാവില്ല, ഫിൽട്ടർ ചെയ്ത പോർട്ടിലേക്ക് കണക്ട് ചെയ്യാനാവില്ല, HBA നിയമം കണക്ഷൻ നിലനിൽക്കുന്നതിന് ശേഷം എന്ത് സംഭവിക്കുന്നു എന്ന് മാത്രം തീരുമാനിക്കുന്നു. മാറ്റത്തിന് ഫലമില്ലാത്തപ്പോൾ, മൂന്ന് പാളികളിൽ ഏതാണ് നിങ്ങൾ യഥാർത്ഥത്തിൽ മാറ്റിയതെന്ന് കണ്ടെത്തുക.

സെർവർ എവിടെ കേൾക്കുന്നു

ഇന്റർഫേസ് നാമത്തിലല്ല, മെഷീന് യഥാർത്ഥത്തിൽ അനുവദിച്ച വിലാസത്തിലേക്ക് ബൈൻഡ് ചെയ്യുക:

listen_addresses = '10.20.0.30'

ഡാറ്റാബേസിന് സ്വന്തം ടണൽ ഇന്റർഫേസ് ഇല്ലാതെ VPN ഗേറ്റ്വേയുടെ പിന്നിലാകാം, അതുകൊണ്ടാണ് വിലാസം പേര് നൽകാൻ ശരിയായ കാര്യം. ഈ ക്രമീകരണം മാറ്റാൻ പൂർണ്ണ പുനരാരംഭം ആവശ്യമാണ്; വീണ്ടും ലോഡ് ചെയ്യുന്നത് മതിയാകില്ല.

തുടർന്ന് പോർട്ട്, സാധാരണയായി 5432, ഹോസ്റ്റിലും അതിന് മുന്നിലുള്ള ഓരോ അതിർത്തിയിലും ഫിൽട്ടർ ചെയ്യുക. ഒരു സ്വകാര്യ വിലാസത്തിലേക്ക് ബൈൻഡ് ചെയ്യുന്നത് പൊതു നിരോധനത്തിന്റെ തെളിവല്ല, കാരണം പോർട്ട് ഫോർവേഡിംഗോ ക്ലൗഡ് വിലാസ മാപ്പിംഗോ ഇപ്പോഴും ആ സ്വകാര്യ ലിസണറിലേക്ക് പാക്കറ്റുകൾ എത്തിക്കാം.

HBA യഥാർത്ഥത്തിൽ കാണുന്ന വിലാസം

റൂട്ട് ചെയ്ത പ്രവേശനത്തിൽ സെർവർ ഓരോ ക്ലയന്റിന്റെയും ആന്തരിക ടണൽ വിലാസം കാണുന്നു. ഉറവിട വിവർത്തനത്തിൽ അത് പകരം ഗേറ്റ്വേയുടെ വിവർത്തനം ചെയ്ത വിലാസം കാണുന്നു, ഓരോ ക്ലയന്റും ആ ഒരു മൂല്യത്തിലേക്ക് ചുരുങ്ങുന്നു. അനുവദിക്കാനുള്ള പ്രിഫിക്സ് തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് സെർവറിന്റെ സ്വന്തം കണക്ഷൻ തെളിവുകളിലൂടെ ഉറവിടം പരിശോധിക്കുക.

ഇതിനകം TLS ഉം SCRAM ഉം ഉപയോഗിക്കുന്ന വിന്യാസത്തിന്, ബോധപൂർവം ഇടുങ്ങിയ ഒരു റിമോട്ട് ആക്സസ് ഉദാഹരണം ഇങ്ങനെയാണ്:

hostssl appdb app_login 10.8.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
host all all ::/0 reject

ഇത് പറഞ്ഞ പൂളിൽ നിന്ന് TLS വഴി ഒരു റോളിനും ഒരു ഡാറ്റാബേസിനും അനുമതി നൽകി, തുടർന്ന് മറ്റ് റിമോട്ട് TCP ആക്സസ് നിരസിക്കുന്നു. ഇത് പൂർണ്ണ HBA ഫയലിന്റെ പകരമല്ല: പ്രാദേശിക അഡ്മിനിസ്ട്രേഷൻ, റെപ്ലിക്കേഷൻ, മറ്റേതെങ്കിലും അംഗീകൃത സേവനം എന്നിവ നിലനിർത്തി, ഇടുങ്ങിയ നിയമങ്ങൾ കൂടുതൽ വിശാലമായ അനുമതികൾക്ക് മുമ്പ് വയ്ക്കുക.

വിവർത്തനം നടക്കുമ്പോൾ, HBA-ക്ക് ക്ലയന്റുകളെ അവരുടെ യഥാർത്ഥ വിലാസങ്ങളാൽ വേർതിരിക്കാനാവില്ല. നെറ്റ്വർക്ക് പ്രവേശനം കർശനമായി നിലനിർത്തി യഥാർത്ഥ ഡാറ്റാബേസ് ക്രെഡൻഷ്യലുകൾ ആവശ്യപ്പെടുക, യഥാർത്ഥ അക്കൗണ്ടിന് പകരം trust പ്രാമാണീകരണം ഒരിക്കലും ഉപയോഗിക്കരുത്.

ആദ്യത്തെ പൊരുത്തം വിജയിക്കുന്നു, പകരം വഴിയില്ല

PostgreSQL ഫയൽ മുകളിൽ നിന്ന് താഴേക്ക് വായിച്ച്, കണക്ഷനുമായി പൊരുത്തപ്പെടുന്ന ആദ്യ റെക്കോർഡ് ഉപയോഗിക്കുന്നു. ആ റെക്കോർഡിന്റെ പ്രാമാണീകരണം പരാജയപ്പെട്ടാൽ രണ്ടാമത്തെ ശ്രമമില്ല, അതിനാൽ മുൻപുള്ള വിശാലമായ അനുമതി പിന്നീടുള്ള നിരസിക്കലിനെ നിശബ്ദമായി തോൽപ്പിക്കുന്നു.

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

HBA റഫറൻസ് ക്രമവും host, hostssl റെക്കോർഡുകൾ തമ്മിലുള്ള വ്യത്യാസവും നിർവചിക്കുന്നു, നിയമത്തിന്റെ ഉദ്ദേശ്യം കണക്ഷൻ എൻക്രിപ്റ്റ് ചെയ്തിരിക്കണം എന്നതാകുമ്പോൾ ഇത് പ്രധാനമാണ്.

വീണ്ടും ലോഡ് ചെയ്യൽ, പുനരാരംഭം, നിരസിച്ച സന്ദർഭം

HBA മാറ്റങ്ങൾ വീണ്ടും ലോഡ് ചെയ്താണ് പ്രയോഗിക്കുന്നത്, pg_hba_file_rules കാഴ്ച പാഴ്സ് പിശകുകൾ കണ്ടെത്താൻ സഹായിക്കുന്നു. ആ കാഴ്ച ഫയലിന്റെ നിലവിലെ ഉള്ളടക്കം വിവരിക്കുന്നു, പ്രവർത്തിക്കുന്ന സെർവർ അവ വിജയകരമായി ലോഡ് ചെയ്തോയെന്നല്ല, അതിനാൽ വൃത്തിയുള്ള പട്ടിക പുതിയ നിയമങ്ങൾ സജീവമാണെന്നതിന്റെ തെളിവല്ല.

ലിസണർ മാറ്റങ്ങൾക്ക് സ്വന്തം പുനരാരംഭം ആവശ്യമാണ്, മാറ്റത്തിന് ഫലമില്ലെന്ന് തോന്നുമ്പോൾ രണ്ട് പ്രവർത്തനങ്ങളും കൂടിക്കുഴയാൻ എളുപ്പമാണ്.

പുതിയ സെഷനുകളിൽ പരീക്ഷിക്കുക: ഉദ്ദേശിച്ച അക്കൗണ്ടുള്ള അംഗീകൃത ക്ലയന്റ് കണക്ട് ചെയ്യുന്നു, അതേ അക്കൗണ്ട് അംഗീകരിക്കാത്ത വഴിയിൽ നിന്ന് കണക്ട് ചെയ്യുന്നില്ല, അനധികൃത ഡാറ്റാബേസ് ഐഡന്റിറ്റി ഇപ്പോഴും VPN-നുള്ളിൽ നിന്ന് പരാജയപ്പെടുന്നു. ഈ മൂന്ന് ഫലങ്ങൾ നെറ്റ്വർക്ക് അതിർത്തിയെ ഡാറ്റാബേസ് അനുമതിയിൽ നിന്ന് വേർതിരിക്കുന്നു, തീരുമാനങ്ങൾ വേറിട്ട് നിർത്തുന്നതിന്റെ മുഴുവൻ ഉദ്ദേശ്യവും അതാണ്.