LAN హోస్ట్ OpenVPN క్లయింట్ చిరునామా కోసం ARP ఎందుకు పంపుతుంది

LAN హోస్ట్ మరియు VPN క్లయింట్ మధ్య చేరుకోగల సమస్యలు తరచుగా చిరునామా ప్రణాళికకే తిరిగి వస్తాయి. ఆ హోస్ట్కు 10.0.100.0/22పై ఇంటర్ఫేస్ ఇవ్వండి; అది 10.0.100.0 నుండి 10.0.103.255 వరకు ప్రతి చిరునామాన్ని నేరుగా కనెక్ట్ అయినట్లు పరిగణిస్తుంది, 10.0.101.0/24లో నిశ్శబ్దంగా ఉంచిన క్లయింట్ పూల్తో సహా. సమాధానం ఎప్పుడూ రౌటర్కు వెళ్లదు, ఎందుకంటే హోస్ట్ దృష్టిలో ఏ రౌటర్ పాల్గొనదు. ప్యాకెట్ ఒక పొరుగువారికి చిరునామా చేయబడి వైర్పై అడగబడుతుంది.

ఈ యంత్రాంగం మొత్తం నివేదికల కుటుంబం వెనుక ఉంది: టన్నెల్ అమలులో ఉంది, సర్వర్కు మార్గం ఉంది, అయినా LAN హోస్ట్ క్లయింట్ను చేరుకోలేదు.

/24ని మింగే /22

ప్రిఫిక్స్ను పరిధిగా చదవండి, స్ట్రింగ్గా కాదు. ఒక /22లో 1024 చిరునామాలు ఉంటాయి, 10.0.100.0/22 10.0.100.0 నుండి 10.0.103.255 వరకు విస్తరిస్తుంది, కాబట్టి 10.0.101.0/24లోని పూల్ పూర్తిగా దాని లోపల ఉంటుంది. ఈ పొరపాటు సమీక్షను తప్పించుకుంటుంది, ఎందుకంటే పూల్ మొదటి ఆక్టెట్లు LAN మొదటి ఆక్టెట్లకు భిన్నంగా కనిపిస్తాయి, మూడవ ఆక్టెట్ మాత్రమే ఈ కలయికను బయటపెడుతుంది. రెండు పరిధులను సంఖ్యల్లో రాయండి, వాటిని వేర్వేరుగా ప్రకటించే ముందు.

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

ప్రత్యక్ష కనెక్షన్ అంటే ARP, రౌటింగ్ కాదు

/22 ఇంటర్ఫేస్ ఉన్న హోస్ట్ 10.0.101.25-కి పంపినప్పుడు, కెర్నల్ గమ్యాన్ని ఇంటర్ఫేస్ ప్రిఫిక్స్తో పోల్చి సరిపోలిక కనుగొంటుంది. ప్యాకెట్ రౌట్ చేయబడిన ప్యాకెట్ కాకుండా పొరుగు అన్వేషణగా మారుతుంది, ఈథర్నెట్లో పొరుగు అన్వేషణ ఆ చిరునామా కోసం ARP అభ్యర్థన. చిరునామా రౌటెడ్ గేట్వే వెనుక ఉన్న VPN క్లయింట్కు చెందినదైతే, LANలో ఏ హోస్ట్ దానిని కలిగి ఉండదు, కాబట్టి అభ్యర్థన ప్రతిస్పందన లేకుండా ఉంటుంది, ప్యాకెట్లు పడవేయబడతాయి. టన్నెల్ దోషి కాదు, క్లయింట్ ట్రాఫిక్ను ఎప్పుడూ చూడదు.

అందుకే వైఫల్యం అసమానంగా, అప్పుడప్పుడు అంతరాయంగా కనిపిస్తుంది. VPN హోస్ట్ తరచుగా LANను చేరుకుంటుంది, ఎందుకంటే దాని స్వంత మార్గాలు సరైన దిశలో చూపుతాయి, కానీ LAN హోస్ట్ సమాధానం ఇవ్వలేదు, పాత ARP నమోదును కాష్ చేసే ఏదైనా లక్షణాన్ని మెరిసేలా చేస్తుంది.

TUN, TAP మరియు ప్రతి ఒక్కటి ఏమి మోసుకుంటుంది

TUN పరికరం IP ప్యాకెట్లను, TAP పరికరం ఈథర్నెట్ ఫ్రేమ్లను మోసుకుంటాయి. రౌటెడ్ TUN లింక్ IP యాక్సెస్ ఇవ్వడానికి ARP మోసుకోవాల్సిన అవసరం లేదు, అందుకే పైనున్న ప్రతిస్పందన లేని అభ్యర్థన ఆశించదగినది, పాడైనది కాదు. ఉద్దేశపూర్వక బ్రిడ్జ్తో TAP ప్రసార డొమైన్ను విస్తరించి ARP పనిచేయించగలదు, కానీ క్లయింట్ ఏమి చూడగలదో మారుస్తుంది, అదే ఫ్రేమింగ్కు మద్దతు ఇచ్చే చివరలను కోరుతుంది, ఇది అతివ్యాప్తి ప్రిఫిక్స్కు మరమ్మతు కాదు, నెట్వర్క్ నమూనా పునఃరూపకల్పన. చిరునామా ప్రణాళిక లోపాన్ని నయం చేయడానికి రౌటెడ్ అమరికను TAPకు మార్చడం చిన్న సమస్యను పెద్దదానితో మారుస్తుంది.

ముగింపులకు రాకముందు ARP అభ్యర్థన ఎక్కడ కనిపించింది, ఏ వ్యవస్థ పంపింది అని నమోదు చేయండి. పంపినవారు గమ్యం గురించి తాను ఏమనుకుంటున్నారో చెబుతారు, టన్నెల్ ఏమి చేస్తుందో కాదు.

అతివ్యాప్తి చెందలేని పూల్ను రూపకల్పన చేయండి

ప్రతి కనెక్ట్ అయిన ప్రిఫిక్స్ మరియు ప్రతి ప్రకటిత సైట్ ప్రిఫిక్స్ వెలుపల పూల్ ఎంచుకోండి, ఆపై దాన్ని రెండు దిశల్లో చేరుకోగలిగేలా చేసే మార్గాలను జోడించండి. ప్రణాళికలో ఉపయోగించని భాగంలో 10.8.0.0/24 వంటి పరిధిని ఆలోచించడం సులభం, దాన్ని చేరుకోవాల్సిన LAN, VPN సర్వర్ను చూపే స్థిర మార్గాన్ని పొందుతుంది. కేటాయింపు, ప్రకటిత మార్గాలు, అనుమతించిన మూల చిరునామాలు మరియు ఫైర్వాల్ నియమాలను కలిసి మార్చండి, ఎందుకంటే అవి నాలుగు సెట్టింగ్లు కాదు, ఒక రూపకల్పనను వివరిస్తాయి.

సర్వర్పై Source NAT పూల్ను LAN నుండి రౌట్ చేయగల చిరునామా వెనుక దాచగలదు, ఇది చట్టబద్ధమైన స్థానభ్రంశ సాధనం. ఇది మూలాన్ని కూడా తిరిగి రాస్తుంది, కాబట్టి LAN కనెక్షన్లను వ్యక్తిగత క్లయింట్లకు ఆపాదించడం, క్లయింట్ వారీగా నియమాలు వర్తింపజేయడం అనే సామర్థ్యాన్ని కోల్పోతుంది.

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