AWS Site-to-Site VPN: പുറവും ഉള്ളും LAN പ്രിഫിക്സും

AWS Site-to-Site VPN-ലെ മിക്ക പിഴവുകളും വിലാസ പിഴവുകളാണ്, ഒരു പാക്കറ്റ് പോലും നീങ്ങുന്നതിന് മുമ്പ് അവ സംഭവിക്കുന്നു. ടണലിന്റെ പുറം വിലാസങ്ങൾ IPsec പിയറുകളിൽ എത്തുന്നു, ഉള്ളിലെ വിലാസങ്ങൾ അവയ്ക്കിടയിലുള്ള റൂട്ടിംഗ് ലിങ്ക് ഉണ്ടാക്കുന്നു, സംരക്ഷിത പ്രിഫിക്സുകൾ ആ ലിങ്ക് എന്തിനുവേണ്ടിയാണോ അതാണ്. ഒരു റോൾ മറ്റൊന്നിലേക്ക് പകർത്തൂ, ടണൽ ഉയരും പക്ഷേ ഒന്നും റൂട്ട് ചെയ്യപ്പെടില്ല. BGP കസ്റ്റമർ ഗേറ്റ്‌വേയിൽ ഞാൻ ഉപയോഗിക്കുന്ന വായിക്കുക-പരിശോധിക്കുക-കോൺഫിഗർ ചെയ്യുക ക്രമം ഇതാണ്; മൂല്യങ്ങൾ ഓർമ്മയിൽ നിന്നല്ല, ഡൗൺലോഡ് ചെയ്ത ഉപകരണ കോൺഫിഗറേഷനിൽ നിന്നാണ്.

മൂന്ന് വിലാസ റോളുകൾ, ഒരു ടണൽ

പുറം വിലാസങ്ങൾ പൊതുവായതും IPsec പിയറുകളുടേതുമാണ്: AWS വശത്ത് ഓരോ ടണലിനും ഒന്ന്, നിങ്ങളുടെ വശത്ത് കസ്റ്റമർ ഗേറ്റ്‌വേയുടെ എത്താവുന്ന ഐഡന്റിറ്റി, നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ ഉള്ള NAT ക്രമീകരണത്തിന് അനുസൃതമാക്കി. ഉള്ളിലെ വിലാസങ്ങൾ സ്വകാര്യവും ലോജിക്കൽ ലിങ്കിന്റേതുമാണ്, അതിനെ AWS 169.254.0.0/16-ൽ നിന്ന് എടുത്ത /30 എന്ന് രേഖപ്പെടുത്തുന്നു. സംരക്ഷിത പ്രിഫിക്സുകൾ ആ ലിങ്കിലൂടെ നിങ്ങൾ റൂട്ട് ചെയ്ത് പ്രഖ്യാപിക്കുന്ന VPC, ഓൺ-പ്രെമിസസ് അല്ലെങ്കിൽ ട്രാൻസിറ്റ് നെറ്റ്‌വർക്കുകളാണ്.

ടണൽ ഇന്റർഫേസിന്റെ വിലാസമായി ഒരു LAN പ്രിഫിക്സ് നൽകുന്നതാണ് ഈ പിഴവിന്റെ ക്ലാസിക് രൂപം. ഇന്റർഫേസ് കോൺഫിഗർ ചെയ്തതായി തോന്നും, LAN പ്രഖ്യാപിക്കപ്പെടുന്നില്ല, എതിർവശത്ത് അതിന് റൂട്ടില്ല. ടണലിന് സ്വന്തം ആന്തരിക ping പോലും കടക്കാം, പക്ഷേ ഓരോ ആപ്ലിക്കേഷൻ നാമവും സമയപരിധി കഴിയും. ടണൽ ഓപ്ഷൻ റഫറൻസ് ആന്തരിക CIDR-ന്റെ നിയന്ത്രണങ്ങൾ ലിസ്റ്റ് ചെയ്യുന്നു, അത് ഏത് വിലാസ ശ്രേണിയിൽ നിന്ന് വരണം എന്നത് ഉൾപ്പെടെ.

മൂല്യങ്ങൾ ഡൗൺലോഡ് ചെയ്ത കോൺഫിഗറേഷനിൽ നിന്ന് വായിക്കുക

