OpenVPN ఎలాంటి లోపం లేకుండా ప్రారంభం కావడం లేదా? journal చూడండి

ఆదేశం తిరిగి వస్తుంది, సేవ విఫలమైనట్లు కనిపిస్తుంది, మరియు వివరణ లాంటిది ఏదీ టెర్మినల్కు చేరుకోదు. ఆ నిశ్శబ్దమే ప్రజలు «OpenVPN ప్రారంభం కావడం లేదు» అని వర్ణించే లక్షణం, మరియు ప్రోగ్రామ్ ఏమీ చెప్పకుండా చనిపోయింది అని అర్థం కావడం దాదాపు ఎప్పుడూ లేదు. సందేశం మీరు చదవని ఛానెల్కు వెళ్ళింది, లేదా మీరు ప్రారంభించినది మీరు కాన్ఫిగర్ చేసినది కాదు అని అర్థం. ప్రొఫైల్ను అనుమానితుడిగా పరిగణించడం ఆపిన తర్వాత రెండు సందర్భాలను ఒక నిమిషంలోపు నిర్ధారించవచ్చు.

అవుట్పుట్ను నాలుగు స్థలాలు పీల్చుకుంటాయి: unit యొక్క journal, కనెక్షన్ను కలిగి ఉన్న plugin, సొరంగం మరో చివర, మరియు మీరు అనుకుంటున్న దానికి భిన్నమైన binary. ప్రతి ఒక్కటి దాని స్వంత తనిఖీని కలిగి ఉంది.

నిశ్శబ్దం అంటే మీరు సరైన ఛానెల్ను చూడలేదు

ముందు ప్లాన్ కాల్ మీ టెర్మినల్కు ముద్రిస్తుంది. unit journalకు ముద్రిస్తుంది, మరియు విఫలమైన unit ఏదైనా రాయడానికి ముందే నిష్క్రమించవచ్చు, వైఫల్యం అది ఎలా ప్రారంభించబడింది అనేదానిలో ఉంటే, దానికి ఏమి చెప్పబడింది అనేదానిలో కాదు. ఈ భేదం ముఖ్యం: journalలో నమోదు లేకపోవడం అంటే ప్రక్రియ నిజంగా ఎప్పుడూ నడవలేదు, ఒక నమోదు మరియు దాని తర్వాత నిష్క్రమణ ఉంటే అది నడిచి ఏదో తిరస్కరించింది అని అర్థం.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

స్వచ్ఛమైన నిష్క్రమణను సిగ్నల్ నుండి వేరు చేయడానికి ఇది జోడించండి: systemctl show -p Result -p ExecMainStatus openvpn-client@office. స్థితి 1 మరియు Result=exit-code ప్రోగ్రామ్ నిర్ణయం; Result=signal లేదా టైమ్అవుట్ బదులుగా పర్యావరణాన్ని సూచిస్తాయి, మరియు ప్రొఫైల్ సవరణ ఎంత చేసినా దాన్ని మార్చదు. ఏదైనా పునఃప్రారంభించే ముందు రెండు విలువలను నమోదు చేయండి, ఎందుకంటే పునఃప్రారంభం వాటిని ఉత్పత్తి చేసిన తాత్కాలిక స్థితిని తుడిచివేస్తుంది.

instance పేరు మార్గంలో భాగం

ప్యాకేజ్ చేసిన template unit ఫైల్ మార్గాన్ని తీసుకోదు. అది instance పేరును తీసుకుంటుంది, ఆ పేరు ప్రొఫైల్ను కనుగొనడానికి డైరెక్టరీకి జోడించబడుతుంది: office Debian మరియు Ubuntu ప్యాకేజింగ్లో /etc/openvpn/client/office.conf గా పరిష్కరించబడుతుంది. office-v2.conf అనే ఫైల్ @office గా ప్రారంభించినా ఎప్పుడూ చదవబడదు, దాని దృష్టిలో చేయవలసినది ఏమీ లేకపోవడంతో unit నిశ్శబ్దంగా నిష్క్రమిస్తుంది. శోధన డైరెక్టరీ client మరియు server మోడ్లలో భిన్నంగా ఉంటుంది, కాబట్టి template మార్చినప్పుడు అదే పొరపాటు పూర్తిగా వేరే చోటుకు సూచిస్తుంది.

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

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

unit ప్రారంభించబడి ఉండి ఏ instance జాబితా చేయబడకపోతే, ప్రారంభం స్వయంగా తర్వాత పేరు మార్చబడిన పేరును సూచించవచ్చు. సరైన instanceను మళ్లీ ప్రారంభించడం సాధారణంగా సరిపోతుంది, మిగిలిపోయిన పాత unit ఫైల్ను తొలగించడం మంచిది, అది తర్వాతి వ్యక్తిని గందరగోళపరచకుండా. మిగిలిపోయిన unit ఫైల్ తర్వాత ఎవరికో ఒక గంటను కోల్పోయే చిన్న విషయం.

