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 ఇన్‌స్టాన్స్ ఇబ్బంది లేకుండా ఇంటర్నెట్‌ను చేరుకోవడం. ఈ రెండు పరిశీలనలు ఏవీ విరిగిన దిశను పరీక్షించవు.

ఆచరణలో ప్యాకెట్ ఆన్-ప్రెమైసెస్ మూల చిరునామాతో వస్తుంది మరియు దాన్ని అనువదించే మద్దతు ఉన్న తదుపరి 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 ఉన్నాయి మరియు ప్రతి బాణం మీరు కాన్ఫిగర్ చేయాల్సిన 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 నియమం లేకుండా తిరిగి వస్తాయి. ఆ లక్షణం ఏ ఆన్-ప్రెమైసెస్ సేవను ఇంటర్నెట్‌లో ప్రచురించదు, అలా భావించడం ఎప్పుడూ ఏర్పడని కనెక్షన్‌ను డీబగ్ చేయడంలో బృందానికి ఒక రోజు కోల్పోయేలా చేస్తుంది. క్లయింట్ ప్రారంభించే ట్రాఫిక్‌కు నాలుగు 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 నిర్మించిన తర్వాత కనుగొనడం కంటే చవకైనది.