రెండు చివరల్లోనూ ఒకే సబ్నెట్: రిమోట్ LAN ను ఉచిత పరిధికి మ్యాప్ చేయండి

ఇల్లు మరియు కార్యాలయం రెండూ 192.168.1.0/24 ఉపయోగిస్తాయి, కాబట్టి 192.168.1.1 కు అభ్యర్థనకు రెండు సాధ్యమైన సమాధానాలు ఉన్నాయి మరియు క్లయింట్ అడగకుండానే ఒకటి ఎంచుకుంటుంది. నడుస్తున్న కార్యాలయ నెట్వర్క్ను తిరిగి సంఖ్యీకరించడం అరుదుగా ప్రజాదరణ పొందుతుంది, మరియు రౌటర్ చిరునామాలు తరచుగా ప్రింటర్లు, కెమెరాలు మరియు పత్రాలలో పాతుకుపోయి ఉంటాయి. క్లయింట్ వైపు చిరునామా మ్యాపింగ్ బదులుగా రిమోట్ నెట్వర్క్ను ఉచిత పరిధి కింద ప్రదర్శించగలదు, హోస్ట్ భాగం అలాగే ఉండగలదు, దాంతో 192.168.1.20 10.203.41.20 గా కనిపిస్తుంది. ఇబ్బంది ఏమిటంటే కొన్ని క్లయింట్లు మాత్రమే దాన్ని అమలు చేస్తాయి, మరియు అది తిరిగి వచ్చే మార్గం కోసం ఏమీ చేయదు.

ఒకే హోస్ట్ యొక్క రెండు దృశ్యాలు

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

ఇంట్లోని స్థానిక పరికరాలు తమ 192.168.1.x చిరునామాలను ఉంచుకుంటాయి, ఈ వ్యాయామం యొక్క ఉద్దేశ్యం అదే. పక్క గదిలోని ప్రింటర్ అందుబాటులో ఉంటుంది, కార్యాలయం ఢీకొనని పరిధి కింద కనిపిస్తుంది.

ఆర్గ్యుమెంట్ల క్రమమే మొత్తం ఉపాయం

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

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

కొత్త పరిధి కోసం క్లయింట్ ప్యాకెట్లను సొరంగంలోకి పంపేది మార్గం; అనువాదం దారిలో గమ్యస్థానాన్ని తిరిగి రాస్తుంది. 192.168.1.20 నుండి వచ్చిన సమాధానం 10.203.41.20 కు తిరిగి రాయబడుతుంది, దాంతో క్లయింట్లోని సాకెట్ స్థిరంగా ఉంటుంది. ఒకే హోస్ట్ పూర్తి పొడవు మాస్క్తో అదే విధంగా పనిచేస్తుంది, మార్గం మరియు మ్యాపింగ్ ఒకే చిరునామాను వివరించినంత కాలం.

ఇది చిరునామా మ్యాపింగ్, పోర్ట్ మ్యాపింగ్ కాదు. ఒకే హోస్ట్లో రెండు సేవలను దీనితో వేరు చేయలేరు, మరియు తన పేలోడ్లో IP చిరునామాలను పొదిగిన ప్రోటోకాల్ ఇప్పటికీ నిజమైనవాటిని చూస్తుంది.

మ్యాపింగ్ తిరిగి వచ్చే మార్గాన్ని సృష్టించదు

అనువాదం క్లయింట్ వద్ద జరుగుతుంది, కాబట్టి సర్వర్ ఇప్పటికీ సమాధానాలను సొరంగానికి మార్గనిర్దేశం చేయాలి మరియు దాని ఫైర్వాల్ ఇప్పటికీ వాటిని అనుమతించాలి. రిమోట్ గేట్వేకు సొరంగం సబ్నెట్ను ఎలా చేరుకోవాలో తెలియకపోతే, అభ్యర్థన వస్తుంది మరియు సమాధానం తప్పు తలుపు ద్వారా బయటకు వెళ్తుంది; మ్యాపింగ్ వైఫల్యాన్ని క్లయింట్ సమస్యలా కనిపించేలా చేస్తుంది.

