രണ്ട് ഹോസ്റ്റുകൾക്കിടയിൽ IPsec: സംരക്ഷണം എവിടെ തുടങ്ങി എവിടെ തീരുന്നു
ഒരു ജോടി ഹോസ്റ്റുകൾക്ക് ഗേറ്റ്‌വേ ഇല്ലാതെ തിരഞ്ഞെടുത്ത പ്രവാഹങ്ങൾ സംരക്ഷിക്കാനാകും. അറ്റം പോയിന്റുകൾ, ട്രാഫിക് തിരഞ്ഞെടുക്കുന്ന നയം, വേറിട്ടുനിൽക്കുന്ന അനുമതികൾ എന്നിവ നിർവചിക്കുക.
ഹോസ്റ്റുകളുടെ ജോടിയിൽ സംരക്ഷണം ആരംഭിക്കുന്നത് സുരക്ഷാ സംഘം അവസാനിക്കുന്നിടത്താണ്, ഗേറ്റ്‌വേ രൂപത്തിലുള്ള അന്തർദൃഷ്ടി ഏറ്റവും കൂടുതൽ വിട്ടുപോകുന്ന വസ്തുത അതാണ്. ഒരു അപ്ലിക്കേഷൻ സർവറും അതിന്റെ ഡാറ്റാബേസ് സർവറും അവരുടെ സ്വന്തം സംഭാഷണം നേരിട്ട് സംരക്ഷിക്കാനാകും, പാതയിൽ ഒരു ദൂര പ്രവേശന കേന്ദ്രീകരണവുമില്ലാതെ, സംരക്ഷണ അതിർത്തി അപ്പോൾ ഫയർവാളിൽ അല്ലാതെ ഓരോ ഹോസ്റ്റിനുള്ളിലായിരിക്കും. ഇത് തിരഞ്ഞെടുത്ത പ്രവാഹങ്ങൾക്ക് ഒരറ്റം മുതൽ മറ്റേ അറ്റം വരെ പരിരക്ഷ നൽകുന്നു. ആർക്ക് ഏത് വരി വായിക്കാം എന്ന തീരുമാനം ഇത് നൽകുന്നില്ല.
അതിർത്തി SA അവസാനിക്കുന്നിടത്താണ്
RFC 4301 ഗതാഗത മോഡിലെ സുരക്ഷാ സംഘങ്ങളെ ഹോസ്റ്റുകളുടെ ജോടിക്കിടയിൽ ഒരറ്റം മുതൽ മറ്റേ അറ്റം വരെ സംരക്ഷണത്തിന് സാധാരണയായി ഉപയോഗിക്കുന്ന ക്രമീകരണമായി വിവരിക്കുന്നു. ആ രണ്ട് ഹോസ്റ്റുകളാണ് താക്കോലുകൾ സൂക്ഷിക്കുന്നത്, ഓരോന്നും തന്റെ സ്വന്തം ഏത് പാക്കറ്റുകൾ സംഘത്തിൽ പ്രവേശിക്കണം എന്ന് തീരുമാനിക്കുന്നു. ഒരു ഗേറ്റ്‌വേ ടണൽ തികച്ചും വേറെയൊരിടത്ത് അവസാനിച്ച് അധിക ആന്തരിക ഭാഗത്തിലൂടെ ഹോസ്റ്റിൽ എത്തുന്നു, ഇത് വ്യത്യസ്ത വിശ്വാസ അതിർത്തിയാണ്, പാക്കറ്റ് അതിന്റെ യാത്രയുടെ ഭൂരിഭാഗവും എൻക്രിപ്റ്റ് ചെയ്തിരുന്നാലും.
ഹോസ്റ്റ്-ടു-ഹോസ്റ്റും ഗതാഗത മോഡും എന്നിരുന്നാലും പര്യായങ്ങളല്ല. രണ്ട് ഹോസ്റ്റുകൾക്ക് പരസ്പരം അതേ അളവിൽ ശരിയായി ടണൽ മോഡ് സംഘം നിർമ്മിക്കാനാകും, അതിനാൽ ആദ്യം മോഡ് തിരഞ്ഞെടുത്ത് പിന്നീട് അറ്റം പോയിന്റുകൾ വിവരിക്കുക. രണ്ടും ഡിസൈൻ കുറിപ്പിൽ സഹപ്രവർത്തകരുടെ വിലാസങ്ങൾക്ക് സമീപം എഴുതുക, കാരണം മോഡ് മാത്രം അറിയുന്ന അവലോകകൻ മറ്റൊന്ന് അനുമാനിക്കും.
SPD സംരക്ഷണവും, പാത ദിശയും തീരുമാനിക്കുന്നു
റൂട്ടിംഗ് പട്ടിക പാക്കറ്റ് എവിടേക്ക് പോകുന്നു എന്ന് ഉത്തരം നൽകുന്നു. സുരക്ഷാ നയ ഡാറ്റാബേസ് തിരഞ്ഞെടുത്ത ട്രാഫിക് സംരക്ഷണ അതിർത്തി എങ്ങനെ കടക്കുന്നു എന്ന് ഉത്തരം നൽകുന്നു, അത് ഓരോ ദിശയ്ക്കും സ്വന്തം തിരഞ്ഞെടുക്കികളോടെ ചെയ്യുന്നു. ആ വിഭജനമാണ് കാരണം, ഡാറ്റാബേസിലേക്കുള്ള പ്രവർത്തിക്കുന്ന പാത അഭ്യർത്ഥന സംരക്ഷിതമായിരുന്നോ എന്നതിൽ ഒന്നും തെളിയിക്കുന്നില്ല, കൂടാതെ സ്ഥാപിത ചർച്ച ഒന്നും തെളിയിക്കുന്നില്ല ഈ പ്രത്യേക അപ്ലിക്കേഷൻ അതുമായി പൊരുത്തപ്പെട്ടോ എന്നതിൽ. എണ്ണികളെ താരതമ്യം ചെയ്യുന്നതിന് മുമ്പ് തിരഞ്ഞെടുക്കികളെ താരതമ്യം ചെയ്യുക, കാരണം എണ്ണികൾ അവിടം വരെ എത്തിയ പ്രവാഹങ്ങളെ മാത്രം വിവരിക്കുന്നു.
Linux ൽ, ip xfrm policy ആ എൻട്രികൾ അവയുടെ ദിശ, മുൻഗണന, തിരഞ്ഞെടുക്കി, അനുവദിക്കുക, തടയുക അല്ലെങ്കിൽ കെണിയാക്കുക എന്ന പ്രവർത്തനത്തോടെ പ്രിന്റ് ചെയ്യുന്നു, അതേസമയം ip xfrm state ഉണ്ടായ സംഘങ്ങളും അവയുടെ എണ്ണികളും കാണിക്കുന്നു. രണ്ടും ഒരുമിച്ച് വായിക്കുന്നതാണ്, വിശാലമായ അനുമതി എൻട്രി ആദ്യം പൊരുത്തപ്പെട്ടതിനാൽ ടണലിനെ നിശ്ശബ്ദമായി ഒഴിവാക്കിയ പ്രവാഹം കണ്ടെത്താനുള്ള വഴി.
മുൻഗണന ക്രമം നയത്തിന്റെ ഭാഗമാണ്, നടപ്പാക്കലിന്റെ വിശദാംശമല്ല. ഡാറ്റാബേസ് പോർട്ട് സംരക്ഷിക്കേണ്ടിയിരുന്ന ഇടുങ്ങിയ എൻട്രി ഉയർന്ന മുൻഗണനയുള്ള വിശാലമായ എൻട്രിയോട് തോൽക്കുന്നു, പരാജയം നയത്തോട് ഒരിക്കലും ചോദിച്ചിട്ടില്ലെന്ന പോലെ തോന്നുന്നു.
ഗതാഗത മോഡ് അടുത്ത പാളി മൂടുന്നു, IP തലക്കെട്ടല്ല
| Transport mode | Tunnel mode | |
|---|---|---|
| Original IP header | kept for routing the flow | replaced by an outer header |
| What ESP protects | the carried next-layer payload | the whole inner IP packet |
| Where it terminates | commonly the two hosts | gateway pair, or a host pair |
ഗതാഗത മോഡിൽ ESP തലക്കെട്ട് IP തലക്കെട്ടിനും പേലോഡിനും ഇടയിൽ ഇരിക്കുന്നു, ആ തലക്കെട്ടിലെ വിലാസ ഫീൽഡുകൾ പാതയിലെ ഓരോ ഉപകരണത്തിനും കാണാവുന്നതായി തുടരുന്നു. വിലാസങ്ങൾ രഹസ്യമല്ലാതിരിക്കുകയും പേലോഡ് രഹസ്യമായിരിക്കുകയും ചെയ്യുമ്പോൾ ഇത് കുഴപ്പമില്ല. ആന്തരിക ടോപ്പോളജിയും മറയ്ക്കേണ്ടതുണ്ടെങ്കിൽ ഇത് തെറ്റായ തിരഞ്ഞെടുപ്പാണ്, കാരണം ടണൽ മോഡ് മാത്രമാണ് യഥാർത്ഥ തലക്കെട്ട് പുതിയതിനുള്ളിൽ പൊതിയുന്നത്.
രണ്ട് മോഡുകൾക്കും അടുത്ത പാളിയിലെ നിരവധി പ്രോട്ടോക്കോളുകൾ വഹിക്കാനാകും, ESP തിരഞ്ഞെടുക്കിയുമായി പൊരുത്തപ്പെടുന്നത് സംരക്ഷിക്കും, ഹോസ്റ്റ് അയയ്ക്കുന്നതെല്ലാമല്ല.
തിരഞ്ഞെടുപ്പ് ബന്ധത്തെക്കാൾ ഇടുങ്ങിയതാണ്
ഒരു സംഘത്തിന് നിരവധി പ്രവാഹങ്ങൾ വഹിക്കാനാകും, എന്നാൽ നയം തിരഞ്ഞെടുക്കുന്നവ മാത്രം. സഹപ്രവർത്തകരുടെ ഐഡന്റിറ്റികൾ, ഉറവിട, ലക്ഷ്യ വിലാസങ്ങൾ, പ്രോട്ടോക്കോൾ, നിങ്ങൾ ഉദ്ദേശിക്കുന്ന ബന്ധത്തിന്റെ സേവന പരിധി എന്നിവ രേഖപ്പെടുത്തുക, തുടർന്ന് പൊരുത്തപ്പെടാത്ത ട്രാഫിക് തുറന്ന് പോകാമോ, സംരക്ഷിക്കപ്പെടണമോ, അല്ലെങ്കിൽ സംഘം ലഭ്യമല്ലാത്തപ്പോൾ വലിച്ചെറിയണമോ എന്ന് വെവ്വേറെ തീരുമാനിക്കുക. ഈ അവസാന തീരുമാനമാണ് അത്ഭുതങ്ങൾ സൃഷ്ടിക്കുന്നത്, കാരണം തെറ്റായ ഉറവിടത്തിന് സംരക്ഷണം ആവശ്യപ്പെടുന്ന നിയമത്തിന് നിങ്ങളുടെ സ്വന്തം നിർവ്വഹണ പ്രവേശനം ഒരു നുഴഞ്ഞുകയറ്റക്കാരനെ തടയുന്നത്ര ഫലപ്രദമായി തടയാനാകും.
നടപ്പാക്കൽ മാറ്റുമ്പോൾ അംഗീകൃത ബാൻഡ്-പുറത്ത് പാത സൂക്ഷിക്കുക, രണ്ട് ഹോസ്റ്റുകളും അപ്രാപ്യമായതിന് ശേഷമല്ല, ആവശ്യമാകുന്നതിന് മുമ്പ് അത് പരിശോധിക്കുക.
യന്ത്രത്തിന്റെ ഐഡന്റിറ്റി അപ്ലിക്കേഷൻ അനുമതിയല്ല
IPsec കോൺഫിഗർ ചെയ്ത സഹപ്രവർത്തകനെ സാക്ഷ്യപ്പെടുത്തുകയും തിരഞ്ഞെടുത്ത പാക്കറ്റുകൾ സംരക്ഷിക്കുകയും ചെയ്യുന്നു. ഏത് ഡാറ്റാബേസ് രേഖ ഒരു വ്യക്തിക്ക് തിരുത്താമെന്ന് അത് തീരുമാനിക്കുന്നില്ല, വിശ്വസനീയ സർവർ ഐഡന്റിറ്റിയെ എല്ലാ അപ്ലിക്കേഷൻ പ്രത്യേകാവകാശങ്ങളുടെ ദാനമാക്കി മാറ്റുന്നുമില്ല. അപ്ലിക്കേഷൻ അക്കൗണ്ടുകൾ, റോളുകൾ, അധികാരം എന്നിവ ഉണ്ടായിരുന്നിടത്തുതന്നെ തുടരുന്നു, അപ്ലിക്കേഷൻ തലത്തിലുള്ള TLS ആവശ്യകത നെറ്റ്‌വർക്ക് പാത ഇതിനകം സംരക്ഷിതമായിരുന്നാലും സ്വന്തം ലക്ഷ്യം നിലനിർത്തുന്നു.
രൂപകൽപ്പന ഉദ്ദേശിച്ച ഉറവിടത്തിൽ നിന്ന് ഒരു പ്രവർത്തനത്തോടും നിരസിക്കേണ്ട ഒരു പ്രവർത്തനത്തോടും സ്വീകരിക്കുക, ആവശ്യമായ സംഘം സ്ഥാപിക്കാനാകാത്തപ്പോൾ എന്ത് സംഭവിക്കുന്നു എന്നതും ഉൾപ്പെടുത്തുക. സാധാരണ പ്രവേശന പരിശോധന പാക്കറ്റുകൾ നീങ്ങുന്നു എന്ന് പറയുന്നു; അവ നിങ്ങൾ എഴുതിയ നയത്തിന് കീഴിൽ നീങ്ങി എന്ന് പറയുന്നില്ല.