AWS Site-to-Site VPN മുതൽ NAT Gateway വരെ: VGW vs Transit Gateway

ആദ്യമായി എല്ലാവരും ഒരേ ഡയഗ്രം വരയ്ക്കുന്നു: VPC-യിലേക്ക് VPN, പിന്നെ NAT gateway വഴി ഇന്റർനെറ്റിലേക്ക്, കഴിഞ്ഞു. പക്ഷേ VPN virtual private gateway-യിൽ അവസാനിക്കുമ്പോൾ AWS ആ പാത പിന്തുണയ്ക്കുന്നില്ല, പരാജയം വളരെ നിശ്ശബ്ദമായതിനാൽ ടീമുകൾ അത് ഒന്നിലധികം തവണ വീണ്ടും നിർമ്മിക്കുന്നു. പ്രവർത്തിക്കുന്ന ഡിസൈനിന് transit gateway ആവശ്യമാണ്, അത് ഇരുവശത്തും gateway-ഉം route tables-ഉം മാറ്റുന്നു. എന്തെങ്കിലും വരയ്ക്കുന്നതിന് മുമ്പ് രണ്ട് രൂപങ്ങളും താരതമ്യം ചെയ്യുക.

വ്യക്തമായി തോന്നുന്നുവെങ്കിലും പിന്തുണയ്ക്കാത്ത ടോപ്പോളജി

AWS-ന്റെ NAT gateway ഡോക്യുമെന്റേഷൻ ഒരു VPC ഡിസൈൻ മാത്രം നിർമ്മിച്ചവരെ അമ്പരപ്പിക്കുന്ന ഒരു വര വരയ്ക്കുന്നു: Site-to-Site VPN കണക്ഷനിൽ നിന്നുള്ള ട്രാഫിക് virtual private gateway വഴി NAT gateway-ലേക്ക് റൂട്ട് ചെയ്യാൻ കഴിയില്ല. VPN അവസാനിക്കുന്ന gateway തരം വിവർത്തന പാതയുണ്ടോ എന്ന് തന്നെ തീരുമാനിക്കുന്നു. തകരാർ നിലനിൽക്കുന്നത് ടണൽ നില UP ആയതിനാലും അതേ subnet-ലെ EC2 ഇൻസ്റ്റൻസ് പ്രശ്നമില്ലാതെ ഇന്റർനെറ്റിലെത്തുന്നതിനാലുമാണ്. ഈ രണ്ട് നിരീക്ഷണങ്ങളും തകർന്ന ദിശ പരിശോധിക്കുന്നില്ല.

പ്രായോഗികമായി പാക്കറ്റ് ഓൺ-പ്രെമിസ് ഉറവിട വിലാസത്തോടെ എത്തുന്നു, അത് വിവർത്തനം ചെയ്യുന്ന പിന്തുണയുള്ള അടുത്ത hop കണ്ടെത്തുന്നില്ല. ടേബിളുകൾ അനുസരിച്ച് അത് egress അതിർത്തിയിൽ ഉപേക്ഷിക്കപ്പെടുന്നു, ടണൽ UP ആയി തുടരുകയും അതേ subnet-ലെ ഇൻസ്റ്റൻസ് ഇന്റർനെറ്റിലെത്തുകയും ചെയ്യുന്നതിനാൽ പരാജയം ഓൺ-പ്രെമിസ് firewall പ്രശ്നമായി റിപ്പോർട്ട് ചെയ്യുന്നു.

Virtual private gateway vs transit gateway

ഒരു virtual private gateway ഒരു VPC-യുടേതാണ്. അത് VPN അവസാനിപ്പിക്കുന്നു, ആ VPC-യുടെ route tables-ൽ routes ഇൻസ്റ്റാൾ ചെയ്യുന്നു, അവിടെ നിർത്തുന്നു. അതിന് attachment മോഡലില്ല, അതിനാൽ മറ്റൊരു VPC-യ്ക്കോ പങ്കിട്ട egress സെഗ്മെന്റിനോ ട്രാഫിക് നൽകാൻ കഴിയില്ല. ഈ ഒരു VPC പരിധിയാണ് മുഴുവൻ നിയന്ത്രണവും, VPC-യ്ക്കുള്ളിൽ ചേർക്കുന്ന ഒരു route-ഉം അത് മാറ്റുന്നില്ല.

Transit gateway ഒരു പ്രാദേശിക ഹബ്ബാണ്, അവിടെ VPN, ഓരോ spoke VPC, പങ്കിട്ട സേവനങ്ങളുടെ VPC എന്നിവയെല്ലാം attachments ആയി പ്രത്യക്ഷപ്പെടുന്നു. അതിന് സ്വന്തം route tables ഉണ്ട്, ഏത് attachment ഒരു നിർദ്ദിഷ്ട prefix സ്വീകരിക്കുമെന്ന് അവ തിരഞ്ഞെടുക്കുന്നു.

