LAN రౌటర్ మరియు VPN క్లయింట్: రెండు పరికరాలు, రెండు రూట్ పట్టికలు

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

రూట్ను తాకే ముందు రెండు హాప్లను గీయండి

ఒక ఉదాహరణ లేఅవుట్ తీసుకోండి: LAN హోస్ట్లు 192.168.50.0/24 లో, సాధారణ రౌటర్ 192.168.50.1 లో, అంకిత క్లయింట్ 192.168.50.15 లో, మరియు దూర LAN 10.60.0.0/24 లో ఉంది, అది ఆ క్లయింట్ కలిగి ఉన్న టన్నెల్ ద్వారా మాత్రమే చేరుకోగలం. రెండు ప్రైవేట్ పరిధులలో ఏదీ మరొకదానితో అతివ్యాప్తి చెందదు, మరియు టన్నెల్కు దాని సొంత చిరునామా ప్రణాళిక ఉంది.

రెండు ప్రైవేట్ పరిధులు ముఖ్యం ఎందుకంటే ఏ పరికరం సమాధానం ఇవ్వగలదో అవి నిర్ణయిస్తాయి. దూర వైపు ప్యాకెట్ క్లయింట్ టన్నెల్ చిరునామా నుండి వస్తున్నట్లు చూస్తుంది, దాని సమాధానం 192.168.50.0/24 కి తిరిగి వెళ్లే మార్గాన్ని కనుగొనాలి. బయటకు వెళ్లే దిశ మాత్రమే కాన్ఫిగర్ చేయబడితే, అభ్యర్థన పని చేయవచ్చు కానీ సమాధానం మాయమవుతుంది.

దశ 1: రౌటర్ను టన్నెల్ వైపు కాదు, క్లయింట్ వైపు మళ్లించండి

LAN రౌటర్పై, తదుపరి హాప్ క్లయింట్ LAN చిరునామా అయిన గమ్య రూట్ను జోడించండి:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

ఆ రికార్డ్ “టన్నెల్ చేయగల మెషీన్కు అది అందించు” అని చెబుతుంది. టన్నెల్ ఎలా నిర్మించబడుతుందనే దాని గురించి ఏమీ చెప్పదు, మరియు అది క్లయింట్ యొక్క సొంత రూట్కు ప్రత్యామ్నాయం కాదు. నిర్వహించబడే రౌటర్లో సమానమైనది పరికరం యొక్క స్టాటిక్ రూట్ పేజీలో నివసిస్తుంది; Linux రౌటర్లో అది LANని కలిగి ఉన్న ఇంటర్ఫేస్ కాన్ఫిగరేషన్కు చెందుతుంది, మీరు మూసివేసే షెల్కు కాదు.

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

దశ 2: క్లయింట్కు టన్నెల్ వైపు దాని సొంత రూట్ను ఇవ్వండి

క్లయింట్ ఇప్పుడు 10.60.0.0/24 కోసం ప్యాకెట్ను స్వీకరించి తన సొంత పట్టికను చూస్తుంది. దాని టన్నెల్ కాన్ఫిగరేషన్ ఆ ప్రిఫిక్స్కు రూట్ను ఇన్స్టాల్ చేసి ఉంటే, ప్యాకెట్ ఎన్క్రిప్టెడ్గా కొనసాగుతుంది. లేకపోతే, ప్యాకెట్ సాధారణ డిఫాల్ట్తో సరిపోయి 192.168.50.1 కి తిరిగి వెళ్తుంది, అది దాన్ని మళ్లీ క్లయింట్కు పంపుతుంది.

ఏదైనా జోడించే ముందు చూడండి:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

ప్రతి పట్టికలో ప్రిఫిక్స్ రూట్ లేకపోవడమే మీరు వెతుకుతున్న అన్వేషణ. టన్నెల్ యొక్క సొంత కాన్ఫిగరేషన్ ద్వారా దాన్ని జోడించండి, తదుపరి పునఃకనెక్షన్ దాన్ని మళ్లీ ఇన్స్టాల్ చేస్తుంది; చేతితో చేసిన ip route add సెషన్తో పాటు మాయమై అత్యంత అసౌకర్య సమయంలో లోపాన్ని తిరిగి తెస్తుంది. తదుపరి హాప్ టన్నెల్ ఇంటర్ఫేస్ లేదా VPN తన పీర్గా కేటాయించే చిరునామా, క్లయింట్పై ఆధారపడి ఉంటుంది, మరియు పీర్ చిరునామా పాత గమనిక నుండి కాదు, ప్రస్తుత ప్రొఫైల్ నుండి రావాలి.

