Firebird 3-ലെ വയർ എൻക്രിപ്ഷനും VPN-ഉം രണ്ട് വ്യത്യസ്ത അതിരുകളാണ്

VPN ബന്ധിപ്പിക്കുന്നു, ക്ലയന്റ് ഒരു സെഷൻ തുറക്കുന്നു, എല്ലാവരും ഡാറ്റാബേസ് കണക്ഷൻ സുരക്ഷിതമാണെന്ന് അനുമാനിക്കുന്നു. ഇപ്പോൾ തന്നെ മൂന്ന് വ്യത്യസ്ത കാര്യങ്ങൾ കൂട്ടിക്കലർത്തി. ലിസണർ എത്തിച്ചേരാമോ, സർവർ ഉപയോക്താവിനെ സ്വീകരിച്ചോ, ഒപ്പം Firebird വയർ എൻക്രിപ്ഷനിൽ ചർച്ച നടത്തിയോ എന്നിവ വെവ്വേറെ സംവിധാനങ്ങളും വെവ്വേറെ തെളിവുകളുമാണ്. ടണൽ ആദ്യത്തേതിന് മാത്രം ഉത്തരം നൽകുന്നു, അതും നിങ്ങൾ അനുവദിച്ച ഉറവിടങ്ങൾക്ക് മാത്രം.

രണ്ട് അതിരുകൾ, അവ ഒന്നിനൊന്ന് ആവർത്തിക്കുന്നില്ല

VPN അതിർ ക്ലയന്റിനും ഗേറ്റ്വേയ്ക്കും ഇടയിലുള്ള പാക്കറ്റുകൾ സംരക്ഷിക്കുന്നു. Firebird-ന്റെ വയർ എൻക്രിപ്ഷൻ ക്ലയന്റ് ലൈബ്രറിക്കും സർവർ പ്രോസസ്സിനും ഇടയിലുള്ള ഡാറ്റാബേസ് പ്രോട്ടോക്കോൾ സംരക്ഷിക്കുന്നു. രണ്ടും ഉണ്ടാകാം, ഒന്നും മറ്റൊന്നിന് പകരമാകുന്നില്ല.

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

ആദ്യ അതിർ: ലിസണർ ആർക്ക് തുറക്കാം

യഥാർത്ഥ സർവർ വിലാസവും ക്രമീകരിച്ച പോർട്ടും കണ്ടെത്തുക, അത് മാറ്റിയിട്ടില്ലെങ്കിൽ 3050, തുടർന്ന് ഹോസ്റ്റിന്റെയും നെറ്റ്വർക്കിന്റെയും ഫയർവാളുകളിൽ അംഗീകരിച്ച VPN ഉറവിടങ്ങൾക്ക് മാത്രം അനുവാദം നൽകുക. VPN ഗേറ്റ്വേയിലെ ഏതെങ്കിലും വിലാസ വിവർത്തനം പരിഗണിക്കുക, ഗേറ്റ്വേ വെവ്വേറെയാണെങ്കിൽ ഡാറ്റാബേസ് ഹോസ്റ്റിന് ക്ലയന്റ് പൂളിലേക്ക് മടക്കുപാത നൽകുക.

തുടർന്ന് നിഷേധം തെളിയിക്കുക. നിരസിക്കേണ്ട ബാഹ്യ പാത നിരസിക്കപ്പെട്ടു തന്നെയിരിക്കണം, കാരണം ടണൽ തുറക്കുന്നത് Firebird ലിസണറെ സ്വയം പരിമിതപ്പെടുത്തുന്നില്ല.

രണ്ടാം അതിർ: Firebird എന്താണ് ചർച്ച ചെയ്യുന്നത്

Firebird 3 പ്രവർത്തനരഹിതമാക്കാവുന്നതോ പ്രവർത്തനക്ഷമമാക്കാവുന്നതോ നിർബന്ധമാക്കാവുന്നതോ ആയ സർവർ നയത്തോടെ വയർ-എൻക്രിപ്ഷൻ ചട്ടക്കൂട് അവതരിപ്പിച്ചു. നയം അടിസ്ഥാനതലം നിശ്ചയിക്കുന്നു. യഥാർത്ഥ സെഷൻ ഇപ്പോഴും ആപ്ലിക്കേഷൻ ലോഡ് ചെയ്യുന്ന ക്ലയന്റ് ലൈബ്രറിയെയും ഇരുവശവും പിന്തുണയ്ക്കുന്ന പ്ലഗിന്നുകളെയും ആശ്രയിച്ചിരിക്കുന്നു.

Firebird 3-ന്റെ റിലീസ് കുറിപ്പുകളിൽ ആ റിലീസിനുള്ള സ്ഥിരസ്ഥിതി വയർ-എൻക്രിപ്ഷൻ പ്ലഗിനായി Arc4 പട്ടികപ്പെടുത്തിയിരിക്കുന്നു. Arc4 ഒരു ചരിത്രപരമായ സ്ഥിരസ്ഥിതിയാണ്, ആധുനിക സൈഫറിനുള്ള ശുപാർശയല്ല, അത് പുറം VPN സംരക്ഷണത്തിന് തുല്യമല്ല.

