IPsec-നുള്ളിൽ IPsec: പുറം ടണൽ ഏത് വിലാസങ്ങൾ വഹിക്കണം

നെസ്റ്റഡ് IPsec-നെക്കുറിച്ച് ചിന്തിക്കാൻ എളുപ്പം, രണ്ട് പാളികളും വ്യത്യസ്ത യന്ത്രങ്ങളിൽ അവസാനിക്കുമ്പോൾ. നാല് ഗേറ്റ്വേകൾ, രണ്ട് ടണലുകൾ, രൂപകൽപ്പന പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്ന ഒരു ചോദ്യം: ഉള്ളിലെ ടണൽ പാക്കറ്റുമായി തീർന്നതിന് ശേഷം പുറം ടണൽ യഥാർത്ഥത്തിൽ എന്താണ് കാണുന്നത്? അതിന് ഉത്തരം നൽകുക, സെലക്ടറുകൾ, റൂട്ടുകൾ, പ്രശ്നപരിഹാര ക്രമം എല്ലാം പിന്തുടരും. തെറ്റിപ്പോയാൽ സാങ്കേതികമായി സജീവമായ ഒരു ടണൽ ഡീബഗ് ചെയ്യാൻ ഒരു ദിവസം ചെലവഴിക്കും.

നാല് ഗേറ്റ്വേ മാതൃക

പുറം ഗേറ്റ്വേകൾ A, B എന്നിവ രണ്ട് സൈറ്റുകൾക്കിടയിൽ ആദ്യ ടണൽ നിർമ്മിക്കുന്നു. A-യുടെ പിന്നിൽ ട്രാൻസിറ്റ് വിലാസം 10.60.0.2 ഉള്ള ഉള്ളിലെ ഗേറ്റ്വേ C, B-യുടെ പിന്നിൽ ട്രാൻസിറ്റ് വിലാസം 10.70.0.2 ഉള്ള ഉള്ളിലെ ഗേറ്റ്വേ D എന്നിവയുണ്ട്. ആപ്ലിക്കേഷൻ നെറ്റ്വർക്കുകൾ C-യുടെയും D-യുടെയും പിന്നിലാണ്, ഉദാഹരണത്തിലെ ഓരോ വിലാസവും ബോധപൂർവ്വം ഓവർലാപ്പ് ചെയ്യുന്നില്ല.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

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

ഓരോ പാളിയും അതിന്റെ സ്വന്തം സംരക്ഷണം മാത്രം നീക്കുന്നു

C, D-യ്ക്കായി ഒരു ആപ്ലിക്കേഷൻ പാക്കറ്റ് എൻക്രിപ്റ്റ് ചെയ്യുന്നു. ഫലം C-യിൽ നിന്ന് D-യിലേക്ക് വിലാസമാക്കുന്നു, അതാണ് A-യിൽ എത്തുന്നത്. തുടർന്നുള്ളതെല്ലാം ആ പുനർലേഖനത്തെ ആശ്രയിച്ചിരിക്കുന്നു.

A അതിനെ B-യ്ക്കായി വീണ്ടും എൻക്രിപ്റ്റ് ചെയ്യുന്നു. B പുറം പാളി ഡീക്രിപ്റ്റ് ചെയ്ത്, C-യിൽ നിന്ന് D-യിലേക്കുള്ള പാക്കറ്റ് കണ്ട്, അത് ഇപ്പോഴും എൻക്രിപ്റ്റ് ചെയ്ത നിലയിൽ തന്നെ കൈമാറുന്നു. D ഉള്ളിലെ സംരക്ഷണം നീക്കി ആപ്ലിക്കേഷൻ പാക്കറ്റ് എത്തിക്കുന്നു.

അതിനാൽ A-യും B-യും ഉള്ളിലെ അറ്റപ്പോയിന്റുകളും അവയുടെ മെറ്റാഡാറ്റയും കാണുന്നു, പക്ഷേ ആപ്ലിക്കേഷൻ പേലോഡ് ഡീക്രിപ്റ്റ് ചെയ്യുന്ന കക്ഷികൾ അവരല്ല. അത് രൂപകൽപ്പനയുടെ യഥാർത്ഥ സ്വഭാവമാണ്, C, D അല്ലെങ്കിൽ ആപ്ലിക്കേഷൻ ഹോസ്റ്റുകൾ വിശ്വസനീയമാണ് എന്ന വാദമല്ല.

