VPN క్లయింట్లు సర్వర్‌ను చేరుతాయి, LAN-ను కాదు: ఏ పరిష్కారం?

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

మొదట ఏ దిశ పాడైందో నిర్ధారించండి

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

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

LAN హోస్ట్ ఇప్పటికే VPN సర్వర్‌ను చూపిస్తే, మీ సమస్య ఫైర్‌వాల్ నియమం లేదా MTU పరిమితి, తిరిగి వెళ్లే మార్గం లేకపోవడం కాదు. ఫిల్టర్ సరిచేయడానికి మార్గం జోడించవద్దు.

మొదటి ప్రశ్న: దూరపు LAN రౌటర్‌ను సవరించగలరా?

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

ఎవరైనా పూల్ మార్చిన రోజు ఇది నిశ్శబ్దంగా విఫలమవుతుంది. విలువను ఒకసారి రాసి పెట్టుకోండి, మూడు స్థలాల్లో ఏదైనా ఒకదానిలో మార్పును మూడింటికీ మార్పుగా భావించండి.

సేవను హోస్ట్ చేసే NAS లేదా Layer 3 స్విచ్‌కు కూడా అదే మార్గం కావాలి, అది ప్రతిదీ ఆ మార్గం ఉన్న రౌటర్ ద్వారా పంపకపోతే. సబ్‌నెట్‌ను ముగించే పరికరాన్ని తనిఖీ చేయండి, ఇంటర్నెట్ వైపు చూసేదాన్ని మాత్రమే కాదు. చిన్న నెట్‌వర్క్‌లలో రౌటింగ్‌పై అభిప్రాయం ఉన్న మూడు పరికరాలు తరచుగా ఉంటాయి.

రెండో ప్రశ్న: LAN క్లయింట్ చిరునామాలను చూడటం ఆపగలదా?

రౌటర్ మరొకరిది అయితే, VPN సర్వర్‌పై అనువాదానికి సహకారం అవసరం లేదు. LAN హోస్ట్ సర్వర్ LAN చిరునామాను చూస్తుంది, దానికి సమాధానం ఇస్తుంది, సర్వర్ తిరిగి అనువదిస్తుంది. అందుకే పరికరాలు మరియు NAT ఆధారిత రిమోట్ యాక్సెస్ పాత్రలు ఇలా ప్రవర్తిస్తాయి.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

ధర ఆపాదన: ప్రతి క్లయింట్ చిరునామాలు LAN లాగ్‌ల నుండి మాయమవుతాయి. LAN హోస్ట్‌లోని ఏ అనుమతి జాబితా అయినా అప్పుడు పూల్‌కు బదులు సర్వర్‌ను పేర్కొనాలి.

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

మూడో ప్రశ్న: సర్వర్ తానే మరో టన్నెల్ క్లయింటా?

మరో టోపాలజీని ఊహించండి: VPN సర్వర్ వాణిజ్య ప్రదాతను కూడా డయల్ చేస్తుంది, కాబట్టి దానికి రెండు టన్నెల్‌లు, రెండు చిరునామాల సెట్లు ఉన్నాయి. తన క్లయింట్ల కోసం పంపే ట్రాఫిక్ ప్రదాత ద్వారా బయటికి వెళ్తుంది, అది ప్రతిస్పందనలను పూల్ చిరునామాలకు తిరిగి మార్గనిర్దేశం చేయదు. అందుకే రెండు టన్నెల్‌లు ఆరోగ్యంగా ఉన్నా ప్రతిస్పందనలు మాయమవుతాయి.

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

తర్వాత రెండు దిశలను, రెండు పరిమాణాలను తనిఖీ చేయండి

మార్పు తర్వాత క్లయింట్ నుండి LAN హోస్ట్‌కు, తర్వాత LAN హోస్ట్ నుండి క్లయింట్‌కు ping చేయండి. రెండో దిశను ప్రజలు దాటవేస్తారు, అదే అసంపూర్ణ అనువాద నియమాన్ని బయటపెడుతుంది. రెండు ఫలితాలను సమయ ముద్రతో నమోదు చేయండి, తర్వాతి తిరోగమనం పోల్చదగినదిగా ఉంటుంది.

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

చివరగా, పునఃప్రారంభం తర్వాత మళ్లీ పరీక్షించండి. రన్‌టైమ్ మార్గం మరియు ఫైర్‌వాల్ ఆదేశాలు దానిని తట్టుకోవు, తదుపరి ప్రారంభంలో మాయమయ్యే సరిచేతను తక్కువ సందర్భం ఉన్న వ్యక్తి మళ్లీ నిర్ధారిస్తాడు. మార్పును మీ సిస్టమ్ ఇప్పటికే చేసే విధంగానే శాశ్వతం చేయండి, తర్వాత ఒకసారి ఉద్దేశపూర్వకంగా పునఃప్రారంభించండి.