AWS Client VPN కనెక్ట్ అయింది కానీ ఇంటర్నెట్ లేదు: మార్గాల తనిఖీ

AWS Client VPN కనెక్ట్ అయింది కానీ ఇంటర్నెట్ యాక్సెస్ లేదా? క్లయింట్ మార్గాలు, ఎండ్పాయింట్ అనుమతి, సబ్నెట్ ఎగ్రెస్ మరియు DNS ఆ క్రమంలో తనిఖీ చేయండి.

మీరు AWS Client VPN ఎండ్పాయింట్కు కనెక్ట్ అయ్యారు, ప్రైవేట్ సబ్నెట్ సమాధానం ఇస్తోంది, అయినా ప్రతి పబ్లిక్ పేజీ సమయం ముగిసి ముగుస్తోంది. ఈ కలయిక సమస్యను నిర్వహించే వైపు మూడు వస్తువులలో ఒకటిగా కుదిస్తుంది: క్లయింట్ ఇన్స్టాల్ చేసే మార్గం, ఎండ్పాయింట్ మార్గం దాని అనుమతి నియమంతో, లేదా అనుబంధిత సబ్నెట్ తదుపరి హాప్. క్లయింట్ వైపు నుండి ప్రతి వైఫల్యం భిన్నంగా కనిపించడంతో నేను వాటిని ఆ క్రమంలో తనిఖీ చేస్తాను. ఈ మార్గదర్శిని VPCతో అనుబంధించిన నిర్వహిత ఎండ్పాయింట్కు సంబంధించినది, EC2 ఇన్స్టాన్స్పై OpenVPN సర్వర్కు లేదా Cloud WAN లేదా Transit Gateway కనెక్షన్కు కాదు.

క్లయింట్ నిజంగా ఏమి మార్గనిర్దేశం చేస్తుందో దానితో ప్రారంభించండి

కనెక్ట్ అయిన స్థితి TLS సెషన్ మరియు క్లయింట్కు CIDR కేటాయింపును మాత్రమే నిరూపిస్తుంది, అంతకంటే ఏమీ లేదు. టన్నెల్ పని చేస్తున్నప్పుడు పబ్లిక్ చిరునామా ఎక్కడికి వెళ్తుందో ఆపరేటింగ్ సిస్టమ్ను అడగండి. Linuxలో ip route get 1.1.1.1 టన్నెల్ ఇంటర్ఫేస్ను పేర్కొనాలి; macOSలో netstat -rn -f inet | head -5 డిఫాల్ట్ నమోదును చూపిస్తుంది; Windowsలో Find-NetRoute -RemoteIPAddress 1.1.1.1 ఎంచుకున్న ఇంటర్ఫేస్ మరియు తదుపరి హాప్ను ముద్రిస్తుంది.

తర్వాత split-tunnel ఫ్లాగ్ను చదవండి, ఎందుకంటే ఎండ్పాయింట్ ప్రచురించిన మార్గాలే క్లయింట్ టన్నెల్కు పంపే ఏకైక గమ్యస్థానాలా అనేది అది నిర్ణయిస్తుంది:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

ఎప్పుడు SplitTunnel true అయితే, పబ్లిక్ గమ్యం టన్నెల్ను ఉపయోగించేది ఎండ్పాయింట్ దానిని కవర్ చేసే మార్గాన్ని ప్రచురించినప్పుడు మాత్రమే, కాబట్టి లేని 0.0.0.0/0 ఆ ట్రాఫిక్ను స్థానిక ఇంటర్ఫేస్పై వదిలివేస్తుంది. అది false అయితే, క్లయింట్ ట్రాఫిక్ను పట్టుకుంటుంది, కానీ ఎండ్పాయింట్ ఇంకా మార్గనిర్దేశం చేసి అనుమతించాలి; లేకపోతే ప్యాకెట్లు టన్నెల్లోకి వెళ్లి అక్కడ ఆగుతాయి. రెండింటిలో ఏదైనా మార్చిన తర్వాత క్లయింట్ను మళ్లీ కనెక్ట్ చేయండి, ఎందుకంటే మార్గాలు మరియు DNS సర్వర్లు కనెక్షన్ సమయంలోనే అందించబడతాయి మరియు నడుస్తున్న క్లయింట్ పాత సెట్ను ఉంచుకోవచ్చు.

