AWS Client VPN కనెక్ట్ అయింది, కానీ EC2 ఇప్పటికీ స్పందించడం లేదు
కనెక్ట్ అయింది అంటే సర్టిఫికెట్ లేదా SAML లాగిన్ పనిచేసింది మాత్రమే. అనుమతి నియమాలు, endpoint మార్గాలు మరియు భద్రతా సమూహాలు ప్రైవేట్ హోస్ట్‌కు వెళ్లే మార్గంలో ఒక్కొక్క భాగాన్ని కాపాడుతాయి.
నా ల్యాప్‌టాప్ కనెక్ట్ అయిందని చూపించింది. AWS Client VPN క్లయింట్ తన ఆకుపచ్చ స్థితిని చూపించింది, endpoint ఒక సెషన్‌ను నమోదు చేసింది, అయినా ప్రైవేట్ సబ్‌నెట్‌లోని EC2 ఇన్‌స్టాన్స్‌పై MongoDB పోర్ట్ తెరవలేకపోయాను. స్పష్టంగా ఏదీ పాడైలేదు: సర్టిఫికెట్ చెల్లుబాటులో ఉంది, ప్రొఫైల్ కన్సోల్ నుండి వచ్చింది, టన్నెల్ ట్రాఫిక్‌ను మోసింది. తప్పు నాదే, ఎందుకంటే నేను కనెక్ట్ అయిందనేదాన్ని అధికారం పొందినదిగా చదివాను.
లాగిన్ సరిగ్గా ఒక ప్రశ్నకు సమాధానం ఇస్తుంది: ఈ గుర్తింపు సెషన్‌ను ఏర్పాటు చేయగలదా? దాని తర్వాత అన్నింటినీ మీ సర్టిఫికెట్‌ను ఎప్పుడూ చూడని వేరే నియమాలు నిర్ణయిస్తాయి. ప్రామాణీకరణ పాస్ అయ్యే సెషన్ మరియు చేరుకునే ప్యాకెట్ రెండు వేరే విజయాలు, వాటి మధ్య ఖాళీలోనే VPN నడుస్తోంది కానీ హోస్ట్ చేరుకోలేము అనే చాలా ఫిర్యాదులు నివసిస్తాయి.
కింది తనిఖీలు నేను ఇప్పుడు ఉపయోగించే క్రమం.
కనెక్ట్ అయిన సెషన్ నిజంగా ఏమి నిరూపిస్తుంది
Handshake సమయంలో endpoint క్లయింట్ సర్టిఫికెట్‌ను తన trust store తో ధృవీకరిస్తుంది, లేదా SAML కాన్ఫిగర్ చేయబడినప్పుడు బ్రౌజర్‌ను మీ గుర్తింపు ప్రదాతకు మళ్లిస్తుంది. అది పాస్ అయితే, క్లయింట్ endpoint యొక్క క్లయింట్ CIDR నుండి చిరునామా పొందుతుంది, కన్సోల్ క్రియాశీల కనెక్షన్‌ను చూపిస్తుంది. ఆ మార్పిడిలో ఏ క్షణంలోనూ 10.0.4.17 ను 27017 పోర్ట్‌లో చేరుకోగలమా అని ఎవరూ అడగరు.
గమ్యానికి అనుమతి endpoint పై ప్రత్యేక వస్తువు. ప్రతి ప్రవాహం అనుమతి నియమాలతో సరిపోల్చబడుతుంది, ప్రతి నియమం గమ్య CIDR ను నియమం ఇవ్వబడిన సమూహంతో జోడిస్తుంది. ఏ నియమం గమ్యాన్ని కవర్ చేయకపోతే, endpoint సెషన్‌ను అంగీకరించి ట్రాఫిక్‌ను పడవేస్తుంది. బ్యానర్ లేదు, తిరిగి కనెక్ట్ లూప్ లేదు, తిరస్కరించబడింది అని చెప్పే ఏదీ క్లయింట్ UI లో లేదు.
అనుమతి నియమాన్ని VPC తో కాదు, వనరుతో పోల్చండి
నియమాలను జాబితా చేసి, ఇన్‌స్టాన్స్‌కు నిజంగా ఉన్న చిరునామా పక్కన ఉంచండి:
aws ec2 describe-client-vpn-authorization-rules \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8అవుట్‌పుట్ ప్రతి నియమానికి గమ్య CIDR మరియు సమూహ ID చూపిస్తుంది. అందులో రెండు వైఫల్యాలు దాగి ఉన్నాయి. నియమం 10.0.0.0/16 కు అనుమతి ఇవ్వవచ్చు, కానీ ఇన్‌స్టాన్స్ 10.1.0.0/16 పై పీర్ చేయబడిన VPC లో ఉండవచ్చు; పీరింగ్ మార్గం ఉంది, కానీ రెండవ పరిధికి ఎవరూ అనుమతి నియమం రాయలేదు. లేదా నియమం, వినియోగదారు డైరెక్టరీలో సభ్యుడిగా ఉన్న కానీ endpoint మూల్యాంకనం చేసే సమూహంలో లేని డైరెక్టరీ సమూహాన్ని సూచిస్తుంది.
గమ్యాన్ని కవర్ చేసే అత్యంత సన్నని నియమాన్ని రాయండి, రెండవ CIDR నిజంగా అవసరమైనప్పుడు మాత్రమే రెండవ నియమాన్ని జోడించండి. త్వరిత ప్రారంభం నుండి వచ్చిన విశాలమైన 0.0.0.0/0 నియమం పనిచేస్తుంది, అందుకే అది ఉత్పత్తి వరకు నిలిచి నమూనాను దాచుతుంది.
ప్యాకెట్ కదులుతుందా అనేది రెండు మార్గ పట్టికలు నిర్ణయిస్తాయి
endpoint మార్గం గమ్య CIDR ను endpoint అనుబంధించిన సబ్‌నెట్‌లలో ఒకదానికి మ్యాప్ చేస్తుంది. అది సగం దూరం. సబ్‌నెట్ యొక్క స్వంత మార్గ పట్టిక ప్యాకెట్‌ను ఎలా ముందుకు పంపాలో ఇంకా తెలుసుకోవాలి, గమ్యం పీరింగ్ కనెక్షన్, ట్రాన్సిట్ గేట్‌వే లేదా సైట్-టు-సైట్ టన్నెల్ ద్వారా చేరుకోగల ఆన్-ప్రిమైసెస్ పరిధి వెనుక ఉన్న క్షణంలో అది ముఖ్యం.
aws ec2 describe-client-vpn-routes \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8గమ్యం వనరు CIDR తో సరిపోలే మరియు లక్ష్యం అనుబంధిత సబ్‌నెట్ అయిన మార్గాన్ని వెతకండి. మార్గం లేకపోతే జోడించండి. ఉన్నా హోస్ట్ ఇంకా నిశ్శబ్దంగా ఉంటే, ఖాళీ VPC వైపు ఉంది, కాబట్టి అనుబంధ సబ్‌నెట్ మార్గ పట్టికతో పోల్చండి.
క్లయింట్ వైపు ఒక సెట్టింగ్ టన్నెల్‌ను విరగ్గొట్టకుండా మార్గనిర్దేశనాన్ని విరగ్గొడుతుంది: route-nopull ఉన్న ప్రొఫైల్. ఈ సూచన OpenVPN ఆధారిత క్లయింట్‌కు సర్వర్ నెట్టే మార్గాలను నిర్లక్ష్యం చేయమని చెబుతుంది, కాబట్టి ఇంటర్‌ఫేస్ endpoint యొక్క స్వంత చిరునామాతో మాత్రమే పైకి వస్తుంది, గమ్యానికి మార్గమే ఉండదు. Linux లో ip route show లేదా macOS లో netstat -rn ఉపయోగించి tun ఇంటర్‌ఫేస్ ద్వారా మార్గం ఉందో లేదో తనిఖీ చేయండి. లేకపోతే, ఎగుమతి చేసిన ప్రొఫైల్ నుండి route-nopull తీసివేసి, నెట్టిన మార్గాలు వర్తించేలా మళ్లీ కనెక్ట్ చేయండి.
భద్రతా సమూహాలు మీ క్లయింట్ చిరునామాన్ని చూడవు
నేను అర్ధరోజు తప్పుగా ఉంచుకున్న భాగం ఇదే. సబ్‌నెట్‌తో అనుబంధించిన IPv4 endpoint కోసం, సేవ క్లయింట్ యొక్క మూల చిరునామాను ఆ సబ్‌నెట్‌లో endpoint యొక్క నెట్‌వర్క్ ఇంటర్‌ఫేస్ చిరునామాకు అనువదిస్తుంది. ఇన్‌స్టాన్స్‌కు చేరుకునే ప్యాకెట్ మీ క్లయింట్ చూపించిన చిరునామాను మోయదు, కాబట్టి క్లయింట్ పూల్, చెప్పాలంటే 172.16.0.0/22, ను అనుమతించే భద్రతా సమూహ నియమం దేనితోనూ సరిపోలదు.
పోర్ట్‌ను క్లయింట్ CIDR నుండి కాదు, అనుబంధం యొక్క ఇంటర్‌ఫేస్‌కు జోడించిన endpoint యొక్క భద్రతా సమూహం నుండి అనుమతించండి. సమూహాన్ని సూచించడం చిరునామాను కఠినంగా కోడ్ చేయడం కంటే ఎక్కువ కాలం నిలుస్తుంది, ఎందుకంటే ఇంటర్‌ఫేస్ చిరునామా మీ నియంత్రణలో లేదు. నెట్‌వర్క్ ACL స్థితిలేనివి, కాబట్టి అనుకూల నమోదులు ఉన్న చోట లోపలికి మరియు బయటికి రెండు దిశలు ప్రవాహాన్ని అనుమతించాలి.
ఇన్‌స్టాన్స్ యొక్క ప్రైవేట్ చిరునామాకు కూడా కనెక్ట్ అవ్వండి. పబ్లిక్ IP ప్యాకెట్‌ను VPC నుండి బయటకు తీసుకెళ్లి వేరే నియమాలతో వేరే మార్గం ద్వారా లోపలికి తెస్తుంది, కాబట్టి పబ్లిక్ చిరునామాపై చేసే పరీక్ష ప్రైవేట్ మార్గం గురించి ఏమీ చెప్పదు.
మొదటి వైఫల్యం వద్ద ఆగే వేరుచేయు క్రమం
ఇవి క్రమంగా చేయండి మరియు ఒకటి విఫలమైన చోట ఆగండి. ప్రతి అడుగు అన్ని పొరలను కాదు, ఒక పొరను తొలగిస్తుంది.
- సెషన్ ఏ గుర్తింపును ఉపయోగించింది మరియు endpoint ఏ సమూహాన్ని మూల్యాంకనం చేస్తుందో నిర్ధారించండి. ఒక trust store యొక్క సర్టిఫికెట్ డైరెక్టరీ నుండి వచ్చిన SAML దృవీకరణ వంటి అదే ప్రిన్సిపాల్ కాదు.
- అనుమతి నియమం ఆ సమూహానికి వనరు CIDR ను కవర్ చేస్తుందని నిర్ధారించండి.
- endpoint మార్గం ఉందని మరియు అది అనుబంధిత సబ్‌నెట్‌ను లక్ష్యంగా చేసుకుందని, తర్వాత సబ్‌నెట్ మార్గ పట్టిక ముందుకు పంపగలదని నిర్ధారించండి.
- భద్రతా సమూహం పోర్ట్‌ను క్లయింట్ పూల్ నుండి కాదు, endpoint ఇంటర్‌ఫేస్ నుండి అనుమతిస్తుందని నిర్ధారించండి.
- అప్లికేషన్ సమస్యను క్లయింట్ మార్గ సమస్య నుండి వేరు చేయడానికి VPC లోపల నుండి, అదే సబ్‌నెట్‌లోని మరో ఇన్‌స్టాన్స్‌పై SSM సెషన్‌తో పరీక్షించండి.
అడుగులు నిర్ణాయకం కానప్పుడు నేను ఆధారపడేది ఈ పట్టిక:
| Symptom | Layer to inspect |
|---|---|
| Client shows connected, host times out, no byte growth on the interface | Authorization rule, then security group |
| Ping fails but a TCP connect to the port succeeds | ICMP is blocked; not an access failure |
| Tunnel reconnects every few minutes | Two machines sharing one client certificate |
| Works on one laptop, fails on another | Local profile has route-nopull or stale pushed routes |
ఖాతా వివరాలు రెండు అనుమతి వైఫల్యం లాంటి లక్షణాలను సృష్టిస్తాయి. ప్రతి వినియోగదారుకు ప్రత్యేక క్లయింట్ సర్టిఫికెట్ అవసరం; ఒకటి రెండు మెషీన్లలో పంచుకుంటే సెషన్లు ఒకదాన్నొకటి నెట్టివేస్తాయి, ఫలితం తిరస్కరణ కాదు, తిరిగి కనెక్ట్ లూప్. కొత్త endpoint సృష్టించినప్పుడు కన్సోల్ ఒక DNS పేరును చూపిస్తుంది, కొన్ని క్లయింట్ వెర్షన్లు దాన్ని endpoint పేజీలో చూపిన యాదృచ్ఛిక ప్రిఫిక్స్‌తో మాత్రమే అంగీకరిస్తాయి, కాబట్టి పేరును తిరిగి నిర్మించకుండా పూర్తి పేరును కాపీ చేయండి.
ఐదవ అడుగు మిమ్మల్ని అడ్డుకుంటే, ఏదైనా మార్చే ముందు endpoint యొక్క కనెక్షన్ లాగ్‌ను తీసి అనుమతి నమోదులను చదవండి. లాగ్ తనిఖీ చేసిన గమ్యాన్ని మరియు సరిపోలిన లేదా సరిపోలని నియమాన్ని పేర్కొంటుంది, అది నాలుగు పొరల ప్రశ్నను ఒకే సమాధానానికి కుదిస్తుంది.