OpenVPN ప్రారంభం కావడం లేదు: కాన్ఫిగ్ కాదు, మొదటి పంక్తిని చదవండి

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

అక్కడికి మూడు చదవడం-మాత్రమే కమాండ్లు చేరుస్తాయి: journalctl -u openvpn@server -b --no-pager మొదట, systemctl status openvpn@server రెండవది, మరియు UDP శ్రోతలకు, వాటి యజమానులకు ss -lunp.

మొదటి పంక్తి శాఖను ఎంచుకుంటుంది

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

అసలు పంక్తిని దాచే రీట్రై లూప్ పై కన్ను వేయండి. పునఃప్రారంభ విధానం ఉన్న యూనిట్ మొదటి వైఫల్యాన్ని ఒకేలాంటి డజన్ కింద పాతిపెట్టగలదు, కాబట్టి యూనిట్ ప్రకారం ఫిల్టర్ చేసి పై నుంచి చదివే journalctl -b తోక కంటే మేలు.

1194 పోర్టును ఇంకా ఎవరు పట్టుకున్నారు

నిందితుడు సాధారణంగా ఎవరో ఉద్దేశపూర్వకంగా కాన్ఫిగర్ చేసిన రెండవ సర్వర్ కాదు. మరో టెర్మినల్లో ఇంకా సజీవంగా ఉన్న చేతితో ప్రారంభించిన క్లయింట్, అనుకోకుండా అదే పోర్టును ఎంచుకున్న రెండవ ప్రొఫైల్, లేదా దాని సొంత టన్నెల్ 1194ని పట్టుకున్న విక్రేత బండిల్ను ఆశించండి. సాకెట్ యజమాని ss -lunp లో కనిపిస్తాడు; ఒక యూనిట్ బాధ్యత వహిస్తుందో లేదో తెలుసుకోవడానికి ఆ PIDని systemctl status కి ఇవ్వండి. సిగ్నల్తో కాకుండా దాని సొంత నియంత్రణ మార్గం ద్వారా దాన్ని తీసేయండి.

యూనిట్ నిర్వహిస్తున్న ప్రాసెస్కు ఇచ్చే సిగ్నల్ సాధారణంగా పునఃప్రారంభాన్ని రేకెత్తిస్తుంది, అదే వైఫల్యం కొద్దిసేపటికి కొత్త సమస్యలా మళ్లీ కనిపిస్తుంది. యూనిట్ కోసం systemctl stop వాడండి, విక్రేత ఇన్స్టాల్ కోసం బండిల్ సొంత సేవా కమాండ్ను, సిగ్నల్ను ఆ షెల్లో మీరు చేతితో ప్రారంభించిన దానికి మాత్రమే వాడండి.

శుభ్రపరిచిన తర్వాత మిగిలిన యూనిట్లు

శుభ్రపరచడం బైనరీలను తొలగిస్తుంది; చేతితో రాసిన యూనిట్ ఫైళ్లు, సాధారణంగా /etc/systemd/system కింద, దాన్ని తట్టుకుంటాయి. Systemd తర్వాత ఇక లేని మార్గాన్ని చూపే యూనిట్ను మళ్లీ ప్రయత్నిస్తుంది, సందేశం నిన్నటి తొలగింపు గురించి కాదు, ఆ లేని ఫైల్ గురించి. systemctl status యూనిట్ ఫ్రాగ్మెంట్ మార్గాన్ని పైన చూపుతుంది, కాబట్టి ఏదైనా తొలగించడానికి ముందు dpkg -S తో దాన్ని తనిఖీ చేయండి. అనాథ మారిపోయాక, systemctl daemon-reload మరియు systemctl reset-failed స్థితిని శుభ్రం చేస్తాయి; లేకపోతే తర్వాతి ప్రతి స్థితి తనిఖీ దాన్ని వారసత్వంగా పొందుతుంది.

which openvpn /usr/local కింద ఏదో సమాధానం ఇచ్చినప్పుడు, అమలులో ఉన్న బైనరీ apt నుండి కాదు, విక్రేత ఇన్స్టాలర్ నుండి వచ్చింది. అలాంటి ఇన్స్టాలర్ సాధారణంగా దాని సొంత శ్రోతను, సొంత బూట్ ఎంట్రీని, సొంత కాన్ఫిగ్ డైరెక్టరీని తెస్తుంది, కాబట్టి కనిపించే కమాండ్ను తొలగించినా సాకెట్ ఆక్రమించబడి ఉంటుంది.

విక్రేత డాక్యుమెంట్ చేసిన విధంగా దాన్ని అన్ఇన్స్టాల్ చేయండి, ss -lunp తో పోర్ట్ ఖాళీగా ఉందని నిర్ధారించండి, అవసరమైతే మాత్రమే పంపిణీ క్లయింట్ను జోడించండి.

మళ్లీ ప్రయత్నించే ముందు స్థితిని స్థిరపరచండి

దాని నుండి నిర్ణయాలకు రాకముందు విఫల స్థితిని శుభ్రం చేయండి: systemctl reset-failed కౌంటర్లను తొలగిస్తుంది, తర్వాత systemctl status యూనిట్ చరిత్రను కాదు, దాని ప్రస్తుత స్థితిని నివేదిస్తుంది. ఒకసారి ప్రారంభించి, బాక్స్ మొత్తం స్థితిని కాదు, ఆ ఇన్స్టాన్స్ సొంత లాగ్ను చదవండి. టన్నెల్ ఏమీ మోయనప్పుడు యాక్టివ్గా నివేదించే యూనిట్ వేరే సమస్య, మరియు చాలా సాధారణమైనది. బగ్ నివేదికల్లో రెండూ కలిసిపోతాయి, ఎందుకంటే రెండూ వినియోగదారు VPN పనిచేయడం లేదు అని చెప్పడంతో ముగుస్తాయి.

మీరు తీసుకున్న శాఖను గుర్తుంచుకోండి: పోర్ట్ ఘర్షణ, లేని బైనరీ, లేని కాన్ఫిగ్. తదుపరి సంఘటనను వేగంగా గుర్తిస్తారు.