OpenVPN క్లయింట్ వెనుక ఉన్న సబ్‌నెట్‌ను ఎందుకు చేరుకోలేము?

సర్వర్ టన్నెల్ చిరునామాకు ping విజయవంతమవుతుంది, క్లయింట్ సొంత రూట్ పట్టిక సరిగ్గా కనిపిస్తుంది, అయినా ఆ క్లయింట్ వెనుక ఉన్న LAN ఇంకా చేరుకోలేనిదే. క్లయింట్ రూటింగ్ పట్టిక సరిగ్గా కనిపిస్తుంది, సర్వర్‌లో టన్నెల్ వైపు చూపే మార్గం ఉంది, ప్యాకెట్లు ఇంకా మాయమవుతాయి. ఇది layer-3 టన్నెల్ యొక్క సాంప్రదాయ లక్షణం, దాని క్లయింట్లలో ఒకరు కూడా గేట్‌వే అని దానికి తెలియదు.

tun ఇంటర్‌ఫేస్‌లో ప్రతి క్లయింట్‌కు తదుపరి హాప్ ఉండదు. కర్నెల్ అనేక పీర్లతో ఉన్న ఒకే ఇంటర్‌ఫేస్‌ను చూస్తుంది, కాబట్టి దూరపు LAN కోసం ఏ క్లయింట్ ప్యాకెట్ పొందాలనే నిర్ణయం OpenVPN ప్రక్రియ లోపల తీసుకోవాలి. ఆ నిర్ణయం iroute ద్వారా కాన్ఫిగర్ చేయబడుతుంది, అది లేకుండా ప్యాకెట్‌కు వెళ్లడానికి చోటు లేదు.

సర్వర్ ఇంటర్‌ఫేస్ ప్రకారం కాదు, క్లయింట్ ప్రకారం రూట్ చేస్తుంది

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

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

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

క్లయింట్‌ను పేర్కొనే iroute నమోదును రాయడం

iroute సర్వర్ ప్రధాన కాన్ఫిగరేషన్‌లో కాదు, క్లయింట్-నిర్దిష్ట కాన్ఫిగరేషన్ ఫైల్‌లో ఉంటుంది. client-config-dir ఎంపికతో సర్వర్‌ను డైరెక్టరీ వైపు చూపండి, తర్వాత పేరు క్లయింట్ సర్టిఫికెట్ యొక్క సాధారణ పేరుగా ఉన్న ఫైల్‌ను సృష్టించి అందులో ప్రిఫిక్స్ పెట్టండి.

LAN 10.20.0.0/24 గాను సర్టిఫికెట్ సాధారణ పేరు branch-router గాను ఉన్న శాఖకు, ఆ మార్గంలోని ఫైల్‌లో iroute 10.20.0.0 255.255.255.0 వంటి పంక్తి ఉంటుంది. ప్రధాన కాన్ఫిగరేషన్‌కు డైరెక్టరీ ఎంపిక మాత్రమే కావాలి; ప్రిఫిక్స్ క్లయింట్ దగ్గర ఉంటుంది.

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

ఒక క్లయింట్ అనేక ప్రిఫిక్స్‌లను కలిగి ఉండవచ్చు. ప్రతి నెట్‌వర్క్‌కు ఒక iroute పంక్తిని జోడించండి, మ్యాపింగ్ ఆడిట్ చేయగలిగేలా ఉండటానికి జాబితాను ఆ క్లయింట్ మిగిలిన సెట్టింగ్‌ల పక్కన ఉంచండి.

రెండు దిశలలో తిరిగి వచ్చే మార్గాన్ని నిర్మించడం

దూరపు LANకు ప్యాకెట్లను చేర్చడం సగం పని. క్లయింట్ ఆ LAN ట్రాఫిక్‌ను కూడా టన్నెల్‌లోకి పంపాలి, ఇది సాధారణంగా క్లయింట్‌కు మార్గాన్ని నెట్టడం ద్వారా చేయబడుతుంది: push "route 10.8.0.0 255.255.255.0" వంటి పంక్తి ప్రతి క్లయింట్‌కు సర్వర్ వైపు నెట్‌వర్క్‌ను ఎలా చేరుకోవాలో చెబుతుంది. శాఖకు, సమానమైన మార్గం సర్వర్ వైపు చేరుకోవాల్సిన అన్నింటికీ టన్నెల్ వైపు చూపుతుంది.

తిరిగి వచ్చే దిశకు దూరపు వైపు యజమాని కావాలి. ఆ వైపు ఎవరో తిరిగి వెళ్లే మార్గం తెలిసి ఉండాలి: VPN పూల్‌ను సర్వర్ వైపు చూపే LAN రూటర్‌లో స్థిర మార్గం, లేదా ట్రాఫిక్ LANలోకి ప్రవేశించే ముందు సర్వర్‌లో చిరునామా అనువాదం. స్థిర మార్గం అసలు చిరునామాలను లాగ్‌లు మరియు యాక్సెస్ నియమాలలో కనిపించేలా ఉంచుతుంది కానీ LAN యజమాని సహకారం అవసరం; అనువాదం స్వయం సమృద్ధం కానీ నిజంగా ఎవరు కనెక్ట్ అయ్యారో దాచుతుంది.

సర్వర్ హోస్ట్‌పై ఫార్వర్డింగ్ ప్రారంభించబడి ఉండాలి. అది లేకుండా కర్నెల్ టన్నెల్ నుండి ప్యాకెట్‌ను అంగీకరించి దాన్ని LAN ఇంటర్‌ఫేస్‌కు పంపడానికి నిరాకరిస్తుంది, ఇది క్లయింట్ దృష్టికోణంలో తప్పిపోయిన iroute లాగానే కనిపిస్తుంది.

సరైన ప్రోబ్‌లతో చేరికను ధృవీకరించడం

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

తర్వాత ప్యాకెట్లను గమనించండి. టన్నెల్ ఇంటర్‌ఫేస్‌పై క్యాప్చర్ సర్వర్ క్లయింట్ వైపు పంపుతోందా అని చూపుతుంది, LAN ఇంటర్‌ఫేస్‌పై క్యాప్చర్ అది ఫార్వర్డ్ చేస్తోందా అని చూపుతుంది. మొదటిది ప్యాకెట్లను చూపి రెండవది ఏమీ చూపకపోతే, సమస్య ఫార్వర్డింగ్ లేదా ఫిల్టర్‌లో ఉంది; రెండూ ఏమీ చూపకపోతే, శోధన ముందే విఫలమైంది.

టన్నెల్‌తో అనుసంధానించబడిన రెండు సర్వర్లు రెండు వైపులా అదే నియమాన్ని పునరావృతం చేస్తాయి: ప్రతిదానికి మరొకదాని పూల్ కోసం iroute కావాలి, మార్గాన్ని సమరూపంగా చేసే మార్గం మరియు ఫార్వర్డింగ్ కావాలి. ఇక్కడ రూటింగ్ మరియు విధానం వేర్వేరు విషయాలు. రూటింగ్ ప్యాకెట్ ఎక్కడికి వెళ్లగలదో నిర్ణయిస్తుంది, FORWARD నియమం అనుమతించబడిందా అని నిర్ణయిస్తుంది, కాబట్టి రెండు iroute పంక్తులు ఉన్న క్లయింట్ ఫిల్టర్ వేరే చెప్పకపోతే రెండు ప్రిఫిక్స్‌లను చేరుకోగలదు.