OpenVPN active (exited) అంటోందా? మీరు ప్రారంభించిన ఇన్స్టెన్స్ను కనుగొనండి
active (exited) టన్నెల్ కాదు, RemainAfterExit నిలిపే /bin/true యొక్క ఒకసారి పని. ఇన్స్టెన్స్ను కనుగొని, అది సూచించే ఫైల్ను చదివి, ఆపై దాని జర్నల్ను చదవండి.
మీరు టన్నెల్ను తనిఖీ చేసి, systemctl status openvpn నడిపి, Main PID లేకుండా మరియు ఖాళీ ప్రాసెస్ జాబితాతో active (exited) పొందుతారు. సేవ ప్రారంభమై మరణించిందనేది సహజ పఠనం, కాబట్టి మీరు unit తెరిచి /bin/true కనుగొని ప్యాకేజీ విరిగిపోయిందని నిర్ధారిస్తారు. Debian ప్యాకేజింగ్లో ఆ స్థితి రూపకల్పన ప్రకారం పనిచేసే wrapper, టన్నెల్ అది ప్రారంభించే instance unitలలో ఒకదానిలో జీవిస్తుంది. మొత్తం unit ఏ ఇన్స్టెన్స్ దాన్ని నిర్మించిందో ఎప్పటికీ చెప్పదు.
ఈ unitపై active (exited) నిజంగా ఏమి అర్థం
ప్యాకేజీ చేసిన unit ఒకసారి పని: దాని ExecStart /bin/true, ముగిసిన unit active (exited)గా నివేదించబడుతూ ఉండటానికి RemainAfterExit=yes కారణం. ఆ ఆదేశాన్ని తీసేస్తే అదే విజయవంతమైన /bin/true పని inactive (dead)లో ముగుస్తుంది, అదే ప్రజలు ఆశించి వ్యతిరేక దిశలో తప్పుగా చదివే స్థితి. ఆదేశం కేవలం స్థానభర్తి, unit ఇతర unitలు చేసే పని గురించి నివేదిస్తుంది. ఈ ఏర్పాటులో ఏదీ విరిగిలేదు, /bin/trueని మార్చడం టన్నెల్ను కాదు, ప్యాకేజింగ్ ఒప్పందాన్ని మారుస్తుంది.
wrapper ప్రాతినిధ్యం చేస్తుంది. ప్యాకేజీ కాన్ఫిగరేషన్ లేదా దాని systemd జనరేటర్ అందించే instance unitలను ప్రారంభిస్తుంది, అందుకే ఖాళీ ప్రాసెస్ జాబితా టన్నెల్ గురించి ఏమీ నిరూపించదు. ఏ ఇన్స్టెన్స్ ఎంపిక కాకపోయినా wrapper విజయవంతమవుతుంది, ఏమీ ప్రారంభించదు. స్థితి wrapper నడిచిందా అని సమాధానమిస్తుంది, టన్నెల్ ఉందా అని కాదు.
బ్రాకెట్లోని పదం కాదు, status అవుట్పుట్ మూడు పంక్తులు చదవండి. Loaded systemd చదివిన unit ఫైల్ను పేర్కొంటుంది, Active చివరి విజయవంత పరుగు సమయ ముద్రను కలిగి ఉంటుంది, Main PID లేకపోవడం ముగిసిన ఒకసారి పనికి సరిపోతుంది. ఆ మూడు పంక్తులే ఈ wrapperను ప్రారంభమైన ఒక సెకను తర్వాత పడిపోయిన సేవ నుండి వేరు చేసి గుర్తించే మార్గం.
status మళ్లీ చదవకముందు unitలను జాబితా చేయండి
ఏమి నడుస్తోందో అడగకముందు systemdను ఏమి ఉందో అడగండి. ఏ ఇన్స్టెన్స్ సృష్టించకుండానే టెంప్లేట్ ఇన్స్టాల్ కావచ్చు, సృష్టించిన unit మాత్రమే టన్నెల్ కలిగి ఉంటుంది. లోడ్ అయిన సెట్తో ప్రారంభించండి:
systemctl list-units 'openvpn*'
ఆ జాబితా systemd ఈ క్షణంలో లోడ్ చేసినది, టన్నెల్ జాబితాకు దగ్గరగా ఉండేది అదే. ఇన్స్టాల్ అయిన unit ఫైళ్లు వేరే ప్రశ్నకు సమాధానమిస్తాయి, ఏమీ సృష్టించనప్పుడు కూడా ఆ జాబితా టెంప్లేట్ను చూపుతుంది:
systemctl list-unit-files 'openvpn*'
రెండు జాబితాలను కలిపి చదవండి, ఎందుకంటే రెండోదానిలో టెంప్లేట్, మొదటిదానిలో ఇన్స్టెన్స్ రెండు వేరు సమాధానాలు. ఉన్న టెంప్లేట్, నడుస్తున్న ఇన్స్టెన్స్ ఒకే వాస్తవం కాదు, రెండోది మాత్రమే టన్నెల్ అని అర్థం. ప్యాకేజీ లేఅవుట్లు పంపిణీలు, OpenVPN సంస్కరణల మధ్యా మారుతాయి. పాత openvpn@ టెంప్లేట్, విడిపోయిన client మరియు server జోడీ, పంపిణీ wrapper అన్నీ తమ ప్యాకేజింగ్లో చెల్లుబాటు కావచ్చు.
మీరు కనుగొన్న ట్యుటోరియల్కు కాదు, మీ మెషీన్కు సరిపోయేలా మార్చుకోండి. ఇతరుల అవుట్పుట్లో ఇన్స్టెన్స్ పేరు office కావచ్చు, మీది home లేదా work కావచ్చు. బదిలీ అయ్యేది పద్ధతి, స్ట్రింగ్ కాదు.
ఇన్స్టెన్స్ పేరు నుండి అది చదివే ఫైల్ వరకు వెళ్లండి
upstream client టెంప్లేట్లో unit పని డైరెక్టరీ /etc/openvpn/client, దాని ఆదేశం అక్కడి నుండి %i.conf తీసుకుంటుంది, కాబట్టి openvpn-client@office /etc/openvpn/client/office.conf చదువుతుంది. ఉదాహరణను నమ్మకుండా ఇన్స్టాల్ అయిన unitపై ఆ మ్యాపింగ్ను నిర్ధారించండి, ఎందుకంటే మీ టెంప్లేట్ పాతది లేదా పంపిణీ రీరైట్ కావచ్చు:
systemctl cat [email protected]
ఆ అవుట్పుట్ కింద కనిపించే drop-inలను చదవండి, ఎందుకంటే .d/ కింద ఉన్న ఫైల్ ExecStart, పని డైరెక్టరీ లేదా కాన్ఫిగరేషన్ మార్గాన్ని మార్చవచ్చు. మీరు office.ovpnగా డౌన్లోడ్ చేసిన ప్రొఫైల్ ఇన్స్టెన్స్ తెరిచే ఫైల్ కాదు. ఈ తేడాయే మీరు ఎప్పుడూ సవరించని మార్గాన్ని లోపం పేర్కొనడానికి సాధారణ కారణం.
ప్రొఫైల్ లోపలి సాపేక్ష మార్గాలు తదుపరి ఉచ్చు. ca, cert, key సూచనలు సాపేక్షంగా ఉండగా ప్రధాన ఫైల్ను తరలించడం ద్వారా మిస్సింగ్-ఫైల్ లోపాన్ని మరో మిస్సింగ్-ఫైల్ లోపంతో మారుస్తారు. రెండోది ఉందని మీరు ఖచ్చితంగా నమ్మిన ఫైల్ను సూచిస్తుంది, అందుకే ఫైల్ పేరు కంటే ప్రొఫైల్ డైరెక్టరీ ముఖ్యం.
దాన్ని ప్రారంభించి, ఆపై ఆ ఇన్స్టెన్స్ జర్నల్ చదవండి
మీరు ఇప్పుడే పరిశీలించిన ఇన్స్టెన్స్ను ప్రారంభించండి, ఎందుకంటే మొత్తం unit లాగ్లో టన్నెల్ లోపాలు ఉండవు. ఆపై ఈ బూట్ జర్నల్ చదివి అదే క్రమంలో కాన్ఫిగరేషన్ లోపం, ఫైల్ యాక్సెస్ లోపం, కనెక్షన్ లోపం వెతకండి, ఎందుకంటే ఒక్కొక్కటి ప్రారంభంలో వేరే దశలో విఫలమవుతుంది.
sudo systemctl start [email protected]
journalctl -u [email protected] -b
ప్రారంభించడం, ప్రారంభించి ఉంచడం వేర్వేరు నిర్ణయాలు: start unitను ఇప్పుడు నడుపుతుంది, enable తదుపరి బూట్ను ఏర్పాటు చేస్తుంది, enable --now రెండూ ఒక అడుగులో చేస్తుంది. daemon-reload unit నిర్వచనాలను మళ్లీ చదువుతుంది, నడుస్తున్న ప్రాసెస్ను పునఃప్రారంభించదు, సవరించిన ప్రొఫైల్ను వర్తింపజేయదు. ప్రొఫైల్ మార్చిన తర్వాత ఇన్స్టెన్స్ను పునఃప్రారంభించండి, ఎందుకంటే ఫైల్ను మళ్లీ చదివేది అదే.
అదే టన్నెల్పై రెండో మేనేజర్ను పెట్టవద్దు
NetworkManager, OpenVPN 3 సెషన్ మేనేజర్లు తమ సొంత కనెక్షన్ స్థితిని కలిగి ఉంటాయి, వాటిలో ఒకదాని పక్కన systemd ఇన్స్టెన్స్ ఉంటే అదే టన్నెల్పై ఇద్దరు యజమానులు అవుతారు. లక్షణం ఏమిటంటే టన్నెల్ పైకి వచ్చి కొన్ని సెకన్ల తర్వాత భర్తీ చేయబడటం, లేదా ఆగి ఉండటానికి నిరాకరించడం. డెస్క్టాప్ కోసం మీ పంపిణీ డాక్యుమెంట్ చేసే మేనేజర్ను ఎంచుకోండి, సర్వర్పై systemdను ఉద్దేశపూర్వకంగా ఉపయోగించండి.
ఇన్స్టెన్స్ ప్రారంభించే ముందు ఇప్పటికే యజమాని ఉన్నారా తనిఖీ చేయండి. డెస్క్టాప్ యాప్లెట్ కనెక్షన్ చూపినప్పుడు, మీరు ప్రారంభించే ఇన్స్టెన్స్ దాన్ని పూర్తి చేయడానికి బదులు దానితో పోటీపడుతుంది. రెండింటినీ నడిపి క్రమం నిలుస్తుందని ఆశించడానికి బదులు మీరు ఉపయోగించని మేనేజర్ను నిలిపివేయండి. ఆ ఘర్షణే టన్నెల్ స్థాపించబడి, తర్వాత మీరు ఎప్పుడూ ప్రారంభించని ప్రాసెస్ దాన్ని పగలగొట్టే జర్నల్లను కూడా వివరిస్తుంది.
మూల ప్రశ్నకు ఇన్స్టెన్స్ పేరు, అది చదివిన ఫైల్, విఫలమైన జర్నల్ పంక్తితో సమాధానం ఇవ్వండి. systemd ఏకీకరణ గురించి OpenVPN నోట్లు టెంప్లేట్ లేఅవుట్ను, ఇన్స్టెన్స్ పేరు పరిష్కరించబడే ఫైల్ మ్యాపింగ్ను వివరిస్తాయి.