പുറം സെലക്ടറുകൾ ഉള്ളിലെ ഗേറ്റ്വേകളെ പേരിടുന്നു

ഇവിടെയാണ് ഇത്തരം നിർമ്മിതികളിൽ ഭൂരിഭാഗവും പരാജയപ്പെടുന്നത്. നയാധിഷ്ഠിത പുറം ടണലിന്, നിങ്ങൾ ചർച്ച ചെയ്യുന്ന സെലക്ടറുകളിൽ A-യും B-യും യഥാർത്ഥത്തിൽ കൈകാര്യം ചെയ്യുന്ന വിലാസങ്ങൾ ഉണ്ടായിരിക്കണം: 10.60.0.2/32 കൂടാതെ 10.70.0.2/32, ശരിയായ പ്രാദേശിക, ദൂര ക്രമത്തിൽ.

അന്തിമ ആപ്ലിക്കേഷൻ സബ്നെറ്റുകൾ പുറം സെലക്ടറുകളിൽ ഇടുന്നത് പ്രവർത്തിക്കുന്നില്ല, കാരണം പാക്കറ്റ് A-യിൽ എത്തുമ്പോഴേക്കും ഉള്ളിലെ എൻക്യാപ്സുലേഷൻ A സംരക്ഷിക്കേണ്ടതിനെ മാറ്റിയെഴുതിക്കഴിഞ്ഞു. അപ്പോൾ പുറം നയം ഒന്നിനും പൊരുത്തപ്പെടില്ല, ടണൽ ഡേറ്റ വഹിക്കാതെ ഉയരും.

പുറം അനുമതി UDP 500-ലേക്ക് ചുരുക്കരുത്. ഉള്ളിലെ കണക്ഷന് സ്വന്തം ഡേറ്റ പാതയുണ്ട്, അത് ചർച്ച ചെയ്തതനുസരിച്ച് ESP അല്ലെങ്കിൽ UDP എൻക്യാപ്സുലേഷൻ ഉപയോഗിക്കുന്നു, പുറം നയം ആ പ്രോട്ടോക്കോൾ അനുവദിക്കണം.

ഓരോ ഗേറ്റ്വേയിലും swanctl --list-sas ഉപയോഗിച്ച് ഫലം പരിശോധിച്ച്, ചൈൽഡ് സെക്യൂരിറ്റി അസോസിയേഷനുകൾ നിങ്ങൾ ഉദ്ദേശിച്ച വിലാസങ്ങൾ റിപ്പോർട്ട് ചെയ്യുന്നുണ്ടെന്ന്, ഊഹിച്ചവയല്ല എന്ന് ഉറപ്പാക്കുക. ലിസ്റ്റിൽ ആപ്ലിക്കേഷൻ സബ്നെറ്റുകൾ കാണിച്ചാൽ, പുറം നയം തെറ്റായ പാളിക്കാണ് എഴുതിയത്. റൂട്ടിംഗ് ഡീബഗ് ചെയ്യുന്നതിന് മുൻപ് സെലക്ടറുകൾ ശരിയാക്കുക, കാരണം റൂട്ടിംഗ് നന്നായി കാണും, കൗണ്ടറുകൾ അനങ്ങില്ല.

ഫോർവേഡിംഗും പുനരാവർത്തനക്കെണിയും

സെലക്ടറുകൾ റൂട്ടിംഗിന് പകരമല്ല. A-യും B-യും C-യ്ക്കും D-യ്ക്കും ഇടയിൽ ഇരു ദിശകളിലും ട്രാഫിക് ഫോർവേഡ് ചെയ്യണം, അതായത് IP ഫോർവേഡിംഗ് സജീവം, ടണലിലേക്ക് ചൂണ്ടുന്ന റൂട്ടുകൾ, മറുവശത്ത് നിലനിൽക്കുന്ന മടക്ക പാത.

