LAN చిరునామా ఉన్న VPN క్లయింట్ LAN-లో లేదు

క్లయింట్ కనెక్ట్ అవుతుంది, 10.50.0.200 పొందుతుంది మరియు రెండు నంబర్లు ఒకే /24లో ఉన్నా 10.50.0.20లోని సర్వర్‌కు చేరుకోలేదు. ఈ కాన్ఫిగరేషన్ వెనుక ఉన్న నమ్మకం ఏమిటంటే LAN ప్రిఫిక్స్ నుండి వచ్చిన చిరునామా క్లయింట్‌ను LANలో భాగం చేస్తుంది. అది చేయదు. క్లయింట్ పాయింట్-టు-పాయింట్ లింక్‌పై ఉంది, సర్వర్ గమ్యాన్ని స్థానికంగా భావిస్తుంది, మరియు లేని భాగం ఎవరూ పంపని పొరుగు సమాధానం.

అపోహ: అదే ప్రిఫిక్స్ అంటే అదే సెగ్మెంట్

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

సర్వర్ 10.50.0.200కు పంపినప్పుడు, గమ్యాన్ని తన మాస్క్‌తో పోల్చి, చిరునామా on-link అని నిర్ణయించి, దానిని కలిగి ఉన్న హార్డ్‌వేర్ చిరునామాను స్థానిక సెగ్మెంట్‌ను అడుగుతుంది. ఆ అభ్యర్థన Ethernet ఇంటర్ఫేస్ ద్వారా బయటకు వెళ్తుంది, VPN క్లయింట్ దానిని వినడానికి అక్కడ లేదు.

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

స్థానిక హోస్ట్ చిరునామాతో నిజంగా ఏమి చేస్తుంది

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

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

మార్గ శోధన గమ్యాన్ని Ethernet ఇంటర్ఫేస్ ద్వారా on-linkగా నివేదిస్తుంది, మరియు సమస్య సరిగ్గా అదే. VPN సెషన్ నడుస్తున్నప్పుడు పొరుగు నమోదు అసంపూర్ణంగా ఉంటే, లేని భాగం లింక్-పొర పరిష్కారమే తప్ప రౌటింగ్ లేదా ఫైర్‌వాల్ విధానం కాదని మీరు నిర్ధారించారు.

మరో సబ్‌నెట్‌లోని హోస్ట్ నుండి అదే తనిఖీ చేసి పోల్చండి. రౌటర్ ద్వారా క్లయింట్‌ను చేరుకునే హోస్ట్‌కు పొరుగు నమోదు అవసరమే లేదు, ఆ భేదమే చిన్న స్థాయిలో డిజైన్ నిర్ణయం.

proxy ARP తదుపరి హాప్‌ను ఎలా అందిస్తుంది

proxy ARP, మరో ఇంటర్ఫేస్ ద్వారా చేరుకోగల గమ్యం తరఫున లింక్-పొర అభ్యర్థనకు గేట్‌వే సమాధానం ఇచ్చేలా చేస్తుంది. LAN హోస్ట్ హార్డ్‌వేర్ చిరునామా పొంది, ఫ్రేమ్‌ను గేట్‌వేకు పంపుతుంది, గేట్‌వే ప్యాకెట్‌ను VPN సెషన్‌లోకి పంపుతుంది. హోస్ట్ దృష్టికోణంలో క్లయింట్ గేట్‌వే వెనుక ఉన్నట్టు కనిపిస్తుంది. క్లయింట్ కాన్ఫిగరేషన్‌లో ఏదీ మారదు.

MikroTik RouterOS ARP పత్రాలు కనెక్ట్ అయిన LAN చిరునామా స్థలాన్ని అప్పు తీసుకునే డయల్-ఇన్ క్లయింట్‌లకు ఆ వినియోగాన్ని వివరిస్తాయి. ఈ యంత్రాంగం పొరుగు పరిష్కారం యొక్క మరమ్మతు, గేట్‌వే నిజంగా రెండు మార్గాల్లో ఉన్నందున ఇది పనిచేస్తుంది.

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