നിങ്ങളുടെ നിർദ്ദിഷ്ട ഉപകരണ മോഡലിനുള്ള കോൺഫിഗറേഷൻ കണക്ഷനിൽ നിന്ന് ഡൗൺലോഡ് ചെയ്യുക, എന്നിട്ട് അതിന്റെ വിലാസ പട്ടിക സത്യത്തിന്റെ ഉറവിടമായി കണക്കാക്കുക. കൺസോൾ ഓരോ ടണലിനും അതേ മൂല്യങ്ങൾ കാണിക്കുന്നു: പുറം IP, ആന്തരിക CIDR, AWS വശത്തെ BGP പിയർ വിലാസം. രണ്ട് ടണലുകളും വെവ്വേറെ ഒബ്ജക്റ്റുകളാണ്, വെവ്വേറെ പുറം എൻഡ്‌പോയിന്റുകളും വെവ്വേറെ ആന്തരിക /30-കളുമുണ്ട്, രണ്ടും ഒരേ സംരക്ഷിത നെറ്റ്‌വർക്കുകൾ വഹിക്കുന്നുവെങ്കിലും.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query 'VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,TunnelInsideCidr]'
aws ec2 describe-customer-gateways --customer-gateway-ids cgw-0123456789abcdef0 \
  --query 'CustomerGateways[0].[IpAddress,BgpAsn]'

ഡൗൺലോഡ് ചെയ്ത ഫയലും ലൈവ് കൺസോളും ഒത്തുപോകുന്നില്ലെങ്കിൽ ഫയൽ പഴയതാണ്. വിലാസങ്ങൾ കൈകൊണ്ട് തിരുത്തുന്നതിന് പകരം വീണ്ടും ഡൗൺലോഡ് ചെയ്യുക, കാരണം ആന്തരിക ജോഡിയും പിയറിന്റെ കോൺഫിഗർ ചെയ്ത അയൽക്കാരനും തമ്മിലുള്ള വൈരുദ്ധ്യം നിശ്ശബ്ദ BGP പരാജയമാണ്.

ശരിയായ വിലാസം ചേർത്ത് ലിങ്ക് നിർമ്മിക്കുക

Linux ഗേറ്റ്‌വേയിൽ ടണൽ VTI അല്ലെങ്കിൽ XFRM ഇന്റർഫേസാണ്, ആന്തരിക /30 ആ ഇന്റർഫേസിലേക്ക് പോകുന്നു. രണ്ട് ടണൽ എന്നാൽ രണ്ട് ഇന്റർഫേസും രണ്ട് BGP അയൽക്കാരും, ഓരോ AWS എൻഡ്‌പോയിന്റിനും ഓരോന്ന്. AWS ഡൗൺലോഡ് ചെയ്ത ഉപകരണ കോൺഫിഗറേഷനിൽ അച്ചടിക്കുന്ന സമ്പ്രദായം വെർച്വൽ പ്രൈവറ്റ് ഗേറ്റ്‌വേയെ ഓരോ ആന്തരിക /30-ന്റെയും ആദ്യ വിലാസത്തിലും നിങ്ങളുടെ കസ്റ്റമർ ഗേറ്റ്‌വേയെ രണ്ടാമത്തേതിലും വയ്ക്കുന്നു, അതിനാൽ നിങ്ങൾ ഉയർന്ന വിലാസം എടുത്ത് താഴ്ന്നതുമായി പിയർ ചെയ്യുന്നു. ഇവിടെ ഒന്നിനും LAN വിലാസം ആവശ്യമില്ല.

ip tunnel add tun0 mode vti local 203.0.113.10 remote 18.230.1.1 key 42
ip addr add 169.254.10.2/30 dev tun0
ip link set tun0 up mtu 1400
ip tunnel add tun1 mode vti local 203.0.113.10 remote 18.230.2.1 key 43
ip addr add 169.254.10.6/30 dev tun1
ip link set tun1 up mtu 1400

നിങ്ങളുടെ ഉപകരണ മോഡലിന്റെ ഫയൽ വിപരീത ജോഡി അച്ചടിക്കുന്നുവെങ്കിൽ അതിന്റെ സംഖ്യകൾ ഉപയോഗിക്കുകയും നിയമം പാലിക്കുകയും ചെയ്യുക: ഇന്റർഫേസിലെ വിലാസം നിങ്ങളുടേതാണ്, പിയർ വിലാസം AWS-ന്റേതാണ്. ഇത് തലകീഴായി ചെയ്താൽ ഒരിക്കലും Established-ൽ എത്താത്ത ടണൽ ഉണ്ടാകും, കാരണം നിങ്ങൾ കോൺഫിഗർ ചെയ്ത അയൽക്കാരൻ നിങ്ങളുടെ സ്വന്തം ഇന്റർഫേസ് ഇതിനകം വഹിക്കുന്ന വിലാസമാണ്.

