LAN సర్వర్లో VPN క్లయింట్: ప్రతిస్పందనలు తప్పు మార్గంలో ఎందుకు వెళ్తాయి

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

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

అభ్యర్థన వెళ్లిన మార్గం ద్వారానే ప్రతిస్పందన తిరిగి వస్తుందనే భావనను వదిలేయడం సహాయకరం. రౌటింగ్ ప్రతి ప్యాకెట్ కు, ప్రతి దిశకు, పంపే హోస్ట్పై నిర్ణయించబడుతుంది. టన్నెల్ లోపల 10.64.0.23 నుండి వచ్చిన అభ్యర్థన ఎలాంటి తిరిగి వచ్చే మార్గాన్ని సృష్టించదు; హోస్ట్ ప్రతిస్పందించినప్పుడు ఆ ప్రతిస్పందన కొత్త ప్యాకెట్గా పట్టికతో సరిపోల్చబడి గెలిచే మార్గం ద్వారా బయటకు వెళ్తుంది.

అందుకే LAN కు కూడా సేవ చేసే మెషీన్లో పూర్తి టన్నెల్ క్లయింట్ ఇంత గందరగోళమైన వైఫల్యాన్ని సృష్టిస్తుంది. క్లయింట్ డిఫాల్ట్ రూట్ను, లేదా కొన్ని క్లయింట్లు ఇష్టపడే రెండు సగం-డిఫాల్ట్ రూట్లను ఇన్స్టాల్ చేస్తుంది, LAN క్లయింట్కు ప్రతిస్పందన ఇప్పుడు టన్నెల్కు సరిపోతుంది. అది ప్రదాత వద్దకు వెళ్తుంది, వారికి దానిని ముందుకు పంపే కారణం లేదు, హోస్ట్ నడుస్తూ స్థానికంగా ప్రతిస్పందిస్తున్నా LAN క్లయింట్ సమయ ముగింపును చూస్తుంది. క్యాప్చర్ దీన్ని స్పష్టం చేస్తుంది, రౌటింగ్ పట్టిక దీన్ని వివరిస్తుంది.

మిగిలినది చదివేటప్పుడు రెండు ఉపజాలాలను గుర్తుంచుకోండి. ఒకటి దూరపు క్లయింట్లు వచ్చే VPN చిరునామా పూల్, ఈ ఉదాహరణలో 10.64.0.0/24. మరొకటి పని కొనసాగాల్సిన LAN, 172.16.24.0/24, దాని రౌటర్ 172.16.24.1 వద్ద. లోపం ఏమిటంటే వాటి మధ్య ట్రాఫిక్ను డిఫాల్ట్ రూట్ నిర్ణయిస్తుంది.

క్యాప్చర్ మరియు లుకప్తో దాన్ని నిరూపించండి

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

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

ప్రతిస్పందనను రెండు భాగాలుగా చదవండి. అది dev tun0 అని పేర్కొంటే, హోస్ట్ ప్రతిస్పందనను ఎన్క్యాప్సులేట్ చేసి ప్రదాతకు ఇస్తుంది, LAN క్లయింట్ దాన్ని ఎప్పటికీ చూడదు. అది dev eth0 అని పేర్కొని క్లయింట్ ఇంకా సమయ ముగింపు పొందితే, రూట్ ఇప్పటికే సరైనది మరియు ప్యాకెట్ తర్వాత విస్మరించబడుతుంది, అది వేరే సమస్య మరియు వేరే పరిష్కారం.

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

టన్నెల్ను మించే అత్యంత సన్నని రూట్ను ఇన్స్టాల్ చేయండి

ప్రిఫిక్స్ పొడవు నిర్ణయిస్తుంది, మెట్రిక్ కాదు, కాబట్టి LAN రౌటర్ ద్వారా క్లయింట్ పూల్ రూట్ VPN క్లయింట్ ఇన్స్టాల్ చేసే ఏ డిఫాల్ట్ను అయినా ఓడిస్తుంది. మెట్రిక్ శస్త్రచికిత్స అవసరం లేదు, డిఫాల్ట్ క్లయింట్ పెట్టిన చోటే ఉండగలదు.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

