ఒక AWS Client VPN సెషన్ వెనుక LAN: ఏమి ఫార్వర్డ్ అవుతుంది

ల్యాప్‌టాప్ AWS Client VPN ఎండ్‌పాయింట్‌కు కనెక్ట్ అవుతుంది, ప్రైవేట్ సబ్‌నెట్‌ను చేరుకుంటుంది, మరియు అన్నీ ఆరోగ్యంగా కనిపిస్తాయి. అదే LAN లోని డెస్క్‌టాప్ ఏదీ చేరుకోదు, అయినప్పటికీ Linux హోస్ట్‌కు కూడా బ్రిడ్జ్ ఇంటర్‌ఫేస్ ఉంది మరియు రెండు మెషీన్లు ఒకే వైర్‌పై ఉన్నాయి. టన్నెల్‌లో ఏదీ తప్పుగా కాన్ఫిగర్ కాలేదు; లేని భాగం రూటింగ్, బ్రిడ్జ్ ఒక తప్పుడు సూచన.

Client VPN సెషన్‌ను LAN కు విస్తరించడం గేట్‌వే పాత్ర. ఇది నిర్వహిత సేవలోకి లాగిన Ethernet విభాగం కాదు.

హోస్ట్ పని చేస్తుంది, LAN చేయదు

Linux మెషీన్‌లోని టన్నెల్ ఇంటర్‌ఫేస్‌కు Client VPN క్లయింట్ CIDR లోపల చిరునామా ఉంది, ఎండ్‌పాయింట్ VPC పరిధుల కోసం రూట్‌లను నెట్టింది. ఆ మెషీన్‌పై చేసిన అభ్యర్థన స్థానికంగా ఉత్పత్తి అయిన ట్రాఫిక్: అది ఒక రూట్‌ను ఎంచుకుని, టన్నెల్ ద్వారా బయటకు వెళ్లి, ప్రతిస్పందన పొందుతుంది. ఆ మార్గం ఎప్పుడూ ఫార్వర్డింగ్ కోడ్, LAN ఇంటర్‌ఫేస్ లేదా ట్రాన్సిట్‌ను నియంత్రించే ఏ ఫైర్‌వాల్ నియమాన్నీ తాకదు.

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

ప్రతి క్లయింట్ గేట్‌వే కాలేదు

AWS తమ Client VPN డెస్క్‌టాప్ యాప్ IP ఫార్వర్డింగ్‌కు మద్దతు ఇవ్వదని, ఇతర క్లయింట్‌లు ఇవ్వవచ్చని చెబుతుంది. ఆ పరిమితి ఏ ఆదేశం టైప్ చేయకముందే ఆర్కిటెక్చర్‌ను నిర్ణయిస్తుంది. అందుబాటులో ఉన్న ఏకైక క్లయింట్ అధికారిక డెస్క్‌టాప్ యాప్ అయితే, LAN కోసం ఫార్వర్డ్ చేసే Linux గేట్‌వే మీరు పూర్తి చేయగల కాన్ఫిగరేషన్ కాదు, ఎంత masquerading చేసినా అది మారదు.

ప్రత్యామ్నాయ క్లయింట్ ఎండ్‌పాయింట్ ప్రామాణీకరణ పద్ధతికి మరియు మీరు అమలు చేయదలిచిన విధానానికి కూడా సరిపోలాలి. ధృవపత్రం ఆధారిత, డైరెక్టరీ ఆధారిత మరియు SAML ఆధారిత ఎండ్‌పాయింట్‌లు అదే క్లయింట్ కాన్ఫిగరేషన్‌లను అంగీకరించవు, ప్రామాణీకరించి కానీ నెట్టిన రూట్‌లను విస్మరించే తృతీయ పక్ష క్లయింట్ మెరుగుదల కాదు.

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

LAN ను టన్నెల్ వైపు మళ్లించి అనువదించండి

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

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

నియమాన్ని పైన చెప్పినట్లు టన్నెల్ ఇంటర్‌ఫేస్ మరియు VPC పరిధికి పరిమితం చేయండి, హోస్ట్ ఫార్వర్డ్ చేసే ప్రతిదాన్ని masquerade చేయడం బదులు. సన్నని నియమం గురించి ఆలోచించడం సులభం, మరియు అది తన అసలు మూల చిరునామాను నిలుపుకోవాల్సిన ట్రాఫిక్‌ను నిశ్శబ్దంగా మార్చదు.

వీలైతే LAN రూట్ దానంతట అదే రానివ్వండి: DHCP ఎంపిక, రౌటర్ ప్రకటన లేదా LAN ను నిర్వహించేది నెట్టే స్థిర రూట్. ఒకే పరీక్ష మెషీన్‌లో మాత్రమే ఉన్న రూట్, మరొకరు ప్రయత్నించిన క్షణంలో డిజైన్ విరిగినట్లు చూపిస్తుంది.

ప్రతిస్పందనకు కూడా మార్గం కావాలి