లూప్ సంభవించినప్పుడు ఆచరణలో అనంతం కాదు: ప్రతి ప్రయాణంలో TTL తగ్గుతుంది మరియు ప్యాకెట్ సమయం మించిపోయిందనే సందేశంతో మరణిస్తుంది. అందుకే పునరావృత traceroute చక్రాన్ని సూచించవచ్చు, అయితే ఫార్వార్డ్ చేయని క్లయింట్ అదే ప్యాకెట్ను నిశ్శబ్దంగా వదిలేస్తుంది.

దశ 3: ఫార్వార్డింగ్ను అనుమతించి తిరిగి వచ్చే మార్గాన్ని ఎంచుకోండి

స్వీకరించడం మరియు ఫార్వార్డ్ చేయడం వేర్వేరు అనుమతులు. క్లయింట్పై net.ipv4.ip_forward=1 కర్నెల్ స్థాయిలో ట్రాన్సిట్ను అనుమతిస్తుంది, మరియు ఫైర్వాల్ నియమం దాన్ని LAN ఇంటర్ఫేస్ మరియు టన్నెల్ మధ్య ఇంకా అనుమతించాలి. క్లయింట్ యొక్క సొంత నిర్వహణ పేజీకి ప్రవేశాన్ని అనుమతించే నియమం దూర LANకి ట్రాన్సిట్ను అనుమతించదు, మరియు అదే హోస్ట్ స్థానికంగా pingలకు సమాధానం ఇచ్చినప్పుడు ఈ భేదాన్ని మిస్ అవ్వడం సులభం.

దూర వైపుకు అద్దం లాంటి సమస్య ఉంది. 192.168.50.0/24 ఈ ప్రామాణీకృత క్లయింట్ ద్వారా చేరుకోగలదని అది తెలుసుకోవాలి. OpenVPN తో సాధారణంగా సర్వర్ కాన్ఫిగరేషన్ నెట్టే ప్రతి-క్లయింట్ రూట్, లేదా సర్వర్లో క్లయింట్ వెనుక ఉన్న LANని ప్రకటించే క్లయింట్-నిర్దిష్ట ఫైల్ను సూచిస్తుంది. అది లేకుండా, దూర LAN సమాధానాన్ని వదిలేస్తుంది లేదా దాన్ని దాని సొంత డిఫాల్ట్ గేట్వేకి, అంటే ఇంటర్నెట్కి పంపుతుంది.

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

దశ 4: రెండు నిర్ణయాలను శాశ్వతం చేసి, తర్వాత నిజమైన మార్గాన్ని పరీక్షించండి

ప్రతి రూట్కు యజమాని ఉంటారు, మరియు యజమాని అంటే బూట్లో లేదా పునఃకనెక్షన్లో తిరిగి ఉత్పత్తి అయ్యే కాన్ఫిగరేషన్. రౌటర్లో అది స్టాటిక్ రూట్ ఎంట్రీ కావచ్చు; క్లయింట్లో అది VPN ప్రొఫైల్, NetworkManager లేదా systemd-networkd కావచ్చు. టన్నెల్ను తిరిగి కనెక్ట్ చేసి క్లయింట్ను రీబూట్ చేసి ధృవీకరించండి, తర్వాత మార్పును నమ్మడం కంటే పట్టికను మళ్లీ చదవండి.

టన్నెల్ యొక్క బాహ్య కనెక్షన్ను మోసుకెళ్లే డిఫాల్ట్ రూట్ను అస్పృశ్యంగా ఉంచండి. సెటప్ను “సరళీకృతం” చేయడానికి దాన్ని భర్తీ చేయడం ఏదైనా అంతర్గత ట్రాఫిక్ ఉపయోగించే ముందే ఎన్క్రిప్టెడ్ మార్గాన్ని విచ్ఛిన్నం చేస్తుంది, మరియు లక్షణం మార్పు తర్వాత ఎప్పటికీ పునఃస్థాపించబడని టన్నెల్.

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