ഈ ഹബ്ബാണ് കേന്ദ്രീകൃത egress സാധ്യമാക്കുന്നത്: VPN ഒരു attachment ആയി ഇറങ്ങുന്നു, egress VPC മറ്റൊന്നായി, transit gateway route table ഇന്റർനെറ്റ് ലക്ഷ്യമിടുന്ന prefixes ആദ്യത്തേതിൽ നിന്ന് രണ്ടാമത്തേതിലേക്ക് അയയ്ക്കുന്നു. virtual private gateway-യിൽ അയയ്ക്കാൻ രണ്ടാമത്തെ attachment ഇല്ല, അതിനാൽ ഡിസൈൻ പിന്നീട് പാച്ച് ചെയ്ത് ഉണ്ടാക്കാൻ കഴിയില്ല.

പിന്തുണയുള്ള egress പാത, ഘട്ടം ഘട്ടമായി

റഫറൻസ് ഡിസൈനിൽ അഞ്ച് hops ഉണ്ട്, ഓരോ അമ്പും നിങ്ങൾ കോൺഫിഗർ ചെയ്യേണ്ട ഒരു routing തീരുമാനമാണ്. ട്രാഫിക് ഓൺ-പ്രെമിസ് നെറ്റ്വർക്കിൽ നിന്ന് Site-to-Site VPN attachment-ലേക്ക് പോകുന്നു, transit gateway route table അതിനെ egress VPC attachment-ലേക്ക് കൈമാറുന്നു, അവിടെ subnet ടേബിൾ അതിനെ പൊതു NAT gateway-ലേക്ക് അയയ്ക്കുന്നു. NAT gateway ഉറവിടം വിവർത്തനം ചെയ്യുന്നു, internet gateway പാക്കറ്റ് പുറത്തേക്ക് കൊണ്ടുപോകുന്നു.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

അവസാന hops പ്രവർത്തിക്കുമോ എന്ന് രണ്ട് കാര്യങ്ങൾ തീരുമാനിക്കുന്നു. NAT gateway പൊതുവായിരിക്കണം, elastic IP-ഉം internet gateway-ലേക്കുള്ള route-ഉം വേണം, കാരണം സ്വകാര്യ NAT gateway നെറ്റ്വർക്കുകൾക്കിടയിൽ വിവർത്തനം ചെയ്യുന്നു, ഒരിക്കലും ഇന്റർനെറ്റ് എക്സിറ്റ് ആകുന്നില്ല.

നിങ്ങൾ സേവനം നൽകാൻ ഉദ്ദേശിക്കുന്ന ഓരോ Availability Zone-നും ഒരു NAT gateway ആസൂത്രണം ചെയ്യുക, ഓരോ subnet ടേബിളും പ്രാദേശികമായതിലേക്ക് ചൂണ്ടട്ടെ. നിങ്ങളുടെ കുറിപ്പുകളിൽ transit gateway ടേബിളും VPC ടേബിളുകളും വെവ്വേറെ വസ്തുക്കളായി സൂക്ഷിക്കുക, ഒന്ന് attachment-ഉം മറ്റൊന്ന് VPC-യ്ക്കുള്ളിലെ ഉറവിടവും തിരഞ്ഞെടുക്കുന്നു. ഒന്നിൽ മാത്രം default route ഉണ്ടെങ്കിൽ പാതയുടെ പകുതി നിർവചിക്കപ്പെടാതെ നിൽക്കുകയും തിരിച്ചറിയാൻ ഏറ്റവും ബുദ്ധിമുട്ടുള്ള ഭാഗിക പരാജയങ്ങൾ ഉണ്ടാകുകയും ചെയ്യും.

ഈ ഡിസൈനുകൾ പരാജയപ്പെടുന്നത് തിരിച്ചുള്ള പാതയിലാണ്

NAT gateway കണ്ടുകഴിഞ്ഞ flows-ന് stateful ആണ്, അതിനാൽ പുറത്തേക്കുള്ള കണക്ഷന്റെ മറുപടികൾ പുതിയ inbound നിയമമില്ലാതെ തിരികെ വരുന്നു. ആ ഗുണം ഓൺ-പ്രെമിസ് സേവനം ഇന്റർനെറ്റിൽ പ്രസിദ്ധീകരിക്കുന്നില്ല, അങ്ങനെയാണെന്ന് കരുതുന്നത് ഒരിക്കലും സ്ഥാപിക്കപ്പെടാത്ത ഒരു കണക്ഷൻ ഡീബഗ് ചെയ്യാൻ ടീമിന് ഒരു ദിവസം നഷ്ടപ്പെടുത്തുന്നു. ക്ലയന്റ് ആരംഭിക്കുന്ന ട്രാഫിക്കിന് നാല് routes യോജിക്കണം: ഓൺ-പ്രെമിസ് നയം, transit gateway ടേബിൾ, egress subnet ടേബിൾ, NAT subnet ടേബിൾ. അവസാനത്തേത് വിട്ടുപോയാൽ അഭ്യർത്ഥന കെട്ടിടം വിട്ടുപോകും, മറുപടി AWS-നുള്ളിൽ മരിക്കും.

