EC2 లో strongSwan: VPC పనిభారాన్ని రూట్ చేయనివ్వండి

సొరంగం నడుస్తోంది, గేట్‌వే ఇన్‌స్టాన్స్ దూర నెట్‌వర్క్‌కు పింగ్ చేయగలదు, కానీ దాని పక్కన ఉన్న అప్లికేషన్ ఇన్‌స్టాన్స్ ఎక్కడికీ చేరుకోలేదు. ఏదీ పగిలిపోలేదు. విజయవంతమైన పరీక్ష VPN హోస్ట్‌పై ప్రారంభమైంది, ఆ హోస్ట్ అదే IPsec సంబంధం ద్వారా మరో మూల చిరునామాను తీసుకెళ్లగలదా అని అది ఎప్పుడూ అడగలేదు. ఈ రన్‌బుక్ ఆ ఖాళీని నాలుగు దశల్లో మూసివేస్తుంది, ప్రతి వైఫల్యాన్ని కనిపిస్తూనే ఉంచే క్రమంలో.

మొదట నాలుగు చిరునామాలను రాయండి

క్రింది ప్రతి దశ వీటిని సూచిస్తుంది, కాబట్టి రూటింగ్ పట్టికను తాకే ముందు వాటిని మీ స్వంత ఖాతా కోసం నింపండి.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

ఉదాహరణ ఆమోదించబడిన, పనిచేసే విధాన ఆధారిత IPsec కనెక్షన్ మరియు మూలాన్ని కాపాడే ప్రవాహాన్ని ఊహిస్తుంది. ఇది ఒక కేటాయించిన చిరునామాను అప్పు తీసుకునే NAT ఉన్న దూర ప్రవేశ క్లయింట్ కాదు, మరియు ఆ భేదమే ఎంపికకారులను మార్చాలా వద్దా అని నిర్ణయిస్తుంది.

దశ 1: పనిభారం యొక్క సబ్‌నెట్‌కు ఒక రూట్ ఇవ్వండి

పనిభారం యొక్క సబ్‌నెట్‌తో నిజంగా అనుబంధించబడిన రూటింగ్ పట్టికకు దూర ఉపసర్గ కోసం గేట్‌వే యొక్క నెట్‌వర్క్ ఇంటర్‌ఫేస్ వైపు చూపే మార్గం అవసరం. ఇన్‌స్టాన్స్ లోపల ఇన్‌స్టాల్ చేసిన అతిథి రూట్ ఆ AWS రూటింగ్ పట్టికలో ఎంట్రీ కాదు, ఏ strongSwan కాన్ఫిగరేషన్ దాన్ని సృష్టించదు.

AWS యొక్క పరికరం ద్వారా రూటింగ్ మార్గదర్శకం నెట్‌వర్క్ ఇంటర్‌ఫేస్ లక్ష్యాలను మరియు ఫార్వర్డ్ చేసే ఇన్‌స్టాన్స్ యొక్క మూల/గమ్యస్థాన తనిఖీ అవసరాన్ని వివరిస్తుంది. ఆ తనిఖీ మార్పును గేట్‌వే పాత్రకు పరిమితం చేయండి, సాధారణ అప్లికేషన్ ఇన్‌స్టాన్స్‌లను ప్రశాంతంగా ఉండనివ్వండి.

ఒక ఆమోదించిన నెట్‌వర్క్ కోసం స్థలం చేయడానికి VPC యొక్క స్థానిక రూట్‌ను లేదా ప్రతి ఇప్పటికే ఉన్న ఎంట్రీని భర్తీ చేయవద్దు. ఏది అనుబంధించబడింది మరియు చురుకుగా ఉందో పరిశీలించండి, ఎవరూ ఉపయోగించని రూటింగ్ పట్టిక కోసం కన్సోల్ పేజీ ఏమి చూపిస్తుందో కాదు. ఒకేలా కనిపించే రెండు పట్టికలకు వేర్వేరు అనుబంధాలు ఉండవచ్చు. ముఖ్యమైనది పనిభారం యొక్క సబ్‌నెట్ అనుసంధానించబడిన పట్టిక.

దశ 2: అతిథిపై ఫార్వర్డింగ్ ఆన్ చేయండి

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

కెర్నల్ ఫార్వర్డ్ చేయాలి మరియు హోస్ట్ ఫైర్‌వాల్ ప్రయాణాన్ని అనుమతించాలి. అన్నింటినీ అంగీకరించడం బదులు పనిభారం మరియు దూర ఉపసర్గల కోసం ఉద్దేశించిన ఫార్వర్డింగ్ నియమాలను జోడించండి, గేట్‌వే సబ్‌నెట్ తన సొంత ట్రాఫిక్ కోసం ఉపయోగించగల రవాణా మార్గాన్ని నిలుపుకుంటుందని నిర్ధారించండి.