ప్లాట్‌ఫారమ్ మోడ్ పేర్లను జాగ్రత్తగా చదవండి. RouterOS proxy-arp మరియు local-proxy-arp లను వేరు చేస్తుంది, రెండవది అదే ఇంటర్ఫేస్ ద్వారా లోపలికి వచ్చి బయటకు వెళ్లే ట్రాఫిక్‌ను నిర్వహిస్తుంది. ఇవి పరస్పరం మార్చుకోగల వర్ణక్రమాలు కావు, రెండింటినీ భేదం లేకుండా ఆన్ చేయడం సులభమార్గం కాదు.

proxy ARP మీకు ఇవ్వనిది

ఇది broadcast లేదా multicast అన్వేషణను అందించదు. broadcast ద్వారా సేవను కనుగొనాల్సిన క్లయింట్ ఇప్పటికీ విఫలమవుతుంది, ఎందుకంటే గేట్‌వే unicastను సెషన్‌కు పంపుతుంది మరియు క్లయింట్‌ను LAN యొక్క broadcast డొమైన్ సభ్యునిగా చేయదు. broadcastపై ఆధారపడే అన్వేషణ ప్రోటోకాల్లు అప్పు తీసుకున్న చిరునామాల డిజైన్‌లలో «ఒక విషయానికి పనిచేస్తుంది, మరొకదానికి కాదు» అనే నివేదికలకు సాధారణ మూలం.

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

మరియు ఇది LAN యజమానితో సమన్వయం అవసరాన్ని తొలగించదు. చిరునామా ప్రణాళిక యజమానిని ఆశ్చర్యపరిచే proxy ARP నమోదు ప్రశాంతమైన వారం కోసం ఎదురుచూస్తున్న మద్దతు సంఘటన.

వేరుగా రౌట్ చేయబడిన పూల్‌తో పోలిక

ప్రత్యామ్నాయం ఏమిటంటే VPN క్లయింట్‌లకు వారి స్వంత ప్రిఫిక్స్ ఇవ్వడం మరియు LAN హోస్ట్‌లు అక్కడికి రౌట్ చేయడానికి అనుమతించడం. అప్పుడు సర్వర్ తన గేట్‌వేకు off-link సమాధానాలు పంపుతుంది, గేట్‌వే ప్రిఫిక్స్‌ను VPN ముగింపు బిందువుకు రౌట్ చేస్తుంది, LAN సెగ్మెంట్‌లో పొరుగు పరిష్కారం అవసరమే లేదు. ఇది అప్పు తీసుకున్న చిరునామా మరియు proxy సమాధానం కంటే తక్కువ కదిలే భాగాలు.

ఆ డిజైన్ గురించి ఆలోచించడం సులభం, ఆడిట్ చేయడం కూడా సులభం, ఎందుకంటే క్లయింట్ పరిధి LAN పరిధి నుండి స్పష్టంగా వేరుగా ఉంది. దాని ఖర్చు ఒక మార్గం, తిరిగి వచ్చే మార్గం మరియు ఒక యాక్సెస్ నియమం, అంటే proxy ARP డిజైన్‌కు తక్కువ స్పష్టమైన చోట అవసరమయ్యే అవే విషయాలు.

నమూనాల మధ్య ఉద్దేశపూర్వకంగా ఎంచుకోండి, యాదృచ్ఛికంగా కాదు. proxy ARP ఒక నిర్దిష్ట సంబంధాన్ని మరమ్మతు చేస్తుంది; రౌట్ చేయబడిన పూల్ ఆ మరమ్మతు అవసరాన్ని తప్పిస్తుంది. మీరు ఏది ఎంచుకున్నారు మరియు ఎందుకు అని రాయండి, తర్వాతి వ్యక్తి విఫలమైన పొరుగు నమోదు నుండి దాన్ని మళ్లీ కనుగొనాల్సిన అవసరం ఉండదు.