EC2-ൽ strongSwan: VPC ജോലിഭാരം റൂട്ട് ചെയ്യട്ടെ

ടണൽ പ്രവർത്തിക്കുന്നു, ഗേറ്റ്‌വേ ഇൻസ്റ്റൻസിന് ദൂരെയുള്ള നെറ്റ്‌വർക്കിലേക്ക് പിംഗ് ചെയ്യാം, എന്നാൽ അതിനടുത്തുള്ള ആപ്ലിക്കേഷൻ ഇൻസ്റ്റൻസിന് ഒന്നിലും എത്താനാകുന്നില്ല. ഒന്നും തകർന്നിട്ടില്ല. വിജയിച്ച പരിശോധന VPN ഹോസ്റ്റിൽ നിന്നാണ് ആരംഭിച്ചത്, അതേ IPsec ബന്ധത്തിലൂടെ ആ ഹോസ്റ്റിന് മറ്റൊരു ഉറവിട വിലാസം വഹിക്കാനാകുമോ എന്ന് അത് ഒരിക്കലും ചോദിച്ചില്ല. ഈ റൺബുക്ക് ആ വിടവ് നാല് ഘട്ടങ്ങളിൽ അടയ്ക്കുന്നു, ഓരോ പരാജയവും ദൃശ്യമായി നിർത്തുന്ന ക്രമത്തിൽ.

ആദ്യം നാല് വിലാസങ്ങൾ എഴുതിയിടുക

താഴെയുള്ള ഓരോ ഘട്ടവും ഇവയെ സൂചിപ്പിക്കുന്നു, അതിനാൽ റൂട്ടിംഗ് പട്ടിക തൊടുന്നതിന് മുമ്പ് അവ നിങ്ങളുടെ സ്വന്തം അക്കൗണ്ടിനായി പൂരിപ്പിക്കുക.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

ഉദാഹരണം അംഗീകരിക്കപ്പെട്ട, പ്രവർത്തിക്കുന്ന നയാധിഷ്ഠിത IPsec കണക്ഷനും ഉറവിടം സംരക്ഷിക്കുന്ന പ്രവാഹവും അനുമാനിക്കുന്നു. ഇത് ഒരു അനുവദിച്ച വിലാസം കടമെടുക്കുന്ന NAT ഉള്ള ദൂരസ്ഥ പ്രവേശന ക്ലയന്റല്ല, ആ വ്യത്യാസമാണ് സെലക്ടറുകൾ മാറ്റണോ എന്ന് തീരുമാനിക്കുന്നത്.

ഘട്ടം 1: ജോലിഭാരത്തിന്റെ സബ്‌നെറ്റിന് ഒരു റൂട്ട് നൽകുക

ജോലിഭാരത്തിന്റെ സബ്‌നെറ്റുമായി യഥാർത്ഥത്തിൽ ബന്ധിപ്പിച്ചിരിക്കുന്ന റൂട്ടിംഗ് പട്ടികയ്ക്ക് ദൂരെയുള്ള പ്രിഫിക്സിനായി ഗേറ്റ്‌വേയുടെ നെറ്റ്‌വർക്ക് ഇന്റർഫേസിലേക്ക് ചൂണ്ടുന്ന ഒരു പാത ആവശ്യമാണ്. ഇൻസ്റ്റൻസിനുള്ളിൽ ഇൻസ്റ്റാൾ ചെയ്ത ഗസ്റ്റ് റൂട്ട് ആ AWS റൂട്ടിംഗ് പട്ടികയിലെ ഒരു എൻട്രിയല്ല, ഒരു strongSwan കോൺഫിഗറേഷനും അത് സൃഷ്ടിക്കില്ല.

AWS-ന്റെ ഉപകരണത്തിലൂടെയുള്ള റൂട്ടിംഗ് മാർഗ്ഗനിർദ്ദേശം നെറ്റ്‌വർക്ക് ഇന്റർഫേസ് ലക്ഷ്യങ്ങളും ഫോർവേഡ് ചെയ്യുന്ന ഇൻസ്റ്റൻസിന്റെ ഉറവിട/ലക്ഷ്യ പരിശോധനാ ആവശ്യകതയും വിവരിക്കുന്നു. ആ പരിശോധനാ മാറ്റം ഗേറ്റ്‌വേ റോളിൽ പരിമിതപ്പെടുത്തുക, സാധാരണ ആപ്ലിക്കേഷൻ ഇൻസ്റ്റൻസുകളെ വിശ്രമിക്കാൻ വിടുക.

