క్లౌడ్ సరిహద్దులో VPN క్లయింట్ IPలను నిలబెట్టుకోండి లేదా SNAT చేయండి

VPN క్లయింట్ చిరునామాను అప్లికేషన్ వరకు ఉంచడం ప్రతి లాగ్ పంక్తి మరియు అనుమతి జాబితాలోని ప్రతి నమోదు ఒకే అర్థాన్ని ఇచ్చేలా చేస్తుంది. క్లౌడ్ అంచున దాన్ని తిరిగి రాయడం రౌటింగ్ పట్టికను సులభతరం చేస్తుంది మరియు లాగ్లను తక్కువ ఉపయోగకరంగా చేస్తుంది. రెండు ఎంపికలూ తమంతట తాము తప్పు కావు, మరియు దాన్ని నిర్ణయించే వాదన అరుదుగా పనితీరు గురించి ఉంటుంది. మూడు షరతులు దాన్ని నిర్ణయిస్తాయి: ఏ మనిషి కనెక్ట్ అయ్యాడో అప్లికేషన్ తెలుసుకోవాలా, మీరు పంపదలుచుకున్న మూలాన్ని క్లౌడ్ వస్త్రం అంగీకరిస్తుందా, మరియు తర్వాత తిరిగి వెళ్లే మార్గం బాధ్యతను ఎవరు తీసుకుంటారు.

మూడు షరతులు నిర్ణయిస్తాయి

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

రెండవ షరతు యాంత్రికం. వర్చువల్ నెట్వర్క్ పంపే ఇంటర్ఫేస్కు కేటాయించని చిరునామాను పేర్కొనే ప్యాకెట్ను స్వయంచాలకంగా నమ్మదు. చాలా క్లౌడ్ వస్త్రాలు దాన్ని వివిధ మార్గాల్లో మరియు పేర్లతో అమలు చేస్తాయి, దాన్ని పట్టించుకోని డిజైన్ రేఖాచిత్రంలో సరిగ్గా కనిపిస్తుంది మరియు ఉత్పత్తిలో నిశ్శబ్దంగా పడిపోతుంది.

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

మార్గం జాలీకి అనుమతి కాదు

తిరిగి వెళ్లే మార్గాన్ని జోడించడం జవాబులు ఎక్కడికి వెళ్లాలో మీ సబ్నెట్కు చెబుతుంది. ఆ ప్యాకెట్లను ఫార్వార్డ్ చేసే ఇన్స్టాన్స్కు వాటిని విదేశీ మూలంతో పంపే హక్కు ఉందని అది వస్త్రానికి చెప్పదు. AWSలో సంబంధిత నియంత్రణ మూలం మరియు గమ్యం తనిఖీ, మరియు అది ప్రతి ఇన్స్టాన్స్కు కనిపిస్తుంది:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

దాన్ని డాక్యుమెంట్ చేసిన పని ఫార్వార్డింగ్ అయిన ఇన్స్టాన్స్కు మాత్రమే ఆఫ్ చేయండి, మరేదానికీ కాదు. తనిఖీని ఆన్లో ఉంచే ప్రతి అప్లికేషన్ VM అనేది అప్పు తీసుకున్న మూలంతో ట్రాఫిక్ పంపడానికి ఉపయోగించగల ఒక యంత్రం తక్కువ. మీ ప్లాట్ఫారమ్ AWS కాకపోతే, ప్రవర్తన బదిలీ అవుతుందని ఊహించడానికి బదులు సమానమైన యాంటీ-స్పూఫింగ్ లేదా అనుమతించిన చిరునామా సెట్టింగ్ను వెతకండి.

వేగవంతమైన ప్యాకెట్ క్యాప్చర్ కన్సోల్ చదవడం కంటే వేగంగా ప్రశ్నను పరిష్కరిస్తుంది. జవాబులు బయటకు వెళ్లి క్లయింట్ వాటిని ఎప్పుడూ చూడకపోతే, అప్లికేషన్ విఫలం కావడం లేదు, వస్త్రం నకిలీ మూలాన్ని పారేస్తోంది.

అనువాదం ఏమి కొంటుంది మరియు ఏమి ఖర్చు చేస్తుంది