అభ్యర్థన VPC చేరుకున్న తర్వాత, ప్రతిస్పందన అదే అనువాద స్థితుల ద్వారా తిరిగి వచ్చి గేట్‌వేపై LAN రూట్‌ను కనుగొనాలి. ఆ భాగం సాధారణంగా masquerade నియమం ఉన్నప్పుడు పని చేస్తుంది, ఎందుకంటే మ్యాపింగ్ దాన్ని చేసిన హోస్ట్‌పై నివసిస్తుంది. VPC వైపు ప్రతిస్పందనను వేరే చోటికి పంపే రూట్ ఉన్నప్పుడు అది విరిగిపోతుంది, అందుకే క్లయింట్ CIDR రూట్ మరియు ఎండ్‌పాయింట్‌లోని సబ్‌నెట్ అనుబంధం రెండూ ముఖ్యం.

ping మాత్రమే కాదు, కౌంటర్లను చూడండి. సున్నా ప్యాకెట్ల masquerade నియమం అభ్యర్థన ఎప్పుడూ టన్నెల్ ఇంటర్‌ఫేస్‌ను చేరుకోలేదని చెబుతుంది, ఇది LAN రూట్ లేదా క్లయింట్ స్వంత రూటింగ్ పట్టిక వైపు సూచిస్తుంది. ప్యాకెట్లు ఉన్నా ప్రతిస్పందనలు లేని నియమం VPC వైపు, అనుమతి నియమాలు లేదా అనువదించిన మూలాన్ని అంగీకరించని భద్రతా సమూహం వైపు సూచిస్తుంది. ఏదైనా మార్చే ముందు రెండు దిశలను చదవండి, ఎందుకంటే ఒక వైపు మాత్రమే పెరిగే లెక్క నెమ్మదైన మార్గం కాదు, ఒక-మార్గ మార్గం.

ఎండ్‌పాయింట్ నిర్వహిత సేవ అని గుర్తుంచుకోండి. సవరించడానికి సర్వర్ కాన్ఫిగరేషన్ ఫైల్ లేదు, జోడించడానికి client-config సూచన లేదు, అందువల్ల అనుకూల క్లయింట్ సబ్‌నెట్ రూట్‌లతో స్వీయ-నిర్వహిత OpenVPN సర్వర్ కోసం రాసిన సూచనలు బదిలీ కావు. AWS లో లివర్‌లు సబ్‌నెట్ అనుబంధం, అనుమతి నియమాలు మరియు VPC రూటింగ్ పట్టికలు.

పంచుకున్న గుర్తింపు అనేది విధానం సమాధానం చెప్పాల్సిన భాగం

గేట్‌వే వెనుక ఉన్న ప్రతి పరికరం గేట్‌వే VPN సెషన్‌ను ఉపయోగిస్తుంది. ఎండ్‌పాయింట్ అనుమతి నియమాలు వినియోగదారు లేదా సమూహానికి యాక్సెస్ ఇస్తాయి, సేవ దృష్టికోణంలో ఆ సెషన్‌పై సరిగ్గా ఒక వినియోగదారు ఉన్నారు. స్థానిక ఫార్వర్డింగ్ ఆ గుర్తింపును ప్రతి-పరికర ప్రామాణీకరణగా గుణించదు, మూలలో ఉన్న ప్రింటర్ వరకు పరికర స్థితి తనిఖీలను విస్తరించదు.

అది ఆమోదయోగ్యం కావచ్చు, లేదా డిజైన్ తిరస్కరించబడటానికి కారణం కావచ్చు. VPC వనరులు ఎవరు కాల్ చేస్తున్నారనే దాని గురించి ఏమి ఊహిస్తాయనే దానిపై ఆధారపడి ఉంటుంది. అనుమతి నమూనాకు సరిపోయే పంచుకున్న గుర్తింపు మంచిది; ఒక ప్రామాణీకృత సెషన్‌ను నిశ్శబ్దంగా మొత్తం LAN యాక్సెస్‌గా మార్చేది రాయబడటానికి వేచి ఉన్న ఆవిష్కరణ.

అవసరం నిజంగా మొత్తం సైట్‌ను VPC కు కనెక్ట్ చేయడమే అయితే, రిమోట్-యాక్సెస్ క్లయింట్‌ను విస్తరించే ముందు మద్దతు ఉన్న సైట్-నుండి-సైట్ డిజైన్‌ను పోల్చండి. అర్థం భిన్నం, VPC LAN లోకి కనెక్షన్‌లను ప్రారంభించాల్సినప్పుడు NAT చేసిన క్లయింట్ సెషన్ సైట్ లింక్‌కు పేద ప్రత్యామ్నాయం.

క్లయింట్, రూట్, అనువాదం మరియు గుర్తింపు కథను అదే క్రమంలో నిర్ణయించండి. ప్రతిదీ తదుపరిదాన్ని పరిమితం చేస్తుంది, ఈ క్రమం హోస్ట్ ఎందుకు పని చేస్తుంది కానీ LAN చేయదు అని వివరిస్తుంది.