AWS NAT గేట్వే ద్వారా GRE మరియు ESP ఎందుకు విఫలమవుతాయి

టన్నెల్ విఫలమవుతుంది, భద్రతా సమూహం ఇప్పటికే అన్ని ట్రాఫిక్ను అనుమతిస్తుంది, మరియు AWS VPN ను నిరోధిస్తోందని నిర్ధారణకు వస్తారు. అది ఏమీ నిరోధించడం లేదు. నిర్వహిత NAT గేట్వే డాక్యుమెంట్ చేయబడిన బాహ్య ప్రోటోకాల్ల సమితిని పంపుతుంది, మరియు స్థానిక GRE లేదా స్థానిక ESP అందులో లేవు, కాబట్టి మీరు జోడించే ఏ నియమం గేట్వేను వాటిని మోయించదు. అనుమతి నియమం మరియు రవాణా సామర్థ్యం రెండు వేర్వేరు విషయాలు, వాటిలో ఒకటి మాత్రమే మీరు మార్చగలరు.

నియమాల సమితి ప్రోటోకాల్ సమితి కాదు

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

AWS NAT గేట్వే ప్రోటోకాల్ స్పెసిఫికేషన్ నిర్వహిత సేవ కోసం TCP, UDP మరియు ICMP జాబితా చేస్తుంది. అదే పూర్తి మద్దతు సమితి. మరొక IP ప్రోటోకాల్ కోసం అనుమతి నియమం దాన్ని విస్తరించలేదు, ఎందుకంటే గేట్వే యొక్క ఫార్వార్డింగ్ మార్గాన్ని చేరుకోవడానికి చాలా ముందే నియమం మూల్యాంకనం చేయబడుతుంది.

ఈ భేదం ముఖ్యం ఎందుకంటే రెండు వైఫల్యాలు క్లయింట్ వైపు నుండి ఒకేలా కనిపిస్తాయి మరియు వాటి సరిదిద్దుకోలు పూర్తిగా భిన్నంగా ఉంటాయి.

PPTP పోర్ట్ పరీక్ష ఎందుకు అబద్ధం చెబుతుందో చూపిస్తుంది

ఏదీ నిరూపించని పోర్ట్ తనిఖీకి PPTP అత్యంత స్పష్టమైన పాత ఉదాహరణ. ఇది 1723 పోర్ట్లో TCP నియంత్రణ కనెక్షన్ను తెరిచి, తర్వాత టన్నెల్ డేటాను GRE పై మోస్తుంది, అది IP ప్రోటోకాల్ 47. ప్రోటోకాల్ 47 TCP పోర్ట్ 47 కాదు, ఈ రెండు సంఖ్యలకు అంకెలు పంచుకోవడం తప్ప ఏ సంబంధం లేదు.

1723 కు కనెక్టివిటీని పరీక్షించి పూర్తయిన హ్యాండ్షేక్ చూసే ఆపరేటర్ మార్గం పనిచేస్తుందని నిర్ధారిస్తాడు. తర్వాత డేటా ఛానెల్ ఒక్క ప్యాకెట్ కూడా దాటించదు, ఎందుకంటే గేట్వేకు అందించడానికి GRE మద్దతు లేదు. ఇది పాత ప్రోటోకాల్ అవసరాల వ్యాఖ్యానం, సంవత్సరాలుగా కాలం చెల్లిన PPTP ను అమలు చేయాలని సలహా కాదు.

నియంత్రణ ఛానెల్ TCP లేదా UDP అయి డేటా మార్గం అలా లేని ఏ ప్రోటోకాల్కైనా ఇదే తర్కం వర్తిస్తుంది.

IPsec UDP గానే జీవించి ఉంటుంది

IPsec అనేది సమాధానం స్పష్టమైన కాదు కాదు, షరతులతో కూడిన సందర్భం. NAT గేట్వే ద్వారా IPsec కోసం NAT ట్రావర్సల్ను AWS మద్దతు ఉన్న ఏర్పాటుగా డాక్యుమెంట్ చేస్తుంది. NAT-T చర్చల తర్వాత ESP UDP లోపల ఎన్క్యాప్సులేట్ అవుతుంది మరియు గేట్వే ప్రోటోకాల్ 50 కి బదులు సాధారణ UDP చూస్తుంది.

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

