ഒരു ക്ലൗഡ് സേവനത്തിനായി തദ്ദേശീയ TLS, SSH ഫോർവേഡ് അല്ലെങ്കിൽ VPN

രണ്ട് ക്ലൗഡ് മെഷീനുകൾക്കിടയിൽ എന്തെങ്കിലും എൻക്രിപ്റ്റ് ചെയ്യണോ എന്നതല്ല ചോദ്യം; ഏത് ഇന്റർഫേസാണ് നിങ്ങൾ എൻക്രിപ്റ്റ് ചെയ്യുന്നത്, ആരാണ് ആരുടെ ഐഡന്റിറ്റി പരിശോധിക്കുന്നത് എന്നതാണ്. ഞാൻ ഈ സംഭാഷണങ്ങൾ നെറ്റ്‌വർക്ക് ഡയഗ്രത്തിൽ നിന്നല്ല, സേവനത്തിൽ നിന്നാണ് തുടങ്ങുന്നത്, കാരണം സേവനത്തിന് എന്ത് വേണമെന്ന് ഇപ്പോൾ അറിയാം. മിക്ക കേസുകളെയും മൂന്ന് അതിർത്തികൾ ഉൾക്കൊള്ളുന്നു: ആപ്ലിക്കേഷന്റെ സ്വന്തം TLS, SSH വഴി ഫോർവേഡ് ചെയ്ത ഒരു TCP പോർട്ട്, ഓരോ പങ്കാളിക്കും വിലാസം നൽകുന്ന റൂട്ട് ചെയ്ത ഓവർലേ. ശക്തിയുടെ അടിസ്ഥാനത്തിലല്ല, പ്രശ്നത്തിന്റെ എത്ര ഭാഗം ഉൾക്കൊള്ളുന്നു എന്നതിന്റെ അടിസ്ഥാനത്തിലാണ് അവ ക്രമീകരിക്കുന്നത്.

നെറ്റ്‌വർക്കിൽ നിന്നല്ല, സേവനത്തിൽ നിന്ന് തുടങ്ങുക

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

8443 പോർട്ടിൽ ഇതിനകം HTTPS നൽകുന്ന ഒരു ചെറിയ ആന്തരിക API എടുക്കുക, api.internal.example എന്നതിന് സർട്ടിഫിക്കറ്റിനൊപ്പം. ഹോസ്റ്റിലെ ss -ltnp അത് എന്തുമായി ബന്ധിക്കപ്പെട്ടിരിക്കുന്നു എന്ന് കാണിക്കുന്നു, openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example സർട്ടിഫിക്കറ്റ് ക്ലയന്റ് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന പേരിന് സാധുവാണോ എന്ന് കാണിക്കുന്നു. രണ്ടും ആരോഗ്യകരമാണെങ്കിൽ, സേവനത്തിന് സ്വന്തം സ്ട്രീം സംരക്ഷിക്കാനാകും, ബാക്കിയുള്ളത് എത്തിച്ചേരൽ മാത്രമാണ്. ഒരു നെറ്റ്‌വർക്ക് നിർമ്മിക്കുന്നതിനേക്കാൾ വളരെ ചെറിയ പ്രശ്നമാണിത്.

ഘട്ടം 1: സേവനം സ്വയം സംരക്ഷിക്കുന്നുണ്ടോ?

യോജിക്കുമ്പോൾ തിരഞ്ഞെടുക്കേണ്ട ഓപ്ഷനാണിത്, ടീമുകൾ കരുതുന്നതിലും കൂടുതൽ തവണ യോജിക്കുന്നു. സേവനത്തിന്റെ എൻക്രിപ്ഷൻ ക്ലയന്റിനും സെർവറിനും ഇടയിലുള്ള മുഴുവൻ പാതയും, ഇടയിലുള്ള ഓരോ ഹോപ്പും ഉൾപ്പെടെ ഉൾക്കൊള്ളുന്നു, മധ്യത്തിന് ചുറ്റുമുള്ള ഒരു ടണലും അത് മെച്ചപ്പെടുത്തുന്നില്ല. ക്ലയന്റിന്റെ ഡിഫോൾട്ട് സ്റ്റോറിൽ യാദൃശ്ചികമായി ഉള്ളതിനെ ആശ്രയിക്കുന്നതിനുപകരം പ്രതീക്ഷിക്കുന്ന പേരും വിശ്വാസവും വ്യക്തമായി സജ്ജമാക്കുക.