భద్రతా సమూహాలు ఈ దశ సాధారణంగా ఆగే స్థలం. మధ్యవర్తి పరికరం ప్రత్యక్ష ఇన్‌స్టాన్స్ కమ్యూనికేషన్ యొక్క భద్రతా సమూహ సూచన ప్రవర్తనను వారసత్వంగా పొందదు, కాబట్టి నిర్వహించబడే Client VPN ఉదాహరణ నుండి కాపీ చేసిన నియమం ఎప్పటికీ సరిపోలకపోవచ్చు. వాస్తవ మార్గంలో రెండు దిశలలో భద్రతా సమూహాన్ని మరియు సబ్‌నెట్ ACL ను తనిఖీ చేయండి.

దశ 3: ఎంపికకారులను నిజమైన మూలాల వరకు విస్తరించండి

AWS వైపు 10.60.1.10/32 ను మాత్రమే కవర్ చేసే విధానం 10.60.2.20 ను కవర్ చేయకుండా గేట్‌వే నుండి ప్రారంభమైన విజయాన్ని వివరిస్తుంది. దూర గమ్యస్థానం వైపు మార్గం ఏ ట్రాఫిక్ ఎంపికకారును విస్తరించదు, మరియు అదే అదే ఆశ్చర్యం యొక్క రెండవ సగం.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

అంగీకరించిన నిర్మాణం మొత్తం VPC ను రక్షిస్తే, రెండు పక్షాలూ 10.60.0.0/16 మరియు 10.90.0.0/24 ను అంగీకరించాలి. అది ఒక పనిభారాన్ని రక్షిస్తే, ఆ సన్నని ఉపసర్గను ఉద్దేశపూర్వకంగా ఉపయోగించండి. ఏ సందర్భంలోనైనా, ఇన్‌స్టాల్ చేసిన CHILD-SA విధానాన్ని పరిశీలించండి, ఎందుకంటే మీరు సవరించిన కాన్ఫిగరేషన్ మరియు దాన్ని వేరే విధంగా సన్నగా చేసిన పక్షం ఒకే ఒప్పందం కాదు.

దూర ప్రాంతం కూడా నిల్వ చేసిన VPC మూలాల కోసం ప్రతిస్పందనలను ఉద్దేశించిన IPsec గేట్‌వే ద్వారా తిరిగి రూట్ చేయాలి. ఇతర మూల NAT నియమాలు ఉన్న చోట రక్షిత ట్రాఫిక్ కోసం మద్దతు ఉన్న NAT మినహాయింపును ఉంచండి; ఆమోదించని పనిభారాన్ని అనుమతించిన హోస్ట్ చిరునామాగా అనువదించడం మరో గుర్తింపు ఒప్పందం, మీరు కోరుకున్న ప్రవేశానికి సత్వరమార్గం కాదు.

దశ 4: ధృవీకరించండి, అవసరమైతే వెనక్కి తిప్పండి

పనిభారం నుండే కొత్త అనుమతించిన అప్లికేషన్ ఆపరేషన్‌తో పరీక్షించండి, ఆపై మినహాయించాల్సిన గమ్యస్థానంతో పునరావృతం చేయండి. దూర సేవ చూసే మూల చిరునామాను మరియు అది ఉపయోగించే తిరిగి వచ్చే మార్గాన్ని నమోదు చేయండి. గేట్‌వేకు పింగ్ లేదా ఆకుపచ్చ IKE స్థితి ఆ పరీక్ష కాదు.

గేట్‌వే పనిచేస్తున్నప్పుడు కూడా పనిభారం విఫలమైతే, దశల ద్వారా క్రమంగా వెనక్కి వెళ్లండి: ఎంపికకారు, తర్వాత ఫార్వర్డింగ్ మరియు భద్రతా సమూహాలు, తర్వాత అనుబంధించిన రూటింగ్ పట్టిక. ప్రతి ఒక్కటి వేరే లక్షణాన్ని కలిగి ఉంటుంది, మరియు ఊహ నిజంగా తప్పైన దాన్ని దాటవేస్తుంది.

వెనక్కి తిప్పడం అదే క్రమాన్ని తలకిందులు చేస్తుంది. పనిభారం యొక్క సబ్‌నెట్ మార్గాన్ని చివరగా తొలగించండి, మునుపటి ఎంపికకారులను పునరుద్ధరించిన తర్వాత, దాని మూలాలను ఇకపై రక్షించని గేట్‌వే వైపు చూపే సబ్‌నెట్‌ను వదలకుండా. ఈ ఒప్పందాలు నిలిచినప్పుడు స్వీయ-హోస్టింగ్ గేట్‌వే హోస్ట్ కంటే ఎక్కువ సేవ చేయగలదు, మరియు AWS నిర్వహించే Site-to-Site VPN మరో కార్యాచరణ నమూనా, అక్కడ strongSwan బదులుగా కస్టమర్ గేట్‌వే చివరన కూర్చోవచ్చు.