VGW లేదా TGW? AWS Site-to-Site యొక్క IPsec సొరంగం ఎక్కడ ముగుస్తుంది

AWS Site-to-Site VPN ప్యాకెట్ను ఎక్కడ రక్షించడం ఆపేస్తుంది అని ప్రజలు అడిగి ఒకే సమాధానాన్ని ఆశిస్తారు: గేట్వే వద్ద. ఆ సమాధానం యొక్క ఉపయోగకరమైన రూపం ఏ గేట్వే అని పేర్కొంటుంది, ఎందుకంటే వర్చువల్ ప్రైవేట్ గేట్వే మరియు ట్రాన్సిట్ గేట్వే వేర్వేరు అటాచ్మెంట్ ఆబ్జెక్టులతో కూడిన వేర్వేరు ఏర్పాట్లు, తప్పుదాన్ని ఊహించే సమీక్షకుడు లేని రేఖాచిత్రంపై మిగిలిన మూల్యాంకనాన్ని నిర్మిస్తాడు. క్రింది మూడు తనిఖీలను క్రమంగా చేయండి. ప్రతి ఒక్కటి సరిహద్దును నిర్ధారిస్తుంది లేదా మునుపటి సమాధానం మరొక వనరు గురించి అని చెబుతుంది.

ఏదైనా మూల్యాంకనం చేసే ముందు మూడు చివరి బిందువులను పేర్కొనండి

ఈ మార్గం యొక్క ఎన్క్రిప్షన్ సమీక్షకు మూడు పేర్కొన్న విషయాలు అవసరం: కస్టమర్ గేట్వే, IPsec ను ముగించే AWS VPN లక్ష్యం, మరియు లోపలి ప్యాకెట్ను స్వీకరించే అప్లికేషన్ చివరి బిందువు. ఒక కన్సోల్ పేజీని కూడా తెరవకముందే వాటిని వాటి వనరు గుర్తింపులతో రాయండి, ఎందుకంటే ఈ బిందువు తర్వాత అంతా ఆ మూడింటిలో ఒకటి గురించిన ప్రకటన.

కస్టమర్ గేట్వే మీదే, దాని కాన్ఫిగరేషన్ మీకు కనిపిస్తుంది. AWS లక్ష్యం నిర్వహించబడే వనరు, తప్పు దాన్ని ఊహించడం: VPN కనెక్షన్ వర్చువల్ ప్రైవేట్ గేట్వేకు లేదా నేరుగా ట్రాన్సిట్ గేట్వేకు అటాచ్ కాగలదు, ఏదీ మరొకదాన్ని సూచించదు. మూడవ చివరి బిందువు ప్రజలు దాటవేసేది, అప్లికేషన్ డేటా గురించిన నిజమైన ప్రశ్నకు సమాధానం అది ఒక్కటే ఇస్తుంది.

తనిఖీ 1: సొరంగాన్ని నిజంగా ఏ గేట్వే ముగిస్తుంది

రెండు ఏర్పాట్లు మద్దతు పొందుతాయి మరియు Site-to-Site VPN ఆర్కిటెక్చర్ మార్గదర్శిని వాటిని పక్కపక్కనే వివరిస్తుంది, కాబట్టి తరచుగా ఏడాది పాత రేఖాచిత్రం బదులు API ను అడగండి. ఒక కనెక్షన్పై చదవడం-మాత్రమే ప్రశ్న VPN లక్ష్య ఫీల్డ్లను తిరిగి ఇస్తుంది:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

భేదకం TransitGatewayId, VpnGatewayId కాదు. TransitGatewayId ఖాళీగా ఉన్న కనెక్షన్ స్వతంత్ర వర్చువల్ ప్రైవేట్ గేట్వే వద్ద ముగుస్తుంది, ఆ ఫీల్డ్ సెట్ చేసిన కనెక్షన్ ట్రాన్సిట్ గేట్వే యొక్క VPN అటాచ్మెంట్ వద్ద ముగుస్తుంది, ఆ సందర్భంలో VpnGatewayId ఇంకా నిండి ఉండవచ్చు ఎందుకంటే అది అటాచ్మెంట్ యొక్క ఆధార గేట్వేను పేర్కొనగలదు. మొదట TGW ఫీల్డ్ చదవండి, తర్వాత అటాచ్మెంట్ రకాన్ని ఫీల్డ్ పేరు నుండి కాదు, అటాచ్మెంట్ జాబితా నుండి నిర్ధారించండి, ఎందుకంటే ఆ ట్రాన్సిట్ గేట్వేపై ఉన్న VPC అటాచ్మెంట్ VPN అటాచ్మెంట్ కాదు. కనెక్ట్ చేయబడిన VPC లో గమ్యస్థాన ఇన్స్టాన్స్ను కనుగొనడం ఏ VPN అటాచ్మెంట్ ప్యాకెట్ను తీసుకెళ్ళింది అనే దాని గురించి ఏమీ చెప్పదు.

అక్కడ ఉన్నప్పుడు సొరంగాలను కూడా తనిఖీ చేయండి. కనెక్షన్ పునరావృత్తి కోసం రెండు IPsec సొరంగాలను మోసుకెళ్తుంది, రెండవ సొరంగం ఎప్పుడూ లేవని కనెక్షన్ ఎన్క్రిప్షన్ సరిహద్దు గురించి ఏమీ మార్చకపోయినా లభ్యతకు నిజమైన కనుగొనడం:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

తనిఖీ 2: లోపలి ప్యాకెట్ ఇంకా ఏమి మోసుకెళ్తుంది