రెండవ add కు బదులు replace వాడండి, ఎందుకంటే మళ్లీ కనెక్ట్ అయ్యే క్లయింట్ తన ఎంట్రీని ఇన్స్టాల్ చేసుకుని ఉంటుంది మరియు రెండవ add అనుమతి సమస్యలా చదవబడే ఇప్పటికే ఉన్న రూట్ లోపంతో విఫలమవుతుంది. Windows హోస్ట్పై సమానమైనది route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, ఇక్కడ -p రీబూట్ల మధ్య ఎంట్రీని ఉంచుతుంది, టన్నెల్ మళ్లీ పైకి వచ్చినప్పుడు క్లయింట్ పట్టికను తిరిగి నిర్మించగలదు. ఆధునిక Windows హోస్ట్పై మద్దతు ఉన్న సమానమైనది New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, పాత route ఆదేశం లెగసీ రూపంగా ఉంచబడుతుంది.

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

మళ్లీ కనెక్ట్ అయిన తర్వాత కూడా ప్రతిస్పందనను ఉంచండి

చేతితో జోడించిన రూట్ ఉత్తమ స్థితిలో తదుపరి మళ్లీ కనెక్ట్ అయ్యే వరకు నిలుస్తుంది. క్లయింట్ పూల్ చలనశీలమైతే, మీరు రూట్ చేసిన ప్రిఫిక్స్ క్లయింట్లు పొందే ప్రిఫిక్స్గానే ఉండేలా దాన్ని సర్వర్ కాన్ఫిగరేషన్లో పిన్ చేయండి; లేకపోతే ఎంట్రీ ఖాళీ పరిధిని సూచిస్తుంది మరియు లక్షణం వారాల తర్వాత స్పష్టమైన కారణం లేకుండా తిరిగి వస్తుంది. రూట్ను క్లయింట్ సొంత up-స్క్రిప్ట్లో రాయడం మరొక నమ్మదగిన ఎంపిక, ఎందుకంటే క్లయింట్ పట్టికను తిరిగి రాసిన తర్వాత అది నడుస్తుంది.

స్థితి ఉన్న ఫైర్వాల్ సరైన రూట్ను కూడా ఓడించగలదు. క్యాప్చర్ ఇప్పుడు ప్రతిస్పందన eth0 ద్వారా బయటకు వెళ్తున్నట్లు చూపి క్లయింట్ ఇంకా సమయ ముగింపు పొందితే, హోస్ట్ పంపే ముందు ప్యాకెట్ను విస్మరిస్తుందా అని చూడండి. కఠినమైన రివర్స్-పాత్ ఫిల్టరింగ్ మరియు net.ipv4.conf.all.rp_filter 1 గా సెట్ చేయడం, వచ్చిన ఇంటర్ఫేస్ ద్వారా వెనుకకు రూట్ చేయబడని మూలం ఉన్న ప్యాకెట్లను విస్మరిస్తాయి, మరియు ఇది మీరు ఇప్పుడే సృష్టించి తర్వాత సరిచేసిన అసమరూప సందర్భమే, conntrack స్థితి ముందుకు పంపిన పోర్టులకు అదే కథ చెబుతుంది.

చివరి తనిఖీ మనుషులు దాటవేసేది: టన్నెల్ కిందకు వెళ్లి మళ్లీ పైకి వచ్చిన తర్వాత లుకప్ను పునరావృతం చేయండి. నాలుగు విలువలు మీరు రాసుకున్న వాటితో సరిపోలాలి: గమ్యం, తదుపరి హాప్, పరికరం మరియు ఎంచుకున్న మూలం. వాటిలో ఏదైనా కదిలి ఉంటే, క్లయింట్ పట్టికను తిరిగి రాసింది మరియు పరిష్కారం దాని హుక్స్లో ఉంది, shell చరిత్రలో కాదు.