പ്രാമാണീകരണം അതേ ചർച്ചയിലെ മൂന്നാമത്തെ ചരമാണ്. സർവർ പ്രാമാണീകരണ പ്ലഗിന്നുകളുടെ ഒരു കൂട്ടം സ്വീകരിക്കുന്നു, ക്ലയന്റ് ലൈബ്രറി അതിന്റെ ഒരു ഉപഗണം നൽകുന്നു, രണ്ടും ഒത്തുചേരണം.

Legacy_Auth കെണി

Legacy_Auth പിന്തുണയ്ക്കാൻ സർവറിന്റെ സ്ഥിരസ്ഥിതി നിർബന്ധിത-എൻക്രിപ്ഷൻ നയം ലഘൂകരിക്കേണ്ടതുണ്ട്. അതാണ് രേഖപ്പെടുത്തിയ അനുയോജ്യതാ ചെലവ്, അതുകൊണ്ടാണ് കണക്ഷൻ പിശക് നിശബ്ദമാക്കാൻ നയം താഴ്ത്തുന്നത് പരിഹാരമല്ലാതെ സുരക്ഷാ മാറ്റമാകുന്നത്.

സർവർ അപ്ഗ്രേഡിന് ശേഷം ഒരു ക്ലയന്റ് പെട്ടെന്ന് പരാജയപ്പെട്ടാൽ, എന്തെങ്കിലും ദുർബലമാക്കുന്നതിന് മുമ്പ് പ്ലഗിൻ പട്ടികകൾ താരതമ്യം ചെയ്യുക. പരാജയം സാധാരണയായി ചർച്ചയിലെ പൊരുത്തക്കേടാണ്, ഉത്തരം ഇരുവശത്തും പിന്തുണയ്ക്കുന്ന ഒരു പ്ലഗിനാണ്.

പ്രധാനമായ കണക്ഷൻ പരിശോധിക്കുക

സന്ദർഭ ചരം നൽകുന്ന ഒരു ബിൽഡിൽ, ഈ ക്വറി നിലവിലെ കണക്ഷന്റെ എൻക്രിപ്ഷൻ അവസ്ഥ റിപ്പോർട്ട് ചെയ്യുന്നു:

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

അത് ആപ്ലിക്കേഷന്റെ സ്വന്തം കണക്ഷനിലൂടെ പ്രവർത്തിപ്പിക്കുക, അതേ സർവറിലെ അഡ്മിനിസ്ട്രേറ്റർ സെഷനിലൂടെയല്ല. എൻക്രിപ്റ്റ് ചെയ്ത അഡ്മിൻ കണക്ഷൻ മറ്റൊരു ക്ലയന്റ് ലൈബ്രറിയുടെ സെഷനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, ചരം പിന്തുണയ്ക്കാത്ത പഴയ ബിൽഡ് എൻക്രിപ്ഷൻ ഓഫാണെന്നതിന് തെളിവുമല്ല.

ക്ലയന്റ് ലൈബ്രറിയുടെ പതിപ്പ്, സർവർ ബിൽഡ്, ഫലം എന്നിവ ഒരുമിച്ച് രേഖപ്പെടുത്തുക, കാരണം അവയിൽ ഏതെങ്കിലും ഒന്ന് മാത്രം വായിക്കാനാവില്ല.

അനുമതികളും അപ്ഗ്രേഡ് പാതയും

ഉറവിടങ്ങൾ പരിമിതപ്പെടുത്തുന്നതും ഗതാഗതം എൻക്രിപ്റ്റ് ചെയ്യുന്നതും പ്രാമാണീകരണത്തിനോ കുറഞ്ഞ-പ്രത്യേകാവകാശ അനുമതികൾക്കോ പകരമാകുന്നില്ല. സാധാരണ ഡാറ്റാബേസ് ഉപയോക്താവ് യഥാർത്ഥത്തിൽ സ്പർശിക്കുന്ന വസ്തുക്കളിലുള്ള അനുമതികൾ പരിശോധിക്കുക.

അവസാനമായി, ദീർഘകാല വിന്യാസത്തെ ഒരു പരിപാലന ചോദ്യമായി കാണുക. ടണൽ കാലഹരണപ്പെട്ട ക്ലയന്റ് ലൈബ്രറിയെ അനിശ്ചിതമായി സുരക്ഷിതമാക്കുന്നില്ല, പിന്തുണയുള്ള അപ്ഗ്രേഡ് പാത അതിന് ആവശ്യമായ പ്ലഗിൻ നീക്കം ചെയ്തുവെന്ന് കണ്ടെത്തുന്നതിനേക്കാൾ വിലകുറഞ്ഞതാണ്.