ఎండ్పాయింట్ మార్గాన్ని మరియు అనుమతి నియమాన్ని విడివిడిగా చదవండి

ఇవి రెండు వస్తువులు, ఒకటి సృష్టించడం మరొకటి సృష్టించదు. ఎండ్పాయింట్ మార్గాలను జాబితా చేసి, లక్ష్యం అనుబంధిత సబ్నెట్ అయిన డిఫాల్ట్ మార్గాన్ని వెతకండి:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

ప్రతి మార్గానికి సరిగ్గా ఒక లక్ష్య సబ్నెట్ ఉంటుంది, కాబట్టి మూడు అనుబంధాలకు ఒక్కొక్కటి సరిపోయే డిఫాల్ట్ మార్గం అవసరం. AWS ఈ కవరేజ్ అవసరాన్ని నమోదు చేస్తుంది, మరియు లోటు యొక్క ఆచరణాత్మక లక్షణం ఒక సబ్నెట్ నుండి పని చేసి మరొక దాని నుండి ఆగిపోవడం, ఇది తప్పిపోయిన మార్గం కాకుండా అడపాదడపా వచ్చే లోపంగా చదవబడుతుంది. అధికారిక Client VPN దృశ్య పత్రాలు ఈ మార్గాలు చెందిన పబ్లిక్ సబ్నెట్ ఏర్పాటును వివరిస్తాయి.

అనుమతి రెండవ వస్తువు. పబ్లిక్ గమ్యాన్ని ఏ నియమం కవర్ చేయనప్పుడు, టన్నెల్ ప్యాకెట్ను మోసుకెళ్తుంది మరియు సేవ దానిని పారేస్తుంది, కాబట్టి ప్రైవేట్ వనరులు పని చేస్తూనే ఉంటాయి, ఇంటర్నెట్ మాత్రం కాదు:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

VPC CIDR కోసం నియమం 0.0.0.0/0 గురించి ఏమీ చెప్పదు. పూర్తి టన్నెల్ కోసం లేని భాగాలను జోడించడం అంటే ప్రతి అనుబంధిత సబ్నెట్కు ఒక మార్గం మరియు తర్వాత ఆడిట్ చేయగల అనుమతి నియమం:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all ఎండ్పాయింట్ యొక్క ప్రతి క్లయింట్కు గమ్యాన్ని ఇస్తుంది, కాబట్టి టన్నెల్ పూర్తిగా ఉండాల్సిన కాలం వరకు మాత్రమే ఉంచండి; కట్టడానికి సమూహాలు ఉంటే డైరెక్టరీ సమూహానికి కట్టిన నియమం మంచిది.

ప్యాకెట్ను అనుబంధిత సబ్నెట్ నుండి బయటకు అనుసరించండి

ఎండ్పాయింట్ మార్గం AWS ఆ ప్యాకెట్ను ఆ సబ్నెట్కు ఇస్తుందని నిర్ణయిస్తుంది. దాని తర్వాత తదుపరి హాప్ను అది నిర్ణయించదు, అది సబ్నెట్ సొంత VPC మార్గ పట్టికలో ఉంటుంది:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

ఉపయోగించగల డిఫాల్ట్ మార్గం పబ్లిక్ సబ్నెట్కు ఇంటర్నెట్ గేట్వే వైపు, లేదా ప్రైవేట్ దానికి NAT గేట్వే వైపు చూపిస్తుంది, మరియు blackhole స్థితి అంటే లక్ష్యం తొలగించబడింది మరియు మార్గం ఇప్పుడు నిశ్శబ్దంగా చనిపోతోంది. ఇవి ఎండ్పాయింట్ మార్గ జాబితా కంటే వేరే పట్టికలు, ఒకటి సరిచేయడం మరొకటి సరిచేయదు.

