రౌటర్ VPN పని చేస్తుంది, కానీ LAN క్లయింట్‌లకు ఇంటర్నెట్ లేదు

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

LAN హోస్ట్ నుండి వైఫల్యాన్ని చదవండి

విఫలమయ్యే పరికరం నుండి ప్రారంభించండి, ఎందుకంటే రౌటర్‌లో నడిపించే డయాగ్నస్టిక్స్ మరొక ప్రశ్నకు సమాధానం ఇస్తుంది. క్లయింట్ డిఫాల్ట్ గేట్‌వే ఈ రౌటర్ అని నిర్ధారించండి, దాని మూల చిరునామా మరియు సబ్‌నెట్‌ను గమనించండి, ఆపై రౌటర్ టన్నెల్ ఇంటర్‌ఫేస్ నుండి ఏమి బయటకు వెళ్తుందో చూడండి.

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

స్థానిక మరియు ఫార్వార్డ్ ట్రాఫిక్ వేర్వేరు

Linux మరియు చాలా రౌటర్ ఫర్మ్‌వేర్‌లు పెట్టె స్వయంగా ఉత్పత్తి చేసే ప్యాకెట్‌లను దాని గుండా వెళ్లే ప్యాకెట్‌లకు భిన్నంగా నిర్వహిస్తాయి. అవుట్‌పుట్ చైన్ మొదటి రకాన్ని చూస్తుంది, ఫార్వార్డ్ చైన్ రెండవదాన్ని చూస్తుంది, మరియు రౌటర్ స్వంత ట్రాఫిక్ కోసం సర్దుబాటు చేసిన విధానం ఫార్వార్డింగ్‌ను తాకకుండా వదిలేయగలదు.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

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

తిరిగి వచ్చే మార్గం కూడా ఉండాలి

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

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

క్లయింట్ DNS కూడా అదే సమీక్షలో ఉంటుంది. రౌటర్ రిజాల్వర్ సమాధానం ఇవ్వగలదు, కానీ మరొక సర్వర్‌కు సూచించబడిన క్లయింట్‌కు ఏమీ లభించదు.

అనుమతించిన ఒక ప్రవాహాన్ని మరియు తిరస్కరించిన ఒక ప్రవాహాన్ని ధృవీకరించండి

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

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

దూరపు చివరలో గమనించిన మూల చిరునామాను తనిఖీ చేయండి, ఎందుకంటే ఏ డిజైన్ నిజంగా నడుస్తోందో అది చెబుతుంది. చిరునామాతో పాటు పేరు శోధనను కూడా ధృవీకరించండి, ఎందుకంటే రిజాల్వర్ ప్రవర్తన అదే పెట్టె గుండా వెళ్లే ప్రత్యేక మార్గం.

నియమాలను టన్నెల్ అవసరమయ్యే క్లయింట్ నెట్‌వర్క్‌లకు మాత్రమే పరిమితం చేయండి, మరియు ఒక పరీక్ష గడవడానికి ఫార్వార్డింగ్ ఫిల్టర్‌ను నిలిపివేయడాన్ని వ్యతిరేకించండి. ఆ మార్పు పరీక్షను సరిదిద్దుతుంది మరియు టన్నెల్ అందించాల్సిన సరిహద్దును తొలగిస్తుంది. మూల చిరునామా, అనువాద నిర్ణయం మరియు తిరిగి వచ్చే మార్గాన్ని తేదీతో పాటు ఒకే గమనికలో రాయండి.