peered VPC చేరుకోవడానికి AWS Client VPN లేదా bastion
రెండు మార్గాలు పనిచేస్తాయి, కానీ వేర్వేరు ప్రదేశాల్లో విఫలమవుతాయి. endpoint మార్గాలు, రిటర్న్ రూటింగ్ మరియు bastion నిజాయితీ సరిహద్దు అయ్యే మూడు సందర్భాలను పోల్చండి.
ఒక Client VPN endpoint తన అనుబంధిత VPC తో peered గా ఉన్న VPC ను చేరుకోగలదు, మరియు దాన్ని చట్టబద్ధం చేయడానికి మీకు bastion అవసరం లేదు. చేయదగిన ఎంపిక ట్రాఫిక్ ఎక్కడ చేతులు మారుతుంది అనేది: association సబ్‌నెట్‌లో దిగి peering కనెక్షన్ దాటే endpoint మార్గం, లేదా peered VPC లో సెషన్‌ను ముగించే host. రెండు మార్గాలు పనిచేస్తాయి మరియు వేర్వేరు ప్రదేశాల్లో విఫలమవుతాయి, కాబట్టి నిర్ణయం యాజమాన్యం మరియు ఆడిట్ గురించి, AWS ఏమి అనుమతిస్తుంది అనేది గురించి కాదు. వాటి మధ్య నేను ఎలా ఎంచుకుంటాను, మరియు routed మార్గాన్ని పనిచేయించే నాలుగు నమోదులు ఇక్కడ ఉన్నాయి.
రెండు మార్గాలు, ఒక endpoint, వేర్వేరు యజమానులు
routed మార్గంలో క్లయింట్ ట్రాఫిక్ endpoint ను చేరుతుంది, association సబ్‌నెట్‌లోని Client VPN నెట్‌వర్క్ ఇంటర్‌ఫేస్ చిరునామాగా అనువదించబడుతుంది, మరియు A నుండి B వరకు peering కనెక్షన్ ద్వారా ఆ సబ్‌నెట్‌ను విడిచిపెడుతుంది. VPC B ఏ VPN సెషన్‌ను ముగించదు; ఇది VPC A నుండి సాధారణ ట్రాఫిక్‌ను చూస్తుంది, అందుకే దాని రిటర్న్ మార్గం క్లయింట్ పూల్‌కు కాదు, VPC A కు సూచిస్తుంది.
bastion మార్గంలో క్లయింట్ మొదట host ను చేరుతుంది. A లోని bastion చివరి హాప్‌ను ఇంకా peering కనెక్షన్ దాటనిస్తుంది, కాబట్టి peering పని మిగిలి ఒక సెషన్ చేరుతుంది. B లోని bastion కూడా క్లయింట్ నుండి మార్గం కావాలి, ఆ మార్గం అదే endpoint మార్గం అయితే, routed రూపకల్పనకు ఒక హాప్ చేరుతుంది. bastion పనిని తగ్గించేది అది ఇప్పటికే ఉన్నప్పుడు, ఇప్పటికే ఆమోదించబడినప్పుడు, మరియు దాని వెనుక ఉన్నది నెట్‌వర్క్ సరిహద్దు కాకుండా సెషన్ సరిహద్దు కావాల్సినప్పుడు మాత్రమే.
నాలుగు నమోదులు routed మార్గాన్ని పనిచేయిస్తాయి
AWS ఈ దృశ్యాన్ని Client VPN how-it-works పేజీలో నమోదు చేస్తుంది, ఆచరణలో రెండు లేదా మూడు బృందాల యాజమాన్యంలోని నాలుగు నమోదులకు వస్తుంది. పరిధులు ఉదాహరణకు; peered పరిధి ప్రత్యేకంగా ఉండాలి మరియు రిటర్న్ పరిధి మీ ప్రణాళికకు సరిపోలాలి.
| Control | What it must say |
|---|---|
| Endpoint route | 10.70.0.0/16 targets the association subnet |
| Authorization rule | The approved group may reach 10.70.0.0/16 |
| VPC A association-subnet table | 10.70.0.0/16 targets the peering connection |
| VPC B resource-subnet table | VPC A's range targets the same peering connection |
మార్గం మరియు అనుమతి వేర్వేరు నియంత్రణలు. సరిపోలే అధికార నియమం లేని సరైన endpoint మార్గం క్లయింట్‌కు ఏమీ ఇవ్వదు; endpoint రూట్ చేయలేని గమ్యానికి అధికార నియమం అతనికి నల్ల రంధ్రం ఇస్తుంది. రెండూ ఒకే పరిధిని పేర్కొనాలి.
endpoint మార్గం endpoint యొక్క స్వంత VPC లోని సబ్‌నెట్‌ను సూచిస్తుంది, ఎప్పుడూ peering కనెక్షన్‌ను కాదు. VPC మార్గ పట్టికలు peering కనెక్షన్‌ను సూచిస్తాయి, ఎప్పుడూ instance లేదా ఇంటర్‌ఫేస్‌ను కాదు. రెండింటి మధ్య విలువను కాపీ చేయడం ఫిర్యాదు లేకుండా సేవ్ అవుతుంది మరియు ఏమీ రూట్ చేయదు.
association సబ్నెట్ క్లయింట్ మూలాన్ని అనువదిస్తుంది కాబట్టి, B క్లయింట్ పూల్‌కు కాదు, VPC A కు తిరిగి రూట్ చేయాలి. peering కనెక్షన్ మీద క్లయింట్ పరిధిని పంపడం సమమితంగా కనిపిస్తుంది, సమీక్షను దాటుతుంది మరియు నిశ్శబ్దంగా విఫలమవుతుంది ఎందుకంటే B క్లయింట్ మూలంతో ఉన్న ప్యాకెట్‌ను ఎప్పుడూ చూడదు.
భద్రతా సమూహాలు మరియు అనుమతి చివరి మీటర్
రూటింగ్ ప్యాకెట్‌లను B లోకి తెస్తుంది; నిర్ణయం B ఇంకా తీసుకుంటుంది. అదే ప్రాంతంలోని క్రియాశీల peering కనెక్షన్‌కు, B లోని భద్రతా సమూహం Client VPN association కు వర్తించిన సమూహాన్ని సూచించగలదు, ఇది నియమాన్ని ఇరుకుగా ఉంచి చిరునామా మార్పులను తట్టుకుంటుంది. సమూహ సూచన సాధ్యం కాని చోట, 0.0.0.0/0 వరకు విస్తరించే బదులు association సబ్నెట్ పరిధిని స్పష్టంగా అనుమతించండి, ఎందుకంటే అది రూటింగ్ లోపాన్ని వివరణ లేని టైమ్‌అవుట్‌గా మారుస్తుంది.
తర్వాత రూటింగ్ ఎప్పుడూ తాకని దాన్ని తనిఖీ చేయండి: రెండు సబ్‌నెట్‌లపై నెట్‌వర్క్ ACL, అప్లికేషన్ allow-list లేదా టోకెన్ ప్రేక్షకులు, మరియు DNS. peering ప్రైవేట్ హోస్టెడ్ జోన్‌లను కాపీ చేయదు, కాబట్టి ల్యాప్‌టాప్ పరిష్కరించలేని చిరునామాకు పనిచేసే మార్గాన్ని ఉంచుకోవచ్చు, మరియు peering కనెక్షన్ ధృవపత్రానికి విశ్వాసాన్ని జోడించదు. endpoint ను B కోసం సమాధానమిచ్చే resolver కు సూచించండి, తర్వాత ప్రైవేట్ పేరు మరియు ధృవపత్రం సరిపోలుతాయని నిర్ధారించండి.
bastion నిజాయితీ సమాధానం అయినప్పుడు
ఉద్దేశపూర్వకంగా bastion ఎంచుకోవడానికి నేను మూడు ట్రిగ్గర్‌లను ఉంచుతాను. peered VPC మీ పరిధికి రిటర్న్ మార్గాన్ని జోడించని లేదా సమూహ సూచనను అంగీకరించని బృందానికి చెందుతుంది. యాక్సెస్ ప్రతి సెషన్‌కు ఆమోదించబడాలి లేదా నమోదు చేయబడాలి మరియు అప్లికేషన్ దాన్ని తనే మోయలేదు. లేదా చివరి హాప్ B లోనే ఉండాలి ఎందుకంటే సేవ అక్కడ మాత్రమే పరిష్కరించబడుతుంది మరియు దాని TLS గుర్తింపు అంతర్గత పేరుకు పిన్ చేయబడింది.
వీటిలో ఏదీ peering ట్రాన్సిటివ్ కాదు అనే వాస్తవాన్ని దాటవేయడం కాదు. ట్రాన్సిటివ్ కాని స్వభావం B లోని వనరులు ఏమి చేయగలవో పరిమితం చేస్తుంది: A తో peered గా ఉన్న మూడవ VPC కి A ను ట్రాన్సిట్‌గా ఉపయోగించలేరు. VPN వినియోగదారు నేరుగా peered VPC ను చేరుకోలేడు అని అది ఎప్పుడూ అర్థం కాలేదు, మరియు ఆ తప్పు పఠనాన్ని తప్పించుకోవడానికి నిర్మించిన bastion కారణం లేకుండా ప్యాచ్ చేయాల్సిన host.
వ్యతిరేక లోపం కాలక్రమేణా ఎక్కువ ఖర్చవుతుంది: ప్రతి బృందాన్ని ఇప్పటికే ఉన్న ఒకే bastion ద్వారా పంపండి, తర్వాత దాని భద్రతా సమూహం, మార్గ పట్టిక మరియు ప్యాచ్ విండో ఉత్పత్తి ఆధారం అని కనుగొనండి. host ఏ ట్రిగ్గర్‌కు సేవ చేస్తుందో రాయండి, మరియు ట్రిగ్గర్ పోయినప్పుడు దాన్ని విరమింపజేయండి.
Transit Gateway మరియు అనేక association లెక్కను మారుస్తాయి
endpoint సబ్‌నెట్‌కు బదులు నేరుగా Transit Gateway కు జోడించబడి ఉంటే, నమూనా మారుతుంది: క్లయింట్‌లు ఇకపై association సబ్‌నెట్‌లోని ఇంటర్‌ఫేస్ చిరునామాగా అనువదించబడరు, మరియు gateway మార్గ పట్టికలు క్లయింట్ పరిధిని మరియు peered VPC కి దారితీసే కనెక్షన్‌ను మోయాలి. ఇది స్కేల్‌లో శుభ్రంగా ఉంటుంది, కానీ పని నాలుగు నమోదుల నుండి gateway మార్గ పట్టికలకు మారుతుంది.
అనేక association తనిఖీలను గుణిస్తాయి. endpoint మార్గం endpoint యొక్కది, అయినా ప్రతి association సబ్‌నెట్‌కు నిజమైన peering తదుపరి హాప్ ఉన్న మార్గ పట్టిక కావాలి. ఒక association ద్వారా సెషన్ విజయవంతం కావచ్చు, మరొకదానికి రిటర్న్ మార్గం ఉండకపోవచ్చు, కాబట్టి ప్రతి ఒక్కటి పరీక్షించండి.
విరిగినదాన్ని త్వరగా కనుగొనే ధృవీకరణ క్రమం
వీటిని క్రమంగా నడపండి; ప్రతి దశ తదుపరిది విఫలమవుతున్నప్పుడు కూడా పాస్ కావచ్చు, మరియు క్లయింట్ టైమ్‌అవుట్ ఏది విరిగిందో దాదాపు ఎప్పుడూ చెప్పదు.
- క్లయింట్ నుండి అప్లికేషన్ పేరును పరిష్కరించి, చిరునామా peered పరిధిలో ఉందని తనిఖీ చేయండి.
- కనెక్ట్ అవ్వండి, తర్వాత సెషన్‌ను ముగించిన association కోసం endpoint కనెక్షన్ లాగ్ చదవండి.
- ఆ association సబ్‌నెట్‌లో, మార్గ పట్టిక peered పరిధిని క్రియాశీల peering కనెక్షన్‌కు సూచిస్తుందని నిర్ధారించండి.
- B లోని వనరు సబ్‌నెట్‌లో, ఇంటర్‌ఫేస్ పరిధికి రిటర్న్ నమోదు మరియు సరిపోలే సమూహ నియమాలను నిర్ధారించండి.
- అనుమతించిన ఒక ఆపరేషన్ మరియు చేరుకోలేనిదిగా ఉండాల్సిన ఒక వనరును పరీక్షించండి; రెండవది డీబగ్గింగ్ అవశేషాలను పట్టుకుంటుంది.
- ఏదైనా split-tunnel మార్గ మార్పు తర్వాత మళ్లీ కనెక్ట్ అవ్వండి, ఎందుకంటే నడుస్తున్న టన్నెల్ కొత్త మార్గ సెట్‌ను తీసుకోదు.
గుర్తుంచుకోదగిన రెండు లక్షణాలు ఉన్నాయి. సమాధానం లేకుండా B ను చేరే SYN దాదాపు ఎప్పుడూ తప్పిపోయిన రిటర్న్ మార్గం. పూర్తయి తర్వాత రీసెట్ అయ్యే కనెక్షన్ సాధారణంగా సమూహం, ACL లేదా అప్లికేషన్. రెండూ endpoint లాగ్‌లో కారణంగా కనిపించవు, కాబట్టి నాలుగు నమోదులను ప్రతి ఒక్కటి పక్కన యజమానితో ఉంచండి.
మూడు ట్రిగ్గర్‌లలో ఏదీ వర్తించకపోతే, routed మార్గాన్ని పూర్తి చేసి ఆ నాలుగు నమోదులను నమోదు చేయండి. ఒకటి వర్తిస్తే, bastion ను ఆ సరిహద్దుకు మాత్రమే ఉంచి, ముందు సెషన్ అవసరం లేని సేవలకు endpoint మార్గాన్ని వదిలేయండి.