AWS Client VPN DNS: subnet కాదు, VPC resolver ఉపయోగించండి

endpoint 10.0.8.0/24 లో ఉంది, కాబట్టి resolver 10.0.8.2 అయి ఉండాలి. ఇదే నేను ఎక్కువగా వినే వాదన, మరియు ఇది రెండుసార్లు తప్పు. Route 53 Resolver ప్రాథమిక VPC IPv4 పరిధి ప్లస్ రెండుకు సమాధానం ఇస్తుంది, అది 10.0.0.0/16 VPC కి 10.0.0.2, endpoint ఏ subnet ఉపయోగించినా. రెండవ తప్పు మరింత నిశ్శబ్దం: endpoint లో సరైన చిరునామా పెట్టడం అంటే client ఆపరేటింగ్ సిస్టమ్ ఎప్పుడైనా దాన్ని ఏదైనా అడుగుతుందని కాదు. రెండు తప్పులూ ఒకే లక్షణం ఇస్తాయి: పేరు పరిష్కారం కొన్ని client లలో పనిచేస్తుంది, మరికొన్నింటిలో విఫలమవుతుంది.

అపోహ subnet అనుబంధం నుండి మొదలవుతుంది

అనుబంధం అంటే client కనెక్షన్ల కోసం elastic network interfaces ఎక్కడ ఉంటాయో, ఏ resolver చిరునామా ఉందో కాదు. endpoint యొక్క subnet లు client లకు VPC లోపల చిరునామా ఇస్తాయి, అవి ఒక్కొక్కటీ తమ సొంత resolver ను కలిగి ఉండవు.

ఆ రెండు భావనలను వేరు చేసిన తర్వాత లెక్క మర్మమైనదిగా ఉండదు, సమస్య పరిష్కారం client వైపుకు మారుతుంది, ఈ కేసుల్లో చాలావరకు నిజంగా అక్కడే ముగుస్తాయి.

ప్రాథమిక VPC పరిధి నుండి చిరునామా లెక్కించండి

VPC యొక్క ప్రాథమిక IPv4 CIDR తీసుకుని network చిరునామాకు రెండు జోడించండి. 10.0.0.0/16 10.0.0.2 ఇస్తుంది, 172.31.0.0/16 172.31.0.2 ఇస్తుంది, ద్వితీయ పరిధి ఉన్న VPC resolver ను ప్రాథమికంలోనే ఉంచుతుంది. ఆ VPC లోపల 10.0.8.0/24 subnet దాన్ని కదిలించదు. endpoint ను తాకే ముందు VPC ID పక్కన చిరునామా రాయండి, ఎందుకంటే ఈ సంఖ్య VPC యొక్క లక్షణం, కనెక్షన్ యొక్క కాదు.

VPC link-local చిరునామా 169.254.169.253 లో కూడా సమాధానం ఇస్తుంది. ఈ చిరునామా VPC లోపల నుండి చేరుకోగలిగినది, కానీ సొరంగం మరొక చివర ఉన్న ల్యాప్‌టాప్‌కు ఇది సాధారణంగా రూట్ చేయబడిన గమ్యం కాదు.

కాబట్టి రెండు చెల్లుబాటు అయ్యే resolver చిరునామాలు ఉన్నాయి, వాటిలో ఏదీ subnet ప్లస్ రెండు కాదు.

endpoint సెట్టింగ్ ఏమి చేస్తుంది, ఏమి చేయదు

Client VPN endpoint లో DNS సర్వర్ ఫీల్డ్‌లు ఉన్నాయి, console VPC resolver ఎంపిక ఇచ్చే చోట అదే భావనను నింపుతుంది. వాటిని సెట్ చేయడం కనెక్షన్ ఏర్పాటు సమయంలో సేవ client లకు ఏమి ఇస్తుందో మారుస్తుంది. నిర్వహించబడని OpenVPN client ఆ విలువతో ఏమి చేస్తుందో ఇది మార్చదు, ఎందుకంటే client దాన్ని ఆపరేటింగ్ సిస్టమ్‌పై వర్తింపజేయాలి. «నా Mac లో పనిచేస్తుంది కానీ Linux బాక్స్‌లో కాదు» అనేది ఈ అంతరం నుండే వస్తుంది.

