OpenVPN ఇంకా పాత మార్గాలను నెట్టుతోందా? అది ఏమి లోడ్ చేసిందో చూడండి

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

క్రింది పోలిక ప్రక్రియ నుండి బయటకు వెళ్తుంది, ఎందుకంటే ఏ ఫైల్ అమలులో ఉందో తెలిసే ఏకైక అధికారం ప్రక్రియకే ఉంది.

మీరు సవరించిన ఫైల్ మరియు ప్రక్రియ చదివే ఫైల్

unit మరియు అది సృష్టించిన కమాండ్ లైన్తో ప్రారంభించండి. systemd హోస్ట్లో systemctl cat openvpn@server ExecStart పంక్తిని ముద్రిస్తుంది, మరియు instance unit సాధారణంగా తన కాన్ఫిగరేషన్ మార్గాన్ని instance పేరు నుండి పొందుతుంది, కాబట్టి openvpn@office పేరుతో ప్రారంభించిన డీమన్ openvpn@server పేరుతో ప్రారంభించిన దానికంటే వేరే ఫైల్ను చదువుతుంది. దీన్ని నడుస్తున్న ప్రక్రియ argv తో పోల్చండి. కాన్ఫిగరేషన్ నిర్వహణ సాధనం మార్పు పోయే మరో మార్గాన్ని జోడిస్తుంది: సరైన ఫైల్ను unit ఎప్పుడూ ప్రస్తావించని చోట రాయవచ్చు, అప్పుడు విజయవంతమైన డిప్లాయ్ ఏమీ చేయనట్టే కనిపిస్తుంది.

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

సర్వర్ ఏమి నెట్టుతుంది మరియు క్లయింట్ ఏమి ఇన్స్టాల్ చేస్తుంది

నెట్టిన మార్గం రెండు ఫిల్టర్లను దాటాలి. సర్వర్లో అది లోడ్ చేసిన కాన్ఫిగరేషన్లో ఉండాలి, వ్యాఖ్యానించిన బ్లాక్లో లేదా పేరు సరిపోని క్లయింట్-నిర్దిష్ట ఫైల్లో కాదు. క్లయింట్లో pull ప్రారంభించి ఉండాలి మరియు ఏ pull-filter ఆ ఎంపికను విసరకూడదు. verbosity 4 తో కనెక్ట్ అయి క్లయింట్ నివేదించే నెట్టిన ఎంపికలను చదవండి: మార్గం ఆ జాబితాలో ఉంటే, సర్వర్ తన పని చేసింది మరియు దాన్ని ఇన్స్టాల్ చేయకూడదని క్లయింటే ఎంచుకుంటోంది.

క్లయింట్-నిర్దిష్ట ఫైళ్లు గందరగోళానికి సాధారణ మూలం. సర్టిఫికేట్ common name పేరుతో ఉన్న ఫైల్ ఆ క్లయింట్కే ఎంపికలను నెట్టుతుంది, ఒక అక్షరం తేడా నెట్టడాన్ని నిశ్శబ్దంగా ఆపుతుంది, రెండు వైపులా దోషం కనిపించదు. సర్వర్ కనెక్ట్ అయినప్పుడు చూసిన common name ను నమోదు చేస్తుంది, కాబట్టి ఆ విలువను ఫైల్ పేరుతో పోల్చండి, క్లయింట్ పేరు అని మీరు అనుకునే దానితో కాదు.

నెట్టిన పూర్వపదం మరియు తిరిగి వచ్చే మార్గం వేర్వేరు సమస్యలు

తన స్థానిక ఇంటర్నెట్ మార్గాన్ని కాపాడుకోవడానికి redirect-gateway ను ఉద్దేశపూర్వకంగా విస్మరించే క్లయింట్ రెండో, సంబంధం లేని ఖాళీని సృష్టిస్తుంది. సర్వర్ ప్రోబ్లు టన్నెల్ చిరునామాకు చేరుతాయి, కానీ సమాధానాలు ఎప్పుడూ రావు, ఎందుకంటే సర్వర్ టన్నెల్ IP కి పంపిన సమాధానం క్లయింట్ సాధారణ డిఫాల్ట్ గేట్వే ద్వారా మార్గం పడుతుంది. ఇక్కడ నెట్టిన సబ్నెట్ మార్గం తప్పు కాదు; లేనిది సర్వర్ టన్నెల్ నెట్వర్క్ ట్రాఫిక్ను టన్నెల్ పరికరం ద్వారా తిరిగి పంపే మార్గం.

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

రెండు చివరల పట్టికలను పోల్చండి

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

మూడు గుర్తింపులను కలిసి ఉంచండి: కాన్ఫిగరేషన్ మార్గం, unit లేదా instance పేరు, మరియు మీరు పరీక్షించిన క్లయింట్ గుర్తింపు.

ఈ మూడూ తదుపరి సంఘటనను మళ్లీ దర్యాప్తు చేయడం బదులు ఐదు నిమిషాల తనిఖీగా మారుస్తాయి, మరియు టన్నెల్ మరొకరి సమస్య అయినప్పుడు సహోద్యోగికి కావలసినది కూడా ఇవే.

పునఃప్రారంభాన్ని దాటి నిలిచే మార్గ సమస్య తరచుగా మార్గనిర్దేశన సమస్యే కాదు; లోపం మీరు నిరంతరం చదివే పట్టికకు పైన ఉంటుంది.