plugin సొరంగాన్ని కలిగి ఉన్నప్పుడు, టెర్మినల్ ఏమీ చూడదు

డెస్క్టాప్ applet నుండి ప్రారంభమైన కనెక్షన్ను NetworkManager కలిగి ఉంటుంది, దాని OpenVPN అవుట్పుట్ మీరు తెరిచిన ఏ shellకూ కాదు, ఆ సేవ యొక్క journalకు వెళ్తుంది. clientను చేతితో నడపడం మరియు ఏమీ కనిపించకపోవడం ఆ ఏర్పాటులో ఆశించినది, చేతితో నడపబడిన ప్రక్రియ కనెక్షన్ను మోసేది కాదు.

దాన్ని కలిగి ఉన్న సేవను journalలో వెతకండి, తర్వాత మీరు చదవగలిగే వివరాల స్థాయిలో విశ్లేషణను మళ్లీ ఉత్పత్తి చేయండి. కింది రెండు ఆదేశాలు ఒకే వైఫల్యం యొక్క వేరే యజమానులను చూస్తాయి.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

స్వతంత్ర నడక సందేశాలను చదవడానికి, నిర్వహించబడే కనెక్షన్ను భర్తీ చేయడానికి కాదు, మరియు రెండూ తర్వాత భిన్నంగా ఉంటాయి: DNS ఏకీకరణ, మార్గాలు మరియు జీవితకాలం pluginకు చెందుతాయి. స్వతంత్ర నడకలో విశ్లేషణ లోపాన్ని సరిచేయడం applet నియంత్రణ తీసుకున్న తర్వాత పేర్ల పరిష్కారాన్ని స్వయంచాలకంగా సరిచేయదు, కాబట్టి రెండు పరిశీలనలను వేరుగా ఉంచండి.

రెండు binary, ఒక PATH

చేతితో నిర్మించిన ఇన్స్టాల్ /usr/local కింద ఉంటే shell కాల్లో గెలుస్తుంది, ఎందుకంటే /usr/local/sbin డిఫాల్ట్ Ubuntu PATHలో /usr/sbin కంటే ముందు వస్తుంది. unit మీ PATHను ఉపయోగించదు; అది ExecStart లో రాసిన పూర్తి మార్గాన్ని నడుపుతుంది. కాబట్టి మీ టెర్మినల్లో పనిచేసే సంస్కరణ మరియు సేవగా విఫలమయ్యే సంస్కరణ నిజంగా వేరే ప్రోగ్రాములు కావచ్చు.

ఏదైనా పునర్నిర్మించే ముందు రెండింటిని పోల్చండి. మూడో ఆదేశమే వాదనను నిర్ణయిస్తుంది.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

మరో పర్యావరణ భేదం అదే చోట దాగి ఉంది. ప్యాకేజ్ చేసిన unit /run కింద systemd దాని కోసం సృష్టించే రన్టైమ్ డైరెక్టరీపై ఆధారపడి ఉంటుంది; ఆ సెట్టింగ్ను వదిలేసే చేతితో రాసిన ప్రత్యామ్నాయ unit ఒక ఫైల్ను కూడా తెరవకముందే విఫలం కావచ్చు, మరియు వైఫల్యం ఏ OpenVPN సందేశం లేని సాధారణ తిరస్కరణలా కనిపిస్తుంది.

client తెలియజేయలేని వైఫల్యాలు

కొన్ని ఫలితాలు దూరపు చివరలో నిర్ణయించబడతాయి. HTTP స్థితితో సమాధానమిచ్చి కనెక్షన్ను మూసే గేట్వే దాని స్వంత స్థితిని మీకు చెప్పింది, తదుపరి ఉపయోగకరమైన అడుగు మీ స్థానిక ఫైళ్లు కాదు, దాని లాగ్ లేదా ఆధారాల వెనుక ఉన్న ఖాతా. ఆ సందర్భంలో స్థానికంగా ఏదీ పాడైలేదు, పరిహారం కోసం ప్రొఫైల్ను సవరించడం తదుపరి నిర్ధారణను కష్టతరం చేస్తుంది. client కాన్ఫిగరేషన్ను తాకే ముందు ఆ లాగ్ను చదవండి.

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

పొరలను వరుసగా నిర్వహించండి: unit ఉందా మరియు instance పేరు సరైనదా, journal లేదా --log ఫైల్కు ఏదైనా చేరిందా, ఏ binary మరియు ప్రొఫైల్ నిజంగా నడిచాయి, మరియు వైఫల్యం స్థానికమా లేక దూరమా. ప్రతి సమాధానం ఒక పొరను తొలగిస్తుంది. ప్రొఫైల్ నుండి ప్రారంభించడం అంటే ఎప్పుడూ తెరవబడని ఫైల్ను మళ్లీ రాయడం.