గేట్వేలో మూలాన్ని తిరిగి రాయడం తిరిగి వెళ్లే మార్గ సమస్యను తొలగిస్తుంది. అప్లికేషన్ చేరుకోవడానికి ఇప్పటికే తెలిసిన ఒక చిరునామాను చూస్తుంది, మరియు క్లయింట్ ప్రిఫిక్స్ ఎప్పుడూ క్లౌడ్ రూట్ పట్టికలో రావాల్సిన అవసరం లేదు. Linuxలో నియమం ఒక పంక్తి, మరియు మీరు చేయగలిగిన అత్యంత ఇరుకైన సంస్కరణను రాయడం విలువైనది:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

అప్లికేషన్ ఇప్పుడు ఏమి నమోదు చేస్తుందో గమనించండి: ప్రతి వినియోగదారుకు 10.40.3.10, ప్రతి కనెక్షన్లో, శాశ్వతంగా. ఆ విలువపై నిర్మించిన ఏదైనా చిరునామా అనుమతి జాబితా ఇప్పుడు మొత్తం రిమోట్ యాక్సెస్ జనాభాకు యాక్సెస్ ఇస్తుంది, మరియు ఏదైనా సంఘటన సమీక్ష ఇది ఎవరు అని జవాబు చెప్పడానికి గేట్వేకు తిరిగి వెళ్లాలి.

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

రిలే వేరే ఇంటర్ఫేస్

అప్లికేషన్ ముందు ఉన్న రివర్స్ ప్రాక్సీ రూట్ చేసిన మార్గం ప్రశ్నను పూర్తిగా దాటవేస్తుంది. ప్రాక్సీ తన సొంత బ్యాకెండ్ కనెక్షన్ను తెరుస్తుంది, కాబట్టి క్లయింట్ ప్రిఫిక్స్ వర్చువల్ నెట్వర్క్ లోపల ఎప్పుడూ రూట్ చేయదగినదిగా ఉండాల్సిన అవసరం లేదు, మరియు అప్లికేషన్ ప్రాక్సీ సెట్ చేసే హెడర్లో గుర్తింపును పొందవచ్చు.

ఆ హెడర్ బ్యాకెండ్ దాన్ని ప్రాక్సీ నుండి మాత్రమే అంగీకరించి మరేదాని నుండీ అంగీకరించనప్పుడు మాత్రమే నమ్మదగినది. nginx పదాల్లో దీని అర్థం వచ్చిన ప్రతిదాన్ని నమ్మడానికి బదులు నమ్మదగిన భాగస్వామిని స్పష్టంగా పేర్కొనడం:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

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

రిలే మీరు కొనే దాన్ని కూడా మారుస్తుంది. మీకు అప్లికేషన్ స్థాయి గుర్తింపు మరియు దాన్ని నమోదు చేయడానికి సహజమైన స్థలం లభిస్తాయి; మీరు సాధారణత్వాన్ని వదులుకుంటారు, ఎందుకంటే ప్రతి కొత్త ప్రోటోకాల్కు దాని సొంత ప్రాక్సీ మద్దతు కావాలి. HTTP సేవలకు ఈ మార్పిడి సాధారణంగా మంచిది, మరియు HTTP కాని దేనికైనా సాధారణంగా అది అసలు అందుబాటులో ఉండదు.

ప్రతి సరిహద్దు ఏమి చూస్తుందో రాయండి

మీరు ఏది ఎంచుకున్నా, డిజైన్ సమీక్ష ప్రతి దశలో మూల చిరునామా మరియు నిరూపించగల గుర్తింపును పేర్కొనే ఒక పట్టికతో ముగియాలి. అది లేకుండా, మొదటి సంఘటన వేర్వేరు క్లయింట్ను వివరించే మూడు బృందాలను ఉత్పత్తి చేస్తుంది.

తర్వాత ఎంచుకోండి. అప్లికేషన్ అధికారం నిజంగా క్లయింట్ చిరునామాపై ఆధారపడి ఉంటే, మరియు మీరు మార్గాన్ని తీసుకోగలిగితే మూలాన్ని నిలబెట్టుకోండి. అలా కాకపోతే, గుర్తింపును బ్యాండ్ వెలుపల తీసుకెళ్లగలిగితే అనువాదం చేయండి, మరియు ప్లాట్ఫారమ్-నిర్దిష్ట ఫార్వార్డింగ్ సెట్టింగ్లకు AWS ఫార్వార్డింగ్-ఇన్స్టాన్స్ మార్గదర్శిని ఉపయోగించండి. సేవ HTTP మాట్లాడితే మరియు గుర్తింపు పూర్తిగా చిరునామా కాకూడదనుకుంటే రిలే వైపు మళ్లండి.