VPN-ക്ക് പിന്നിലുള്ള യഥാർത്ഥ ക്ലയന്റിനൊപ്പം പരിശോധിച്ച് അത് ഏത് പൊതു ഉറവിട വിലാസം അവതരിപ്പിക്കുന്നു എന്ന് നോക്കുക. അത് NAT gateway-ന്റെ elastic IP ആണെങ്കിൽ വിവർത്തനം നടക്കുന്നു; മറ്റെന്തെങ്കിലും ആണെങ്കിൽ നിങ്ങൾ മറ്റൊരു egress അളക്കുന്നു.

ഈ പരാജയത്തിന്റെ അസമമായ രൂപം നേരത്തെ തിരിച്ചറിയേണ്ടതാണ്. ഒരു Availability Zone-ന്റെ NAT subnet ടേബിളിൽ ക്ലയന്റ് prefix-ലേക്ക് തിരിച്ചുള്ള route ഉണ്ടായിരിക്കുകയും മറ്റൊന്നിൽ ഇല്ലാതിരിക്കുകയും ചെയ്താൽ, flow ഏത് മേഖലയിൽ വീഴുന്നു എന്നതിന് അനുസരിച്ച് പുതിയ കണക്ഷനുകൾ വിജയിക്കുകയോ പരാജയപ്പെടുകയോ ചെയ്യും, ഈ മാതൃക അസ്ഥിരമായ ഇന്റർനെറ്റായി തെറ്റായി വായിക്കപ്പെടുന്നു. ടിക്കറ്റ് തുറന്ന മേഖല ശരിയാക്കുന്നതിനുപകരം നിങ്ങൾ സേവനം നൽകുന്ന ഓരോ മേഖലയുടെയും subnet ടേബിളുകൾ താരതമ്യം ചെയ്യുക, കാരണം കാണാത്ത route ആണ് മുഴുവൻ തകരാറും, മറുവശത്ത് ഒന്നും മാറ്റേണ്ടതില്ല.

എപ്പോഴാണ് വ്യക്തമായ proxy മികച്ച ഡിസൈൻ

egress VPC-യിലെ ഇൻസ്റ്റൻസിൽ HTTP proxy ഒരു സാധുവായ ബദലാണ്, പലപ്പോഴും വിലകുറഞ്ഞതും. ക്ലയന്റുകൾ അത് ഉപയോഗിക്കാൻ കോൺഫിഗർ ചെയ്യപ്പെടുന്നു, proxy സ്വന്തം കണക്ഷൻ പുറത്തേക്ക് തുറക്കുന്നു, തിരിച്ചുള്ള പാത സമമിത routing-ന്റെ പസിലല്ല, proxy-യുടെ പ്രശ്നമായി മാറുന്നു. കുറച്ച് അപ്ലിക്കേഷനുകൾക്ക് ഇത് transit gateway-യുടെ ഭൂരിഭാഗം ജോലിയും ഒഴിവാക്കുന്നു. NAT gateway നിർമ്മിക്കാൻ കഴിയാത്ത ഉപയോക്തൃതല ലോഗിംഗും ഇത് നൽകുന്നു.

എന്നാൽ അത് സുതാര്യമല്ല. proxy ക്രമീകരണങ്ങൾ അവഗണിക്കുന്ന എന്തും, HTTP അല്ലാത്ത ഓരോ പ്രോട്ടോക്കോളും ആ പാത പിന്തുടരില്ല.

തിരഞ്ഞെടുപ്പ് നിങ്ങളുടെ അപ്ലിക്കേഷനുകൾ യഥാർത്ഥത്തിൽ സംസാരിക്കുന്നതും ലോഗുകളിൽ എത്ര ഐഡന്റിറ്റി വേണമെന്നതും അനുസരിച്ചാണ്. അവ HTTP സംസാരിക്കുന്നിടത്ത് proxy-ക്ക് സ്ഥാനമുണ്ട്; ഏകപക്ഷീയ പ്രോട്ടോക്കോളുകൾക്ക് പൊതു egress വേണ്ടിടത്ത് AWS പിന്തുണയ്ക്കുന്ന ഡിസൈൻ transit gateway ആണ്. ഇത് മുൻകൂട്ടി തീരുമാനിക്കുന്നത് route tables നിർമ്മിച്ചതിന് ശേഷം കണ്ടെത്തുന്നതിനേക്കാൾ വിലകുറവാണ്.