എൻക്രിപ്ഷനും എത്തിച്ചേരലും വെവ്വേറെ നിയന്ത്രണങ്ങളായി തുടരുന്നു, അവയെ കൂട്ടിച്ചേർക്കുന്നതാണ് ഈ ഓപ്ഷൻ തെറ്റാകുന്ന സ്ഥലം. പരിധിയില്ലാത്ത പൊതു ശ്രോതാവിലുള്ള TLS സേവനം ഇപ്പോഴും ആരിൽ നിന്നും കണക്ഷൻ ശ്രമങ്ങൾ സ്വീകരിക്കുന്നു, അതിനാൽ പേലോഡ് സംരക്ഷിക്കപ്പെട്ടിരിക്കുന്നു എന്ന വസ്തുതയിൽ നിന്ന് സ്വതന്ത്രമായി ശ്രോതാവും നെറ്റ്‌വർക്ക് നിയമങ്ങളും നിർവചിക്കണം. തുടർന്ന് ആശ്രിതത്വങ്ങൾ പരിശോധിക്കുക, കാരണം TLS-ന് മുകളിലുള്ള API ഡിസ്കവറി എൻഡ്‌പോയിന്റ്, അഡ്മിൻ പോർട്ട് അല്ലെങ്കിൽ അടുത്തുള്ള ബൾക്ക് ട്രാൻസ്ഫർ ചാനൽ എന്നിവയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. അവയിൽ ഓരോന്നിനും സ്വന്തം ഉത്തരം വേണം, ഒരു അസുരക്ഷിത സഹോദരൻ മുഴുവൻ അതിർത്തിയെയും കൽപ്പിതകഥയാക്കാൻ മതി.

ഘട്ടം 2: ഒരു TCP പോർട്ട് മാത്രമാണോ മുഴുവൻ ആവശ്യകത?

ആവശ്യകത യഥാർത്ഥത്തിൽ ഒരു TCP പോർട്ട് ആണെങ്കിൽ, ഫോർവേഡ് ആണ് പ്രവർത്തിക്കുന്ന ഏറ്റവും ചെറിയ കാര്യം. SSH ലോക്കൽ ഫോർവേഡ് ആ പോർട്ട് ഇതിനകം നിലവിലുള്ള പ്രാമാണീകരിച്ച കണക്ഷനിലൂടെ കൊണ്ടുപോകുന്നു.

രൂപം ssh -N -L 8443:127.0.0.1:8443 [email protected] ആണ്, പ്രധാന വിശദാംശം ലക്ഷ്യ വിലാസമാണ്: 127.0.0.1 വിദൂര വശത്ത് പരിഹരിക്കപ്പെടുന്നു, അതിനാൽ സേവനത്തിലേക്കുള്ള കണക്ഷൻ നിങ്ങളുടെ ലാപ്‌ടോപ്പിൽ നിന്നല്ല, ബാസ്റ്റിയനിൽ നിന്നാണ് തുറക്കുന്നത്. പ്രാദേശിക ശ്രോതാവിനെ -L 127.0.0.1:8443:... എന്ന് ഇടുങ്ങിയതായി ബന്ധിക്കുക, യാദൃശ്ചികമായി സേവനം നിങ്ങളുടെ സ്വന്തം പ്രാദേശിക നെറ്റ്‌വർക്കിൽ പ്രസിദ്ധീകരിക്കാതിരിക്കാൻ. സെർവർ വശത്ത്, ക്ലയന്റിന്റെ നല്ല പെരുമാറ്റത്തിൽ വിശ്വസിക്കുന്നതിനുപകരം അക്കൗണ്ടിന് എന്ത് ഫോർവേഡ് ചെയ്യാമെന്ന് പരിമിതപ്പെടുത്തുക. PermitOpen, AllowTcpForwarding local, ഡിഫോൾട്ട് GatewayPorts no എന്നിവ പൊതുവായ റിലേയെ നിർദ്ദിഷ്ട ചാനലാക്കി മാറ്റുന്ന മൂന്ന് ക്രമീകരണങ്ങളാണ്.

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

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

ഘട്ടം 3: റൂട്ടിംഗ് ആണോ യഥാർത്ഥ ആവശ്യകത?

ആ പട്ടിക ഏറ്റവും ചെറിയ ഓപ്ഷന്റെ സത്യസന്ധമായ വിലയാണ്, അതുകൊണ്ടാണ് ടീമുകൾ ഒടുവിൽ മറന്നുപോയ കുറച്ച് ബാക്ക്ഗ്രൗണ്ട് കമാൻഡുകൾ നിയന്ത്രിതമായ എന്തെങ്കിലും കൊണ്ട് മാറ്റുന്നത്. പകരം വയ്ക്കൽ സ്വയമേവ VPN അല്ല. ആവശ്യകത ഇപ്പോഴും ഒരു TCP പോർട്ട് ആണെങ്കിൽ, രേഖപ്പെടുത്തിയ ഉടമയുള്ള മേൽനോട്ട ഫോർവേഡ് ഓവർലേയേക്കാൾ വിലകുറഞ്ഞതാണ്, നിങ്ങൾക്ക് കാണാവുന്ന രീതികളിൽ അത് പരാജയപ്പെടുന്നു. മനോഹാരിത അളക്കുന്നതിന് മുമ്പ് പ്രവർത്തന ഉടമസ്ഥത അളക്കുക.