mark-ഉം VTI കീയും IKE ഡീമൺ ചൈൽഡ് SA ഇന്റർഫേസിലേക്ക് ബന്ധിക്കാൻ ഉപയോഗിക്കുന്നതുമായി ഒരുമിപ്പിച്ച് നിർത്തുക, അല്ലെങ്കിൽ ട്രാഫിക് ടണലിൽ എത്തും പക്ഷേ ഇറങ്ങാൻ ഇന്റർഫേസില്ല. മറ്റൊരു സൈറ്റിൽ നിന്ന് സംഖ്യ പകർത്തുന്നതിന് പകരം MTU പാതയ്ക്കും IKE ഡീമണിന്റെ സ്വന്തം ക്രമീകരണങ്ങൾക്കും എതിരെ പരിശോധിക്കുക.

റൂട്ടുകൾ പരിശോധിക്കുന്നതിന് മുമ്പ് BGP പരിശോധിക്കുക

IPsec ഉയരുന്നത് പിയറുകൾ ഒരു സെക്യൂരിറ്റി അസോസിയേഷനിൽ യോജിച്ചു എന്ന് മാത്രം തെളിയിക്കുന്നു. BGP സെഷൻ ആന്തരിക ലിങ്കിന് മേലുള്ള വേറിട്ട ചർച്ചയാണ്, അതിനാൽ അയൽക്കാരന്റെ അവസ്ഥയും പ്രിഫിക്സ് കൗണ്ടറുകളും വായിച്ച്, നിങ്ങൾ പ്രഖ്യാപിക്കാൻ ഉദ്ദേശിച്ചതുമായി താരതമ്യം ചെയ്യുക.

ip -s addr show dev tun0
vtysh -c 'show bgp summary'
vtysh -c 'show bgp neighbors 169.254.10.1'
vtysh -c 'show ip bgp neighbors 169.254.10.1 advertised-routes'

Established അവസ്ഥയും പൂജ്യം പ്രിഫിക്സുകൾ സ്വീകരിച്ചതും നയത്തിന്റെയോ പ്രഖ്യാപനത്തിന്റെയോ പ്രശ്നമാണ്, ടണലിന്റേതല്ല. മുഴുവൻ പരിശോധനയും രണ്ടാമത്തെ ടണലിൽ ആവർത്തിക്കുക; പ്രവർത്തിക്കുന്ന ആദ്യ ടണൽ വിലാസങ്ങൾ വിശ്വസനീയമാണെന്ന് പറയുന്നു, രണ്ടാമത്തെ ടണൽ കോൺഫിഗർ ചെയ്തു എന്നല്ല.

റൂട്ട് ചെയ്ത പാക്കറ്റ് പിന്തുടരുക, എന്നിട്ട് നിർത്തുക

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

Reachability Analyzer AWS വശത്തെ ഉപകരണമാണ്, അത് ഒരു ഉറവിടവും ലക്ഷ്യവും പാതയും എടുത്ത് പിന്തുണയ്ക്കുന്ന കോൺഫിഗറേഷനിൽ ഏത് ഘടകം അത് തടഞ്ഞു എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു. VPC-യിൽ നിന്ന് നിങ്ങളുടെ കസ്റ്റമർ ഗേറ്റ്‌വേ വിലാസത്തിലേക്കുള്ള പാത പരിശോധിക്കാൻ ഇത് ഉപയോഗിക്കുക, ആപ്ലിക്കേഷൻ ഹോസ്റ്റിൽ നിന്നല്ല. ഇത് കോൺഫിഗറേഷൻ വിശകലനം ചെയ്യുന്നു, പ്രാദേശിക ഫയർവാളിലൂടെ പാക്കറ്റ് അയയ്ക്കുന്നില്ല, അതിനാൽ അതിന്റെ വിധി നിങ്ങളുടെ സ്വന്തം ഇന്റർഫേസ് കൗണ്ടറുകളിൽ നിന്നും പാക്കറ്റ് ക്യാപ്ചറുകളിൽ നിന്നും വേർതിരിച്ച് നിർത്തുക.

ഓരോ ടണലിന്റെയും പുറം ജോഡി, ആന്തരിക /30, പ്രഖ്യാപിച്ച പ്രിഫിക്സുകൾ ഒരു പട്ടികയിൽ രേഖപ്പെടുത്തുക. ആ പട്ടികയാണ് അടുത്ത മാറ്റം അവലോകനയോഗ്യമാക്കുന്നത്.