പുറം ടണൽ XFRM ഇന്റർഫേസുകൾ ഉപയോഗിക്കുന്നുവെങ്കിൽ, റൂട്ടുകൾ ഇന്റർഫേസ് തിരഞ്ഞെടുക്കുന്നു, ചർച്ച ചെയ്ത നയങ്ങൾ ഇപ്പോഴും അത് എന്ത് വഹിക്കുന്നു എന്ന് പരിമിതപ്പെടുത്തുന്നു. ഇന്റർഫേസ് സംരക്ഷിത പരിധി വിശാലമാക്കുന്നില്ല; കർണൽ പാക്കറ്റ് എങ്ങനെ എടുക്കുന്നു എന്ന് മാത്രം മാറ്റുന്നു.

കെണി പുനരാവർത്തനമാണ്. B-യുടെ പുറം അറ്റപ്പോയിന്റിലേക്കുള്ള A-യുടെ റൂട്ട് A നിർമ്മിക്കുന്ന ടണലല്ല, അടിസ്ഥാന നെറ്റ്വർക്കിനെ പിന്തുടരണം, അല്ലെങ്കിൽ എൻക്യാപ്സുലേഷൻ സ്വയം ഉള്ളിൽ യാത്ര ചെയ്യാൻ ശ്രമിക്കും, കണക്ഷൻ ഒരിക്കലും പൂർത്തിയാകില്ല.

പാളികൾ ചേർക്കുന്നതിന് മുൻപ് വിവർത്തനം പരിശോധിക്കുക

മറ്റെന്തെങ്കിലും ട്യൂൺ ചെയ്യുന്നതിന് മുൻപ് A-യിലും B-യിലുമുള്ള ഏത് സോഴ്സ് NAT-ഉം നോക്കുക. IPsec നയം പ്രയോഗിക്കുന്നതിന് മുൻപ് C-യുടെ വിലാസം മാറ്റിയെഴുതുന്ന നിയമം സമ്മതിച്ച സെലക്ടറുകൾ തകർക്കാം, മറുവശത്ത് D എന്ത് സ്വീകരിക്കുന്നു എന്നതും മാറ്റാം.

വിശാലമായ മാസ്കറേഡിംഗ് രണ്ട് പാളികളുള്ളതുകൊണ്ട് സുരക്ഷിതമാകുന്നില്ല. ദൂരെയുള്ള വശം ഏത് വിലാസം കാണുന്നു എന്ന് അത് മറയ്ക്കുന്നു, ടണൽ സജീവവും ആപ്പ് അല്ലാത്തതുമായ സമയത്ത് കൃത്യമായി ആ വിവരമാണ് വേണ്ടത്.

NAT നിയമം യഥാർത്ഥത്തിൽ ആവശ്യമാണെങ്കിൽ, ഓരോ വശവും ഏത് വിലാസവുമായി സംസാരിക്കുന്നു എന്ന് കരുതുന്നു എന്ന് എഴുതുക. ആ ഒരു വരി ടണലാണോ വിവർത്തനമാണോ കുറ്റക്കാർ എന്ന തർക്കത്തിന്റെ ഭൂരിഭാഗവും പരിഹരിക്കുന്നു. ഒരു വർഷത്തിന് ശേഷം നിയമം നീക്കുമ്പോൾ അടുത്ത എഞ്ചിനീയർ എവിടെ നോക്കണം എന്നും അത് പറയുന്നു. പിംഗ് അതിൽ ഒന്നും ചെയ്യില്ല.

fail-closed തെളിയിച്ച് MTU പരിശോധിക്കുക

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

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

രണ്ട് എൻക്യാപ്സുലേഷനുകൾക്കും ബജറ്റ് വയ്ക്കുക. പ്രവർത്തിക്കുന്ന IKE ചെറിയ പാക്കറ്റുകളുടെ ഫലമാണ്, രണ്ട് ഹെഡറുകൾ ചേർത്തതിന് ശേഷം പൂർണ്ണ വലിപ്പത്തിലുള്ള ആപ്ലിക്കേഷൻ പാക്കറ്റുകൾ ഇപ്പോഴും പരാജയപ്പെടാം; സംഖ്യകൾ കൂട്ടിച്ചേരും എന്ന് കരുതുന്നതിന് പകരം യഥാർത്ഥ പാതയിൽ അറിയാവുന്ന പേലോഡ് വലിപ്പത്തോടെ പരീക്ഷിക്കുക. കണക്ക് എളുപ്പമാണ്, പാതയല്ല.