మీ VPN పూల్ LAN యొక్క DHCP పరిధి కాదు: అది ఎందుకు విరిగిపోతుంది

ఆఫీసు DHCP సర్వర్ ఉపయోగించే అదే పరిధి నుండి VPN క్లయింట్లకు చిరునామాలు ఇవ్వడం ఆకర్షణీయమైన చిన్న మార్గం, ఏదేమైనా అంతా ఒకే నెట్వర్క్ అనే భావనతో. కానీ అది కాదు. రూట్ చేయబడిన సొరంగం రెండు చివరల మధ్య unicast ప్యాకెట్లను తరలిస్తుంది, అయితే LAN పూల్ భౌతిక విభాగంలో ప్రసార అభ్యర్థనలకు సమాధానం ఇవ్వడానికి ఉంది. అదే సంఖ్యలను తిరిగి ఉపయోగించడం ఇద్దరు కేటాయింపుదారులను ఒకే చిరునామా స్థలానికి బాధ్యులను చేస్తుంది మరియు తిరిగి వచ్చే మార్గాన్ని నిర్వచించబడనిదిగా వదిలివేస్తుంది.

ఇద్దరు కేటాయింపుదారులు, ఒకే చిరునామా స్థలం

LAN యొక్క DHCP సర్వర్కు తాను ఏ చిరునామాలను ఏ MAC చిరునామాకు లీజుకు ఇచ్చిందో తెలుసు, మరియు ARP తో వాటిని రక్షిస్తుంది. VPN సర్వర్కు దాని స్వంత పూల్ ఉంది, ఆ లీజుల గురించి ఏమీ తెలియదు. రెండూ తప్పు కాదు; వాటిని ఎప్పుడూ ఒకదానికొకటి పరిచయం చేయలేదు.

VPN సర్వర్ LAN పూల్ నుండి ఇచ్చే చిరునామా ఇప్పటికే ఒక ప్రింటర్కు చెంది ఉండవచ్చు. ఇప్పుడు రెండు పరికరాలు ఒకే ప్రిఫిక్స్లో ఒక చిరునామాను క్లెయిమ్ చేస్తాయి, స్విచ్ యొక్క ఫార్వార్డింగ్ పట్టిక ఎవరు సమాధానం ఇస్తారో నిర్ణయిస్తుంది.

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

రూటర్ VPN చిరునామాలను ఎందుకు పంపిణీ చేయదు

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

అందువల్ల VPN సర్వర్ చిరునామాను తానే నిర్ణయిస్తుంది: సర్వర్ కాన్ఫిగరేషన్లో ఒక పూల్, WireGuard సెటప్లో ప్రతి పీర్కు ఒక చిరునామా, లేదా IKEv2 అమలులో ప్రామాణీకరణ పొర నెట్టే చిరునామా. ఈ యంత్రాంగాలు LAN యొక్క లీజు డేటాబేస్ నుండి స్వతంత్రం, అందుకే వాటికి సొంత పరిధి కావాలి.

అదే తర్కం DHCP స్కోప్ను మార్చినా ఎప్పుడూ చిరునామా పొందని VPN క్లయింట్ ఎందుకు సరిచేయబడదో వివరిస్తుంది. క్లయింట్ LAN సర్వర్ను అడగడం లేదు, స్కోప్లో ఎంత మార్చినా అతన్ని అడిగేలా చేయలేము.

అతివ్యాప్తి నెమ్మదైన నెట్వర్క్గా కాదు, సంఘర్షణగా కనిపిస్తుంది

మద్దతు ఉన్న డిజైన్ లేకుండా ఒకే ప్రిఫిక్స్ను పంచుకునే రెండు నెట్వర్క్లు ద్వంద్వ యాజమాన్యం కంటే భిన్నమైన సమస్య, అవి తరచుగా గందరగోళపరచబడతాయి. VPN పూల్ వేరే ప్రిఫిక్స్ అయితే, ఒక మార్గం ట్రాఫిక్ను తప్పు వైపుకు పంపినప్పుడు మాత్రమే అతివ్యాప్తి ముఖ్యం. పూల్ LAN ప్రిఫిక్స్ లోపల ఉంటే, సంఘర్షణ తక్షణమే మరియు స్థానికం.

ఆచరణలో తప్పు పరికరం నుండి ARP సమాధానాలు, మధ్యలో రీసెట్ అయ్యే కనెక్షన్లు, మరియు తన చిరునామాను మరొకరు క్లెయిమ్ చేస్తున్న క్లయింట్ మీరు చూస్తారు. ఇవేవీ రూటింగ్ సమస్యలా కనిపించవు, అందుకే సరిచేయడం తప్పు పొరపై వర్తించబడుతుంది. ద్వంద్వ లీజు నిర్ధారించడం సులభం, దానితో జీవించడం బాధించేది. రీబూట్ల నుండి కూడా అది బయటపడుతుంది, ఎందుకంటే ఇద్దరు కేటాయింపుదారులు అదే చిరునామాపై పట్టుబడతారు.

తిరిగి వచ్చే మార్గం వేరే సమస్య

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

ఏదైనా మార్చే ముందు మార్గాన్ని రెండు దిశలా చదవండి. గేట్వేలో కెర్నల్ క్లయింట్ చిరునామా కోసం ఏ ఇంటర్ఫేస్ ఉపయోగిస్తుందో అడగండి; క్లయింట్లో LAN చిరునామా కోసం ఏ మార్గం ఉపయోగిస్తుందో అడగండి.

ఈ ఆదేశాలు గేట్వేలోని ఫార్వార్డింగ్ నిర్ణయాన్ని మరియు నకలును బయటపెట్టే పొరుగు నమోదులను చూపుతాయి:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

మొదటి ఆదేశం సొరంగ ఇంటర్ఫేస్తో సమాధానం ఇస్తే, తిరిగి వచ్చే మార్గం ఉంది. అది LAN ఇంటర్ఫేస్తో సమాధానం ఇస్తే, రూటర్ క్లయింట్ తీగపై ఉన్నాడని నమ్మి అతని కోసం ARP చేయడానికి ప్రయత్నిస్తుంది.

వంతెన డిజైన్లు ఉన్నాయి, కానీ వాటిని ఎంచుకోవాలి

సొరంగాన్ని LAN కు వంతెన చేయడం నిజమైన డిజైన్, క్లయింట్లు ప్రసారాలను పొందాల్సి వచ్చినప్పుడు లేదా ఒక విభాగాన్ని ఊహించే ప్రోటోకాల్లు వాటిని కనుగొనాల్సి వచ్చినప్పుడు ఉపయోగిస్తారు. సర్వర్ ఆ వంతెన ప్రవర్తనను మరియు దానితో వచ్చే చిరునామా నిర్వహణను కలిగి ఉండాలి.

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

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