റൂട്ടിംഗ് ആവശ്യകതയാകുമ്പോൾ റൂട്ടിംഗ് ശരിയായ ഉത്തരമാകുന്നു. സാധാരണ IP കണക്റ്റിവിറ്റി ആവശ്യമുള്ള നിരവധി ആപ്ലിക്കേഷനുകൾ, TCP ഫോർവേഡിന് കൊണ്ടുപോകാൻ കഴിയാത്ത പ്രോട്ടോക്കോളുകൾ, അല്ലെങ്കിൽ ഹോസ്റ്റുകൾക്കിടയിൽ നീങ്ങുന്ന സേവനങ്ങൾ — എല്ലാം ഒരേ ദിശയിലേക്ക് ചൂണ്ടുന്നു.

ഓവർലേ പങ്കാളികൾക്ക് വിലാസവും റൂട്ടും നൽകുന്നു, തുടർന്ന് യഥാർത്ഥ ജോലി തുടങ്ങുന്നു: ഓവർലാപ്പ് ചെയ്യാത്ത ശ്രേണികൾ, റൂട്ട് ഉടമസ്ഥത, DNS, രജിസ്ട്രേഷൻ, റദ്ദാക്കൽ, പങ്കാളി അപ്രത്യക്ഷമാകുമ്പോൾ എന്ത് സംഭവിക്കും. അവയൊന്നും വിലാസത്തോടൊപ്പം വരുന്നില്ല. ഓവർലേയിലേക്ക് സ്വീകരിക്കപ്പെട്ട പങ്കാളിക്കും ലക്ഷ്യസ്ഥാനത്തെ ഓരോ പ്രവർത്തനത്തിനും സ്വയമേവ അധികാരമില്ല, അതിനാൽ സേവനതല പ്രാമാണീകരണം നിലനിൽക്കുന്നു.

അതിനുശേഷം നിങ്ങൾക്കുള്ളത്

നിങ്ങൾ വിടുന്ന രേഖയിൽ രണ്ട് കാര്യങ്ങൾ ഉൾപ്പെടുന്നു. ആദ്യത്തേത് ക്ലയന്റ് പരിശോധിക്കേണ്ട ഐഡന്റിറ്റിയാണ്, കാരണം എന്തെങ്കിലും പ്രവർത്തിക്കാൻ പേര് പരിശോധന അയച്ചാൽ ഈ അതിർത്തികളിൽ ഓരോന്നും നിശബ്ദമായി മോശമാകുന്നു. രണ്ടാമത്തേത് നീക്കം ചെയ്യാനുള്ള ഘട്ടമാണ്: പ്രവേശനം അവസാനിക്കുമ്പോൾ ഏത് കീ, ഏത് നിയമം അല്ലെങ്കിൽ ഏത് റൂട്ട് അപ്രത്യക്ഷമാകുന്നു, അത് ആരാണ് ചെയ്യുന്നത്.

ഈ യാത്ര തുടങ്ങിയിടത്ത്, സേവനത്തിൽ അവസാനിക്കുന്നു. യഥാർത്ഥ ട്രാഫിക്കിനെ ഉൾക്കൊള്ളുന്നതും നിങ്ങൾ പരിശോധിക്കാൻ ഉദ്ദേശിച്ച പങ്കാളികളെ പരിശോധിക്കുന്നതുമായ അതിർത്തി തിരഞ്ഞെടുക്കുക, തുടർന്ന് പ്രവേശനം എങ്ങനെ അപ്ഡേറ്റ് ചെയ്യപ്പെടുന്നു, നിരീക്ഷിക്കപ്പെടുന്നു, നീക്കം ചെയ്യപ്പെടുന്നു എന്ന് എഴുതുക. OpenSSH റഫറൻസ് ഇടുങ്ങിയ കരാർ വാഗ്ദാനം ചെയ്യുന്നതിന് മുമ്പ് ഫോർവേഡിംഗ് ഓപ്ഷനുകൾ സ്ഥിരീകരിക്കാനുള്ള സ്ഥലമാണ്. നീക്കം ചെയ്യാനുള്ള ഘട്ടം ഒരു വാക്യത്തിൽ വിവരിക്കാനാകുന്നില്ലെങ്കിൽ, അതിർത്തി പ്രശ്നത്തേക്കാൾ വലുതാണ്.