సర్వర్ వైపు నియమాలు అనువాదం తర్వాత సర్వర్లో ఉన్న చిరునామాలను వివరించాలి, క్లయింట్కు కనిపించే పరిధిని కాదు. ఉపనామాన్ని అనుమతి నియమంలోకి కాపీ చేయడం ఒక మధ్యాహ్నాన్ని వృథా చేస్తుంది, ఎందుకంటే ఆ వైపు ఏ ప్యాకెట్ దాన్ని మోయదు.

క్లయింట్ మార్గనిర్దేశం చేసే మరేదానితోనూ ఢీకొనని ఉపనామ పరిధిని ఎంచుకోండి: మరో VPN, కంటైనర్ నెట్వర్క్, రెండో కార్యాలయం. ఇక్కడ ఢీకొనడం అసలు అస్పష్టతను వేరే సంఖ్య కింద తిరిగి తెస్తుంది మరియు చిరునామాలు పరిచయం లేనివిగా కనిపించడంతో గమనించడం కష్టం.

పేర్లు మరియు పేలోడ్లు అనువాదం నుండి బయటపడతాయి

నిజమైన 192.168.1.20 కు పరిష్కరమయ్యే హోస్ట్పేరు బ్రౌజర్ను రిమోట్కు కాకుండా స్థానిక పరికరానికి పంపుతుంది, రౌటింగ్ పట్టిక ఏం చెప్పినా. ప్రైవేట్ DNS సమాధానం క్లయింట్కు కనిపించే పరిధిని సూచించాలి, TLS ధృవపత్రం ఇప్పటికీ అప్లికేషన్ ఆశించే పేరును కలిగి ఉంటుంది. చిరునామాతో కాకుండా పేరుతో పరీక్షించండి, ఎందుకంటే చిరునామా పనిచేయవచ్చు కానీ పేరు నిశ్శబ్దంగా తప్పు దిశలో పరిష్కరమవ్వవచ్చు. రిమోట్ గేట్వే ఆ జోన్ను కూడా సేవిస్తే, దాని స్వంత రికార్డులకూ క్లయింట్కు కనిపించే పరిధి కావాలి.

దారి మళ్లింపులు, పొదిగిన URL లు మరియు తమ చిరునామాను పేలోడ్లో ఇచ్చే అప్లికేషన్లు ఏ ప్యాకెట్ మ్యాపింగ్ సరిదిద్దలేని విధంగా విరిగిపోవచ్చు. వాటిని అప్లికేషన్ సమస్యగా పరిగణించి, తిరిగి సంఖ్యీకరణ అనవసరమని వాగ్దానం చేయకముందే ప్రయత్నాన్ని దానికి తగ్గట్టు అంచనా వేయండి.

నిబద్ధతకు ముందు మూడు తనిఖీలు

మొదట, క్లయింట్ అమలును నిర్ధారించండి. Community OpenVPN ఈ ఎంపికను మద్దతు ఇస్తుంది; OpenVPN 3 కోడ్బేస్ దాన్ని మద్దతు లేని ఫీచర్లలో జాబితా చేస్తుంది, కాబట్టి Connect శైలి క్లయింట్కు నెట్టిన ప్రొఫైల్ దాన్ని సున్నాగా పట్టించుకోకపోవచ్చు. అంగీకరించబడి ఎప్పుడూ వర్తింపజేయని సూచన లోపం కంటే అధ్వాన్నం, ఎందుకంటే సొరంగం ఆరోగ్యంగా కనిపిస్తుంది.

రెండవది, అధిక వివరాలతో చిన్న డయాగ్నస్టిక్ విండోతో మార్గాన్ని మరియు అనువాదాన్ని విడివిడిగా ధృవీకరించి, తర్వాత ping కు బదులుగా నిజమైన సేవను పరీక్షించండి. మూడవది, స్థానిక రౌటర్ మరియు రిమోట్ వనరు క్లయింట్ నుండి వేరు చేయగలిగేలా ఉన్నాయని నిర్ధారించండి, అదే అసలు లక్ష్యం.

క్లయింట్ అనువాదం చేయలేకపోతే, గేట్వే వైపు సహాయం అడగండి లేదా తిరిగి సంఖ్యీకరణను అంగీకరించండి. అదే చిరునామా కోసం మరిన్ని మార్గాలు జోడించడం డిజైన్ కాదు.