IPsec ముగిసిన తర్వాత AWS డీక్యాప్సులేట్ చేసిన ప్యాకెట్ను దానికి సరిపోయిన మార్గం ద్వారా పంపుతుంది. ఆ బిందువు నుండి ట్రాఫిక్ సాధారణ VPC ట్రాఫిక్, VPN రక్షణ ముగిసింది. ఇది సేవలో లోటు కాదు; ఇదే సరిహద్దు అర్థం, చెక్లిస్ట్ అంశం దాన్ని స్పష్టంగా చెప్పడం, "VPN ఎన్క్రిప్ట్ చేయబడింది" అనేది "డేటా మొదటి నుండి చివరి వరకు ఎన్క్రిప్ట్ చేయబడింది" స్థానంలో నిలబడటానికి అనుమతించకుండా.

ఇప్పుడు లోపల ఏమి ఉందో పరిశీలించండి. లోపలి ప్యాకెట్ సాదా వచన అప్లికేషన్ ప్రోటోకాల్ అయితే, మరొకటి దాన్ని ఎన్క్రిప్ట్ చేసే వరకు క్రింద ఏదీ గోప్యతను జోడించదు. లోపలి ప్యాకెట్ ఇప్పటికే TLS సెషన్ను మోసుకెళ్తుంటే, బయటి IPsec తీసివేయడం ఆ సెషన్కు ఏమీ మార్చదు: అది తన స్వంత చివరి బిందువు వరకు రక్షితంగా ఉంటుంది, ఆ చివరి బిందువు ఎక్కడ ఉన్నా.

సాధారణ అతి-సవరణ అంటే గేట్వే వెనుక ఉన్నదంతా బహిర్గతమైందని నిర్ధారించడం. అలా కాదు. సేవా రవాణా, నిల్వ ఎన్క్రిప్షన్ మరియు అప్లికేషన్ TLS వేర్వేరు షరతులతో కూడిన వేర్వేరు యంత్రాంగాలు, ప్రతి ఒక్కటి VPN ఆకారం నుండి ఊహించడం బదులు దాని స్వంత షరతులపై మూల్యాంకనం చేయాలి. ACCEPT చూపే ఫ్లో లాగ్ నమోదు మార్గనిర్దేశనం పనిచేసిందని నిరూపిస్తుంది మరియు గోప్యత గురించి ఏమీ చెప్పదు, ఈ చెక్లిస్ట్ నిరోధించాలని ఉన్నది అదే పొరపాటు.

తనిఖీ 3: గేట్వే వెనుక TLS ను ఏది ముగిస్తుంది

చిరునామాన్ని కాదు, శ్రోతను అనుసరించండి. లోడ్ బ్యాలెన్సర్ లేదా ప్రాక్సీ TLS ను ముగిస్తే, మీ క్లయింట్ పట్టుకున్న కనెక్షన్ అక్కడే ముగుస్తుంది, ప్రాక్సీ బ్యాకెండ్కు రెండవ కనెక్షన్ తెరుస్తుంది, అది సాదా వచనం లేదా వేరే విశ్వాస గొలుసుతో TLS కావచ్చు. ప్రైవేట్ IP చిరునామా మరియు సరిపోలే మార్గం ఆ రెండవ కనెక్షన్ గురించి సాక్ష్యం కాదు.

మీకు నిజంగా ముఖ్యమైన చివరి బిందువును VPC లోపలి నుండి పరీక్షించండి, ఒకసారి పరిష్కరించిన IP బదులు అప్లికేషన్ ఉపయోగించే పేరుతో:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

అభ్యర్థన దాటే ప్రతి హాప్కు ఇది పునరావృతం చేయండి. క్లయింట్ వైపు పేరుకు మరియు బ్యాకెండ్ పేరుకు మధ్య సమాధానం భిన్నంగా ఉంటే, VPN ఎప్పుడూ కప్పని ఆ విభాగాన్నే మీరు కనుగొన్నారు, అదే రాయవలసిన కనుగొనడం.

ఫలితాన్ని తీర్పుగా కాదు, విభాగాలుగా నమోదు చేయండి

ఈ చెక్లిస్ట్ అవుట్పుట్ ప్రతి విభాగానికి ఒక వరుసతో చిన్న పట్టిక: కస్టమర్ గేట్వే నుండి AWS VPN లక్ష్యం వరకు, గేట్వే నుండి పనిభారం వరకు, పనిభారం నుండి డేటా నిల్వ వరకు, మధ్యలో ఏదైనా ప్రాక్సీ హాప్. ప్రతి వరుస దాన్ని ఏది రక్షిస్తుంది మరియు ఆ రక్షణ ఏదానిపై ఆధారపడి ఉంది అని చెబుతుంది. యంత్రాంగం మరియు చివరి బిందువు లేని "ఎన్క్రిప్ట్ చేయబడింది" వరుస కాదు.

తర్వాత అసలు అవసరానికి అది అడిగిన అదే పదాలలో సమాధానం ఇవ్వండి. పనిభారం స్వీకరించే వరకు డేటా గోప్యంగా ఉండాలనేది అవసరమైతే, VPN మొదటి విభాగాన్ని మాత్రమే తీరుస్తుంది, మిగిలిన వరుసలకు అప్లికేషన్ రవాణా, సేవా TLS లేదా నిల్వ ఎన్క్రిప్షన్ విడిగా కాన్ఫిగర్ చేసి ధృవీకరించాలి.

కనెక్షన్ గుర్తింపులు, సొరంగాల స్థితి మరియు ధృవపత్ర విషయాలను నమోదులో ఉంచండి. ఆరు నెలల తర్వాత ఎవరైనా రూపకల్పనను తిరిగి చూసినప్పుడు, ఆ మూడు కళాఖండాలు రేఖాచిత్రం నుండి వాదనను మళ్లీ ప్రారంభించకుండా నిమిషాల్లో సరిహద్దు ప్రశ్నకు సమాధానం ఇస్తాయి.