ഒരു അംഗീകൃത നെറ്റ്‌വർക്കിന് സ്ഥലം ഒരുക്കാൻ VPC-യുടെ ലോക്കൽ റൂട്ടോ നിലവിലുള്ള ഓരോ എൻട്രിയോ മാറ്റരുത്. എന്താണ് ബന്ധിപ്പിച്ചിരിക്കുന്നതും സക്രിയവുമെന്ന് പരിശോധിക്കുക, ആരും ഉപയോഗിക്കാത്ത ഒരു റൂട്ടിംഗ് പട്ടികയ്ക്കായി കൺസോൾ പേജ് എന്ത് കാണിക്കുന്നു എന്നല്ല. സമാനമായി കാണുന്ന രണ്ട് പട്ടികകൾക്ക് വ്യത്യസ്ത ബന്ധങ്ങളാകാം. പ്രധാനമായത് ജോലിഭാരത്തിന്റെ സബ്‌നെറ്റ് ബന്ധിപ്പിച്ചിരിക്കുന്ന പട്ടികയാണ്.

ഘട്ടം 2: ഗസ്റ്റിൽ ഫോർവേഡിംഗ് ഓണാക്കുക

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

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

സെക്യൂരിറ്റി ഗ്രൂപ്പുകളാണ് ഈ ഘട്ടം സാധാരണയായി കുടുങ്ങുന്നിടം. ഒരു ഇടനില ഉപകരണം നേരിട്ടുള്ള ഇൻസ്റ്റൻസ് ആശയവിനിമയത്തിന്റെ സെക്യൂരിറ്റി ഗ്രൂപ്പ് റഫറൻസ് സ്വഭാവം പാരമ്പര്യമായി നേടുന്നില്ല, അതിനാൽ മാനേജ്ഡ് Client VPN ഉദാഹരണത്തിൽ നിന്ന് പകർത്തിയ ഒരു നിയമം ഒരിക്കലും പൊരുത്തപ്പെടണമെന്നില്ല. യഥാർത്ഥ പാതയിൽ ഇരു ദിശകളിലും സെക്യൂരിറ്റി ഗ്രൂപ്പും സബ്‌നെറ്റ് ACL-ഉം പരിശോധിക്കുക.

ഘട്ടം 3: സെലക്ടറുകൾ യഥാർത്ഥ ഉറവിടങ്ങളിലേക്ക് വിപുലീകരിക്കുക

AWS വശത്ത് 10.60.1.10/32 മാത്രം ഉൾക്കൊള്ളുന്ന ഒരു നയം 10.60.2.20 ഉൾക്കൊള്ളാതെ ഗേറ്റ്‌വേയിൽ നിന്ന് ആരംഭിച്ച വിജയം വിശദീകരിക്കുന്നു. ദൂരെയുള്ള ലക്ഷ്യത്തിലേക്കുള്ള റൂട്ട് ഒരു ട്രാഫിക് സെലക്ടർ വിപുലീകരിക്കുന്നില്ല, അതാണ് അതേ അത്ഭുതത്തിന്റെ രണ്ടാം പകുതി.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

സമ്മതിച്ച രൂപകൽപ്പന മുഴുവൻ VPC-യെയും സംരക്ഷിക്കുന്നുവെങ്കിൽ, ഇരു കക്ഷികളും 10.60.0.0/16, 10.90.0.0/24 സ്വീകരിക്കണം. അത് ഒരു ജോലിഭാരത്തെ സംരക്ഷിക്കുന്നുവെങ്കിൽ, ബോധപൂർവം ആ ഇടുങ്ങിയ പ്രിഫിക്സ് ഉപയോഗിക്കുക. ഏതായാലും, ഇൻസ്റ്റാൾ ചെയ്ത CHILD-SA നയം പരിശോധിക്കുക, കാരണം നിങ്ങൾ തിരുത്തിയ കോൺഫിഗറേഷനും അതിനെ വേറെ രീതിയിൽ ഇടുക്കിയ കക്ഷിയും ഒരേ കരാറല്ല.

