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-க்கு route செய்ய முடியாது. VPN எந்த வகை gateway-ல் முடிகிறது என்பது மொழிபெயர்ப்புப் பாதை இருக்கிறதா என்பதையே தீர்மானிக்கிறது. தவறு நீடிப்பதற்குக் காரணம் சுரங்கப்பாதையின் நிலை UP ஆக இருப்பதும், அதே subnet-ல் உள்ள EC2 instance சிரமமின்றி இணையத்தை அடைவதும் ஆகும். இந்த இரு அவதானிப்புகளில் எதுவும் உடைந்த திசையைச் சோதிக்கவில்லை.

நடைமுறையில் பாக்கெட் உள்ளூர் வலையமைப்பின் மூல முகவரியுடன் வந்து அதை மொழிபெயர்க்கும் ஆதரிக்கப்பட்ட அடுத்த hop-ஐக் காணவில்லை. அட்டவணைகளைப் பொறுத்து அது egress எல்லையில் வீசப்படுகிறது, சுரங்கப்பாதை UP ஆகவே இருக்க, அதே subnet-ல் உள்ள instance இணையத்தை அடைவதால், தோல்வி உள்ளூர் 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 உள்ளன, ஒவ்வொரு அம்பும் நீங்கள் அமைக்க வேண்டிய route முடிவு. டிராஃபிக் உள்ளூர் வலையமைப்பிலிருந்து 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 விதி இல்லாமல் திரும்பி வரும். அந்தப் பண்பு உள்ளூர் சேவையை இணையத்தில் வெளியிடுவதில்லை, அதை அப்படியே கருதுவது ஒருபோதும் உருவாகாத இணைப்பை debug செய்வதில் குழுவுக்கு ஒரு நாளை இழக்கச் செய்கிறது. வாடிக்கையாளர் தொடங்கும் டிராஃபிக்கிற்கு நான்கு 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-யின் instance-ல் HTTP proxy செல்லுபடியாகும் மாற்று, பல நேரங்களில் மலிவானது. வாடிக்கையாளர்கள் அதைப் பயன்படுத்த அமைக்கப்படுகிறார்கள், proxy தன் சொந்த இணைப்பை வெளியே திறக்கிறது, திரும்பும் பாதை சமச்சீர் routing புதிராக இல்லாமல் proxy-யின் பிரச்சினையாகிறது. சில பயன்பாடுகளுக்கு இது transit gateway வேலையின் பெரும்பகுதியை நீக்குகிறது. NAT gateway உருவாக்க முடியாத பயனர் அளவிலான பதிவுகளையும் இது தருகிறது.

இருப்பினும் அது வெளிப்படையானது அல்ல. proxy அமைப்புகளைப் புறக்கணிக்கும் எதுவும், HTTP அல்லாத ஒவ்வொரு நெறிமுறையும் அந்தப் பாதையில் செல்லாது.

தேர்வு உங்கள் பயன்பாடுகள் உண்மையில் என்ன பேசுகின்றன, பதிவுகளில் எவ்வளவு அடையாளம் தேவை என்பதைப் பொறுத்தது. அவை HTTP பேசும் இடத்தில் proxy தன் இடத்தைப் பெறுகிறது; தன்னிச்சையான நெறிமுறைகளுக்குப் பொது egress தேவைப்படும் இடத்தில் AWS ஆதரிக்கும் வடிவமைப்பு transit gateway. இதை முன்கூட்டியே முடிவு செய்வது route tables கட்டிய பின் கண்டுபிடிப்பதை விட மலிவு.