Linux లో resolver ఏకీకరణ కనెక్షన్ మేనేజర్ సొంతం, వినియోగదారు సొంతం కాదు. /etc/resolv.conf ను చేతితో సవరించడం చిరునామా ఒక సెషన్‌కు పనిచేస్తుందని నిరూపిస్తుంది, తర్వాత మళ్లీ కనెక్ట్ అయినప్పుడు మాయమవుతుంది — అందుకే సరిచేసిన అనేక కేసులు మరుసటి ఉదయం తిరిగి వస్తాయి.

కనెక్ట్ అయిన తర్వాత client లో సక్రియ resolver ను తనిఖీ చేయండి, endpoint యొక్క కాన్ఫిగరేషన్ పేజీ కాదు.

split tunneling సరైన resolver ను ఓడించగలదు

split tunneling లో సొరంగంలోకి నెట్టిన మార్గాలు మాత్రమే ఉపయోగించబడతాయి. resolver చిరునామా ఏ మార్గంతోనూ కప్పబడకపోతే, క్వెరీ స్థానిక ఇంటర్‌ఫేస్ ద్వారా బయటకు వెళ్లి మీ ఇంటి రౌటర్ సమాధానం ఇస్తుంది. endpoint లో చిరునామా ఇంకా సరైనదే, శోధన ఇంకా విఫలమవుతుంది. resolver కోసం మార్గాన్ని జోడించి, మళ్లీ పరీక్షించండి.

ఒకదానిపై ఒకటి అతివ్యాప్తి చెందే స్థానిక పరిధులు అదే ఫలితాన్ని మరింత బాధించే విధంగా ఇస్తాయి: క్వెరీకి సమాధానం వస్తుంది, కానీ తప్పు సర్వర్ నుండి.

Amazon DNS చిరునామా కోసం security groups తెరవవద్దు

శోధనలు సమయం మించినప్పుడు సహజ ప్రవృత్తి resolver చిరునామాకు UDP 53 అనుమతించే నియమాన్ని జోడించడం. security groups మరియు network ACL లు Amazon DNS ట్రాఫిక్‌ను సొంత DNS ఇన్‌స్టాన్స్‌కు వెళ్లే ట్రాఫిక్‌లా ఫిల్టర్ చేయవు అని AWS నమోదు చేస్తుంది. ఆ నియమాలను తెరవడం VPC resolver కి ఏమీ మార్చదు, కారణం లేకుండా సరిహద్దును విస్తరిస్తుంది. మీరే నడిపే resolver వేరే కేసు, దానికి నిజంగా సొంత నియమాలు కావాలి.

మీ డిజైన్‌లో రెండూ ఉంటే, ఏ నియమాన్నైనా సవరించే ముందు client నిజంగా ఏది వైపు చూపుతోందో తనిఖీ చేయండి.

మార్గాన్ని ధృవీకరించి, తర్వాత వేరేది కొలవండి

ప్రజా పేరును పరిష్కరించండి, VPC తో అనుబంధించిన ప్రైవేట్ హోస్ట్ చేసిన జోన్‌లో నమోదైన ప్రైవేట్ పేరును పరిష్కరించండి, రెండింటి మధ్య client యొక్క సక్రియ resolver చదవండి. ఈ క్రమం «resolver చిరునామా తప్పు» అనేది «జోన్ అనుబంధించబడలేదు» మరియు «client సెట్టింగ్‌ను విస్మరించింది» నుండి వేరు చేస్తుంది. ప్రతిదానికి వేరే పరిష్కారం, ఏదీ throughput సమస్య కాదు.

విజయవంతమైన శోధన నిరంతర బదిలీ వేగం గురించి ఏమీ చెప్పదు, కాబట్టి నివేదించేటప్పుడు ఈ రెండు సంభాషణలను వేరుగా ఉంచండి.