TCP లేదా UDP ఆధారిత VPN డాక్యుమెంట్ చేసిన రవాణా సమితికి సరిపోతుంది మరియు అయినప్పటికీ రూటింగ్, ఫిల్టరింగ్ లేదా ప్రామాణీకరణ కారణాల వల్ల విఫలం కావచ్చు. సమితికి సరిపోవడం అవసరం, సరిపోదు.

విధానాన్ని విస్తరించే ముందు మార్గాన్ని తనిఖీ చేయండి

వర్క్లోడ్ సబ్నెట్ యొక్క వాస్తవ మార్గాన్ని మరియు దాని తదుపరి హాప్ గుర్తింపును మొదట ధృవీకరించండి. ప్రత్యక్ష పబ్లిక్ మార్గం, NAT ఇన్స్టాన్స్, నిర్వహిత NAT గేట్వే మరియు ట్రాన్సిట్ గేట్వే ద్వారా ప్రైవేట్ మార్గం నాలుగు వేర్వేరు డిజైన్లు, వాటిలో ఒకటి మాత్రమే ఇక్కడ వివరించిన నిర్వహిత సేవ.

తర్వాత ప్రయత్నించిన ఎండ్పాయింట్, చిరునామా కుటుంబం, బాహ్య ప్రోటోకాల్ మరియు ప్రోటోకాల్కు పోర్ట్ ఉన్నట్లయితే ఆ పోర్ట్ను నమోదు చేయండి. విజయవంతమైన బ్రౌజర్ అభ్యర్థనకు బదులు క్లయింట్ డయాగ్నస్టిక్స్ మరియు నెట్వర్క్ యజమాని యొక్క ప్రవాహ పరిశీలనలను ఉపయోగించండి, ఎందుకంటే అది TCP మరియు UDP పనిచేస్తాయని మాత్రమే నిరూపిస్తుంది. ఆ తర్వాత, ప్రవాహం యొక్క రెండు దిశలకు భద్రతా సమూహం, సబ్నెట్ ACL, అతిథి ఫైర్వాల్ మరియు సేవా విధానాన్ని సమీక్షించండి.

సేవ మోయలేని రవాణాను భర్తీ చేయడానికి మొత్తం ట్రాఫిక్ను తెరవవద్దు. నియమ మార్పు దాన్ని సరిచేయదు, మరియు అది సంఘటన తర్వాత కూడా కొనసాగుతుంది.

రవాణా సరిపోనప్పుడు

బాహ్య ప్రోటోకాల్ మద్దతు సమితి వెలుపల ఉంటే, పరిష్కారం నిర్మాణాత్మకం: మార్గం మోయగల రవాణాను ఎంచుకోండి, లేదా మీకు అవసరమైనది మోసే దానికి బహిర్గమనాన్ని తరలించండి. OpenVPN UDP పై, WireGuard UDP పై మరియు TLS ఆధారిత టన్నెల్లు అన్నీ డాక్యుమెంట్ చేసిన సమితికి సరిపోతాయి. నిర్దిష్ట ప్రోటోకాల్ దాటాలి మరియు దాన్ని నడపడానికి కార్యాచరణ ఖర్చు ఆమోదయోగ్యంగా ఉన్నప్పుడు కస్టమర్ నిర్వహించే NAT ఇన్స్టాన్స్ ఎంపిక.

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

పని క్రమం: బాహ్య ప్రోటోకాల్కు పేరు పెట్టండి, తదుపరి హాప్ను నిర్ధారించండి, డాక్యుమెంట్ చేసిన సమితితో పోల్చండి, తర్వాత నిర్మాణం లేదా రవాణాను మార్చండి. వేరే పోర్ట్ సంఖ్య GRE ను TCP గా మార్చలేదు, మరియు మరో అనుమతించే నియమం పూర్తయిన నియంత్రణ మార్పిడిని పనిచేసే డేటా ఛానెల్గా మార్చలేదు.