OpenVPN ద్వారా LAN యాక్సెస్ విరిగిందా? జోన్లు, మార్గాలు మరియు తిరిగి వచ్చే మార్గాన్ని తనిఖీ చేయండి

టన్నెల్ విజయవంతమైన కనెక్షన్ నివేదిస్తుంది, రౌటర్ సొంత పేజీ లోడ్ అవుతుంది, కానీ దాని వెనుక ఉన్న మెషీన్‌కు డ్రైవ్ మ్యాపింగ్ ఇప్పటికీ సమయం ముగిసి విఫలమవుతుంది. ఈ కలయికలో ఏదీ విరుద్ధం కాదు: రౌటర్ తనే అని సమాధానం ఇస్తోంది, దాని వెనుక ఏదైనా చేరుకోవడం వేరే చోట తీసుకున్న మరో నిర్ణయం. క్రింది తనిఖీలను క్రమంగా చేసి మొదటి వైఫల్యం వద్ద ఆపండి, ఎందుకంటే ప్రతి ఒక్కటి మునుపటిపై ఆధారపడి ఉంటుంది. నాలుగూ దాటితే లోపం టన్నెల్ లోపల కాదు, దానిపై ఉంది.

LAN వైపు వెళ్లే ప్యాకెట్‌ను ఏ ఫిల్టర్ చూస్తుంది

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

OpenWrt ఈ విభజనను పరిశీలించదగినదిగా చేస్తుంది, ఈ భేదం ఒకసారి చదవదగినది. టన్నెల్‌ను ముగించే జోన్‌కు LAN జోన్ వైపు ఫార్వర్డ్ నియమం అవసరం, ఇన్‌పుట్ నియమం రౌటర్‌పై నడిచే సేవలను మాత్రమే నియంత్రిస్తుంది. పనిచేస్తున్న అడ్మిన్ పేజీ పక్కన చనిపోయిన LAN ఉండటం ఆ మిస్ అయిన ఫార్వర్డ్ నియమం యొక్క సాధారణ ఫలితం.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

టన్నెల్ మోసే జోన్ యొక్క ఫార్వర్డ్ లక్ష్యాన్ని చూడండి: accept అనేది మెట్లకు అవసరమైనది, reject క్రింది ప్రతి సమయ ముగింపును వివరిస్తుంది. పక్కపక్కనే ఉన్న రెండు సెట్టింగ్‌లు అదే లక్షణాన్ని కలిగిస్తాయి, కాబట్టి ఇక్కడ ఉన్నప్పుడే వాటిని మినహాయించండి. వైర్‌లెస్ ఐసోలేషన్ వైర్డ్ హోస్ట్‌లను వైర్‌లెస్ క్లయింట్ల నుండి దాచుతుంది, నిష్క్రియ LAN హోస్ట్‌లను ఆఫ్‌లైన్‌గా భావించే రౌటర్ ఫార్వర్డింగ్ పనిచేసిన తర్వాత కూడా సమాధానాలను పడేయవచ్చు.

విభజిత టన్నెల్‌కు నెట్టిన ప్రిఫిక్స్ ఎందుకు అవసరం

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

push "route 192.168.50.0 255.255.255.0"

కలిగి ఉన్న ప్రొఫైల్‌లు route-nopull నెట్టిన మార్గాలను పట్టించుకోవు, కాబట్టి అదే ప్రిఫిక్స్ క్లయింట్ ఫైల్‌లో ఉండాలి. ఏదేమైనా, ఎంట్రీ వచ్చిందని నిర్ధారించండి, ఊహించవద్దు, ఎందుకంటే నిశ్శబ్ద ఓవర్‌రైడ్ ఫైర్‌వాల్ సమస్యలాగే కనిపిస్తుంది.

ip route show | grep 192.168.50

సైట్-టు-సైట్ భాగస్వామి నెట్టడం కంటే ఎక్కువ అడుగుతుంది. సర్వర్ ఆ భాగస్వామి వెనుక ఏ ప్రిఫిక్స్‌లు ఉన్నాయో నేర్చుకోవాలి, దాన్ని దాని client-config-dir ఫైల్‌లోని iroute లైన్ చేస్తుంది, దాని సొంత పట్టికకు టన్నెల్‌లోకి వెళ్లే సరిపోలే మార్గం కూడా అవసరం.

సమాధానానికి అది చేరుకోగల చిరునామా అవసరం

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

tcpdump -ni tun0 host 192.168.50.20

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

సరైన చోట ముగిసే మెట్లు

నాలుగు తనిఖీలు పొరను గుర్తిస్తాయి, ప్రతి ఒక్కటి తీర్పు కాదు, ఒకే ఆదేశం. వాటిని క్రమంగా నడపండి మరియు మొదటి వైఫల్యం వద్ద ఆపండి. క్రమం ఆదేశాల కంటే ముఖ్యం, ఎందుకంటే తర్వాతి దశ దాటితే మునుపటి ఎందుకు విఫలమైందో కారణం కనిపించదు.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

పేర్లు మెట్ల చివరలో ఉంటాయి, ఎప్పుడూ ప్రారంభంలో కాదు. 192.168.50.20గా సమాధానం ఇచ్చి nas.localగా ఇవ్వని భాగస్వామ్యం పేరు పరిష్కారం లేదా శోధన ప్రత్యయం వైపు సూచిస్తుంది, ఫైర్‌వాల్ సవరణలు వాటిలో ఏదీ మార్చలేవు.

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