ఈ హాప్పై రెండు ఫిల్టర్లు ఉన్నాయి. లక్ష్య నెట్వర్క్ అనుబంధానికి వర్తించిన భద్రతా సమూహం పబ్లిక్ గమ్యం వైపు బయటకు వెళ్లే ట్రాఫిక్ను అనుమతించాలి, మరియు వర్తించే ఏదైనా నెట్వర్క్ ACL అభ్యర్థనను మరియు స్వల్పకాలిక పోర్టులపై తిరిగి వచ్చే ట్రాఫిక్ను అనుమతించాలి. నిర్బంధ అనుబంధ భద్రతా సమూహం ప్రైవేట్ యాక్సెస్ పని చేసి పబ్లిక్ యాక్సెస్ పని చేయకపోవడానికి సాధారణ కారణం.

మూడింటినీ ఒకేసారి మార్చడం బదులు లక్షణం నుండి మొదటి పొరను ఎంచుకోండి:

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

DNS వైఫల్యాన్ని మృత మార్గం నుండి వేరు చేయండి

పేరు పరిష్కారం ఫార్వర్డింగ్ కంటే భిన్నంగా విఫలమవుతుంది, మరియు పూర్తి టన్నెల్ ఈ భేదాన్ని ముఖ్యమైనదిగా చేస్తుంది ఎందుకంటే నెట్టబడిన రిజాల్వర్కు ఇప్పుడు టన్నెల్ ద్వారా చేరుతారు. ఎండ్పాయింట్ VPC DNS సర్వర్లను పేర్కొంటే, వాటి చిరునామాలకు ఇతర గమ్యం వలె మార్గ కవరేజ్ మరియు అనుమతి అవసరం. ఏ వైఫల్యం ఉందో చూడటానికి రిజాల్వర్ను నేరుగా అడగండి: dig +short example.com @10.0.0.2, లేదా nslookup example.com 10.0.0.2 Windowsలో.

సంఖ్యాత్మక URL సమాధానం ఇచ్చి పేరున్నది ఇవ్వకపోతే, డిఫాల్ట్ మార్గాన్ని సవరించడం ఆపి DNSపై పని చేయండి. IP చిరునామాకు అభ్యర్థన పేరున్న వర్చువల్ హోస్ట్ మరియు దాని సర్టిఫికెట్ గురించి ఏమీ నిరూపించదు, కాబట్టి చివరి తనిఖీలో ఒక పేరున్న పరీక్షను ఉంచండి.

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

శుభ్రంగా వెనక్కి తిప్పండి, తర్వాత ఎగ్రెస్ మార్గాన్ని ధృవీకరించండి

రెండు వస్తువులూ సంకలన స్వభావం కలవి, కాబట్టి వెనక్కి తిప్పడం మరమ్మతు కాదు, తొలగింపు:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

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

చిన్న జాబితాతో ముగించి, చివరి అంశాన్ని పత్రంగా కాక మార్పులో భాగంగా పరిగణించండి:

  • ప్రతి అనుబంధిత సబ్నెట్కు ఒక 0.0.0.0/0 ఎండ్పాయింట్ మార్గం.
  • మీరు సేవ చేయాలనుకున్న క్లయింట్లకు 0.0.0.0/0 కవర్ చేసే అనుమతి నియమం.
  • ప్రతి అనుబంధిత సబ్నెట్లో blackhole కాని VPC డిఫాల్ట్ మార్గం.
  • అనుబంధ భద్రతా సమూహం యొక్క ఎగ్రెస్, దానితో పాటు ACL తిరిగి వచ్చే ట్రాఫిక్.
  • రిజాల్వర్ చిరునామాలు మార్గనిర్దేశం చేయబడి అనుమతించబడి, పేరున్న అభ్యర్థనతో ధృవీకరించబడ్డాయి.
  • మార్గం మరియు నియమం కోసం నమోదు చేయబడిన వెనక్కి తిరిగింపు.

ఒక పరిధి గమనిక: ఇది IPv4 మార్గం. ద్వంద్వ స్టాక్ క్లయింట్ తనకు ఇప్పటికే ఉన్న IPv6 కనెక్టివిటీని నిలుపుకుంటుంది, కాబట్టి IPv6 డిఫాల్ట్ మార్గం దీని దుష్ప్రభావం కాదు, తన సొంత అనుమతితో కూడిన వేరే నిర్ణయం.

సంబంధిత వ్యాసాలు