ദൂരസ്ഥ സൈറ്റും സംരക്ഷിച്ച VPC ഉറവിടങ്ങളുടെ മറുപടികൾ ഉദ്ദേശിച്ച IPsec ഗേറ്റ്‌വേയിലൂടെ തിരികെ റൂട്ട് ചെയ്യണം. മറ്റ് ഉറവിട NAT നിയമങ്ങൾ ഉള്ളിടത്ത് സംരക്ഷിത ട്രാഫിക്കിനായി പിന്തുണയ്ക്കുന്ന NAT ഒഴിവാക്കൽ നിലനിർത്തുക; അംഗീകരിക്കാത്ത ഒരു ജോലിഭാരത്തെ അനുവദിച്ച ഹോസ്റ്റ് വിലാസമാക്കി മാറ്റുന്നത് മറ്റൊരു ഐഡന്റിറ്റി കരാറാണ്, നിങ്ങൾ ആഗ്രഹിച്ച പ്രവേശനത്തിന്റെ കുറുക്കുവഴിയല്ല.

ഘട്ടം 4: സ്ഥിരീകരിക്കുക, ആവശ്യമെങ്കിൽ തിരികെ മാറ്റുക

ജോലിഭാരത്തിൽ നിന്നുതന്നെ പുതിയ അനുവദിച്ച ആപ്ലിക്കേഷൻ പ്രവർത്തനത്തോടെ പരിശോധിക്കുക, പിന്നീട് ഒഴിവാക്കേണ്ട ഒരു ലക്ഷ്യത്തോടെ ആവർത്തിക്കുക. ദൂരസ്ഥ സേവനം കാണുന്ന ഉറവിട വിലാസവും അത് ഉപയോഗിക്കുന്ന തിരിച്ചുവരവ് പാതയും രേഖപ്പെടുത്തുക. ഗേറ്റ്‌വേയിലേക്ക് പിംഗ് അല്ലെങ്കിൽ പച്ച IKE സ്ഥിതി ആ പരിശോധനയല്ല.

ഗേറ്റ്‌വേ പ്രവർത്തിക്കുമ്പോഴും ജോലിഭാരം പരാജയപ്പെടുന്നുവെങ്കിൽ, ഘട്ടങ്ങളിലൂടെ ക്രമത്തിൽ പിന്നോട്ട് പോകുക: സെലക്ടർ, പിന്നെ ഫോർവേഡിംഗും സെക്യൂരിറ്റി ഗ്രൂപ്പുകളും, പിന്നെ ബന്ധിപ്പിച്ച റൂട്ടിംഗ് പട്ടിക. ഓരോന്നിനും വ്യത്യസ്ത ലക്ഷണമുണ്ട്, ഊഹിക്കൽ യഥാർത്ഥത്തിൽ തെറ്റായത് ഒഴിവാക്കുന്നു.

തിരികെ മാറ്റുന്നത് അതേ ക്രമം മറിച്ചിടുന്നു. ജോലിഭാരത്തിന്റെ സബ്‌നെറ്റിന്റെ റൂട്ട് ഒടുവിൽ നീക്കം ചെയ്യുക, മുൻ സെലക്ടറുകൾ പുനഃസ്ഥാപിച്ച ശേഷം, അതിന്റെ ഉറവിടങ്ങളെ ഇനി സംരക്ഷിക്കാത്ത ഒരു ഗേറ്റ്‌വേയിലേക്ക് ചൂണ്ടുന്ന സബ്‌നെറ്റ് അവശേഷിപ്പിക്കാതിരിക്കാൻ. ഈ കരാറുകൾ നിലനിൽക്കുമ്പോൾ സ്വയം-ഹോസ്റ്റിംഗ് ഗേറ്റ്‌വേ ഹോസ്റ്റിനേക്കാൾ കൂടുതൽ സേവിക്കാം, കൂടാതെ AWS-നിർവ്വഹിത Site-to-Site VPN എന്നത് വ്യത്യസ്തമായ പ്രവർത്തന മാതൃകയാണ്, അവിടെ strongSwan പകരം ഉപഭോക്തൃ ഗേറ്റ്‌വേയുടെ അറ്റത്ത് ഇരിക്കാം.